核心要点
- 文章提出清晰公式：Agent = Model + Harness。
- 凡是不属于模型本身、但能让模型变成可工作的 agent 的部分，都属于 harness。
- harness 覆盖 prompt、工具、技能、MCP、文件系统、沙箱、浏览器、编排逻辑和 hooks/middleware。
- 理解 harness 的边界，有助于把 agent 设计从“写 prompt”升级为“设计系统”。
原文链接 English Original — LangChain Blog, by Vivek Trivedy
这篇文章试图回答一个经常被说烂、但很少被说清楚的问题：什么是 harness？ 作者给出的定义非常干脆——Agent = Model + Harness，只要不是模型本身、但又参与了 agent 行为形成的那部分系统，都属于 harness。 按照这个定义，harness 包括很多平时容易被分散讨论的部件：system prompt、tools、skills、MCP 及其描述、文件系统/浏览器/沙箱等捆绑基础设施、subagent/handoff/model routing 之类的 orchestration 逻辑，以及 compaction、continuation、lint check 等 hooks 或 middleware。换句话说，一个“裸模型”不是 agent；它只有被 harness 包装后，才拥有状态、工具执行、反馈循环和可约束行为。 文章的推导路径很有启发：不是从“常见框架有什么功能”出发，而是从“我们希望 agent 具备什么行为，而模型原生做不到什么”倒推。模型本质上只是接收输入、输出文本，它不会天然持久化状态、不会执行代码、不会访问实时知识、不会自己准备工作环境。因此，所有这些能力都必须通过 harness 层补上。 这篇文最有价值的地方，在于它帮助团队建立了一条干净的系统边界：当 agent 表现不好时，问题不一定在模型，也可能在 harness 设计本身。这样一来，优化方向就不再局限于“换模型”或“改 prompt”，而是可以系统性地检查工具定义、流程编排、状态管理和执行约束。 如果说 prompt engineering 是在和模型说话，那 harness engineering 更像是在给模型搭建工作场。后者才是 agent 真正能否稳定交付价值的关键。