说明

一句话结论：Harness Engineering 正在从”给模型套一个外壳”长成”一门分层的工程学科”。多读了几篇资料后，我最大的收获不是又记住了几个名词，而是看清了一件事——这个领域真正难、也真正没定论的问题，已经不是”怎么把模型提示得更好”，而是”在一个会犯错、但可被纠正的系统里，定义对和完成的权力到底该怎么分配”。

这篇是学习笔记，不是综述。起因、几个让我重新想问题的点、它们彼此矛盾的地方，以及一点感想。

一、起因

这阵子在学 Harness Engineering,看了不少外面的资料:模型外面套一层壳,壳里管上下文、管工具、管循环——Agent = Model + Harness,提示词工程长成上下文工程,再长成治具工程。看完一遍,自以为懂了个大概,但心里总有点意犹未尽:这些框架和名词我能复述,可总觉得只摸到了表面,有些”为什么要这么设计”的地方还没真正想透。

带着这点没消化干净的劲儿,我又找了几篇讲这块的资料,想再往深处挖一层。结果还真挖到一些外面讲得很少、甚至刻意绕过的东西。这篇就是再学一轮之后的笔记——记一下哪些点让我重新想了想这个问题,以及它们之间其实并不完全一致的地方。

说明

说明：下面提到的角色名、状态名、数字，都来自这几篇资料里的具体实践，不是我编的抽象模型。我尽量保留它们原本的说法。

二、几个让我重新想问题的点

不是按文档分,是按”它让我重新想的那个问题”分。下面四个点,每一个都对我原来脑子里那套”模型+外壳”的图景做了一点修正。

1. 控制论：给 Harness 配了一套”可控性诊断学”

外面讲 Harness,落点几乎都在”能力”:上下文怎么塞、工具怎么调、循环怎么转。但有篇文档直接把钱学森《工程控制论》和维纳的 Cybernetics 搬过来,问的是另一个问题——一个 Agent 系统到底”可不可控”。这个视角我之前完全没有。它给的不是又一套工具,而是一套”诊断学”:出了偏差,先别急着修,先判断这是什么病。

最让我有收获的是它对”偏差”的三分类,以及配套的纠偏分级。我原来对 Agent 出错的处理基本就是”重试 / 换提示词”,非常糙。

偏差类型	表现	该怎么纠
执行型偏差	做错了具体某一步,目标本身没问题	局部重试 / 单步纠正,代价最小
语义型偏差	理解歪了,做的事和要的事不是一回事	回到上一个决策点,把意图重新对齐
控制型偏差	整个方向跑偏,计划本身错了	触发全局重构,而不是在错的路上修补

配套还有两个我觉得很关键的动作。一是双轨验收:黑盒看输出对不对,白盒看过程合不合理,两条都过才算过——这正好回应了”模型不能可靠地自我评估”那条结论。二是一组借自控制工程的稳定机制:限幅、阻尼、熔断、降级,用来防止系统在纠偏时自己把自己抖崩。

说明

对我最大的改变:以后看到 Agent 出错,第一反应不该是”换个提示词重试”,而该先问一句——这是执行错了,还是理解错了,还是方向就错了? 这三种病吃同一种药,基本都治不好。

2. 去掉 Planner：标准不能被垄断

主流的多 Agent 套路基本是 Planner→Executor→Reviewer,一个大脑在前面拆任务、定计划。有篇文档反其道而行,直接把 Planner 去掉了,理由很简单也很扎心:那个集中的”计划者”既是单点瓶颈,也是单点偏见——它定的标准没人能挑战,一旦它错了,后面全错。

替代方案叫 Sprint Contract,把流程拆成四段,谁都不许垄断”对”的定义:

flowchart LR
    A[NEGOTIATE 协商
双方对齐目标与验收标准] --> B[IMPLEMENT 实现
Generator 产出, 有申辩权]
    B --> C[REVIEW 评审
Evaluator 独立判定]
    C --> D[HOLISTIC 整体校验
全局一致性]
    C -.不通过.-> B

这里两个设计点我很喜欢。一是 Generator 有”申辩权”:评审说不行,实现方可以反驳,而不是被一票否决——因为评审也可能错。二是 Evaluator 独立:它和实现方不是同一个上下文、不共享立场。这两条合起来,本质是一句话:

说明

推荐记住这句:关键不是谁更聪明,而是谁都不能垄断标准。 把”定义对”的权力从一个角色手里拆开,让它在协商和独立评审里产生,而不是被某个 super-brain 钦定。

3. org-os：把”组织纪律”做成硬约束

如果说上面那篇是”去中心化”,这篇 org-os(作者程楠)走的是另一条路:它承认要有一个”组织”,但把组织的纪律做成了系统层面的硬约束,而不是靠每个 Agent 自觉。这点对我冲击挺大——它不是在 prompt 里写”你是只读角色请不要改文件”,而是让只读角色物理上就没有写权限,想改也改不了。

几个具体设计:

