大多数关于 agent harness 的讨论，一开始就站错了地方。
它们从更多 agent 开始。或者更多工具。或者更大的 context window。或者另一个 orchestration framework，承诺让 agent 像一个迷你工程团队一样协作。
这不是核心问题。
核心问题是：软件开发本来就有 workflow，但这个 workflow 散落在人类判断、本地约定、零散文档、半记得的 postmortem、以及项目特定命令里。一个 prompt 保不住这个结构。一个裸 agent loop 也不知道什么时候该加载哪种 context，哪个工具有权威性，什么才算验证完成，或者一次 run 结束后什么东西应该沉淀成可复用模式。
Agent harness 应该解决的是这个。
Agent harness 把开发流程变成 agent 可执行的模式。
它不是更大的 prompt。它是一个 control plane，把 context routing、workflow skills、project-specific tools 和 evaluation feedback 组合成一个可重复的 work loop。
Multi-agent 是一种 context 策略
Multi-agent 系统一般会被描述成角色拆分：
- product manager agent；
- engineer agent；
- reviewer agent；
- testing agent。
这个 framing 有用，但很浅。它很容易变成组织架构 cosplay。
Multi-agent 真正有用的原因，是 context distribution。
真实项目里的 context 太多了：产品意图、代码结构、历史决策、测试失败、issue 历史、设计约束、部署规则、本地约定。不同开发阶段并不需要同一份 context。
PRD agent 需要产品约束和用户意图。Coding agent 需要收敛后的 spec、相关代码和 repo conventions。Validation agent 需要 acceptance criteria、trace、测试和已知 regression。Reviewer 需要 diff、risk model 和历史失败模式。
所以有意思的对象不是 agent role。有意思的对象是 context projection。
Multi-agent 很多时候不是关于并行劳动力，而是把正确的 context 路由到正确的阶段。
你可以用文档做 handoff，但“文档”这个词太宽了。Spec、code map、test trace、postmortem、memory entry、skill 都是文档，但它们的 authority、lifecycle 和使用位置完全不同。
Harness 应该知道这些区别。
一个有用的 context layer 需要分类，而不只是存储：
| Context type | 保留什么 | 什么时候加载 |
|---|---|---|
| Product context | 用户意图、约束、non-goals、acceptance criteria | PRD、planning、scope decision |
| Code context | 相关文件、架构、API、依赖形状 | implementation 和 refactor |
| Runtime context | terminal state、logs、traces、running processes、test output | debugging 和 continuation |
| Decision context | 为什么这么选、被拒绝的备选项、authority | design review 和 conflict resolution |
| Knowledge context | 可复用的 domain/project facts | 当它会改变解释方式时 |
| Memory context | durable priors、偏好、反复出现的事实 | 行为需要被 bias 之前 |
| Postmortem context | 失败、修复、防止复发的规则 | 重复类似工作之前 |
| Skill context | 某个阶段的可执行 procedure | 进入对应 workflow stage 时 |
Harness 不应该问：“我能往 prompt 里塞什么？”
它应该问：“这个阶段需要哪种 context type？这个 projection 带着什么 authority？”
Skill 是 context-bound procedure
Skill 不只是 prompt snippet。
一个有用的 skill 会说明：
- 什么时候使用它；
- 加载什么 context；
- 遵循什么 procedure；
- 调用哪些工具；
- 什么算 done；
- 避免哪些失败。
这让 skill 成为一种 context-bound procedure。
对 harness 设计来说，skill 也需要分类。否则“skill”会变成另一个 junk drawer：
| Skill type | 任务 |
|---|---|
| Planning skill | 把 intent 变成 scope、constraints、non-goals、acceptance criteria |
| Implementation skill | 指导 patch 形状、repo conventions、coding loop、tests-first discipline |
| Validation skill | 判断什么证据足够：tests、build、traces、screenshots、benchmark |
| Review skill | 根据 intent、risk、regressions、security、maintainability 检查 diff |
| Tool-use skill | 教 agent 安全使用项目特定命令和 API |
| Recovery skill | 处理 stuck loop、重复失败、reroute/escalate/stop conditions |
| Postmortem skill | 把失败蒸馏成可复用 procedure、policy 或 tool improvement |
| Publishing skill | 把输出包装到外部表面：blog、PR、email、docs、release notes |
分类重要，是因为每种 skill 都需要不同的 context projection，也有不同的“done”定义。
这就是为什么 skill 像开发流程里的“润滑”。它保存了那些本来只存在于 senior engineer 脑子里的操作性知识：怎么写 PRD，怎么收窄 patch，怎么验证一个改动，怎么 review diff，怎么把失败变成 postmortem 而不污染长期记忆。
传统开发流程依然很熟悉：
PRD → design → implementation → validation → review → postmortemHarness 版本并不是魔法。它只是把同一个 workflow 变成可执行结构：
typed context → stage skill → project tool → agent loop → eval trace → pattern update重点不是假装旧流程消失了。重点是把可复用的部分包装起来，让 agent 不用每次都从零重新发现开发流程。
通用工具给手，项目工具给本体感
早期 agent tool access 很通用：
- web search；
- browser；
- terminal；
- file read/write。
这些是必要的。它们给 agent 手。
但严肃开发需要 project-specific tools：
- 为这个 diff 跑相关测试；
- 用项目 schema 获取 issue context；
- 打开某个 failure 的 trace；
- 验证某条 route 或某个 schema；
- 比较 benchmark run；
- 检查 feature flags；
- 预览本地 app；
- 找一个文件的 owner 或 dependency path。
通用工具让 agent 能行动。项目特定工具让它知道自己在什么地方行动。
Generic tools give the agent hands. Project-specific tools give it proprioception.
这是 chat agent 和 harness 之间最大的区别之一。Chat agent 可以 grep、猜、跑命令。Harness 把项目暴露成一个 agent 可操作的环境。
这也改变了 tool access 的含义。“更多工具”不自动等于更好。真正有用的问题是：这个工具有没有把项目知识压缩成一个更安全、更直接的 action surface？
Repo-specific test runner 比让 agent 猜该跑什么命令更好。Typed trace viewer 比让它 scrape logs 更好。Schema validator 比希望它之后注意到 runtime error 更好。
Harness 应该把项目结构变成工具。
Eval 是 hill-climbing surface
如果 harness 不能评估自己的 run，它就不能改进。它只能累积 prompt tweaks。
但 harness evaluation 不只是 benchmark 数字。开发 workflow 里有 hard signals，也有 soft signals。
Hard signals 可以测量：
- tests pass；
- build passes；
- lint passes；
- benchmark improves；
- issue is resolved；
- regression is covered；
- human intervention count drops。
Soft signals 也是真实的：
- context handoff 有没有保住 intent？
- agent 有没有停在正确边界？
- validation 有没有抓住真正风险？
- workflow 有没有减少混乱？
- postmortem 有没有产出可复用 pattern？
- 下一次 run 有没有变容易？
所以 harness eval 是 imperfect metrics 下的 trace-based comparison。
最终 outcome 只能说明某一次 run 有没有成功。Trace 才说明怎样让它下次也成功。
一个有用的 trace 会记录：
- 加载了哪些 context；
- 调用了哪些工具；
- agent 在哪里失败或 retry；
- 什么证据验证了结果；
- 什么时候打断了人类；
- 哪一部分应该变成 skill、tool、policy、memory candidate 或 postmortem。
Hill climbing 是这样发生的：不是相信 agent 的 self-report，也不是优化一个 synthetic score，而是比较 traces，并蒸馏出更好的 patterns。
完整 loop
把这些放在一起，harness loop 长这样：
- 把 work 拆成可识别的开发阶段；
- 给当前阶段附上 typed context；
- 选择相关 skill；
- 暴露 project-specific tools；
- 运行 agent loop；
- 用 evidence 验证；
- 比较 traces；
- 更新 skill、tool、policy、memory candidate 或 postmortem。
每一部分解决一种不同的失败模式：
Multi-agent solves context distribution.
Skills solve procedure reuse.
Tools solve environment coupling.
Eval solves hill climbing.
Memory solves durable priors.
Postmortem solves pattern extraction.
Harness composes them into a repeatable development loop.这是有用的 framing。
Agent harness 的主要目标不是让 agent 更像人类团队。它是让开发流程本身足够 legible，让 agent 能执行、验证、恢复和改进。
Agent development 的未来，不会由拥有最复杂 agent 组织架构图的系统赢下。
会赢的是这样的系统：精确路由 context，把项目暴露成有用工具，用 trace 验证工作，并把成功 run 沉淀成可复用 pattern。