从地图到真实地形：Agentic Coding 时代的未知项工程#

2.1 已知的已知：Prompt 中最容易表达的部分#

这部分通常包括：

• 要新增什么功能；
• 需要修复什么问题；
• 哪些模块允许修改；
• 要遵循什么架构规范；
• 需要通过哪些测试；
• 最终交付什么文件。

OpenAI 的 Codex 最佳实践将一个良好的任务输入概括为四类信息：目标、上下文、约束和完成条件。² 这四类内容，本质上就是把“已知的已知”尽量结构化。

但仅仅写清楚已知内容还不够。很多失败并不是 Prompt 写错，而是 Prompt 中根本没有覆盖真正决定结果的因素。

2.2 已知的未知：至少知道自己应该停下来调查#

例如：

• 不确定当前认证模块是否允许新增 Provider；
• 不知道某个 API 是否保证幂等；
• 不清楚数据库中的状态字段是否允许回退；
• 不确定前端交互应该使用弹窗还是独立页面；
• 不知道采用事件驱动是否值得增加复杂度。

这是相对“友好”的未知项，因为你至少知道问题存在。

对这类未知，最危险的行为是为了让 Agent 尽快开始而强行给出一个未经验证的答案。正确做法是把它显式标记为待决策项，让 Agent：

1. 阅读代码和文档；
2. 列出候选方案；
3. 展示证据；
4. 说明取舍；
5. 通过原型或实验缩小不确定性。

2.3 未知的已知：人类的“品味”与隐性知识#

这类未知在 UI、产品流程和架构设计中尤其常见。

你可能无法提前准确描述：

• 什么样的页面“看起来专业”；
• 怎样的代码结构“符合团队习惯”；
• 多复杂的抽象才算合适；
• 哪种错误提示“对用户足够友好”；
• 哪种 API 命名“就是不对劲”。

但当你看到结果时，又能迅速做出判断。

这些判断来自经验、审美、业务直觉和组织惯例。它们并不是不存在，只是尚未被语言化。

原文强调：原型的价值不只是验证技术可行性，更重要的是帮助人类把隐性标准变成显性标准。

一旦你能够说出：

• “我不喜欢这个方向，因为信息层级太平均”；
• “这个流程的问题不是步骤多，而是用户失去了回退能力”；
• “这个抽象看起来通用，但破坏了领域语义”；

未知的已知就开始转化为已知的已知。

2.4 未知的未知：真正昂贵的盲区#

这是最难处理的一类：

• 你不知道应该问什么；
• 你不知道优秀结果可以达到什么水平；
• 你不知道代码库中曾经发生过什么；
• 你不知道某个默认选择会触发安全或兼容问题；
• 你甚至不知道当前解决的并不是真正的问题。

未知的未知无法依靠“再把需求写详细一点”解决，因为你缺少的不是表达，而是认知。

因此需要改变任务入口：

不是直接问：

帮我实现这个功能。

而是先问：

在开始实现前，请从架构、业务、数据、权限、兼容性、测试和运维角度做一次盲区扫描，指出我可能尚未意识到、但会改变方案的重要问题。

这不是让 Agent 替代决策，而是让 Agent 帮助人类获得提出正确问题的能力。

4.1 过度具体：把错误方案写成不可违背的命令#

例如：

• 必须新建一个微服务；
• 必须引入消息队列；
• 必须使用某个设计模式；
• 必须按照指定类结构实现；
• 不允许偏离预设步骤。

如果这些要求来自充分调研，它们是约束；如果它们只是未经验证的猜测，就可能把 Agent 锁死在错误方向。

强 Agent 往往能够在代码库中发现更优路径，但若指令没有授权它指出冲突，它可能仍会机械执行。

4.2 过度模糊：把所有设计责任都交给模型默认值#

例如：

帮我把登录功能做好。

Agent 必须自行决定：

• 使用 Session 还是 JWT；
• 是否需要刷新令牌；
• 如何处理撤销；
• 是否允许多设备登录；
• 权限模型如何组织；
• 错误如何返回；
• 安全边界是什么；
• 如何兼容现有用户。

模型可能采用常见实践，但“常见”不等于“适合”。

4.3 更好的任务输入：同时描述意图与认知边界#

一个成熟的任务输入应至少包括：

