design.md

LetsGoal：目标导向的 Agent 自循环框架

痛点 & 洞察

当前已经将 AI 辅助深度应用在日常工作中，典型场景及其工作模式现状为：

• 开发调试：人描述需求 → Agent 编码实现 → 人试跑验证（跑不跑得通、效果对不对）→ 发现 bug 反馈 → Agent 修复 → 人再验证 → ... → 人验收
• 数据采集：人定义采集目标 → Agent 编写/运行采集脚本 → 人检查结果（条数够不够、字段对不对、rank 连不连续）→ 发现问题反馈 Agent 修复 → Agent 重跑 → 人再检查 → ... → 人验收
• 模型调优：人定义调优目标和评测集 → Agent 运行评测 + 归因 → 人检查归因结果（归因对不对、策略合不合理）→ 反馈纠正 → Agent 再调优 → 人再检查 → ... → 人验收

进行一轮抽象，发现不管是开发调试、数据采集还是模型调优，流程结构几乎一样：人把目标交给 AI，AI 执行，人检查结果，发现问题再反馈给 AI 修复——如此反复。

目标 → AI 规划/执行 → 人工检查 → 反馈纠偏 → AI 再执行 → ... → 人工验收 → 完成

痛点：人工在整个过程中基本处于值守状态，随时待命响应反馈，非常低效——也制约了并行任务的数量，一个人同时盯不了几个项目。

但回顾人工在其中的实际作用，主要分两类：

类型	开发调试	数据采集	模型调优	性质
操作反馈	试跑验证、报错反馈、代码重构	检查采集结果、补采指令	检查评测结果、重跑指令	机械性，只是闭合反馈环
方向把控	方案 review、路线选择	采集目标定义、验收标准	调优方向、人工归因纠正	需要判断力，体现人的价值

核心洞察：操作反馈类的工作，人在其中几乎是机械的中转站——完全可以自动化。真正需要人的是方向把控，但这部分也可以聚焦和提效，降低人的投入。当前提效瓶颈：

• 过程不可追溯 — 过程信息和阶段性结论混杂，事后看不清发生了什么
• 介入时机模糊 — 不知道什么时候该介入，要么值守等待，要么错过最佳纠偏窗口
• 决策信息不充分 — 需要做方向判断时，关键上下文淹没在噪音里，缺乏结构化的决策锚点

三者形成恶性循环：不可追溯 → 不敢放手 → 只能值守 → 介入了又信息不足 → 效率低。

目标 & 思路

构建目标导向的 Agent 自循环框架——用户只需给出目标和成功标准，系统自主完成规划、执行、评估、修正和汇报，仅在关键决策点引入人工判断。

Plan（规划）→ Execute（执行）→ Evaluate（评估）→ Repair（修复）→ Report（汇报）

核心设计原则：

1. 操作反馈自动化 — 试跑、验证、修 bug、重构等机械性闭环由系统自动完成
2. 方向把控聚焦 — 人工只在方案 review、路线选择等关键决策点介入
3. 过程可追溯 — 阶段性结论结构化记录，过滤过程噪音
4. 主动通知 — 需要人关注时主动推送，附带决策所需上下文和选项

方案设计

形态：Agent Skill

LetsGoal 以 Agent Skill 为存在形态，集成到宿主 Agent（如 Claude Code）中使用。

为什么是 Skill：

自循环的每一步都是"读状态 → 做判断 → 调工具 → 写状态"，本质是过程知识，skill 天然适合承载。调度能力（定时触发、事件监听、会话管理）由宿主 Agent 提供，不需要自建——Claude Code 的会话管理、cron 调度、飞书事件监听都已有成熟方案，不重复实现。

结构：

LetsGoal/
├── CLAUDE.md                    ← 项目规范（对内）
├── SKILL.md                     ← Skill 入口（被 Claude Code 加载）
├── core/                        ← 共享自循环引擎（通用逻辑）
│   ├── scripts/                 # parse_request / self_loop / types
│   └── references/              # 协议文档
└── directions/                  ← 方向配置（差异点）
    ├── development/DIRECTION.md
    ├── data-collection/
    └── model-tuning/

核心 skill 定义循环逻辑，方向配置定义差异，工具集按需加载。调度层由宿主 Agent 承担，不重复实现。

自循环引擎

Plan → Execute → Evaluate → Repair → Report，五阶段闭环，三个方向通用。

用户输入目标 + 成功标准
  ↓
