鸿迁智评（ArkMigrate-Eval）

作品简介

鸿迁智评（ArkMigrate-Eval） 面向“基于大模型 Coding Agent 的复杂移动应用自动迁移与评测”赛题，选择“迁移 Benchmark 与评测体系设计”方向，提供一套用于 Android / iOS 应用向 OpenHarmony / HarmonyOS ArkTS 迁移的评测与对照实验框架。框架 Schema 面向 Android 与 iOS 迁移任务设计；初赛真实模型证据来自 SWE-OpenHarmony 的 Android A2H track。

本作品重点解决“如何客观评估迁移方案”的问题：通过场景级 Benchmark、结构化 Context 消融实验、可复现评分指标和报告生成能力，量化比较不同 Coding Agent、不同迁移 Pipeline、不同上下文组织方式在复杂移动应用迁移任务中的效果。

作品关注的迁移难点包括：

Ability 架构差异：Android Activity / Service、iOS ViewController 到 UIAbility / ExtensionAbility 的语义适配；
安全与权限模型重构：运行时权限、module.json5 权限声明和调用行为一致性；
复杂应用链路：多页面导航、状态管理、数据库持久化、网络请求、后台任务、媒体处理、多模块调用；
OpenHarmony 特有能力：分布式数据、软总线、跨设备协同等能力的合理采纳与评估；
Agent 长链路稳定性：Plan、调用链、源码片段、依赖元信息等 context 组件对迁移效果和 token 成本的影响。

项目已具备静态评测闭环，并在决赛阶段增加真实构建与受限自动修复，兼容 SWE-OpenHarmony Benchmark 原型：

Benchmark Schema、10 个 synthetic 场景样例，以及 SWE-OpenHarmony release/JSONL Adapter；
spec_only、spec+plan、spec+plan+callchain、full_source、structured_priority_context 等 context 配置；
deterministic mock agent，便于无模型密钥时复现实验；
OpenAI-compatible 模型接口，便于接入兼容 /v1/chat/completions 的大模型服务；
多维度 evaluator，输出通过率、综合分、token 用量、错误类型和级联失败标记；
JSON、CSV、Markdown 和 HTML Dashboard 四种报告格式；
自动生成可离线打开的 HTML 实验仪表盘，展示 Context 质量/成本和 case 失败原因；
在外部提供 matrix/Hypium 结果后，按 SWE-OpenHarmony 口径汇总构建率、动态测试、Diff 产出率、Token、耗时和成本；
从 Git base_commit 进行预算受控的相关源码检索，不读取参考提交；
将模型生成的完整文件确定性转换为标准 Git unified diff，减少模型补丁格式错误；
unified diff 格式、patch 应用性、ArkTS 结构、权限声明和生命周期静态检查；
重复实验、成对 context 对比、bootstrap 置信区间与运行环境清单。

决赛交付物

src/：可安装运行的 Python CLI 源码；
tests/：单元测试、集成测试和复现入口；
demo/index.html：无需安装、无需网络、无需模型密钥的离线迁移评测台；
demo/evidence/：决赛 A2H 真实模型结果、模型产物、报告和补丁验证证据；
docs/：项目说明书、项目创新说明、成员贡献说明、人工智能及第三方工具使用说明 PDF；
presentation/：决赛 PPT 和演示视频；
根目录 作品原创承诺书.pdf：官方模板填写件，提交前请核对签名/盖章状态。

模型密钥、SDK 路径、设备序列号、SWE-OpenHarmony 外部数据及下游应用仓库不进入本仓库。

核心结果速览

初赛实验在 3 个 A2H case 上比较 3 种 Context，共完成 9 次 qwen3-coder-flash 真实调用：

structured_retrieved_context 的平均代理分为 0.834，相对 spec_only 的 0.732 提升约 **13.9%**；
ArkTS 产物完整度由 33.3% 提高到 **100.0%**，调用链完整率由 84.2% 提高到 **87.5%**；
代价是平均 Token 增加约 **199.5%**、平均耗时增加约 **138.7%**，单位 Token 得分下降约 **61.9%**；
三组硬门槛失败率均为 **100%**，主要缺口为返回导航生命周期实现不完整。

因此，本项目的初步结论不是“Context 越多越好”，而是相关源码能够提高质量上限，但需要按需检索控制成本。上述编译、功能和调用链数值均为确定性静态代理。

