AI 前沿情报站AGENT ENGINEERING
AGENT 工程 · 深读系列

Agent Harness 解剖：Agent = Model + Harness

LangChain · The Anatomy of an Agent Harness · 精读

LangChain 给 Agent 领域重新划了边界：Agent 不是「更聪明的模型」，而是模型加上一整套把它变成生产力机器的外部系统——真正的设计功夫，藏在模型之外。

2026.03.23约 10 分钟来源：blog.langchain.com · Vivek Trivedy

一句话结论

Agent 不是“更聪明的模型”，而是“模型 + 一整套把它变成生产力机器的外部系统”。这套外部系统，就是 harness。

作者的核心公式是：

Agent = Model + Harness

其中：

一、这篇文章到底在讲什么

这篇文章的真正价值，不只是解释一个术语，而是在给 Agent 领域重新划边界。

过去大家常把很多能力混在一起谈：

作者的答案是：

这些能力里，有很大一部分其实不是模型本身“会了”，而是 harness 把模型包成了一个可以工作的系统。

也就是说：

作者甚至用了句很强的话：

If you're not the model, you're the harness.

这个说法虽然有点粗暴，但很有穿透力。

二、作者如何定义 harness

作者给出的定义非常工程化：

Harness = every piece of code, configuration, and execution logic that isn’t the model itself.

也就是：

凡是不是模型本身、但能让模型成为 agent 的东西，都可以视为 harness。

文中列举的 harness 组成包括：

这个定义最大的好处是：

1. 它迫使我们把注意力从“模型本身”转向“系统设计”

你不再只问：

而开始问：

2. 它把 Agent 设计转化为“行为 → 机制”的问题

不是笼统地说“做个 agent”，而是：

我想让 agent 呈现哪些行为？ 那我需要在 harness 里补哪些能力？

三、文章的核心推导方法

作者不是在罗列功能，而是采用一个很好的推导方式：

我们想要某种 agent 行为 → 模型本身做不到 → harness 补上对应机制

这个模式非常适合做系统设计。

文章贯穿始终的思路其实是：

Behavior we want → Harness design to achieve it

这也是全文最有方法论价值的部分。

四、核心模块逐段精读

1. Filesystem：为什么文件系统是 agent 的基础原语

作者认为，文件系统是最基础的 harness primitive 之一。

文章要解决的问题

我们希望 agent：

而模型本身只能直接操作当前上下文里的内容。

所以 harness 要补什么

给 agent 一个文件系统抽象和文件操作工具。

文件系统带来的关键能力

1) 持久存储

agent 可以把结果写下来，而不是全靠上下文硬记。

2) 上下文卸载

超出上下文窗口的信息，可以放入文件，按需再读。

3) 工作空间

agent 可以处理代码、文档、数据等真实材料。

4) 协作表面

多个 agent 与人类可以通过共享文件协作。

作者甚至指出，像 Agent Teams 这类架构，本质上依赖文件系统做协作底座。

进一步延伸：Git

作者又把 git 拉进来，形成：

这说明在 coding agent 场景里，文件系统 + git 已经不是“附属工具”，而是能力骨架。

我的理解

这段最值得记住的一句话是：

很多 agent 看起来像“有记忆”，其实不是模型记住了，而是 harness 让它有地方存和再读。

也就是说，memory 在工程上更多是：

而不是模型真正意义上的持续学习。

2. Bash + Code Execution：为什么 bash 成为 today’s default general-purpose tool

文章要解决的问题

我们希望 agent：

传统问题

如果 harness 只有固定工具：

所以 harness 的更优解

给 agent 一个通用执行原语：bash + code execution。

这样 agent 可以：

这段最重要的洞见

作者强调：

code execution 本质上让模型可以“动态发明工具”，而不必被预设工具集限制。

这非常关键。

因为这意味着：

这也是为什么很多 coding agent 的本质越来越接近：

给模型一台电脑，让它自己想办法。

我的理解

这部分体现出一个非常强的工程哲学：

一个通用 primitive 往往比很多特定工具更强。

bash 之所以重要，不是因为命令行本身神奇，而是因为它极大扩展了 agent 的动作空间。