Plan     解析目标 → 结构化任务定义 → 确认评估标准
  ↓
Execute  调用方向配置的工具执行
  ↓
Evaluate 对照标准评估结果（L0→L1→L2→L3 逐层晋级）
  ↓
  ├─ 通过 → Report
  └─ 失败 → Repair
              ↓
         归因 → 修复 → 回到 Evaluate
              ↓
         无法修复 → Report（升级人工）
  ↓
Report   推送摘要；判断是否需要人工决策
  ↓
  ├─ 通过 → 完成
  └─ 需要继续 → 回到 Execute

每个阶段的具体内容由方向配置定义：

阶段	[[#开发调试]]	[[#数据采集]]	[[#模型调优]]
Plan	功能需求、验收标准、约束	采集目标、范围、频率、验收标准	评测集、目标指标、规范约束
Execute	编码实现	采集脚本/UI 自动化/API 调用	评测执行、归因、策略生成
Evaluate	测试/lint/类型/效果	条数/字段/时效	成功率/指标变化/副作用
Repair	修bug→重构→补测试	重试→补采→降级→升级开发调试	自动调优→回滚
Report	飞书通知：开发结论	飞书通知：采集摘要	飞书通知：调优进展

跨轮记忆：自循环跑多轮后上下文会撑爆，解决方案是状态文件作为跨轮记忆。每轮结束时把关键结论写入结构化文件（迭代摘要、当前分数、失败归因、已尝试方案），下一轮开始时只读摘要，不读完整历史。开发调试方向天然由 Git 解决（commit history 即迭代记录），数据采集和模型调优需要显式设计状态文件。

交互模型

三个方向共享统一的交互通道：

通道	职责	支持的输入形式
飞书机器人	信息输入	直接录入 + 飞书文档链接
终端	信息输入	直接录入 + 飞书文档链接
飞书多维表格	过程记录 + 反馈收集	结构化记录迭代状态，行级评论收集反馈
飞书通知	结果/事件通知	任务完成、异常升级、需要人工决策时推送

两个输入通道同时支持：

• 直接录入：自然语言描述目标、约束和验收标准
• 飞书文档链接：指向已有的需求文档、评测规范、方案设计等，系统自动解析提取

方向差异仅在于使用偏好：开发调试以终端为主入口，数据采集和模型调优以飞书机器人为主入口。但两个通道始终同时可用。

需求输入流

用户只需概括性描述需求，系统负责结构化补充并生成飞书文档，后续拆解确认和迭代记录都在同一份文档中完成。lark-cli 是必须依赖。

飞书文档生命周期：

用户输入需求（概括性描述）
  ↓ 系统结构化 + 补充
系统创建飞书文档（request.md 格式 + stories）
  ↓ 用户确认（可在飞书文档中修改后确认）
进入开发迭代
  ↓ 每轮迭代结束
系统追加迭代记录到文档（只追加不修改）
  ↓ 任务完成
系统追加最终结论到文档

lark-cli 接口：

• lark-cli docs +create --title "..." --markdown "..." — 创建文档
• lark-cli docs +update --doc <id> --mode append --markdown "..." — 追加内容

通用表格结构

各方向共享同一多维表格模式，具体字段因方向而异：

表	用途	说明
Tasks	任务定义和状态	通用字段 + 方向扩展字段
Eval Cases	评测用例和结果	通用字段 + 方向扩展字段
Iteration Runs	每轮执行记录和评分	通用
Feedback	用户反馈和消费状态	行级评论 + 消费幂等
Artifacts	产出物链接	通用

开发调试方向额外使用 Git 追踪代码级变更，多维表格负责任务级状态。

关键机制

以下机制服务于四项核心设计原则，按原则分组。每项机制说明解决什么问题、为什么这样设计。

1. 分层评估与评分判定

服务原则：操作反馈自动化 · 过程可追溯

问题：如果每次迭代都跑全部评估（包括昂贵的端到端检查），失败在不相关的层浪费资源；迭代之间也无法客观比较效果。

设计：L0→L1→L2→L3 逐层晋级，每层失败短路不执行后续。三个方向共享同一评估哲学，各方向定义每层的具体内容：

层级	通用含义	开发调试	数据采集	模型调优
L0	结构/规则检查	lint、格式、类型检查	JSONL schema、字段完整性、rank 连续性	结果格式、字段完整性
L1	单元级验证	单元测试	单步抽取/解析正确性	单 case 正确性
L2	集成级验证	集成测试	页面状态、流程节点、异常样例	batch 级指标变化
L3	端到端验证	e2e / 效果验证	真实 App/Web/API 完整采集链路	全量评测 + 副作用检测

L0-L1 失败时 Agent 自行修复，不需要通知人工。L2-L3 失败时视情况升级。

评分：硬门禁 + 加权软分双轨判定。

• 硬门禁：失败则本轮不通过（具体门禁项由方向配置定义）
• 加权软分：比较不同迭代版本，选择最佳候选
• 默认通过分 min_score=0.92

成功条件：所有硬门禁通过 + 总分达标 + L3 通过 + 产物完整。

失败条件：最大迭代轮次耗尽（默认 10）、连续多轮无改善、环境长期不可用、目标不可判定。

评测集版本化冻结：自循环开始前评估标准必须冻结——否则迭代过程中改了标准，就无法客观比较不同版本的效果。一次任务绑定固定 eval_suite_version，确认前可修改，确认后冻结。需要变更时创建新版本。冻结记录包含 eval_suite_version、eval_suite_hash、confirmed_by、confirmed_at 及冻结快照链接。

2. 自循环迭代

服务原则：操作反馈自动化

问题：评估-修复循环需要稳定收敛，否则会无限振荡或原地打转。

设计：Plan→Execute→Evaluate→Repair→Report 五阶段闭环，每轮版本号自增、状态持久化、失败归因驱动下一轮修复。

1. Run L0 → L1 → L2
2. L0-L2 通过后 Run L3
3. 打分 + 归因失败
4. 修复（Agent 可自行应用，无需每轮人工批准）
5. 记录 diff 和产物，版本号自增
6. 写入状态文件
7. 读取并处理用户反馈（如有）
8. 通知进度
9. 判断是否继续

版本号策略：v<major>.<minor>.<patch>.<revision>，每次文件修改自增 revision，纯评测不自增。

3. 人工介入与反馈消费

服务原则：方向把控聚焦

问题：人应该在什么时候介入？介入时需要什么信息？反馈如何被系统消费、避免重复处理？

设计：

只在四种场景升级人工：

• 方向性决策 — 方案选择、路线纠偏
• 连续自愈失败 — 同一问题修复 N 轮未解决
• 未知异常 — 超出归因分类体系的失败
• 高风险变更 — 发布前确认

介入时提供结构化上下文：当前方案、已尝试方案、各方案利弊、推荐选项及理由——而非让人从零判断。

反馈消费规则：

反馈类型	Agent 决策
correction	apply_patch
strategy	apply_patch
approval	skip
rejection	escalate
pause / stop	escalate
resume	skip

幂等消费：idempotency_key = feedback_id + updated_at + run_id。

4. 经验沉淀

服务原则：操作反馈自动化 · 过程可追溯

问题：上一轮踩过的坑，下一轮又踩。跨轮经验没有积累机制。

设计：双层来源互补——

• AI 自省（一手经验）：executor prompt 要求 Claude 输出 learnings（踩坑反思），不可预测但价值高——AI 自己写的反思，是归因函数产不出来的洞察
• 归因提炼（公式化建议）：diagnose 从结构化归因生成修复建议（"category X → 建议做法 Y"），确定性强但缺乏原创洞察

存储于 <workspace>/.letsgoal/learnings.md，diagnose 阶段写入，execute 阶段自动加载。自由 Markdown 格式——这是给 AI 看的经验，不是给程序解析的数据。

与已有机制的区别：

机制	写入者	读者	内容性质
iterations.jsonl	self_loop	程序/审计	结构化日志：每轮发生了什么
task-state.json	self_loop	resume 流程	任务级状态：当前进展
learnings.md	AI 自省 + diagnose	下一轮 AI	经验摘要：下次该怎么做

5. 决策通知

服务原则：主动通知

问题：自循环跑数十分钟无通知，违反"不需值守"设计目标。

设计：定义通知事件和通知通道，按自主模式过滤。

通知事件：

事件类型	触发条件	通知策略
escalation	归因命中 escalate category	始终通知
awaiting_human	strict 模式暂停	始终通知
consecutive_failures	同一 category 连续 3 次失败	strict/standard 通知，autonomous 不通知
task_completed	任务通过或最终失败	始终通知

通知通道：

通道	配置要求	适用场景
terminal	零配置	默认通道
feishu	lark-cli + chat_id	需要 IM 推送时

通道选择通过 LoopConfig.notify_channel 控制，默认 "terminal"。

与自主模式的关系：

• strict：通知 + 暂停等人确认
• standard：通知但继续执行
• autonomous：仅 escalation 和 task_completed 时通知

落地方向

概览

维度	开发调试	数据采集	模型调优
评估重点	测试/lint/类型/效果	条数/字段/时效	成功率/指标/副作用
修复策略	修bug→重构→补测试	重试→补采→降级	自动调优→回滚
状态追踪	飞书多维表格 + Git	飞书多维表格	飞书多维表格
产物	代码 commit + 测试报告	JSONL + 报告	Skill/Prompt + 评测报告
特有机制	渐进式自主	自动化自治	稳定性优先 + 安全降级

开发调试

定位

用户描述需求和效果标准，系统自主完成编码、验证、修复、重构和阶段性汇报，仅在方案 review 和路线选择等关键决策点引入人工判断。

评估

硬门禁：无 lint 错误 · 无类型错误 · 测试覆盖率达标 · L3 端到端通过

失败归因：

类型	自动修复
syntax_error	✅ 直接修复
type_error	✅ 直接修复
test_failure	✅ 归因+修复
lint_violation	✅ 直接修复
integration_error	⚠️ 归因后尝试
architecture_mismatch	❌ 升级人工
requirement_ambiguity	❌ 升级人工
performance_regression	⚠️ 视情况处理

状态存储

开发调试方向使用 飞书多维表格 + Git 双层状态追踪：

• 飞书多维表格：任务级状态（当前任务、阶段、迭代轮次、评分）
• Git：代码级变更追踪，天然满足上下文窗口管理（commit history 即跨轮记忆）

飞书多维表格扩展字段：

通用表	开发调试扩展字段
Tasks	功能需求、验收标准、约束、自主模式
Eval Cases	测试用例、覆盖率目标、eval_suite_version
Iteration Runs	lint 结果、测试结果、覆盖率、类型检查结果
Feedback	评论来源（飞书行级评论 / 终端输入）
Artifacts	代码 commit 链接、测试报告

Git 的优势：每次循环产出一次 commit，git diff 即变更概览，git revert 即回滚机制。多维表格补充的是任务级可观测性——多任务并行时，统一查看所有任务状态。

渐进式自主

根据任务复杂度和历史表现，调整自主程度：

模式	行为	适用场景
严格模式	每个关键步骤前暂停等人工确认	新项目、高风险变更、首次使用
标准模式	自动执行，关键决策点通知	常规功能开发、bug 修复
自治模式	全自动执行，仅完成后汇报	低风险修复、测试补充、文档更新

目标输入

结构化描述需求：

# 开发任务

## 目标
实现用户登录功能

## 验收标准
- 单元测试覆盖率 ≥ 80%
- 支持邮箱和手机号登录
- 登录失败有明确错误提示
- 无 lint 错误、无类型错误

## 约束
- 使用现有 auth 模块
- 不修改数据库 schema
- 最大迭代轮次：10

创建/优化 Skill 时，约束中增加 Skill 特有项：

## 约束（Skill 开发示例）
- 使用 skill-creator 创建初版
- 评测集冻结版本：eval_suite_v2
- 目标 success_rate ≥ 0.85

自然语言也可以，系统解析后生成结构化定义供用户确认。

阶段规划

阶段进展跟踪见 docs/roadmap.md，以下为设计层面的阶段划分。

阶段	目标	关键产出
M1：循环原语	验证"需求→编码→验证→修复→汇报"链路	一个功能从需求到代码提交的全自动闭环
M2：评估体系	归因分类、评测冻结、L0-L3 分层	结构化归因 + Skill 创建/优化
M3：质量与自主	软分择优、渐进自主、经验沉淀、Story 分解	多场景覆盖 + 自治循环
M4：日常可用	/letsgoal 触发、飞书文档、决策通知	开发者日常可用

数据采集

定位

运行采集 Skill，自动监控结果质量，简单异常自动修复，无法处理时通知人工或建议进入开发调试方向修复/新建 Skill。核心价值：从"人盯自动化"到"自动化自治"。

运行流程

定时执行 skill
 → 记录运行过程到 Daily Runs
 → 监测成功率、耗时、条数、字段质量
 → 异常检测（条数骤降、字段缺失、时效性不达标）
 → 简单自愈（重试、补采）
 → 无法自愈 → 飞书通知人工
 → 需要修改/新建 Skill → 建议进入开发调试方向

日常运行不自动优化 Skill，采用"建议先行、确认后执行"策略。

评估

硬门禁：schema 正确 · rank 连续 · 条数达标 · 清理完成 · L3 端到端通过

失败归因：navigation_error、popup_blocked、wrong_tab、preview_list_collected、extraction_error、rank_gap、field_parse_error、swipe_strategy_error、app_crash_or_background、postprocess_error、environment_error

Worker 角色

Worker	职责
Eval Runner Worker	运行 L0-L3 评测，输出评分和报告
Environment Worker	控制目标环境（Android 设备、浏览器、API 客户端等）
Feishu Worker	通过 lark-cli 统一操作飞书文档、表格、附件、消息

状态存储

飞书多维表格扩展字段：

通用表	数据采集扩展字段
Tasks	采集目标、频率、数据源
Eval Cases	L0-L3 用例类型
Iteration Runs	采集条数、字段完整性、rank 连续性
Feedback	评论来源（飞书行级评论）
Artifacts	截图、金标结果、采集日志、diff
Daily Runs	日常运行记录和异常检测（方向特有表）

本地文件：任务状态快照、worker lease、评论消费缓存、同步游标。

飞书命令

命令	作用
/letsgoal status <task_id>	查询状态
/letsgoal latest <task_id>	查看最近结果
/letsgoal pause/resume/stop/retry	控制任务
/letsgoal operate enable <skill>	启用日常运行

所有飞书交互统一通过 lark-cli，飞书权限按 lark-cli 的身份和 scope 体系管理，bot 和 user 身份按操作类型切换。自然语言兜底，归一化到命令协议。多任务场景优先要求显式 task_id。

能力复用

系统运行时复用已有 CLI/skills：

• uixt — Android UI 自动化
• android-adb — 设备控制
• lark-cli — 飞书交互

阶段规划

阶段进展跟踪见 docs/roadmap.md，以下为设计层面的阶段划分。

阶段	目标	关键产出
M5.1：预置 Skill 验证	验证飞书触发→执行→落盘→通知链路	2-3 个预置采集 Skill 可一键触发
M5.2：闭环能力	定时调度、结果校验、自动补采、可视化、主动通知	V1 可用版本
M5.3：自定义任务	自然语言→结构化配置→任务生成	预置+自定义双模式
M5.4：平台化	统一校验策略、通用 dashboard、更多采集插件	平台级能力沉淀
M5.5：复杂场景	页面级、内容级、行为级采集	更复杂采集链路支持

模型调优

定位

用户通过飞书提交任务目标、评测集、规范约束和成功标准，系统通过 Agent + Skill + Harness + Eval 闭环持续优化模型效果，达到可发布水平。核心指标：

• 任务闭环成功率 ≥ 80%
• 约 40% 任务可通过自动调优完成

核心判断

当前最大问题不是"模型不够强"，而是系统稳定性不足：个别 case 能跑通，但批量任务经常失败；失败原因不透明；Agent/Skill/Harness 边界不清。因此产品化优先级：

1. 先做稳定闭环
2. 再做自动调优提效
3. 最后做更强的完全自治

设计原则

1. 稳定性优先于单次最优效果 — 宁可牺牲极少数 case 的最优表现，也要保证批量任务稳定执行
2. 明确分层，降低耦合 — Skill 负责能力描述与策略边界，Agent 负责决策与编排，Harness 负责执行与环境
3. 所有失败可观测、可归因、可重试 — 失败不能定位就无法提升成功率
4. 默认支持人类兜底 — Human-in-the-loop 不是过渡方案，而是产品能力的一部分
5. 自动调优在安全边界内运行 — 只允许调低风险对象，不允许无边界自我演化

评估

硬门禁：核心成功率提升 · 稳定性不下降 · 长尾失败不明显恶化 · 成本/时延可接受

调优对象（低风险、高收益优先）：

优先调	暂缓调
Skill 模板措辞	多 Agent 协作拓扑
Few-shot 示例	任意自由 Prompt 重写
参数开关	无边界工具组合
Agent 路由规则
失败恢复策略

任务状态机：

CREATED → VALIDATING → BASELINE_RUNNING → EVAL_ANALYZING
    → WAITING_HUMAN_REVIEW → TUNING → VERIFYING → DONE
    → FAILED → ABORTED

Agent 限制输出为结构化动作：select_skill、run_case_batch、request_more_context、enter_auto_tune、request_human_feedback、finalize_result。

失败分类体系：所有失败至少分为 7 类：

• 输入问题
• 环境问题
• Skill 设计问题
• Agent 决策问题
• 模型能力问题
• Harness 执行问题
• 评测器误判

只有分类清楚，自动调优才知道该调哪里。

Skill 标准化

Skill 从"经验文本"变为"可执行契约"，每个至少包含：

• 适用场景 + 禁止场景
• 输入/输出字段定义
• 执行步骤模板
• 常见错误与恢复动作
• 评判标准

Harness 稳定性

Harness 是稳定性的核心，必须具备：任务级/case 级 trace id、完整输入输出落盘、可重放、超时控制、重试控制、幂等执行、资源隔离。

建设顺序：单 case 稳定执行 → case batch → 中断恢复 → 全链路 replay。

安全降级

系统不确定时不继续盲调：

• 降级到保守策略
• 缩小参数搜索空间
• 请求人工确认
• 输出部分完成结果

状态存储

飞书多维表格扩展字段：

通用表	模型调优扩展字段
Tasks	评测集、目标指标、规范约束、任务状态机阶段
Eval Cases	case 级错误归因、AI 归因结果、人工纠正列、最终归因列、审核状态列
Iteration Runs	成功率、指标变化、调优对象、副作用检测结果
Feedback	评论来源（飞书行级评论）
Artifacts	评测报告、Skill/Prompt 变更记录、回滚快照

Skill/Prompt 版本管理：v1/v2/v3 版本记录，每轮变更说明、指标变化、一键回滚。

飞书命令

命令	作用
/letsgoal run	发起调优任务
/letsgoal status <id>	查询状态
/letsgoal feedback <id>	人工反馈
/letsgoal approve <id>	审批继续
/letsgoal retry <id>	重试

机器人返回：任务 ID、当前阶段、总 case 数、成功率、失败 case 数、Top 3 失败类型、下一步动作、是否需要人工介入。

飞书卡片展示：当前成功率、调优轮次、最近变更、风险提示、操作按钮。

实验验证

基于 Self-Improvement Loop 实验记录的关键发现：

1. AI 可以基于规范自动生成第一版 Skill — 初版 precision 较低，但 recall 可达较高水平
2. AI 自归因 + 人工纠正有效闭环 — 1 轮迭代后 F1 从 0.286 → 0.800，Accuracy 从 0.545 → 0.955
3. 飞书表格适合作为 HITL 中间层 — case 级归因、人工纠正、审核协作、审计留痕
4. 0 人工自动调优具备早期可行性 — "右上角标签"实验 0 人工 3 轮达到目标门槛，但还不稳定

双态路线：

• 中间态：AI 自动执行 + 飞书表格人工纠正兜底
• 理想态：AI 自动归因、自动调优、自动验收，仅高风险场景转人工

先把"可控的闭环"做成产品，再逐步提高"自动化占比"。

阶段规划

阶段进展跟踪见 docs/roadmap.md，以下为设计层面的阶段划分。

阶段	目标	关键产出
M6.1：中间态产品化	飞书机器人可用闭环	统一任务状态机 + Skill 标准化 + Harness 可回放 + 飞书交互；闭环成功率 60%+
M6.2：稳定性专项	闭环成功率 80%+	失败归因体系化 + 调优策略模板化 + 重试降级策略
M6.3：自动调优增强	自动调优完成率 40%	自动归因置信度 + 多候选并行调优 + 自动验收 + 自动停止

Sprint 拆分：

Sprint	目标	产出
Sprint 1	飞书可用闭环	MVP 命令集 + 任务状态卡片 + 错误归因表结构
Sprint 2	Harness 稳定性	replay + trace + 幂等执行 + case 级日志
Sprint 3	Skill/策略标准化	Skill schema + 失败分类 taxonomy + 策略模板
Sprint 4	自动调优 beta	自动归因分流 + 多候选验证 + 回退机制

指标体系

北极星指标：任务闭环成功率（基线：60%+，目标：80%+）

核心过程指标：baseline 成功率、调优后成功率、自动调优完成率、人工介入率、单任务平均调优轮数、case replay 成功率、Harness 异常率

质量指标：结果可发布率、规范符合率、UI 一致性评分、长尾 case 成功率