决赛阶段真实结果

决赛首轮对 SWE-OpenHarmony 的 A2H page-15 共 15 个任务分别执行一次 structured_retrieved_context 真实模型调用；其中 3 个代表任务另执行 spec_only 对照，另对 1 个超时任务做 1 次定向重试。结果位于 demo/evidence/，每个运行目录包括 results.json、run_manifest.json、模型原始 JSON、报告和补丁验证记录。

15 个优化 Context 任务中，14 个首轮真实调用返回了可验证补丁；1 个任务首轮超时，重试后成功返回；
14 个有效首轮产物以及重试产物均通过 unified diff 格式检查和 git apply --check；
展示快照使用当前确定性评测器重算：15 个优化 Context 的平均代理分为 0.840，严格硬门槛 2/15 通过，平均 10,688 Tokens；3 个配对 spec_only 的平均代理分为 0.645，0/3 通过，平均 2,826 Tokens。两组样本规模不同，不能替代正式统计结论；
代理分最高的代表性结果包括 readyou-accounts 0.961、tasks-task-editor 0.945、catima-barcode-selector 0.943；其中只有同时满足调用链与功能代理门槛的结果才标记为通过；
breezy-card-display 首轮超时，重试后代理分为 0.827；补丁和 HAP 构建通过，但因拖拽持久化与配置子页链路缺失而未通过功能硬门槛；
所有数值均标记为 hidden_dynamic_proxy_only。赛事方隐藏 Hypium 测试、最终评测入口和指定 SDK 未提供，因此本项目不声称取得官方隐藏测试成绩。

初赛的 3×3 Context 实验仍作为历史基线单独引用：structured_retrieved_context 平均代理分 0.834，spec_only 为 0.732，平均 Token 增加约 199.5%，硬门槛通过率为 0%。决赛结果不与初赛结果混合统计。

批量构建与自动修复

本地新增实验位于构建与修复报告，覆盖 15 个任务、11 个仓库、18 个候选。环境为 DevEco 6.1.1.290、SDK 6.1.1.125/API 24，不是赛事指定环境。

验证对象	数量	构建/HAP 通过	页面接入校验通过
未修改基线工程	11 仓库	11/11	不作为迁移指标
`spec_only` 首轮	3 候选	3/3	1/3
结构化检索首轮	15 候选	8/15	7/15
结构化检索 + 有限修复	同 15 候选	8/15	7/15

主批共 10 次修复调用；接入通过率没有提升，优化 Context 平均 Token 从 10,688 增至 17,119。仅 3 个同任务 Context 配对样本，不能将全体 15 个优化结果与 3 个 baseline 直接作统计优劣结论。OHPM 安装失败率为 0；失败分类、耗时、成本、均值/标准差和探索性 Bootstrap 区间见 JSON/CSV 报告。

另外保留 Anki 两轮自动修复 → 独立干净基线复建成功的补充案例：修复权限声明和缺失资源，页面主体沿用原工程。它来自校验器调试批次，仅证明修复闭环可执行，不计入主批成功率。该批模型修复调用合计 12 次（主批 10 次、补充批 2 次），独立复验没有调用模型。

工程可打包仍不等于新增页面参与编译，更不等于功能迁移完成。接入校验已识别错误目录和未注册页面；HAP 字节码路径标记只是静态证据，动态功能指标继续保持未知。主批执行器源码由 engine-snapshot.py 与 SHA256 固定；当前版本又增加资源上下文和非法响应反馈重试，单元测试已验证，但未据此改写主批实测成绩。

build-experiment 复用保存的真实模型产物，不重新执行首轮生成。每个候选在任务的 base_commit 上创建独立 Git 工作树，依次执行补丁检查、OHPM 安装、Hvigor clean/assembleHap、页面注册和 HAP 字节码路径检查。失败时将任务说明、当前源码和编译/接入错误反馈给模型，最多修复 N 轮。

python -m makememoryempty build-experiment `
  --benchmark documents/SWE-OpenHarmony `
  --repos-dir documents/SWE-OpenHarmony/repos `
  --artifacts-dir demo/evidence `
  --output runs/my-build-ablation `
  --model-config config/keys.json --model qwen3-coder-flash `
  --max-repairs 2 --max-calls 10 --build-timeout 300 --model-timeout 180

