Agent = Model + Harness

核心等式

AI Agent 不仅仅是一个语言模型。它是一个嵌入在 Harness 中的语言模型 — Harness 是决定模型能看到什么、能做什么、能记住什么的周围基础设施。

Agent = Model + Harness

将模型想象成引擎。Harness 就是汽车 — 方向盘、刹车、悬挂、燃油系统。世界上最好的引擎，没有底盘来驾驭它，也毫无用处。反过来，一个精心设计的 Harness 可以让中端模型超越一个基础设施糟糕的前沿模型。

这里的 + 表示结构组合，而非独立叠加。Model 与 Harness 是协同演化的：Harness 编码了对模型能力的假设，而这些假设会随着模型改进而过时。更精确的表达是 Agent = f(Model, Harness) — 两者互相约束、互相塑造。加法公式捕捉了结构层面的洞察；动态交互关系在后续章节中详细展开。

这一洞察源自 Anthropic 在 2024 年底至 2026 年初发布的一系列工程文章，代表了业界对构建 AI Agent 思维方式的根本转变。瓶颈不再仅仅是模型智能 — 而是模型周围系统的工程。

什么是 Harness？

Harness 是包裹 LLM 使其成为功能性 Agent 的一切：

组件	作用
系统提示词	指令、角色、约束 — 模型的”工作简报”
工具	模型可调用的函数，用于与外部系统交互
上下文管理	什么信息进入上下文窗口，以及何时进入
会话状态	超越单个上下文窗口持久化的记忆
编排循环	调用模型、路由工具调用、处理错误的控制流
评估	在执行模型输出之前进行质量检查
沙箱	生成的代码安全运行的执行环境

模型提供智能。Harness 提供结构、安全和持久性。两者缺一不可。

从广义 Harness 到三组件解耦

上表是 Harness 的广义定义 — 模型之外的一切。这一定义来自 2024–2025 年的早期实践，它捕捉了”瓶颈不在模型”的关键洞察。

但 2026 年 4 月的 Managed Agents 将这一思考推进了关键一步：广义 Harness 本身也需要解耦。将所有非模型组件打包在一起，会制造出不可替换的”宠物”系统（详见该章”不要养宠物”一节）。更精确的分解是：

Session — 独立的持久事件日志（上表中的”会话状态”被提升为独立组件）
Harness（狭义） — 仅指编排循环（上表中的”编排循环 + 上下文管理 + 评估”）
Sandbox — 可丢弃的执行环境（上表中的”沙箱 + 工具”）

三个组件可以独立失效、独立替换。这一分解是本节最终章的核心主题。

本节中，除非另有说明，“Harness” 均指广义定义 — 模型之外的一切。当需要区分时，会使用”Harness（狭义）”。

公式省略的一个维度：人类参与者。生产环境中的 Agent 在人机协作检查点 (Human-in-the-Loop)、权限边界和反馈循环中运行。人类提供意图、监督和纠偏 — 是 Agent 系统的参与者，而非 Harness 的组件。

为什么 Harness 工程很重要

模型在进步，Harness 必须进化

Anthropic 研究中的一个反复出现的主题：Harness 编码了对模型能力的假设，而这些假设会随着模型的改进而过时。 例如：

Claude Sonnet 4.5 表现出”上下文焦虑” — 在接近上下文限制时提前结束任务。Harness 添加了上下文重置来补偿。Claude Opus 4.5不再表现出此行为，使这些重置成为无用的负担。
早期 Harness 将工作分解为小型”迭代”，因为模型无法在长任务中保持连贯性。Claude Opus 4.6 改进了长期规划能力，使迭代分解成为不必要的脚手架。

教训：每个 Harness 组件都编码了一个值得压力测试的假设。 当新模型到来时，重新审视你的 Harness 并剥离不再承重的组件。

模型是商品，Harness 是产品

随着基础模型在能力上趋于一致，差异化转向 Harness。使用相同模型的两个团队会因 Harness 工程的不同而产生截然不同的 Agent 质量：

如何跨长会话管理上下文
如何在多个 Agent 之间分解任务
如何验证和评估模型输出
如何从失败中恢复

这就是为什么 Anthropic 越来越多地将 Agent 开发定义为 Harness 工程 — 围绕模型构建正确基础设施的技艺。

Agent 工程的演进

Anthropic 关于 Agent 开发的思考经历了四篇不同的发表物，每篇都在前一篇的基础上构建：

发表物	时间	关键贡献
Building Effective Agents	2024.12	Agent 模式分类：Workflow vs. 自主 Agent
Effective Harnesses for Long-Running Agents	2025.11	多会话任务的双 Agent Harness
Harness Design for Long-Running Apps	2026.03	GAN 启发的三 Agent 架构
Scaling Managed Agents	2026.04	基础设施：将大脑与双手解耦

第五个贯穿主题 — Context Engineering — 贯穿所有四篇发表物，代表着从优化单个提示词到管理 Agent 整个信息生命周期的转变。由于它足够重要，已独立成章。

三个原则

从这些发表物中，浮现出三个原则：

1. 从简单开始，仅在需要时增加复杂性

“最成功的实现使用简单、可组合的模式，而非复杂的框架。” — Building Effective Agents

不要一开始就搭建多 Agent 编排系统。从单次模型调用和好的提示词开始。添加工具。添加评估。添加多 Agent 协调。每一层复杂性都应该由可衡量的改进来证明。

2. 将生成与评估分离

“被要求评估自己工作的 Agent 会自信地赞美平庸的输出。” — Harness Design for Long-Running Apps

自我评估偏差是一个根本性限制。做工作的 Agent 不应该是评判工作的 Agent。将生成器与评估器分离 — 调整独立评估器使其持怀疑态度，比让生成器自我批判要容易得多。

3. 为模型进步而设计

“每个 Harness 组件都编码了值得压力测试的假设 — 它们可能是错误的，并且会随着模型的改进而迅速过时。” — Harness Design for Long-Running Apps

更好的模型需要更少的脚手架，但同时为实现先前不可能的能力的更雄心勃勃的 Harness 创造了空间。Harness 工程师的工作是持续找到当前模型能力的正确结构水平 — 既不过度约束能力强的模型，也不对能力有限的模型支持不足。

阅读指南

本节详细追溯 Anthropic 的 Harness 工程系列发表物：

Agent 模式 — 构建模块：从增强型 LLM 到自主 Agent。奠定一切基础的分类体系。
长时运行 Harness — 如何让 Agent 跨多个上下文窗口工作。初始化器/编码器模式。
多 Agent Harness — GAN 启发的规划器/生成器/评估器架构，用于复杂应用开发。
Managed Agents — 规模化基础设施：将大脑与双手解耦、会话作为持久日志、以及超越实现的接口。

横贯主题 Context Engineering 独立成章 — 压缩、记忆设计、提示词分层与渐进式披露，在那里被作为一个统一的设计学科集中阐述。

来源

Building Effective Agents — Anthropic, 2024.12
Effective Harnesses for Long-Running Agents — Anthropic, 2025.11
Harness Design for Long-Running Application Development — Anthropic, 2026.03
Scaling Managed Agents: Decoupling the Brain from the Hands — Anthropic, 2026.04
Effective Context Engineering for AI Agents — Anthropic, 2026