1
目标：我希望改变什么结果？
2
上下文：哪些代码、文档、错误、历史决策与任务相关？
3
约束：哪些边界不能违反？
4
完成条件：如何判断任务真正结束？
5
已知未知：哪些问题我知道尚未确定？
6
经验起点：我对当前领域和代码库了解多少？
7
决策权限：哪些决策 Agent 可以自主做，哪些必须暴露给我？
8
偏离策略：遇到计划外情况时，是停止、保守处理，还是记录后继续？

这比单纯增加 Prompt 字数更重要。

Anthropic 将“Context Engineering”定义为：持续选择和维护在当前推理时刻最有价值的信息，而不只是优化一句系统提示词。⁴ 对长周期 Agent 而言，真正的问题已经从：

我应该怎样措辞？

转变为：

在这个阶段，Agent 需要看到哪些信息，哪些信息应该被压缩，哪些决策必须保持显著，哪些历史内容反而会造成干扰？

5. Blind Spot Pass：先扫描盲区，再开始解决问题#

当任务位于陌生代码模块、陌生技术领域或陌生业务流程中时，第一步不应是让 Agent 写代码，而应是让它帮助你建立问题空间。

1
我准备在当前项目中实现【任务】。
2

3
我的当前认知：
4
- 我对该业务的了解：
5
- 我对相关代码模块的了解：
6
- 我已经确定的约束：
7
- 我目前知道但尚未解决的问题：
8

9
在开始设计或编码前，请做一次 Blind Spot Pass。
10

11
请扫描相关代码、文档、测试和配置，从以下角度识别我可能尚未意识到的未知项：
12
1. 真实业务目标；
13
2. 调用链与状态流转；
14
3. 数据模型；
15
4. 权限与安全；
16
5. 历史兼容；
17
6. 并发、一致性和失败恢复；
18
7. 测试与验收；
19
8. 部署、监控和回滚；
20
9. 是否存在更简单或方向不同的方案。
21

22
请按“未知项—为什么重要—需要什么证据—可能改变什么决策”的格式输出。
23
暂时不要修改代码。

6. Brainstorm 与 Prototype：把隐性判断变成可观察对象#

原文尤其强调在存在大量“未知的已知”时，不要直接进入正式实现。

1
不要给我十个相似方案。
2

3
请给出四个原则明显不同的方向：
4
A. 最小改动；
5
B. 体验优先；
6
C. 架构长期演进优先；
7
D. 重新定义问题的替代方案。
8

9
每个方向说明：
10
- 核心假设；
11
- 最适合的场景；
12
- 最大风险；
13
- 需要验证的未知项；
14
- 最小可行原型。

1
本轮只制作一次性原型，目标是验证【假设】。
2

3
限制：
4
- 不修改正式业务代码；
5
- 不连接生产数据；
6
- 使用假数据或独立目录；
7
- 不提前建设通用抽象；
8
- 输出验证结论和未解决问题；
9
- 原型默认不可直接合并。

7. Interviews：让 Agent 采访你，而不是一次抛出问题清单#

完成初步探索后，通常仍有模糊项。

原文建议让 Agent 一次只问一个问题，并优先询问那些答案会改变架构的问题。

1
请采访我以消除任务中的模糊项。
2

3
规则：
4
- 每次只问一个问题；
5
- 优先询问答案会改变数据模型、接口、权限、状态机或用户主流程的问题；
6
- 每个问题先简短说明“为什么这个答案会改变方案”；
7
- 根据我的回答更新你的任务理解；
8
- 如果我的回答与已有代码约束冲突，请指出，不要自动迎合；
9
- 当高影响未知项已经收敛后，输出决策摘要和仍未解决的问题。

8. References：当语言不够时，用工作示例传递语义#

有些需求很难通过描述完整传达：

• 一套交互的节奏；
• 一个退避算法的真实语义；
• 某种组件组织方式；
• 团队惯用的错误处理；
• 一个复杂工作流的边界行为。

这时，参考实现往往比更多形容词更有效。

1
请阅读 `vendor/rate-limiter` 中的参考实现。
2

3
我希望复用的是：
4
- 指数退避的行为语义；
5
- 抖动策略；
6
- 最大等待上限；
7
- 可取消行为；
8
- 测试覆盖的边界。
9

10
我不希望复用的是：
11
- Rust 的具体类型组织；
12
- 该项目的日志框架；
13
- 与当前代码库冲突的命名。
14

15
请先输出语义对照表，再在当前 TypeScript 客户端中实现等价行为。