只构建、不调用模型时使用 --max-repairs 0 --max-calls 0，不需要模型密钥。--case-id 和 --contexts 可缩小范围。输出目录必须不存在，避免覆盖证据；运行会保留候选工作树，故应预留磁盘空间。

结果包括每轮 Agent 输入、模型响应及 usage、累计补丁、错误分类、构建日志和最终状态，以及 results.json、analysis.json、summary.csv、report.md。修复 Agent 不执行模型提供的命令，禁止修改测试、构建配置、SDK/依赖配置和签名材料；不修复网络/SDK等基础设施错误。模型返回非法路径或冲突的写入/删除操作时拒绝应用。

first_round 与 repair_loop 是同一产物的首轮/有限修复策略对照，不是两批独立模型生成。spec_only 与优化 Context 仅在有相同任务时配对比较。当前修复同时使用编译错误和接入反馈，不能单独声称某个反馈组件带来了提升；尚未单独运行 dependency_aware_context 消融。

未修改的上游工程可另行验证，用于辅助失败归因：

python tools/build_repository_controls.py `
  --benchmark documents/SWE-OpenHarmony `
  --repos-dir documents/SWE-OpenHarmony/repos --output runs/base-controls

离线展示台的“构建与自动修复”页展示本地实验，不连接模型。静态代理分、工程构建、页面接入检查和动态功能结果分别标注；页面入包不等于 UI 可达。设备与隐藏测试未执行时，动态指标保持未知。

自动修复配对复验

此前另完成一批自动修复配对补充实验：预选 Catima、Tasks、ReadYou 三个历史失败任务，两组都从同一原模型补丁重新开始，每个任务最多两轮，共新增 12 次 qwen3-coder-flash 修复调用，SDK 为本机 API 24。

现有错误反馈对照组：构建与接入终态 0/3；
诊断优先源码＋本机 SDK 依据组：1/3，Tasks 两轮修复后成功，相同累计补丁在干净基线独立复建通过，复验没有调用模型；
Catima 第二轮曾因 Windows 深路径工具错误中断，相同响应短路径重放后仍因资源 JSON 错误失败；ReadYou 的 ArkUI 错误仍未修复。中断和失败证据均保留；
诊断组平均修复 Token 增加约 5,656/任务；只有一个任务改善，差值的探索性 95% 区间为 0 至 100 个百分点，不能宣称稳定优势，不修改历史 15 任务成功率；
CLI 增加 --repair-feedback legacy / --repair-feedback diagnostic_context。诊断记录包括失败阶段、报错文件、字段、源码预算和本机 SDK 摘录来源/哈希；不读取参考答案，不分发完整 SDK。

离线展示台的“构建与自动修复”可切换历史主批与本轮定向复验，并查看诊断依据、工具中断补建及逐轮模型响应。无需 SDK 的证据校验：

python tools/verify_repair_followup.py

本批设备与 Hypium 未执行，成功仅指真实构建和页面入包。与以下 Breezy 辅助工程修复运行案例分开统计；PPT、PDF 和视频本轮未更新。

真实运行案例

直接打开离线展示台，默认展示 Breezy 的完整案例：原模型输出 → 工程接入后构建通过 → 设备发现三项功能缺口 → 辅助工程修复 v2.1 → API 23 模拟器复验。可查看原接入版与 v2.1 对照、四版完整补丁、失败和构建日志、真实截图及已有演示视频；不依赖网络或模型密钥。

队友环境为 macOS、DevEco 6.1.0.860、SDK 6.1.0.105/API 23、Phone 系统 6.1.0.115/API 23。未签名 HAP 已实际安装启动，入口、删除/恢复、返回、长按重排、持久化及 Daily/Hourly 子页交互完成选定检查。这里只是一个工程修复案例，不是官方隐藏成绩或完整功能等价；不计入上述自动 Agent 和 API 24 构建消融统计。

证据位于 demo/handoff/breezy-card-display/engineering-v2.1/；232 个文件的 SHA256、基线和补丁/HAP 关联由 runtime-evidence.json 索引并自动验证。本机核验了返回证据，未重新执行设备测试。复现命令、版本选择和限制见交接与运行说明。

