演进：harness 必然演化

🚧 本章正在开发中。后续节内容陆续补充。

卷一的演进章给出了 spec 维护的工程化方案。Change 包流程：发现差异、归因到 spec 哪一处、修正，然后合并回主 spec。每一步人都在场。一个人盯一个项目，看到测试报告知道哪里是 spec 没跟上，凭对项目的理解知道改哪个文件，改完一审一合就完了。

这个回路依赖人参与三个动作：发现、归因、修正。多线程下三个动作每一个都会爆掉。

发现这一步不行了。卷一里测试报告每天就那么多条，扫一眼能看清。卷二里测试报告、CI 日志、subagent 审计输出每天可能有几千行，人不可能逐条扫过去。问题埋在日志里没人发现。

归因也不行了。一个问题在卷一里的归因路径是清晰的：某条测试挂了，看是 spec 错还是代码错，要么改 spec 要么改代码，二选一。卷二里一个问题可能跨多条线程、多个 harness 层级。前端泳道的 mock 和后端的真实输出不一致，根因可能在 API 契约，可能在前端 spec 里写错的字段，可能在后端测试用例没覆盖。每一处都要追溯，每一处都需要看几个上下文，人脑装不下这么多状态。

修正也不行了。卷一里改一处 spec，影响范围一眼看得见。卷二里同一份 spec 可能被几个子空间冗余引用（规约章建立的自包含原则），改一处需要在所有冗余的位置同步。冗余的位置散落在哪些子空间，人不一定都记得。

人不再是演进回路的执行者，只能是其中一两个环节的兜底。回路本身必须工程化。

演化不是 harness 的补丁，是它的内在组成

根因是注意力有限，不是环境在变。"环境在变，所以工具要跟着变"是直觉的错误归因。Linux 内核也面对持续变化的环境，但内核架构非常稳定。环境变化本身不是 harness 必须演化的根因。

一个人不可能一次想清楚所有可能的失效模式。harness 在第一次设计的时候，设计者只看得到当时遇到的问题，看不到那些还没暴露的失效模式。等项目跑大了、模型升级了、新场景来了，旧 harness 的盲区就会被照出来。这不是设计者的水平问题，是注意力本身的物理边界。

一个 harness 没有演化机制，第一次失效就是它的死期，不是它的修复机会。

这一章怎么展开

后面三节把演化机制的具体设计落到流程上。

下一节讲双轨制。每次异常处理必须有两个产出：短期方案修当前问题，长期方案改 harness 让这类问题不再发生。单轨修当前是救火，救一辈子也救不完。双轨制的核心是把每次异常都变成 harness 演化的输入，这个动作必须工程化，不能依赖人的自觉。这一节具体讲怎么把双轨写进流程。

之后讲健康度指标。多线程下日志的量已经超出人能扫的边界。需要把系统的健康状态压缩成少量客观信号。一个数字告诉你 harness 是不是在工作，比一份详细日志有用。这一节讲健康度指标的设计原则，以及怎么从中识别 harness 失效。

最后一节讲演化产物的沉淀。harness 演化出的规约、验证机制、流程模板，是这套体系长期的资产。代码反而是这些资产的输出。这条结论引向卷三的组织资产讨论。

Harness Engineering Playbook · AgentsZone Community