9. Implementation Plan：计划应优先暴露决策，而不是堆砌步骤#

很多 Agent 生成的计划看起来很详细：

1. 创建文件；
2. 新增类；
3. 修改 Controller；
4. 增加 Service；
5. 编写测试。

但这些往往是最不需要人类审查的机械动作。

真正需要提前暴露的是：

• 为什么改变数据模型；
• 新接口如何定义；
• 状态机如何变化；
• 哪些行为对用户可见；
• 如何保持兼容；
• 哪些失败需要补偿；
• 哪些地方仍依赖假设。

1
# Implementation Plan
2

3
## 1. 目标与非目标
4

5
## 2. 已确认事实
6

7
## 3. 仍存在的未知项
8

9
## 4. 需要人类审查的关键决策
10
### 4.1 数据模型
11
### 4.2 公共接口与类型
12
### 4.3 权限与安全
13
### 4.4 状态流转
14
### 4.5 用户可见行为
15
### 4.6 兼容与迁移
16

17
## 5. 验收与验证策略
18

19
## 6. 回滚方案
20

21
## 7. 机械性实现步骤
22

23
## 8. 暂不处理事项

10. 使用新的实现会话，但传递结构化成果#

原文建议：规划完成后，开启一个新的 Claude Code 会话，并把规格、原型、计划和参考材料传入。

这样做的价值在于：

• 减少探索过程中的噪声；
• 避免过长对话造成注意力稀释；
• 将已收敛结论作为新的任务起点；
• 迫使团队把关键认知沉淀为可复用文件；
• 让实现 Agent 不必重新经历全部讨论。

Anthropic 的 Context Engineering 文章指出，上下文是有限资源，更多 Token 并不必然带来更好结果；随着内容增长，信息检索与注意力会逐渐退化。⁴

因此，理想做法不是把全部聊天历史塞给 Agent，而是提供一组结构化资产：

1
/spec.md
2
/prototype/
3
/implementation-plan.md
4
/architecture-decisions.md
5
/references.md
6
/acceptance-tests.md

11. Implementation Notes：为执行中的未知项建立日志#

无论规划多充分，Agent 都会在真实代码中遇到：

• 文档与实现不一致；
• 隐藏的兼容逻辑；
• 缺失的测试基础；
• 无法复用的抽象；
• 计划没有覆盖的边界；
• 外部依赖的真实限制；
• 原方案在当前架构中不可行。

原文建议维护一个临时 implementation-notes.md。

1
# Implementation Notes
2

3
## Progress
4
- [ ] ...
5

6
## New Findings
7
### F-001
8
- 发现：
9
- 证据：
10
- 影响：
11

12
## Decisions Made
13
### D-001
14
- 决策：
15
- 候选方案：
16
- 选择理由：
17
- 影响范围：
18
- 是否需要人类复核：
19

20
## Deviations
21
### DEV-001
22
- 原计划：
23
- 实际发现：
24
- 偏离方案：
25
- 为什么选择保守处理：
26
- 风险：
27
- 后续动作：
28

29
## Assumptions
30
### A-001
31
- 假设：
32
- 当前证据：
33
- 如果假设错误会发生什么：
34
- 如何验证：
35

36
## Deferred Issues
37
- ...

1
实施期间维护 `implementation-notes.md`。
2

3
遇到计划外情况时：
4
1. 如果会改变公共接口、数据模型、权限、安全边界或不可逆迁移，停止并明确报告；
5
2. 如果只是局部实现差异，选择影响最小、最容易回滚的方案继续；
6
3. 所有偏离必须记录原计划、发现、决策、证据和影响；
7
4. 不得为了“完成任务”静默删除验收条件；
8
5. 不得将临时绕过方案描述为正式解决方案。

12. 从逐动作审批转向可观测的监督#

随着用户对 Agent 更熟悉，他们通常不会继续逐条批准每一个命令，而是允许 Agent 执行更长时间，并在发现偏离时中断。

Anthropic 对 Agent 自主性的研究发现，经验更丰富的 Claude Code 用户更常开启自动批准，但同时也更频繁地进行主动中断。⁷

这意味着有效监督并不等于：

每一步都点确认。

更成熟的监督是：

• 能看到 Agent 正在做什么；
• 能看到它依据了什么；
• 能看到计划与实际的差异；
• 能在关键节点介入；
• 能够快速回滚；
• 能在事后重建完整过程。

因此，Agent 系统应该提供：

