怎么理解 Agent = Model + Harness

背景

“Agent = Model + Harness” 这一表述，最早源于 LangChain、OpenAI SDK、Anthropic、Cognition、Cursor 等 AI Infra 公司在实际工程中逐渐形成的共识。早期业界普遍认为 Agent 等价于一个“超级聪明的大模型”，但真正上线后才发现，大模型在 Agent 中真正负责的部分仅包括：理解问题、推理、决策、写少量代码、输出下一步。而真正复杂且占据大量工程量的部分——工具调用、状态管理、上下文压缩、错误恢复、权限控制、Memory、Observation、Workflow、Retry、Logging、Evaluation——全部都不是模型本身。因此，行业开始用“Agent = Model + Harness”来概括这种架构，其中 Harness 指的是将模型“驾驭”起来的一整套运行框架。

核心内容

原文对 Harness 的理解分为四个层次，并在此基础上补充了缺失的关键组件，最终给出一个更完整的 Agent 定义。

第一层：Context Harness

决定模型“看到什么”。包括用户问题、历史对话、Memory、工具结果、长上下文、Prompt 等。很多 Agent 的性能瓶颈不在于模型本身，而在于 Harness 决定了模型接收到的输入内容。

第二层：Execution Harness

模型输出“Call Search”后，实际执行调用的是 Harness。它负责执行（execute()）、拿回结果、继续喂给模型。涵盖 Tool Calling、MCP、Function Calling、API、Browser 等。

第三层：Loop Harness

Agent 能够持续工作的循环机制 —— Think → Act → Observe → Think → Act → Observe。这个循环由 Harness 控制，而非模型自发。本质上，ReAct 就是一种典型的 Harness。

第四层：Recovery Harness

Agent 最大的问题是失败：Tool timeout、API error、404、Permission denied、JSON parse failed 等。模型不会处理这些，Harness 提供 Retry、Fallback、Alternative Tool、Repair JSON、Human in loop 等恢复机制。上线后这部分代码量可能超过 Prompt。

模型职责的演变

随着 Harness 的剥离，模型职责越来越“纯”：从原本负责 Planning、Tool、Memory、Workflow、Coding、Everything，逐步收缩为只负责 Reasoning、Decision、Planning、Generation。其他全部外包。原文用一个比喻：Model 更像 CPU，Harness 更像 Operating System。

原文的补充层

原文认为上述定义还缺两层：

1. Environment：Agent 能力很大一部分来自它能够接触的世界。例如 Claude Desktop 的强大并非因为 Claude 模型本身，而是因为 Claude + MCP + Filesystem + Git + Browser + Slack + Notion。Agent 能做什么，80% 取决于它能否接触世界，而非它会不会推理。因此可以写成 Agent = Runtime + Model + Environment 或 Agent = Reasoning + Execution + World。

2. Memory：长期 Agent 必须依赖 Memory。短期包括 Conversation、Scratchpad；长期包括 User Preference、Past Experience、Project Knowledge、Failures、Learned Skills。没有 Memory，Agent 永远像第一天上班。因此可以写成 Agent = Model + Harness + Memory。

最终架构图

原文用文字描述了一个分层流程：

• Goal 输入 Model（Reasoning）→ 输出 Decision/Plan → 传递给 Harness（Runtime）→ Harness 分别与 Memory、Tools、Environment 交互 → 得到 Observation → 反馈回 Model → 循环。

其中：

• Model 决定“怎么想”（推理、规划、判断）
• Harness / Runtime 决定“怎么执行”（循环、工具调用、错误恢复、状态管理）
• Memory 决定“是否积累经验”（跨会话、跨任务的持续能力）
• Environment 决定“能影响什么世界”（浏览器、代码、文件、业务系统、机器人等）

精力分配建议

• 20% 模型能力：理解推理、Prompt、工具调用等基本能力
• 50% Harness / Runtime：上下文管理、工作流、状态机、调度、容错、可观测性
• 30% Environment 与 Memory：如何连接真实业务系统，如何让 Agent 跨任务积累知识和经验

总结

原文最终观点：“Agent = Harness + Model” 是优秀的工程起点，但不是终点。真正完整的 Agent 更像是：Agent = Model（思考） + Harness（执行） + Memory（积累） + Environment（工作环境）。如果用人类比喻：模型是大脑，Harness 是神经系统和身体协调机制，Memory 是长期记忆，Environment 是这个人能够接触和改变的世界。只有四者协同，Agent 才真正具备持续完成复杂任务的能力。

关键要点

• Agent 不是超级大模型，而是模型与运行框架（Harness）的组合。
• Harness 至少包含四层：Context、Execution、Loop、Recovery。
• 模型职责变纯，主要负责推理、决策、规划、生成，其余由 Harness 承担。
• 比喻：Model 像 CPU，Harness 像 Operating System。
• 缺少 Environment 和 Memory 会导致 Agent 能力受限：80% 能力来自能接触的世界，Memory 让 Agent 积累经验。
• 最终完整定义：Agent = Model（思考） + Harness（执行） + Memory（积累） + Environment（工作环境）。
• 开发精力分配建议：模型 20%，Harness/Runtime 50%，Environment 与 Memory 30%。

意义与影响

原文澄清了 Agent 领域一个长期存在的误解——将 Agent 能力简单归因于模型本身。通过拆解 Harness 的四个层次，揭示了工程实践中真正需要投入大量精力的部分：上下文管理、循环控制、错误恢复和工具调用。这一观点对 AI 开发者和架构师有直接指导意义：盲目追求更强模型不如优化运行时框架和连接真实环境。

此外，原文将 Memory 和 Environment 纳入 Agent 定义，突破了“模型+工具”的狭义框架，强调跨任务积累能力和与真实世界交互的重要性。这种视角有助于构建更持久、更实用的生产级 Agent 系统，而非仅停留在 Demo 阶段。对于行业而言，它引导社区从“模型竞赛”转向“基础设施竞赛”，推动 Agent 走向工程化、可观测和可维护。