2026-10-06 新增 10.6-exp 独立复验批次，规范证据位于 demo/handoff/breezy-card-display/10.6-exp/。162 个原始文件哈希、42 组截图/UI 树/日志及新 HAP 已核验；队友在 API 23 专用模拟器上完成安装、启动及 14 组指定交互检查。使用相同 v2.1 工程补丁，无新增模型调用或应用修复，不计入 Agent 成功率，不补填 Hypium 或功能等价指标。

展示台默认使用该轮设备画面，可切换历史 v2.1；已有视频仍来自历史运行，本轮未更新 PPT、PDF 或视频。队友端浏览器实际操作尚未执行，本机已另行完成离线桌面/手机视口检查，两种验证分开记录。本轮证据说明给出校验入口：

python tools/verify_runtime_recheck.py

无需模型、SDK 或设备。最终收尾事项见决赛缺项与完成状态；正常克隆无需再次导入下载包。

目录结构

.
├── benchmarks/
│   └── synthetic/cases.json      # 自建场景级 benchmark 样例
├── src/makememoryempty/          # 核心实现代码
│   ├── cli.py                    # 命令行入口
│   ├── agent.py                  # mock / model agent 调用封装
│   ├── context.py                # context ablation 配置与构造
│   ├── dataset.py                # benchmark 加载与校验
│   ├── evaluator.py              # 多维度评分逻辑
│   ├── official_metrics.py       # SWE-Harmony 官方指标聚合
│   ├── patch_builder.py          # 完整文件到 Git patch 的确定性转换
│   ├── source_retrieval.py       # base_commit 源码检索
│   ├── static_analysis.py        # OS 语义与 patch 静态检查
│   ├── prediction_validation.py  # prediction/patch 应用性检查
│   ├── providers.py              # mock 与 OpenAI-compatible provider
│   ├── reports.py                # JSON / CSV / Markdown 报告输出
│   ├── dashboard.py              # 无服务器 HTML 实验仪表盘
│   └── runner.py                 # ablation 运行主流程
├── demo/                         # 离线展示台与决赛证据快照
│   ├── index.html
│   ├── snapshot.json
│   └── evidence/
├── docs/                         # 决赛要求的四份 PDF
├── presentation/                 # 决赛 PPT 与演示视频
├── experiments/                  # 初赛真实模型消融结果
├── tests/                        # 单元测试与集成测试
├── pyproject.toml                # Python 项目配置
├── 技术报告.md                    # 设计与实验技术报告
├── 作品原创承诺书.pdf             # 根目录提交材料
└── README.md                     # 作品简介与运行说明

环境要求

Python 3.10 及以上版本；
OpenAI-compatible API 地址、模型名称和密钥；
真实构建：本地 DevEco Studio、HarmonyOS/OpenHarmony SDK 和 Hvigor；版本需按实验清单记录，赛事方尚未指定 SDK；
动态设备测试：模拟器或设备以及 hdc。

仓库自带的 synthetic Benchmark、mock Agent、静态评测和报告生成不需要模型密钥、SDK 或设备，可在干净克隆后直接运行。

运行说明

1. 安装依赖

在仓库根目录执行：

python -m pip install -e .[dev]

安装后可使用新的命令入口：

arkmigrate-eval --help

也可使用模块方式运行：

python -m makememoryempty --help

2. 60 秒快速开始

以下命令只使用仓库内置的 10 个 synthetic case 和 mock Agent，不需要外部数据、模型密钥或 SDK：

arkmigrate-eval validate --benchmark benchmarks/synthetic/cases.json