3. Sandbox + Verification Tooling：为什么“能执行”还不够，还要有环境和观察能力

文章要解决的问题

即便模型已经会写代码、会调用 bash，仍然有一个大问题：

所以 harness 要补的不是单一工具，而是一整个执行环境

作者认为，harness 必须负责：

Sandbox 的价值

1) 安全

不能把 agent 生成的代码直接在本机裸跑。

2) 隔离

不同任务需要隔离环境，避免污染。

3) 可扩展

大规模 agent workload 需要按需创建和销毁环境。

4) 可观测

agent 不能只“做”，还必须“看见自己做了什么”。

所以 harness 应该提供：

这段的核心含义

作者强调，agent 的一个重要闭环是：

写代码 → 执行 → 观察 → 修正

而这个闭环的大部分支撑都不是模型本身，而是 harness 提供的。

我的理解

这部分可以浓缩成一句：

模型不具备天然的 self-verification，harness 通过环境和观察工具把验证能力搭出来。

这对企业级 agent 特别重要，因为“能做”远不够，“可检验”才是落地前提。

4. Memory & Search：为什么持续学习本质上还是 context injection

文章要解决的问题

我们希望 agent：

模型本身的限制

模型没有办法在不改权重的情况下真正“新增知识”。

所以作者很直接地说：

不改模型权重时，所谓“增加知识”，本质都是通过上下文注入实现的。

Harness 如何实现“记忆”

文中提到的方式包括：

这就是一种工程化的 continual learning：

Harness 如何实现“新知识访问”

对于知识截止之后的信息，harness 要提供：

我的理解

这部分很适合用来纠正一个常见误解：

Agent 的记忆，不是 mystical memory，而是可持久化信息 + 动态召回。

也就是说：

5. Context Rot：全文最有现实意义的一段之一

作者提出一个非常重要的概念：

Context Rot

意思是：

随着上下文越来越长，模型的表现会越来越差。

它可能出现：

作者的关键判断

Harness today is largely a delivery mechanism for good context engineering.

这句话非常狠，也非常准。

也就是说，今天很多 harness 的核心工作，其实是在保护模型不要被上下文拖垮。

作者给出的三类主要策略

1) Compaction

上下文快满时，做摘要、压缩、搬运，让任务能继续。

2) Tool Call Offloading

对于超长工具输出：

这样可以避免大段日志污染推理空间。

3) Skills / Progressive Disclosure

一开始不要把所有工具说明、所有 MCP 信息全部加载进 prompt。

而是：

我的理解

这一节的现实价值特别高，因为今天很多 agent 失败，不是因为“智力不足”，而是因为：

所以：

context management 很可能比模型多强半代更影响实际体验。

6. Long-Horizon Autonomous Execution：为什么长任务必须靠 harness 的“复利组合”

文章要解决的问题

我们希望 agent：

模型本身的常见问题

作者提到今天模型在长任务上常见的三个问题：

所以 harness 要补的不是单点功能，而是一整套续航系统

1) Filesystem + Git

用于跨 session 跟踪状态和工作历史。

2) Ralph Loop

这是文中提到的一个 harness pattern：

本质上是一种“强制续航机制”。

3) Planning

通过 prompting 和 plan file 等方式，让模型把大任务拆成步骤。

4) Self-Verification

通过：

让 agent 能检查自己的工作并持续修正。

我的理解

这段最核心的结论是：

长程自治不是模型自然长出来的，而是 harness 一层层托出来的。

也就是说，真正的 long-horizon capability 通常不是单点突破，而是以下能力的叠加：

五、这篇文章最重要的总观点

Harness 不只是补模型短板的 patch

作者后半段特别想说明：

虽然今天很多 harness 看起来像是在弥补模型不足， 但 harness 不只是 patch，它也是 能力放大器。

即使未来模型更强，harness 仍然重要，因为它提供的是：

这些不是“模型变强了就自然消失”的东西。

我的理解

可以这样理解：

在真实产品里，往往是 harness 决定最终体验。

六、未来趋势：模型与 harness 的共同演化

作者提出一个很值得重视的趋势：

