harness agent 到底指什么：六类职责

先给一个能把人吓一跳的数。

同一个任务、同一个模型，只改 harness 的信息量（数据来自 The Interplay of Harness Design and Post-Training in LLM Agents）：GPT-5 Mini 在 Pick-2 任务上从 17.1% 涨到 61.0%，43.9 个百分点。同一篇里还有更狠的一组：Qwen2.5-3B 配好 harness，比 Qwen2.5-7B 配差 harness 高 14.1 个点。原文的说法是 “the choice of harness can outweigh the effect of model capacity”。

模型大一倍，抵不过 harness 写得好一点。这句话如果成立，那「换个更强的模型试试」这个最常见的动作，很多时候是在解错的题。

这个词的定义，各家出奇地一致

翻了一圈论文、大厂工程博客和开源实现，harness 的定义收敛得很干净：

模型之外的一切。

Martin Fowler 站上那篇讲 coding agent 的文章原话是 “everything in an AI agent except the model itself”。LangChain 那篇写成一个等式：agent = model + harness，并把 harness 定义为「连接模型和真实世界的脚手架」。学术那边，2026 年那篇综述直接写成 LLM agent = foundation model + execution harness。

这个定义的价值不在它说了什么，在它划走了什么。 提示词归 harness，工具、状态、崩溃恢复、观测也都归 harness；模型那边只剩下推理本身。于是「agent 效果不好」这句话可以被拆成一个能回答的问题：瓶颈在模型、在 harness、还是在两者的耦合。

六类运行时职责

综述 From Question Answering to Task Completion 把 execution harness 拆成六类彼此耦合的职责。这份清单比「记忆、工具、规划」那种三件套贴近实现得多：

职责	回答什么
Observation 观察	怎么感知环境
Context 上下文	信息怎么流动、怎么装配
Control 控制	谁决定下一步
Action 动作	怎么调工具、怎么产出
State 状态	跨越长时程的信息怎么留住
Verification 验证	凭什么说做完了、做对了

值得留意的是它们是「耦合」的，不是六个可以分头做的模块。上下文装配依赖状态里留了什么，验证依赖观察记了什么，控制决定了动作的边界。任何一格改动，都会从别的格里冒出来。

另一份社区整理的清单给了五格：上下文管理、工具执行与沙箱、持久状态、记忆检索，再加上护栏与人在环。它和六职责基本能对上，只是把 Control 拆进了别处，并把「护栏 + 人在环」单列 —— 那是工程视角，六职责是研究视角。

loop、harness、graph：三层，不是三派

这三个词经常被混着用，其实分工很清楚 —— 这篇技术对比和 MindStudio 那篇把边界划得最干净。

Loop engineering 管「做什么、什么时候停」。 它设计的是 agent 迭代的节奏：每一遍做什么、怎么判断进展、什么条件下停下来。观察 → 行动 → 验证 → 恢复 这个循环，是 loop engineering 的对象。

Harness engineering 管「在哪跑、能碰什么、崩了怎么办、怎么被看见」。 一句话对照：loop 是 agent 的行为，harness 是 agent 的环境。

Graph engineering 管「什么被允许继续往下走」。 这句话我认为是三者里最精准的定义 —— 它关心的不是 agent 在做什么，而是哪条路被批准通行。节点、条件路由、并行分支，都是这一层的表达方式。

所以它们不是三种流派，是三层：

graph    ── 什么被允许继续      （路由、分支、并行）
  loop   ── 做什么、何时停      （迭代节奏、停止条件）
    harness ── 在哪跑、能碰什么  （环境、工具、状态、观测）

有一篇论文把这个关系推到了极端：From Agent Loops to Deterministic Graphs 主张用预定的 DAG 替换掉反应式的 agent loop，理由是 loop 的非确定性让结果不可复现 —— 同样的输入，因为模型采样的微小差别，会走出完全不同的执行路径。它提出的解法叫 execution lineage：完整记录跑了哪些节点、各自的输入输出，从而支持精确重放。这和 Sentry SDK 用面包屑重建崩溃前那几步是同一个思路 —— 现场不是崩的那一刻，是崩之前发生了什么。