arkmigrate-eval run `
  --benchmark benchmarks/synthetic/cases.json `
  --contexts spec_only structured_priority_context `
  --limit 2 `
  --provider mock `
  --output runs/quick-start

预期首先看到：

OK: loaded 10 benchmark cases from benchmarks/synthetic/cases.json

运行结束后，可直接打开 runs/quick-start/dashboard.html 查看 Context 质量、成本和 case 缺口。mock 结果只验证软件流程，不作为比赛模型效果证据。

3. 打开决赛离线展示台

直接双击 demo/index.html，或在浏览器地址栏打开该文件。展示台不启动服务器、不访问模型服务、不保存密钥；所有内容来自 demo/evidence/ 的实验快照。可选择任务和 Context，查看 SPEC、检索源码摘要、迁移计划、生成文件、Git Patch、失败原因、Token、耗时和补丁验证状态。

4. 准备 SWE-OpenHarmony 外部数据（可选）

SWE-OpenHarmony release、11 个 A2H 应用仓库及模型配置不随本仓库提交。需要复现 A2H 实验时，请先从 SMAT/SWE-OpenHarmony 获取赛事负责人提供的 release，并按以下结构放置：

documents/SWE-OpenHarmony/
├── metadata/
├── specs/
├── hypium/
├── trajectories/
├── scripts/
└── repos/
    ├── Mihon/
    ├── AnkiDroid/
    └── ...                       # 共 11 个 A2H 目标仓库

若 release 中包含仓库准备脚本，可执行：

python documents/SWE-OpenHarmony/scripts/prepare_repos.py --track a2h-page-15

随后校验数据并查看组成：

arkmigrate-eval validate `
  --benchmark documents/SWE-OpenHarmony `
  --track a2h-page-15

arkmigrate-eval inspect --benchmark documents/SWE-OpenHarmony

完整原型应识别出 65 个任务：incremental-dev-50 50 条、a2h-page-15 15 条；前者公开 190 个评分方法，后者的 Hypium 测试暂不公开。后续所有 documents/SWE-OpenHarmony 命令均假定已经完成本节准备。

5. 运行真实 A2H 实验

模型配置文件只放在本地，不要提交到 Git：

arkmigrate-eval run `
  --benchmark documents/SWE-OpenHarmony `
  --track a2h-page-15 `
  --repos-dir documents/SWE-OpenHarmony/repos `
  --provider openai `
  --model-config config/keys.json `
  --model qwen3-coder-flash `
  --contexts structured_retrieved_context `
  --case-id mihon-more-tab `
  --output runs/local/mihon-more-tab

精确选择任务由 --case-id 提供；任务失败不会影响已完成的其他运行。补丁验证：

arkmigrate-eval validate-predictions `
  --benchmark documents/SWE-OpenHarmony `
  --predictions runs/local/mihon-more-tab/predictions-structured_retrieved_context.jsonl `
  --repos-dir documents/SWE-OpenHarmony/repos `
  --output runs/local/mihon-more-tab/patch-validation.json

6. 查看内置 Context 配置

arkmigrate-eval list-contexts

内置配置包括：

spec_only
spec+plan
spec+plan+callchain
full_source
structured_priority_context
spec+retrieved_source
structured_retrieved_context

spec+retrieved_source 和 structured_retrieved_context 需要预先准备应用仓库，并通过 --repos-dir 指定路径。检索器使用 git show <base_commit>:<path> 读取源码，不 checkout 工作区，也不会读取 final_commit。

5. 使用 mock Agent 运行完整评测

无需 API key 即可运行：

arkmigrate-eval run `
  --benchmark benchmarks/synthetic/cases.json `
  --output runs/demo `
  --provider mock

生成文件：

runs/demo/results.json：完整机器可读结果；
runs/demo/results.csv：便于表格分析的结果；
runs/demo/report.md：Markdown 实验报告；
runs/demo/dashboard.html：可直接用浏览器打开的实验仪表盘；
runs/demo/agent_outputs/<context>/<case>.json：每次 Agent 的计划、生成文件和 token 记录；
runs/demo/predictions-<context>.jsonl：当模型返回 model_patch 时生成的 SWE-OpenHarmony 提交文件；
runs/demo/analysis.json：分组统计、成对 Context 对比和置信区间；
runs/demo/run_manifest.json：模型、Context、重复次数、源码预算、运行环境和代码版本。

6. 复现初赛真实模型实验

以下命令与“真实模型实验”一节报告的参数一致：3 个 case、3 种 Context、1 次重复，共 9 次真实模型调用。

arkmigrate-eval run `
  --benchmark documents/SWE-OpenHarmony `
  --track a2h-page-15 `
  --repos-dir documents/SWE-OpenHarmony/repos `
  --contexts spec_only spec+plan+callchain structured_retrieved_context `
  --source-max-files 6 `
  --source-max-chars 12000 `
  --limit 3 `
  --repetitions 1 `
  --provider openai `
  --model-config config/keys.json `
  --model qwen3-coder-flash `
  --model-timeout 180 `
  --output runs/a2h-context-ablation-preliminary

该命令会产生真实模型费用。扩大 case 数或重复次数前，请先确认服务额度，并保持模型参数和源码预算一致。

