智能体需要 Harness，不只是更强的模型

当企业把自身的业务知识、当前状态和执行边界组织成 Context，模型才有了判断的基础。但判断不会自动变成可靠的行动。Agent 还要调用工具、改变外部状态、处理失败，并在每一轮执行后判断下一步。

这个从“模型能够作出判断”到“系统能够稳定完成任务”之间的空缺，需要 Harness 来填补。

Agent 能力来自模型与运行系统的组合

很多智能体失败，第一眼看上去都像模型问题。模型选错了工具，忘了目标，太早停下来，写出了不合法的 JSON，或者很自信地说某个操作已经成功，但真实系统里根本没有发生。

更强的模型确实会修掉其中一部分问题。它会推理得更好，更能遵循指令，也更少需要提示词里的补丁。

但这不等于模型本身就是智能体。

智能体是运行在一个系统中的模型。这个系统向它提供 Context、工具、状态、边界和反馈，并决定任务如何持续推进。Anthropic 对此有一个有用的区分：Workflow 让 LLM 和工具沿预先写好的代码路径运行；Agent 则由 LLM 根据当前 Context，动态决定步骤和工具使用。无论使用托管 SDK 还是直接调用模型 API，总要有一层系统管理多轮执行、工具派发、状态、边界和轨迹。

我这里说的 Harness，就是这层 runtime / 工程外壳。它不是魔法框架，也不是一堆提示词，而是把模型调用变成可靠产品的那部分系统。

Harness 将 Context 与工具转化为可靠执行

最简单的公式仍然有用：

Agent = LLM + 上下文 + 工具

但生产环境里的完整版本应该是：

Agent = Model + Harness

其中 Harness 包含：

上下文 + 工具 + 约束 + 验证 + 纠正

Context 让模型能够感知系统指令、对话历史、文档、检索结果、工具定义、记忆和任务当前状态。工具让模型能够行动：调用 API、搜索、编辑文件、运行代码、创建工单，或者把任务交给另一个 Agent。

这两层让智能体“能做事”，但还不能保证它“可靠地做事”。

可靠性来自外面的三层。约束决定它能做什么、不能做什么：权限、schema、沙箱边界、速率限制、花费限制、人工审批。验证检查事情是不是真的做对了：数据库状态、测试、断言、grader、trace、工具返回值。纠正负责出问题后的处理：重试、澄清、回滚、压缩上下文、从持久状态恢复，或者安全停止。

这就是演示和生产系统之间的差距。演示只能证明模型某一次能够完成任务。Harness 要让系统在不完整信息、工具失败和状态变化中仍然可以反复达成结果，并在出错时留下足够证据，支持调试和改进。

执行循环的职责边界决定系统形态

不是每个有用的系统都应该设计成完全自主的 Agent。Anthropic 建议从最简单的可行方案开始，只有在 Agent 自治明确改善结果时才增加复杂度。对于路径已知、边界稳定的任务，预定义 Workflow 往往比自由运行的 Agent 更可靠。

因此，Harness Engineering 不等于采用重型 Agent Framework。很多任务只需要一条简单的 Workflow：分类、路由、调用工具并检查结果；有些任务适合 Prompt Chaining，并在每一步设置验证关卡；有些任务适合 Evaluator-Optimizer Loop。只有当任务步骤无法预先确定时，才需要由 Agent 根据环境反馈规划、调用工具并调整策略。

架构上的关键不是采用哪个名称，而是明确哪一层负责执行循环。

系统必须决定下一轮向模型提供哪些 Context、哪些工具结果可以进入推理过程、何时需要人工介入、何时停止，以及如何跨轮保存状态。托管 SDK 可以承担其中一部分职责；直接调用模型 API 时，应用团队需要自行实现更多运行逻辑。无论采用哪种方式，这些选择都属于产品与系统设计，而不是无关紧要的实现细节。

工具调用的可靠性首先取决于接口设计

模型不会真正执行工具。它只是在请求使用工具。Harness 负责解析请求、校验参数、应用权限、在正确环境里执行，再把结果返回给模型。

这个边界，决定了很多智能体质量。

