Agent = Model + Harness：一个让我重新理解自己工作定位的框架

最近读到一篇来自 LangChain 团队的文章 “The Anatomy of an Agent Harness”，55 万浏览量，1500+ 点赞。读完之后最大的感受不是学到了某个新技术，而是过去几个月零散学到的东西突然被一根线串起来了。

这篇博客记录我的阅读过程和由此引发的思考。

一句话击中我的那个定义

Agent = Model + Harness. If you’re not the model, you’re the harness.

Harness 是模型之外的一切：代码、配置、执行逻辑。裸模型不是 agent——它只接收文本，输出文本。当 harness 给它加上状态、工具执行、反馈循环和可执行的约束后，它才变成 agent。

AI application engineering 也可以叫做 harness engineering 。不是训练模型，不是做算法研究，而是围绕模型的智能构建系统，让这个智能变得可用、可靠、可控。

最优雅的部分：从期望行为反推设计

文章没有列一张功能清单说"harness 应该有这些东西"。它的方法论是反过来的：

我们希望 agent 具备什么行为 → harness 需要提供什么来实现它

这个推导链条是这样的：

  • 想让 agent 操作真实数据并持久化 → harness 提供文件系统 + Git
  • 想让 agent 自主解决问题而不需要人预设每个工具 → harness 提供 Bash + 代码执行
  • 想让 agent 安全执行并自我检查 → harness 提供沙箱 + 验证工具
  • 想让 agent 记住经验、访问新知识 → harness 提供 Memory 文件 + Web Search + MCP
  • 想让 agent 在长对话中不降质 → harness 提供 Compaction + Tool Offloading + Skills
  • 想让 agent 完成跨多个 context window 的长周期任务 → harness 提供 Ralph Loop + Planning + Self-verification

每个 harness 组件的存在都不是"因为别人也有"，而是"因为模型原生做不到这件事"。这个推导方式本身就值得学习——它是一种系统设计的思维方式。

harness engineering 串联现有的 agent 技术

Context Engineering —— 文章里有一句话非常精准：“Harnesses today are largely delivery mechanisms for good context engineering.” 我之前花了大量时间学 Anthropic 的 Contextual Retrieval 论文、Compaction 策略、Structured Note-taking 这些技术。现在我明白了，这些全部属于 harness 的 context 管理层。Compaction 解决 context rot，tool call offloading 避免大输出挤占 context 空间，skills 的 progressive disclosure 控制初始加载量——都是在保护 context 这个稀缺资源。

ReAct 和 Agent Loop —— 文章把 ReAct loop 定位为"主流的 agent 执行模式"，然后指出它的局限：harness 只能执行预置的工具。所以需要 bash + code execution 作为通用工具，让模型自己造工具。这正好对应我在学习 hey!stalker 项目架构时设计的 ReAct + Mem0 方案。

AGENTS.md 和 Memory —— 一个例子就是全局 AGENTS.md 来指导 Codex 的行为。文章直接点名了 AGENTS.md 作为 memory file standard 的例子，说 harness 在 agent 启动时注入这个文件，agent 可以向其中写入发现，实现跨 session 的持续学习。Context Hub（chub）的 annotation 机制也是同一个思路——agent 发现文档的坑，记下来，下次自动附带。

MCP Server 开发 —— 文章把 Tools、Skills、MCPs 列为 harness 的核心组成部分。MCP 本质上是 harness 向外延伸能力边界的标准化接口。

引发最多思考的部分：Model-Harness 协同进化

文章最后讲了一个我之前没想过的现象：今天的 Claude Code、Codex 这类产品，模型是带着 harness 一起 post-train 的。

这形成了一个循环：发现有用的 harness primitive → 标准化进产品 → 用新 harness 训练下一代模型 → 模型在该 harness 内变得更强。

但副作用是模型会 overfit 到特定 harness。文章举了 Terminal Bench 2.0 的例子：同一个 Opus 4.6，在 Claude Code 的 harness 里跑分远低于在其他 harness 里。

这引出了一个我反复思考的问题：随着模型越来越强，harness engineering 会不会变得没有必要？

我的结论是：不会消失，但 重心会不断上移 。

回看过去两年：2024 年初，给模型套一个 while loop 维护聊天历史就是有价值的 harness 工程。今天这已经被每个产品内置了。但 harness engineering 并没有变少——它变的是层次。当前的主战场是 compaction、multi-agent orchestration、Ralph Loop 这些更复杂的问题。再往后，会是几百个 agent 并行编排、agent 自我分析 trace 来修复 harness 层失败、harness 根据任务动态组装工具和上下文。

这就像是 java web开发的演进过程：十五年前你需要手写 servlet 和手配线程池，Spring 吸收了这些；然后你需要手配 Spring XML 和手管部署，Spring Boot 吸收了这些；然后你需要手管容器编排，Kubernetes 吸收了这些。基础设施工程消失了吗？没有。但今天的基础设施工程师在想 service mesh、GitOps、平台工程——抽象层级上移了，但"围绕核心能力构建系统"这个工程需求永远存在。

还有一个反直觉的点： 模型越强，harness 优化的边际收益反而越高 。弱模型无论怎么配 harness 都做不了复杂任务；强模型配好 harness 和配差 harness 的差距是巨大的。就像给初级程序员和高级程序员同样的开发环境，高级程序员从好环境中获得的生产力放大效应远大于初级程序员。仅改 harness 就能把同一个模型从 Top 30 提到 Top 5，这个数据点说明了一切。

启示

无论是设计 system prompt、学习 context engineering、开发 MCP server、构建 AGENTS.md，还是研究 RAG pipeline，全部落在 harness engineering 这个框架里。

重点掌握的是 harness engineering 的 思维方式 ——从期望行为反推系统设计——而不是死记当前的具体实现。具体的 compaction 算法可能会变，但"context 是稀缺资源需要管理"这个认知不会变。具体的 Ralph Loop 实现可能被模型原生吸收，但"长周期任务需要跨 context window 接力"这个问题在相当长时间内仍需 harness 层解决。

“你怎么理解 AI agent 的架构”，Agent = Model + Harness 这个公式加上六大组件的行为反推逻辑，是我能给出的最清晰的回答。

原文：The Anatomy of an Agent Harness，来自 LangChain 团队