7. 接入 OpenAI-compatible 模型服务

支持任何兼容 /v1/chat/completions 的模型服务：

$env:OPENAI_BASE_URL="https://your-compatible-endpoint.example/v1"
$env:OPENAI_API_KEY="替换为实际密钥"
$env:OPENAI_MODEL="替换为实际模型名"

arkmigrate-eval run `
  --benchmark benchmarks/synthetic/cases.json `
  --output runs/model `
  --provider openai `
  --contexts structured_priority_context

也可以使用本地 JSON 配置文件。

模型名也可以通过命令行覆盖，适合先用轻量模型做 smoke test：

arkmigrate-eval run `
  --benchmark documents/SWE-OpenHarmony `
  --track a2h-page-15 `
  --repos-dir documents/SWE-OpenHarmony/repos `
  --provider openai `
  --model-config config/keys.json `
  --model qwen3-coder-flash `
  --model-timeout 180 `
  --contexts structured_retrieved_context `
  --limit 1 `
  --output runs/a2h-smoke

--model-timeout 控制单次请求超时，默认 180 秒。大源码 Context 的生成时间可能超过 60 秒，正式实验应记录统一的 timeout，超时 case 会被隔离为agent_error，不会中断整批任务。

推荐模型返回 JSON，字段包括：

migration_plan：迁移计划步骤数组；
generated_files：仓库相对路径到完整文件内容的映射；框架也兼容常见的 [{"path": "...", "content": "..."}] 数组形式；
notes：模型补充说明数组；
model_patch：可应用到任务 base_commit 的 unified diff，正式 Benchmark 运行时应提供。

如果模型返回非结构化文本，框架仍会保存原始输出，并按原始迁移产物进行代理评分。对于仓库任务，只要模型返回 generated_files，框架会基于任务 base_commit重新构造标准 Git patch，避免将 Markdown 或非 Git 格式 diff 误当作正式提交物。

8. 运行测试

python -m pytest

当前测试覆盖：

Benchmark Schema 与 SWE-OpenHarmony Adapter；
依赖推断、Context 构造与模型配置；
mock Provider、结构化输出和 Token 统计；
源码检索、语义 Evaluator 与静态分析；
确定性 Patch 构建与 git apply --check；
Prediction 验证、统计分析、报告和 CLI 集成。

当前预期结果为：

90 passed

真实模型实验

初赛小样本实验使用 qwen3-coder-flash，选择 3 个公开 A2H case： mihon-more-tab、mihon-statistics、anki-card-browser。每个 case 分别运行：

spec_only；
spec+plan+callchain；
structured_retrieved_context。

共完成 9 次真实模型调用，无 Agent 请求错误。每个 case 仅运行 1 次，因此本实验属于初赛小样本工程验证，不能据此宣称总体统计显著性。实验结果保存在 experiments/preliminary，其中dashboard.html 可直接打开用于演示。

可复查证据包括：

results.json：逐 case 代理指标与失败类型；
analysis.json：分组统计、成对比较和置信区间；
run_manifest.json：模型、Context 和源码预算；
predictions-spec_only.jsonl、predictions-spec+plan+callchain.jsonl、predictions-structured_retrieved_context.jsonl：Patch 验证输入。

Context	平均代理分	静态编译代理	功能等价代理	调用链完整率	ArkTS 产物完整度	生命周期正确率	平均 Token	平均耗时
`spec_only`	0.732	100.0%	88.9%	84.2%	33.3%	0.0%	2,847	15.60s
`spec+plan+callchain`	0.711	91.7%	65.7%	69.3%	66.7%	0.0%	2,809	13.29s
`structured_retrieved_context`	0.834	100.0%	85.8%	87.5%	100.0%	33.3%	8,528	37.24s

相对 spec_only，结构化检索上下文的平均代理分提升 0.102（约 13.9%），ArkTS 产物完整度提升 66.7 个百分点，平均缺口数由 1.67 降至 1.33；代价是 token 增加约 199.5%、平均耗时增加约 138.7%。这说明结构化源码检索提高了质量上限，但不是最省 token 的方案。spec+plan+callchain 在该小样本中没有稳定超过spec_only，提示调用链需要与相关源码按需组合，而不是单纯增加提示文字。