• 进度文件；
• 结构化日志；
• 可读的命令输出；
• 测试状态；
• Diff 摘要；
• 风险告警；
• 明确的停止条件；
• 简单的干预入口。

13. Pitches 与 Explainers：让变更能够被理解和批准#

一个功能能否交付，不只取决于代码是否运行，还取决于其他人是否能够理解：

• 为什么要做；
• 做了什么；
• 为什么这样做；
• 哪些风险已经处理；
• 哪些风险仍然存在；
• 如何验证；
• 如何回滚；
• 需要谁批准。

原文建议把原型、规格、计划和实现记录打包成一份解释材料。

1
# Change Explainer
2

3
## 1. 一分钟摘要
4

5
## 2. 问题与影响
6

7
## 3. 演示
8

9
## 4. 方案概览
10

11
## 5. 关键决策及理由
12

13
## 6. 与原计划的偏离
14

15
## 7. 风险与缓解措施
16

17
## 8. 测试与验证结果
18

19
## 9. 部署与回滚
20

21
## 10. 需要评审者确认的事项

14. Quizzes：确认人类真正理解了 Agent 完成的工作#

长时间 Agent 执行后，人类可能只知道：

• 测试通过了；
• Diff 很大；
• Agent 说任务完成了。

但并不知道：

• 真实调用链如何变化；
• 哪些旧行为被保留；
• 哪些假设被写进代码；
• 失败时如何恢复；
• 数据迁移是否可逆；
• 哪些测试只是表面覆盖；
• 后续维护需要注意什么。

原文作者会要求 Claude 在解释变更后对自己进行测验，并表示只有完全通过后才合并。

这个做法的本质不是考试，而是恢复认知所有权。

1
请生成一份本次变更的完整技术解释，覆盖：
2
- 背景与目标；
3
- 关键调用链；
4
- 数据和状态如何流动；
5
- 主要设计决策；
6
- 与原计划的偏离；
7
- 边界与失败模式；
8
- 测试覆盖；
9
- 部署和回滚；
10
- 后续维护风险。
11

12
然后设计一组测验题：
13
- 不要只问文件名和代码细节；
14
- 重点验证我是否理解系统行为、约束和失败恢复；
15
- 包含场景题；
16
- 我回答后逐题评价；
17
- 在我无法解释关键路径前，不要将评审视为完成。

15. 原文案例：Claude Code 如何完成 Fable 发布视频#

原文使用 Fable 发布视频说明整套方法如何串联。

作者并不是视频编辑专家，但希望使用 Claude Code 端到端完成视频制作。

16. Context Engineering：未知项首先是上下文缺口#

Prompt 只是上下文的一部分。

Agent 在执行中真正依赖的还包括：

• 代码；
• 测试；
• 目录结构；
• 构建命令；
• 规则文件；
• Skills；
• 工具描述；
• 历史决策；
• 当前进度；
• 环境状态；
• 外部资料；
• 执行反馈。

Anthropic 将 Context Engineering 描述为：在有限的注意力预算中，持续选择最可能带来正确行为的信息。⁴

从未知项视角看，Context Engineering 需要解决三个问题：

17. Harness Engineering：未知项需要前馈与反馈双重控制#

Anthropic 在构建有效 Agent 的工程总结中建议，先寻找能够解决问题的最简单方案，只有在确有必要时再增加 Agent 复杂度。⁸

OpenAI 在介绍 Agent-first 工程实践时提到，早期进展不理想往往不是 Codex 缺乏能力，而是环境没有提供足够清晰、可执行和可强制的结构。⁹

当 Agent 失败时，正确问题通常不是：

如何让模型再努力一点？

而是：

它缺少什么能力、工具、规则、反馈或可观察信号？

18. Spec-Driven Development：把意图变成一等工程资产#

Spec-Driven Development 的核心是：先以结构化、面向行为的形式表达意图，再由 Agent 根据 Spec 实现代码。Thoughtworks 对这一实践的梳理指出，Spec 可以从一次性 Spec-first，进一步演进为长期维护的 Spec-anchored，甚至成为主要源资产。¹⁰

“未知项工程”与 SDD 的结合点在于：

• Blind Spot Pass 发现规格缺口；
• Interview 消除规格歧义；
• Prototype 验证规格方向；
• Implementation Plan 将规格映射为技术决策；
• Implementation Notes 记录真实地形对规格的修正；
• Explainer 和 Quiz 验证规格、实现与人类理解是否一致。