控制平面不下场。 Team Lead 是纯编排者,只调度、不亲自干活。控制和执行彻底分离,避免”既当裁判又当运动员”。
23 个专精角色 + 权限绑定。 每个角色能干什么由权限硬性圈定,权限就是边界,不是建议。
9 个状态的状态机。 standby、classifying、brainstorming、routing、task_assignment、monitoring、plan_review、plan_confirmation、backflow——整个协作过程被显式建模成状态流转,而不是一团黑箱对话。
回流优于重试 + 熔断。 出问题时优先”回流”(backflow)到合适的环节重新处理,而不是原地重试;还设了熔断阈值,专门对付”假忙碌”——看着在动、其实没产出的空转。

另外它有两道闸:动手前的 Plan Gate,和完成后的双重评审。前置闸保证不在错的计划上浪费算力,后置闸保证交付前再被独立验一次。

说明

注意:这里最反直觉的一点是——纪律不是写出来劝 Agent 遵守的,是用权限和状态机让它没法不遵守的。 提示词级别的”约定”在规模上一定会被突破,只有硬约束不会。

4. 状态的四层容器：长期性怎么落地

还有篇讲运行时(Hermes Runtime)的,把”状态”这件事拆得很干净。Agent 要长期干活,最难的不是单次推理,而是状态怎么存、怎么续、怎么不串味。它给的是一个四层容器,层层包裹:

层级	是什么	关键约束
Tool Call / Result	一次工具调用和它的返回	必须成对出现,不能只有调用没有结果
Turn	一轮完整交互	由若干成对的 call/result 组成
Session	一段会话(落 SQLite)	状态持久化的基本单位
Lineage	会话血缘(parent_session_id)	会话之间靠血缘串起来,而不是无限堆长

我觉得最妙的是它对”压缩上下文”的处理:compaction 不是在原地把历史截断,而是开一个新 session,通过 parent_session_id 挂回去。这样既控制了上下文长度,又没丢掉来路——想追溯随时能顺着血缘爬回去。比起我之前理解的”超长了就裁掉旧消息”,这个干净太多。

三、最有意思的部分：它们彼此并不一致

读的时候我本来想把它们捏成一套统一的”最佳实践”,后来发现根本捏不拢——而恰恰是它们打架的地方,信息量最大。这说明这个领域真没到收敛的时候,几条路都还在试。

争的是什么	一种主张	另一种主张
要不要中心计划者	org-os:要有 Team Lead 统一编排,靠硬约束维持秩序	Sprint Contract:干脆去掉 Planner,让标准在协商里产生
权力是集中还是分散	集中编排 + 权限切分,纪律靠系统强制	分散协商 + 独立评审,纪律靠相互制衡
纠偏的主路径	回流(backflow)到合适环节重处理	评审驳回 + 实现方申辩,来回拉直

但吵归吵,有一条它们居然异口同声:

说明

模型没法可靠地自我评估。所以无论中心化还是去中心化,大家都把”评判权”外置给了一个独立的角色/机制——独立的 Evaluator、双轨验收、独立 LLM 分类器做权限判定。差别只在”独立的裁判由谁来当”,而不在”要不要独立裁判”。

所以我现在的判断是:Planner 存废、人该站在环里还是环上,这些都还没有标准答案;但”定义对和完成的权力必须和执行权分开”——这一条,已经是共识了。

四、几个值得记住的量化锚点

笔记里我特意把几个数字记下来,因为它们比抽象论证更能说明”这套东西到底值不值得做”。

说明

质量:+13.7 分↑ 引入独立评审 / 双轨验收这类外置评判机制后的质量提升幅度。验证了”把评判权外置”不是花架子。

说明

成本:$9 ↓ vs $124.70 合理的 Harness 编排把单任务成本从约 $124.70 压到 $9 量级。结构设计直接决定钱包厚度。

这两个数字放一起看挺有意思:一个说质量能升,一个说成本能降。说明 Harness 不是”为了正确性多花钱”的保险,而是设计得好就能同时省钱又提质。决定这两条曲线的,恰恰是前面那些看起来很”软”的东西——权力怎么分、状态怎么存、纠偏走哪条路。

五、一点感想

读完最大的感受是:我原来对 Harness 的理解太”工程”了——以为它就是上下文、工具、循环这些可以拼装的零件。但这几篇文档让我意识到,Harness 真正难的部分其实是**“治理”**:在一个注定会犯错、但可以被纠正的系统里,把”谁说了算""错了怎么办""状态归谁管”这些事安排清楚。

三个我会带走的想法:

把”对错”当成一种需要分权的权力。 不管中心化还是去中心化,核心都是别让执行者自己给自己打分。这一点我以后设计任何 Agent 流程都会先想。
出错先分诊,再开方。 执行型 / 语义型 / 控制型,三种偏差三种治法,别一律重试。
纪律要硬。 能用权限和状态机强制的,就别指望提示词里的”请你遵守”。

说明

说到底,这个领域好玩就好玩在它还没有标准答案。这些文档给我的不是”照着做”的结论,而是几把更好用的尺子——下次再看任何一个 Agent 系统,我至少知道该量它哪几个地方了。

附：偷学的几篇文档

说明

笔记里的角色名、状态机、数字都来自下面这几篇,功劳是它们的,我只是个搬运和琢磨的人。放上入口,方便你们顺藤摸瓜去看原文。