三组方案的硬门槛失败率均为 100%，主要缺口是返回导航生命周期实现不完整；个别结果还存在 @Component 缺少 build() 或 Patch 格式错误。因此，最高代理分不表示应用已经通过真实编译或能够运行，这些失败本身也是评测框架识别迁移风险的结果。

独立补丁验证结果：spec_only 和 spec+plan+callchain 的格式率、应用率均为100%；structured_retrieved_context 的格式率为 66.7%，格式有效补丁的git apply --check 通过率为 100%。详细实验方法、指标定义和限制见技术报告.md。

项目 pytest 仅收集 tests/；documents/SWE-OpenHarmony/hypium/ 中的设备测试由官方 runner 执行，不参与本地 Python 单元测试收集。

9. 汇总 SWE-OpenHarmony 官方指标

当迁移 Agent 已输出 Patch，并经 SWE-OpenHarmony matrix runner/Hypium runner 评测后，可按原型的 Leaderboard 公式统一汇总：

arkmigrate-eval score-official `
  --hypium-results results/hypium/agent_model/results.json `
  --matrix-summary results/matrix/run_id/matrix_summary.json `
  --track incremental-dev-50 `
  --output runs/official-metrics.json

10. 检查外部环境

arkmigrate-eval doctor `
  --benchmark documents/SWE-OpenHarmony `
  --track a2h-page-15 `
  --repos-dir documents/SWE-OpenHarmony/repos `
  --model-config config/keys.json `
  --model qwen3-coder-flash

该命令只报告凭据是否配置，不输出密钥内容；同时检查 Git、Node.js、hvigor、hdc、SDK 环境变量和各应用仓库。当前仅执行 A2H 时应带上 --track a2h-page-15，否则 doctor 会同时检查incremental-dev-50 所需的其他仓库。

11. 校验真实 Agent Patch

arkmigrate-eval validate-predictions `
  --benchmark documents/SWE-OpenHarmony `
  --predictions experiments/preliminary/predictions-structured_retrieved_context.jsonl `
  --repos-dir documents/SWE-OpenHarmony/repos `
  --track a2h-page-15 `
  --output runs/recheck/patch-validation-structured-retrieved.json

校验器会创建临时 detached Git worktree，在对应 base_commit 上执行 git apply --check，不会修改主工作区。

构建验证与限制

原环境采用 SWE-OpenHarmony 发布包的 6.1.0/API 23 基线；2026-10-05 本机已升级到 DevEco 6.1.1.290、SDK 6.1.1.125/API 24，工程 compatible/target 仍为 API 22。Mihon 保留原环境的构建证据；Breezy 原接入版及 v2.1 分别保存源码/HAP 和运行记录。队友已在 API 23 Phone 验证 v2.1；不将其混入本机 API 24 构建实验。HAP 未签名，真机验证未执行。

Breezy 原始候选未注册新页面，早期 HAP 成功没有覆盖该页面。接入后首次编译暴露三个 SDK 接口错误，修复后重新构建通过。原始代理分和模型输出继续保留；接入修复版单独展示，不计入新的模型成功率。

队友操作入口见国内模拟器验证交接。下载本仓库后，无需模型密钥即可准备工程：

python -m pip install -e .
python tools/prepare_handoff.py --variant engineering-v2.1 --workspace runs/handoff --build --deveco-home "E:\deveco\DevEco Studio"

国内优先使用原定 API 23 基线复验；若使用其他 SDK，按实际版本回传。签名私钥、设备标识和本机配置不提交仓库。

项目提供统一的真实构建入口，自动使用 DevEco 自带的 Node、OHPM、Hvigor 和 hdc，并在输出目录保存 build-report.json 与 build.log：

