Why Harness Works and Why I Think It Is Not Important
最近事务繁忙，这篇文章先把想法交给 codex 起草。我保留其中的判断，也保留 agent 代笔留下的痕迹。
脚本之外
最近用了一圈好用的 harness 和它们的配套插件——快速总结 skill 的 hermes agent，写代码的神 claude code，还有 ARIS、ralph-loop 之类。一方面，它们确实有用，极大加速了笔者学习和工作的效率；另一方面，也看到了不少像 Openclaw 这种噱头大于实质的 agent。
笔者一直对所谓 agent，或者更时髦一点的 harness engineering，抱有一种矛盾态度。说它只是脚本，好像太轻了：同一个基座模型，套上不同 harness 之后，真实任务表现确实会差很多。说它是新的智能范式，又好像太重了：大多数 harness 拆开看，不过是状态管理、工具调用、失败重试、日志记录、权限隔离、verifier 和 budget control。
笔者自然尊重 harness, 以及当前的各种 agentic 的研究工作。但是笔者想要问的，或者是强调的问题是：harness 到底改变了什么？它的有效性来自哪里？以及这种有效性为什么仍然不构成一种根本重要性？
Agent 与控制论
如果只看当下的 AI 圈，harness 很容易被说成一种新东西：agent framework、tool-use wrapper、workflow engine、multi-agent orchestration、auto-research loop……换一套词，它似乎就带上了革命色彩。可是把时间轴稍微拉长，harness 并不神秘。它更像控制论在 LLM 时代重新露出的一副面孔。
控制论最早关心的并不是“机器有没有心智”，而是系统怎样在扰动中维持目标。Rosenblueth、Wiener 和 Bigelow 在 1943 年的 Behavior, Purpose and Teleology 中讨论目的性行为时，抓住的是 negative feedback：系统观测自身与目标之间的偏差，再用动作缩小偏差。Wiener 后来在 Cybernetics 中把这个领域定义为动物和机器中的控制与通信。把这个定义放到今天看，几乎就是 agent harness 的骨架：观测、误差、动作、反馈、再观测。
harness 的第一层意义，不是“让模型更聪明”，而是把模型放进反馈回路。如果说，裸 LLM 可以看作一个单步生成的开环系统 \(y \sim M(\cdot \mid x)\), 那么控制论意义上的 harness 则是闭环： \[ \text{state} \rightarrow \text{model action} \rightarrow \text{environment/tool} \rightarrow \text{observation} \rightarrow \text{state update}. \]
系统不仅仅问“模型这一次说了什么”，而且追问“这条运行轨迹有没有把系统推向目标”。譬如，写代码 agent 的目标不是吐出一段看起来像 patch 的文本，而是让测试通过、diff 可读、让仓库状态一致、失败可复现。科研 agent 的目标也不该只是写出一篇像论文的文章，而应当形成假设、设计实验、运行实验、读出证据、更新判断。换句话说，harness 把语言模型从一个 generator 放进了 feedback loop，让它成为其中的 controller component。
Ashby 的控制论尤其适合说明这里面的工程直觉。他在 An Introduction to Cybernetics 里提出 Law of Requisite Variety：只有足够的 variety 才能吸收环境的 variety。一个系统面对的扰动越复杂，调节器本身就越需要丰富的状态和动作。放到 LLM harness 上，这句话并不抽象。真实任务会在格式、权限、依赖、网络、测试、资源、上下文、模型幻觉、工具错误、评测漏洞等地方失败。如果 harness 只有 run -> done 两个状态，它当然调节不了这些扰动。于是它长出 parser、retry、timeout、checkpoint、sandbox、verifier、cache、human review、budget control。这些不是装饰，而是 requisite variety。
Conant 和 Ashby 1970 年的 Good Regulator Theorem 说得更直接：每一个好的调节器都必须包含被调节系统的模型。一个 harness 若想调节 agent，就不能只知道“再跑一次”。它必须知道哪些失败可重试，哪些失败致命，哪些状态可恢复，哪些动作越权，哪些输出可以被 verifier 接受。好的 harness 不是更厚的胶水，而是更准确的系统模型。
所以，harness engineering 虽然常常像工程杂活，却经常决定系统表现。控制器的质量不在于叙事有多宏大，而在于它是否把关键状态、关键误差和关键动作编码进闭环。一个能区分 FORMAT_ERROR、TEST_FAILURE、DEPENDENCY_MISSING、UNSAFE_ACTION、BUDGET_EXHAUSTED 的 harness，比一个只会返回 FAILED 的 harness 多了许多调节能力。
To be Continued