关键不是“写一份很长的需求”，而是让规格具有：

• 行为导向；
• 明确边界；
• 可验证条件；
• 决策记录；
• 与代码同步演进的机制。

19. Evals 与 Compound Engineering：让同一个未知项只付一次学费#

如果每次任务都重新遇到同样的问题，说明团队只有“聊天经验”，没有工程记忆。

OpenAI 的 Agent Improvement Loop 将 Trace、人工反馈、模型反馈、Evals 和 Harness 修改连接成闭环：运行记录告诉我们发生了什么，反馈解释什么重要，Evals 将标准变成可重复检查，最终再修改 Agent 的 Harness。¹¹

Simon Willison 将类似思想概括为 Compound Engineering：每次项目结束后做复盘，把有效经验记录下来，让后续 Agent 运行站在更高起点。⁵

20. 未知项生命周期#

可以将原文方法进一步抽象为六个阶段。

21. 建议的项目文档结构#

1
project/
2
├── AGENTS.md
3
├── CLAUDE.md
4
├── docs/
5
│   ├── architecture.md
6
│   ├── domain-model.md
7
│   ├── decisions/
8
│   │   ├── ADR-001-xxx.md
9
│   │   └── ADR-002-xxx.md
10
│   └── agent-workflows/
11
│       ├── blind-spot-pass.md
12
│       ├── implementation-plan-template.md
13
│       ├── code-review-checklist.md
14
│       └── retrospective-template.md
15
├── specs/
16
│   └── feature-x/
17
│       ├── requirements.md
18
│       ├── unknowns.md
19
│       ├── prototype-notes.md
20
│       ├── implementation-plan.md
21
│       ├── implementation-notes.md
22
│       ├── acceptance-tests.md
23
│       └── explainer.md
24
├── evals/
25
│   ├── regression/
26
│   └── agent-behavior/
27
└── scripts/
28
    ├── verify.sh
29
    └── architecture-check.sh

这里需要区分：

• 长期上下文：项目级规则、架构、构建方式；
• 任务上下文：某个 Feature 的需求、计划和实现记录；
• 验证资产：测试、评测、检查脚本；
• 决策资产：ADR、偏离和复盘。

22. 任务启动模板#

1
任务目标：
2
【描述希望改变的业务或系统结果】
3

4
当前上下文：
5
- 相关代码：
6
- 相关文档：
7
- 已知历史：
8
- 当前错误或限制：
9

10
约束：
11
- 不允许改变：
12
- 必须保持兼容：
13
- 安全与合规：
14
- 技术限制：
15

16
完成条件：
17
- 行为验收：
18
- 测试验收：
19
- 文档验收：
20
- 部署与回滚：
21

22
我的认知起点：
23
- 我熟悉：
24
- 我不熟悉：
25
- 我知道尚未确定：
26
- 我可能存在的假设：
27

28
在编码前：
29
1. 做 Blind Spot Pass；
30
2. 标记高影响未知项；
31
3. 必要时逐题采访我；
32
4. 给出差异明显的候选方向；
33
5. 输出决策优先的实施计划；
34
6. 暂时不要修改代码。

23. 未知项登记模板#

1
# Unknowns Register
2

3
| ID | 未知项 | 类型 | 影响 | 可逆性 | 当前证据 | 处理方式 | 决策人 | 状态 |
4
|---|---|---|---|---|---|---|---|---|
5
| U-001 |  | UU | 高 | 低 |  | 原型 |  | Open |

类型：

• KK：Known Known；
• KU：Known Unknown；
• UK：Unknown Known；
• UU：Unknown Unknown。

24. Agent 自治边界模板#

1
你可以自主决定：
2
- 局部变量和私有函数命名；
3
- 不改变行为的机械重构；
4
- 已有模式下的测试补充；
5
- 可轻易回滚的局部实现选择。
6

7
你必须停止并报告：
8
- 公共 API 变化；
9
- 数据模型或迁移变化；
10
- 权限与安全边界变化；
11
- 删除兼容逻辑；
12
- 新增外部依赖；
13
- 无法满足验收条件；
14
- 需要不可逆操作；
15
- 原计划核心假设被证明错误。
16

17
遇到其他计划外情况：
18
- 选择最保守、影响最小、最易回滚的方案；
19
- 记录到 `implementation-notes.md`；
20
- 在最终报告中集中说明。

25. 实施完成后的审查模板#