Anthropic 把这里叫 ACI：Agent-Computer Interface。一个好工具不只是内部 API 的薄封装，而是为模型设计过的接口。名字要直观，参数要不容易误用，工具描述要写清限制、例子和边界条件。如果 agent 改变工作目录后相对路径容易出错，那就要求工具必须使用绝对路径。如果退款金额不能超过订单金额，就在工具边界上让这种错误不可能发生，而不是指望模型每次都记得。

OpenAI Agents SDK 也在往同一个方向走：function tools 会生成 schema，MCP tools 通过一致的接口暴露给 agent，tool guardrails 可以在自定义工具执行前后做检查，traces 会把工具调用、模型轮次、handoffs 和 guardrails 一起记录下来。

这里的教训很简单：不要只是把提示词写得更用力。要把环境设计成“正确动作比错误动作更容易”。

长任务的连续性依赖模型外部的持久状态

短任务往往可以塞进一次模型调用，或者至少塞进一个上下文窗口。长任务不行。

Anthropic 关于 long-running harness 的文章讲得很具体：如果一个 agent 要跨几个小时、几天工作，它就一定会跨越多个 context window。Compaction 有帮助，但光有 compaction 不够。下一次 session 还需要知道之前发生了什么，试过什么，还剩什么，以及哪些 artifact 才是可信来源。否则，新的模型实例就像中途接班、却没有交接记录的工程师。

对产品系统来说，这意味着 Harness 必须在模型调用之外保存状态。保留只追加的消息记录或 trace。保存工具结果。保存 artifact。把旧上下文压缩成摘要，但不能删掉模型保持连贯所需的锚点。Resumability 应该是系统设计出来的能力，而不是长上下文窗口带来的侥幸。

这也是为什么可观察性不是可选项。OpenAI 的 tracing 会记录模型生成、函数调用、guardrails、handoffs 和自定义事件。Anthropic 在讲 evals 时，也把 transcript、outcome、grader 和 evaluation harness 当成一等对象。你看不见轨迹，就没法评估 agent。没法评估，就没法安全地改进。

Harness 中的脚手架必须随模型能力演进

Harness 工程也有一个危险：脚手架会变成化石。

每一个 workaround 都编码了一条关于当前模型能力的假设。模型不会规划，所以你提前把任务拆得很碎；模型管不好上下文，所以你过度 reset；模型不适合某种工具格式，所以你加了很多额外包装。这些假设有些现在成立，有些会在模型进步后失效。

Anthropic 的 Managed Agents 文章很好地纠正了“脚手架越多越好”的直觉。Harness 会编码假设，而这些假设需要经常被重新检查。真正耐用的，不是每一个 workaround，而是稳定接口：session、harness、sandbox、tools、permissions、traces、evals。

所以，Harness 应该由原语搭起来，而不是由习惯堆起来。消息记录要稳定，工具边界要清楚，沙箱要可替换，检查要能量化。等某段 scaffolding 开始妨碍模型，而不是帮助模型，就应该删掉。

模型决定单步能力，Harness 决定端到端可靠性

正确的结论不是“模型不重要”。模型当然重要。模型选择会影响推理、工具使用、延迟、成本、上下文长度和多模态能力。很多 agent 任务里，一个更强的 reasoning model 就是可用和不可用的区别。

但模型进步和 Harness 工程解决的是两个不同问题。

更强的模型，抬高每一次决策的上限。更好的 Harness，抬高整次运行的下限。它让上下文可用，工具可用，权限可执行，结果可验证，失败可恢复，行为可观察。

这就是智能体为什么需要 Harness。不是因为模型弱，也不是因为每个团队都该上重型框架，而是因为真实工作会跨越多轮、工具、状态、失败和信任边界。模型提供智能，Harness 把智能变成可靠行动。

相关阅读

• 为什么笃定 AI：企业真正需要的是什么 —— 从企业认知任务出发，解释为什么值得长期投入 AI。
• 企业 Context 重构：AI 原生转型的基础工程 —— Harness 在每一步如何组装 Context，并把行动结果带回下一轮判断。
• 生产级 Agent 的评估与监控 —— 如何把真实失败转化为 Harness 和 Agent 系统的持续改进依据。
• Harness 工程 —— 更完整地展开上下文、工具、约束、验证和纠正。
• Agent 长任务的瓶颈，是上下文工程 —— 为什么设定长任务天花板的不只是模型，还有上下文窗口。