这条值得单独记住，因为它把「要不要给模型控制权」从审美问题变成了工程问题：交出控制权，就交出了可复现性；而没有可复现性，任何 A/B 和消融都做不成。

这一条我是先踩后读的。自己那套东西一开始就写成了固定流水线，当时给自己的理由只是「步骤本来就确定」；直到做消融实验的时候才发现真正的好处在别处 —— 两版跑同一批题，路径一致，相减才有意义。如果模型每次自己决定走哪条路，那个差值里混着的就不只是我想量的那个变量。

Fowler 的四象限：guides × sensors

Martin Fowler 站上那篇给了一个我认为最实用的切分，尤其对做质量工具的人。

harness 里的控制手段分两类：

Guides（前馈） —— 事前起作用，提高「第一次就做对」的概率。文档、规则、脚手架、约定。
Sensors（反馈） —— 事后起作用，观测产出并触发自我纠正。它强调 sensors 的信号要为 LLM 的消费而优化，不是给人看的。

每一类再按执行方式分两种：

	Computational（确定性、快）	Inferential（语义、概率性）
Guides	类型系统、脚手架模板、lint 规则	生成前的需求澄清、示例检索
Sensors	测试、类型检查、静态分析	AI code review、LLM-as-judge

这张表的用法是盘点：你的 harness 在四个格子里各有什么。绝大多数团队的分布是严重偏斜的 —— 左下角（测试、lint）很满，右上角（生成前的引导）基本空着。

Fowler 那篇还有一条排序原则叫 Keep Quality Left：越早发现问题越便宜，所以快的控制放提交前，贵的 sensor 放集成后。

顺带澄清一个常见混淆：context engineering 是手段，harness engineering 是策略。 原文说得很直接 —— 上下文工程提供了「把 guides 和 sensors 送到 agent 面前」的能力，而给 coding agent 造一层用户 harness，是上下文工程的一种具体形式。

这份清单最该被拿来做什么

不是照着填满。是照着盘点，然后决定哪几格不填。

那篇讲 harness 与后训练的论文里有一组数，说明「不填」的代价有时候比「填错」更小、有时候大得多：用信息量低的 harness 训练出来的模型，一旦工具 schema 变化，正确率从 55.6% 掉到 2.7% —— 比不训练的基线还低 10.8 个点。而用信息量高的 harness 训出来的，同样的变化下还有 69.6%。

同一个模型、同一份训练方法，只因为训练时用的 harness 不同，抗变化能力差了一个数量级。 这件事没法靠事后补 —— 那正是第三篇和第四篇要拆的。

边界与代价

六职责是描述性的，不是处方。 它告诉你一个 harness 可能有哪些面，不告诉你你的场景需要哪几面。照着六格全填是过度工程，而 Anthropic 那篇讲长时程 harness 的文章有一句正好针对这个：harness 里的每一个组件，都编码了一个「模型自己做不到某件事」的假设，而这些假设值得被压力测试。 模型换代之后，很多组件编码的假设已经不成立了，它们从帮手变成了负担。

「模型之外的一切」这个定义太宽。 宽到它同时包含了提示词模板和 Kubernetes 配置。所以真正干活的时候还得往下切一层 —— 六职责、五组件、四象限都是切法，用哪一个取决于你要回答什么问题。

这些数字来自特定的基准。 43.9 个点是 ALFWorld 扩展环境上的 Pick-2 任务，不是普适规律。可以拿它论证「harness 的杠杆可能很大」，不能拿它论证「你的 harness 改一改就能涨 40 个点」。

上面这套清单是通用 harness 的清单。而一个做垂直业务的 harness —— 比如从产品文档生成测试用例 —— 对着这六格会发现两件事：有的格根本不适用，有的格清单上压根没有。

比如「模型不调工具」的时候，Action 这一格是空的；而「凭什么说这条断言是对的」这个问题，六格里的 Verification 装不下，因为它在垂类里要分层。

下一篇拆通用与垂类的差别。