Agent Harness 拆解：从工具调用到组织级治理

harness 不是包装层，它是 agent 变成产品的机器。

一个裸模型没有持久状态，没有工具权限，没有项目边界，没有错误恢复，也没有证据记录。它可以回答问题，但很难独立承担真实任务。

所谓 agent harness，就是把模型放进一个可执行环境：它负责组装上下文、暴露工具、执行工具调用、持久化状态、处理错误、触发验证、控制权限和记录证据。

所以我越来越认同一句判断：当两个产品使用相同模型时，差异往往来自 harness，而不是模型本身。

提示词工程、上下文工程、harness 工程，是三个不同层级。

提示词工程解决“模型应该怎么理解任务”。上下文工程解决“模型此刻应该看到什么”。harness 工程则解决“模型如何在真实环境里持续行动”。

很多 agent 失败，不是因为 prompt 写得不够长，而是因为上下文被污染、工具调用失败、状态丢失、权限不清、验证缺席。

这也是为什么只优化 prompt 很快会遇到天花板。生产级 agent 需要的是围绕模型的一整套软件系统。

我会把 harness 拆成 9 个核心组件。

第一是编排循环：决定模型何时思考、何时行动、何时停止。第二是工具层：注册工具、验证参数、执行并返回结果。第三是上下文层：控制模型看到什么、何时压缩、何时检索。

第四是状态层：保存任务进度、产物、检查点和恢复点。第五是记忆层：跨会话保留经验，但不能把记忆当事实。第六是权限层：决定哪些工具和路径能被触碰。

第七是错误处理：把失败变成下一轮输入。第八是验证循环：测试、类型检查、视觉检查、LLM 评审。第九是 trace/evidence：让过程可复盘、可审计。

harness 会变薄，但不会消失。

随着模型能力增强，一些显式步骤会被模型内化。过去需要复杂规划器的地方，可能会变成简单工具调用；过去需要管理 agent 的地方，可能会变成结构化 handoff。

但这不意味着 harness 会消失。即使模型更强，也仍然需要上下文窗口管理、工具执行、权限、状态、审计和验证。

更准确的说法是：坏的 harness 会被淘汰，好的 harness 会变得更薄、更清晰、更贴近模型训练时熟悉的操作面。

公司需要的不只是 harness，而是 harness governance。

单个 harness 可以让一个 agent 好用。但公司会同时拥有多个 harness：IDE、CLI、SDK、CI、浏览器、飞书、数据平台、内部工具。

如果每个 harness 都有自己的权限、状态、记忆和证据格式，公司就很难形成统一治理。最终结果是自动化很多，但组织层面不可解释。

这就是 IntentDNA 的入口：它不替代所有 harness，而是为它们提供统一的意图声明、约束编译和证据标准。

IntentDNA 应该治理 harness 的边界，而不是重写 harness 的全部能力。

我不想把 IntentDNA 做成另一个 LangGraph、CrewAI 或 Agents SDK。它更应该像一层控制面：输入是组织意图，输出是各个 harness 能执行的约束、提示、权限、验证和证据协议。

这条路线要求 IntentDNA 对每个 harness 保持诚实：支持什么、不能支持什么、只能软约束什么、能硬拦截什么，都要清楚写出来。

真正的竞争力，不是“我也有 agent loop”，而是“我能让多个 agent loop 服从同一套组织意图”。

这些判断背后有清晰的行业信号。

我引用这些来源，是为了把个人判断放回更大的市场、资本和工程实践背景里。它们共同指向一个趋势：AI 的竞争点正在从“模型调用”转向“工作系统设计”。