2 篇博文 含有标签「agent-harness」

你的编码智能体并不知道它在哪一个分支上。它以为它知道。十二轮对话前它看过 git status 的输出，它的上下文中有一份 CLAUDE.md 提到了会话开启时的分支名称，并且它观察到一个工具结果列出了五个当时正确的文件。从那时起，智能体就一直在基于那个快照进行静默推理。与此同时，你在另一个终端里运行了 git checkout main。智能体的 diff 顺利地写入了文件系统，因为操作系统并不关心这些字节属于哪个分支。这个 diff 在语义上是错误的，因为智能体对分支的心理模型已经落后了 300 个提交，且它所基于的父节点在你的工作树中已不复存在。

这就是分支状态漂移 (branch-state drift)，它是数据库中“读-改-写”竞态 (read-modify-write race) 在编码智能体领域的翻版。智能体在第 N 轮读取世界状态，在第 N+1 到 N+k 轮之间修改计划，并在第 N+k+1 轮写回磁盘——而在这一时间窗口内的某个时刻，它脚下的世界已经发生了变化。没有异常抛出，没有工具返回错误。补丁被应用了。危害在下游显现：针对错误的基准分支开启了 PR，手动提交的代码被静默回滚，或者针对昨天刚迁移过的模式 (schema) 实现了新功能。

大多数运行 AI 编程智能体（AI coding agents）的团队都在优化错误的变量。他们过度痴迷于模型选择 —— Claude vs. GPT vs. Gemini —— 却将周围的脚手架视为次要的配套工作。但基准测试数据和生产环境的实战经验告诉我们一个不同的故事：一个在演示中令人惊叹的模型与一个能够可靠交付生产代码的模型之间的差距，几乎完全取决于其周围的控制环（harness），而不是模型本身。

这个公式看似简单：智能体 = 模型 + 控制环 (Harness)。控制环是除此之外的一切 —— 工具 schema、权限模型、上下文生命周期管理、反馈循环、沙箱环境、文档基础设施、架构不变性。如果控制环搞错了，即使是最前沿的模型也会生成虚构的文件路径，在会话进行到 20 轮时破坏自身的约定，甚至在没写任何测试之前就宣称功能已完成。