arkmigrate-eval build `
  --repo documents/SWE-OpenHarmony/repos/Mihon `
  --output runs/build-mihon `
  --deveco-home "E:\deveco\DevEco Studio"

原始单案例构建证据位于 runs/final-2026/builds/，脱敏后随案例复制到 demo/evidence/；新增批量证据位于 tests/validation/build-ablation-v2/。已知限制：A2H 隐藏动态测试不可见，代理分不能替代官方评测；本机构建批次没有设备动态数据，Breezy API 23 队友运行结果单列；API 22 设备、真机和性能未验证；外部 benchmark、完整源码仓库和模型配置不进入提交仓库。

Benchmark 数据说明

当前 synthetic Benchmark 位于：

benchmarks/synthetic/cases.json

每个 case 包含：

源平台：android 或 ios；
场景类型：导航、状态管理、持久化、网络、权限、后台任务、媒体、安全、分布式等；
源码路径与源码片段；
迁移目标；
依赖 metadata；
期望能力；
所需权限和 API；
生命周期语义；
调用链；
OpenHarmony 分布式能力采纳机会；
指标权重。

SWE-OpenHarmony Adapter 支持三种入口：完整 release 目录、suite manifest、track JSONL。它会读取 spec_file 的完整自然语言任务说明，并保留 repo、base_commit、final_commit、hypium_file、fixture 与可见性等溯源信息。其中 final_commit 不会写入模型 Context，防止参考实现泄漏。

Adapter 同时兼容 site/*_flat.jsonl 的 SWE-bench 风格字段，包括 problem_statement、patch、test_cases、FAIL_TO_PASS 和 PASS_TO_PASS。其中参考 Patch 仅保留作离线误差分析与数据 sanity check，不会进入 Agent Context；正式运行仍以 base_commit + problem_statement/spec 为输入。

准备完成后的 documents/SWE-OpenHarmony 原型包含四类核心数据：

metadata/：65 条任务 manifest、仓库地址、基线/参考提交和测试可见性；
specs/：15 条 Android 页面迁移 spec 与 50 条 ArkTS 增量开发 spec；
hypium/：50 条增量开发任务的公开动态测试，A2H 测试隐藏；
trajectories/：多 Agent/模型运行轨迹健康度报告，可用于后续 Agent 行为效率研究。

应用源码不随 release 直接存放，需要根据 metadata/repo_sources.json 克隆到 repos/<repo>，并在每个任务的 base_commit 上运行 Agent。标准提交物是 unified diff Patch，而不是孤立的 ArkTS 文件。

SWE-OpenHarmony 数据与 11 个下游应用仓库遵循各自许可证，本项目不对其重新授权。模型密钥、外部仓库、SDK 和设备信息均由使用者在本地准备，不进入提交仓库。

评测指标

当前 Evaluator 使用确定性代理指标，便于在没有 DevEco/设备时做 Context 消融和预评测：

plan_quality：迁移计划完整度；
dependency_satisfaction：依赖 case 满足情况；
call_chain_completeness：关键调用链覆盖率；
arkts_artifact_completeness：ArkTS / module.json5 产物完整度；
permission_consistency：权限声明与调用需求一致性；
ability_lifecycle_correctness：Ability / 页面生命周期语义覆盖；
static_compile_proxy：ETS 括号、组件 build()、残留 Android import 等结构检查；
functional_equivalence_proxy：功能等价性的轻量代理指标；
distributed_adoption：OpenHarmony 分布式能力采纳情况；
patch_submission_readiness：是否产生官方可接收的 unified diff。

报告会明确标注 proxy_only，避免将代理分数误报为官方成绩。正式对齐 SWE-OpenHarmony 的指标包括：动态功能正确率、SPEC 全通过率、SPEC 至少一项通过率、最终编译率、Diff 产出率、Token、耗时和单 SPEC 成本；其中动态功能正确率是主指标。

仓库级任务采用硬门槛：缺少 unified diff、必要权限、生命周期实现或基本 ArkTS 结构时，即使综合代理分较高也不能标记为通过。

报告按 Provider、Track、Context 分组，并给出相对 spec_only 的成对得分差、Token 差、胜/平/负和 Bootstrap 95% 置信区间。mock 结果只用于验证流程，不能作为比赛实验结论。

Mock 流程预期

使用 mock Agent 运行完整 synthetic Benchmark 时，预期能够观察到：

spec_only 分数最低，常出现调用链缺失、生命周期缺失和级联失败；
spec+plan 相比 spec_only 明显提升；
spec+plan+callchain 能提升调用链完整性；
full_source 能进一步提高 API 与功能代理指标；
structured_priority_context 在当前 synthetic Benchmark 中得分最高，但 Token 成本也更高。

这组结果仅验证评分、报告和消融管线能正常工作，不能引用 mock 分数作为模型优化证据。真实模型静态预评测结论见前文；本机已增加真实 HAP 构建能力，但最终编译与动态功能结论仍以赛事统一环境和官方 Hypium/隐藏测试为准。