1
请不要只告诉我“任务已完成”。
2

3
请执行以下审查：
4

5
1. 对照原始目标和完成条件逐项验收；
6
2. 输出文件级和行为级变更摘要；
7
3. 说明关键调用链；
8
4. 列出所有新假设、偏离和保守处理；
9
5. 运行测试、类型检查、Lint 和可用的静态分析；
10
6. 检查边界条件、失败恢复、权限和并发；
11
7. 使用独立视角重新 Review Diff；
12
8. 说明未覆盖风险；
13
9. 生成部署和回滚步骤；
14
10. 生成一组场景测验，验证我是否理解本次变更。
15

16
如果存在未满足项，不得用“基本完成”掩盖。

26. 反模式一：一上来就让 Agent 全量实现#

问题：

• 尚未验证问题；
• 未发现高影响未知项；
• 隐性偏好直到最后才出现；
• Agent 在错误方向上快速积累代码。

改进：

• 先扫描、原型、访谈和计划；
• 将高风险决策提前。

27. 反模式二：把超长 Prompt 当成完整上下文#

问题：

• 信息过期；
• 规则冲突；
• 关键约束不显著；
• Agent 无法区分事实、猜测和历史讨论。

改进：

• 分离长期上下文和任务上下文；
• 标记已确认事实、假设和待决策项；
• 使用新的实现会话传入压缩后的资产。

28. 反模式三：计划写得很细，却不允许偏离#

问题：

• 真实地形一定会出现新情况；
• Agent 为了服从计划掩盖冲突；
• 计划错误被放大为系统错误。

改进：

• 为不同类型偏离定义策略；
• 对高影响变化停止；
• 对局部变化保守处理并记录。

29. 反模式四：让 Agent 自己说“测试通过，所以正确”#

问题：

• 测试可能不充分；
• 测试可能由同一个错误假设生成；
• 用户体验和业务语义难以完全计算验证；
• Diff 中可能存在未覆盖路径。

改进：

• 规格对照；
• 独立 Review；
• 场景测试；
• 人类理解测验；
• 持续 Eval。

30. 反模式五：每次都重新提醒同样的规则#

问题：

• 经验只存在于聊天记录；
• 团队无法复用；
• Agent 在新会话重复犯错。

改进：

• 两次出现的问题进入规则；
• 可计算的问题进入测试；
• 稳定流程进入 Skill；
• 架构选择进入 ADR；
• 失败案例进入 Eval 集。

31. 反模式六：把所有决策都交给 Agent，或所有决策都由人类批准#

两个极端都低效。

32. Level 0：Prompt 驱动#

特征：

• 每次临时输入；
• 没有结构化上下文；
• 完成标准模糊；
• 主要依赖人工看 Diff。

结果：

• 成功不可复制；
• 错误重复发生；
• Agent 质量波动大。

33. Level 1：计划驱动#

特征：

• 复杂任务先计划；
• 有基本验收条件；
• 会要求 Agent 调研代码。

不足：

• 计划仍是一次性的；
• 实施偏离缺乏记录；
• 经验没有沉淀。

34. Level 2：未知项驱动#

特征：

• 启动前做 Blind Spot Pass；
• 区分四类未知；
• 使用原型和访谈；
• 计划优先展示关键决策；
• 实施中维护 Notes。

结果：

• 返工更早发生；
• 高影响决策更可见；
• 人类和 Agent 形成真正协作。

35. Level 3：Harness 驱动#

特征：

• 项目有规则、Skills、脚本、测试和 Review；
• 前馈与反馈控制完备；
• Agent 自治边界清晰；
• 人类主要监控和干预。

结果：

• 长周期任务可靠性提升；
• 人工 Review 成本下降；
• 结果更容易复现。

36. Level 4：持续改进驱动#

特征：

• Trace、反馈和失败案例进入 Evals；
• 重复问题自动转化为规则或检查；
• Spec、代码和验证资产同步演进；
• 每次项目结束都有 Compound Step。

结果：

• 每次 Agent 运行都在改善下一次运行；
• 团队逐渐形成可复用的 Agent 工程能力；
• 模型升级时也能验证哪些 Harness 仍然必要。

Anthropic 对长周期 Harness 的实践还提醒：Harness 本身也会过时。每一个额外组件都隐含了“模型无法自行完成某件事”的假设，随着模型能力提升，这些假设需要通过逐项删减和对照实验重新验证。¹²