模型训练和 harness 设计正在耦合演化。

也就是说，像 Claude Code、Codex 这类产品，不只是“模型上线后外面套一层壳”，而是：

这会形成一个反馈循环：

  1. harness 发现有用 primitive
  2. 把 primitive 纳入系统
  3. 模型在这种系统里训练/适配
  4. 模型更擅长使用这种 primitive
  5. 新一代 harness 再继续进化

但作者也提醒了副作用：过拟合到特定 harness

比如：

这说明模型可能不是“抽象能力变强”，而是“对某种 harness 习惯得很好”。

一个很重要的判断

作者明确说：

模型被训练在哪个 harness 中，不代表那个 harness 就是你任务的最佳 harness。

这句话非常重要。

因为它说明：

也就是说：

Harness optimization 本身就是一条重要性能杠杆。

七、作者提到的未来研究方向

文章最后给了几个开放问题：

1) 数百个 agent 的并行协同

如何在共享代码库上编排大量 agent 协同工作。

2) agent 自己分析 traces，修复 harness 层失败模式

这意味着 harness 不只是静态系统，而是可自我改进系统。

3) 动态组装工具与上下文

不再是预配置，而是：

这个方向我认为会非常重要，因为它本质上是在解决两个痛点：

八、我对这篇文章的评价

我认为它最强的地方

1) 概念切分非常清楚

“Agent = Model + Harness”是个很强的框架。

2) 它把系统层能力从模型能力里剥离出来

这能显著减少很多伪讨论。

3) 它是很好的工程视角文章

不是在谈抽象 autonomy，而是在谈：

这些都是真正影响 agent 落地的硬东西。

我认为它的局限

1) Harness 定义过宽

“If you're not the model, you're the harness.” 很有传播性，但太大了。

为了真正做架构分析，我更愿意把 harness 再细分成：

2) 明显偏 coding agent 语境

文章里的大量例子都偏向：

如果换成企业办公 agent、审批 agent、客服 agent：

3) 对治理问题展开不够

文章提了 sandbox、allowlist、network isolation， 但没有深入谈：

而这些在企业环境里是必须补上的。

九、对实际做 Agent 设计最有用的启发

如果把全文压缩成几条可执行认知，我认为最重要的是下面五句：

1. 不要只评估模型，要评估 harness

很多 agent 的表现差异，根因在 harness，不在 model checkpoint。

2. 所谓 memory，本质是存储 + 注入

不是模型真正“记住了”，而是 harness 设计了信息保留和再召回机制。

3. 长任务能力不是大上下文自动带来的

必须依赖：

4. 通用执行 primitive 往往比大量定制工具更关键

bash / code exec 的意义在于，它让 agent 不必被事先设计好的工具清单束缚。

5. Context management 是 agent 成败核心之一

很多 agent 失败不是因为模型不够聪明，而是因为 context rot 太严重。

十、我建议采用的“Agent Harness 四层框架”

为了把文章转成更适合实际使用的分析框架，我建议记成四层：

1. Context Layer

负责“给模型看什么”

包括：

2. Tool Layer

负责“模型能做什么动作”

包括：

3. Execution Layer

负责“动作在哪做、怎么做、做完怎么看”

包括：

4. Control Layer

负责“任务如何持续、如何拆分、如何编排、如何兜底”

包括：

这个四层框架比原文更适合做：

十一、最终结论

这篇文章真正推动的不是一个新名词，而是一种新的思考方式：

不要把 agent 理解为“会调用工具的大模型”，而要把它理解为“被 harness 组织起来的模型工作系统”。

如果再压缩一点：

这是我认为这篇文章最值得你带走的判断。

十二、后续可延伸的两个方向

如果后面要继续展开，这篇文章最适合延伸成两类内容：

方向 A：产品/系统对比

拿它去对比：

核心看：

方向 B：企业落地评估框架

把文章里的 harness 观点转成企业版评估维度：

这会直接变成一个 agent 选型 / 评审框架。

附：一句最值得记住的话

The model contains the intelligence and the harness is the system that makes that intelligence useful.

这句话几乎可以当这篇文章的最终摘要。