Agent Harness 解析 – LangChain《The Anatomy of an Agent Harness》解读
原始来源：LangChain Blog The Anatomy of an Agent Harness
原文链接：https://blog.langchain.com/the-anatomy-of-an-agent-harness/
作者：Vivek Trivedy
发布时间：2026-03-10
说明：本文是基于原文的中文解读与个人延展，不是逐句翻译。原文从工程视角解释了 Agent Harness 的组成，本文重点梳理其核心框架、关键启发和对实际 AI Agent 产品/工作流的意义。
这篇 LangChain 的文章，标题叫 The Anatomy of an Agent Harness。
如果直译，大概是“Agent Harness 的解剖”。
但这个词不好翻。
Harness 在这里不是简单的“框架”，也不只是“工具调用层”。更准确地说，它是围绕大模型搭起来的一整套运行外壳：
- 提示词
- 上下文管理
- 工具调用
- 文件系统
- 代码执行
- 浏览器
- 沙箱
- 权限
- 记忆
- 搜索
- 测试反馈
- 长任务恢复
也就是说，Harness 是让一个大模型真正变成 Agent 的工程系统。
原文最重要的一句话是：
Agent = Model + Harness
模型负责智能。
Harness 负责让智能能接触真实世界、调用工具、保存状态、执行任务、验证结果，并且在安全边界内持续工作。
这句话看似简单，但它其实把 AI Agent 领域里一个很容易被忽略的问题讲清楚了：
今天很多 Agent 产品的差异，不只来自模型强弱，而来自 Harness 设计。
同一个模型，放在不同执行环境里，能力会完全不同。
一个只能聊天的模型，和一个可以读仓库、改代码、跑测试、查网页、管理文件、请求用户授权、恢复上下文的模型，不是同一个级别的工具。
差别不在模型参数里。
差别在 Harness。
一、为什么裸模型还不是 Agent
很多人说起 Agent，会直接想到模型。
比如：
- GPT-5 够不够强
- Claude 写代码是不是更稳
- Gemini 上下文是不是更长
- 开源模型能不能追上闭源模型
这些当然重要。
但 LangChain 这篇文章提醒我们：模型本身不是完整 Agent。
裸模型本质上只做一件事：
输入一段上下文，输出一段文本。
它天生不会：
- 记住项目里的文件结构
- 自己读取本地代码
- 自己执行命令
- 自己安装依赖
- 自己打开浏览器
- 自己跑测试
- 自己保存中间结果
- 自己知道哪些操作危险
- 自己在长任务中恢复状态
这些能力都不是模型天然具备的。
它们来自模型外部的系统。
这套外部系统，就是 Harness。
你可以把模型想成一个很强的大脑。
但大脑如果没有眼睛、手、记忆、工作台、文件柜、工具箱、试验场和安全规则，它只能坐在那里说话。
Agent 真正开始“干活”，是在 Harness 把这些东西接上之后。
二、文件系统是 Agent 的第二上下文
原文把文件系统放在很重要的位置。
这点我很认同。
很多人讨论 Agent 时，第一反应是上下文窗口要多长。128K、1M、10M，好像只要窗口足够长，Agent 就能记住所有东西。
但实际做项目会发现，长期工作不能只靠上下文窗口。
上下文窗口再长，也有几个问题：
- 会被无关信息污染
- 会因为工具输出太多而变乱
- 会随着任务变长逐渐失焦
- 会在会话结束后丢失
- 很难让人和多个 Agent 共同维护
文件系统解决的是另一个层面的问题。
它让 Agent 可以把信息落到一个稳定的位置：
- 项目规则写进
AGENTS.md - 进展写进
PROGRESS.md - 稿件放进
posts/ - 脚本放进
scripts/ - 中间输出放进
output/ - 配置模板放进
.env.example
这不是简单的“存文件”。
这是给 Agent 提供一种外部记忆。
模型上下文像短期工作记忆，文件系统像长期项目记忆。
短任务可以靠聊天完成。
但长任务一定要靠文件系统承载状态。
尤其是内容生产、代码开发、插件部署、自动化运营这种连续工作，如果所有信息都只存在对话里，项目很快会变成一团雾。
一旦有了稳定的文件结构，Agent 才能知道：
- 哪篇文章已经写完
- 哪个公众号版本已经生成
- 哪个脚本负责发布
- 哪些操作会影响生产站点
- 哪些内容不能随便改
- 下次接手时应该从哪里继续
所以，文件系统不是 Agent 的附属能力。
它是长期 Agent 的基础设施。
三、代码执行让 Agent 从“会说”变成“会做”
原文提到，很多 Agent 的运行方式本质上是一个循环：
思考 -> 调用工具 -> 观察结果 -> 再思考 -> 再调用工具
这就是常说的 ReAct / Thought-Action-Observation 模式。
但这里有一个关键问题：
工具应该怎么设计？
一种做法是给 Agent 提供很多专用工具：
- 读文件工具
- 写文件工具
- 搜索工具
- 数据库工具
- 浏览器工具
- 发布工具
- 测试工具
这当然有用。
但如果每个动作都必须提前封装成工具，Agent 会被限制在设计者已经想到的范围里。
所以很多生产级 Harness 会给 Agent 一个更通用的能力：代码执行环境。
比如 Bash、PowerShell、Python、Node。
这会让 Agent 的能力范围突然扩大。
它不再只能调用现成按钮，而是可以临时组合动作：
- 批量移动文件
- 解析 Markdown
- 检查目录结构
- 跑测试
- 生成报告
- 转换格式
- 写一次性脚本处理数据
- 对比修改前后的输出
这也是为什么代码执行对 Agent 很关键。
因为它把 Agent 从“会回答问题”推进到“能操作环境”。
当然，这也带来风险。
一个能执行命令的 Agent，比一个只能聊天的模型危险得多。
所以 Harness 不能只提供执行能力，还必须同时提供安全边界。
四、沙箱和权限，是 Agent 进入真实项目的门槛
只要 Agent 能读写文件、执行命令、访问网络，就一定会涉及安全问题。
它可能：
- 误删文件
- 覆盖用户修改
- 泄露
.env - 把测试命令跑到生产环境
- 发布未确认的内容
- 部署未验证的插件
- 调用真实客户站点接口
所以，一个严肃的 Harness 必须有沙箱。
沙箱不是形式上的限制，而是 Agent 能否进入真实工作流的前提。
它至少要回答几个问题：
- Agent 能读哪些目录？
- Agent 能写哪些目录？
- 哪些命令可以直接执行？
- 哪些命令必须用户批准？
- 网络访问是否受限？
- 生产环境操作是否需要确认？
- 敏感配置是否允许读取和输出？
这类规则看起来很“工程”，但它们决定 Agent 能不能被信任。
如果没有这些边界，Agent 越强，风险越高。
如果边界设计得好，Agent 就能在一个可控空间里大胆执行任务。
这也是为什么未来 Agent 产品不会只是“聊天界面 + 工具调用”。
它们更像一个受控操作系统。
模型在里面工作，但它不能随便碰所有东西。
五、记忆、搜索和 MCP：解决模型知识过期的问题
模型训练完成后，它的知识就会有截止日期。
但真实世界一直在变化：
- API 文档会更新
- 模型名称会变
- 开源库会改版本
- 公司规则会调整
- 项目进度会前进
- 网页内容会被修改
所以 Agent 不能只靠训练知识。
它需要两类外部补充。
第一类是项目内记忆。
比如：
AGENTS.mdPROJECT.mdPROGRESS.mdHANDOFF.md- README
- changelog
- 历史脚本
- 代码注释
这些材料告诉 Agent：这个项目是谁、目标是什么、现在做到哪里、哪些事情不能乱动。
第二类是实时知识。
比如：
- Web search
- 官方文档
- 数据库
- 内部知识库
- MCP server
- 浏览器
这些能力让 Agent 可以查到训练后才出现的信息。
原文把这些能力纳入 Harness 范围，是很重要的。
因为对 Agent 来说，“知道什么”不只取决于模型本身，也取决于 Harness 让它能访问什么信息源。
一个不能联网、不能读项目文档、不能查官方文档的 Agent，哪怕模型很强，也会在真实任务里很快撞墙。
六、上下文腐化，是长任务 Agent 的隐形敌人
原文里有一个问题非常关键：context rot。
可以翻成“上下文腐化”。
意思是：上下文越长，不一定越好。
很多人直觉上觉得，只要把更多材料塞给模型，效果就会更好。
但长任务里经常不是这样。
上下文里会慢慢混入很多东西：
- 旧计划
- 已过期判断
- 无关日志
- 工具输出噪音
- 中途失败记录
- 用户已经否定的方案
- 不再相关的文件片段
这些信息会让模型越来越难抓住重点。
它可能开始被旧信息带偏，也可能在一堆日志里忽略真正重要的约束。
所以 Harness 需要做上下文管理。
这不是简单地“多塞一点”或“少塞一点”，而是要决定：
- 哪些信息进入当前上下文
- 哪些信息写入文件即可
- 哪些工具输出只保留摘要
- 哪些旧判断需要丢弃
- 哪些项目规则必须始终可见
- 什么时候需要压缩上下文
这就是为什么原文说，Prompt Engineering 只是最里面的一层。
更外面还有 Context Engineering。
再外面才是 Harness Engineering。
Prompt 解决的是“怎么告诉模型”。
Context 解决的是“让模型现在看到什么”。
Harness 解决的是“整个 Agent 如何运行”。
七、长周期 Agent 不是靠一个超长 Prompt，而是靠工程闭环
如果一个 Agent 只做一步，比如总结一篇文章，事情还比较简单。
但如果你希望它完成一个长任务，比如：
- 写一篇文章
- 生成公众号版本
- 检查格式
- 准备封面
- 发布 WordPress 草稿
- 更新进度文档
- 下次接着处理
这就不是一次模型调用能解决的。
它需要一个工程闭环。
这个闭环包括：
- 明确任务状态
- 保存中间文件
- 执行脚本
- 检查输出
- 必要时请求用户确认
- 记录结果
- 下次可恢复
这也是 Harness 的价值。
真正的 Agent 工作不是“模型一次性给出完美答案”。
而是模型在 Harness 里不断观察、行动、验证、修正。
这和人类工作其实很像。
我们也不是靠脑子记住所有东西。
我们会用文件夹、清单、日历、脚本、版本控制、测试、日志、备忘录和交接文档。
Agent 要长期工作，也需要这些东西。
只不过这些东西要被设计成模型可以理解、可以调用、可以恢复的形式。
八、这篇文章真正提醒我们的事
我觉得这篇文章最有价值的地方，不是发明了一个新名词。
而是它把 Agent 的能力拆开了。
过去大家很容易把所有能力都归因到模型：
- 这个 Agent 写代码强，是模型强
- 这个 Agent 能查资料，是模型强
- 这个 Agent 能改项目，是模型强
- 这个 Agent 能长时间执行，是模型强
但实际上，这里面很多能力来自 Harness。
模型当然重要。
但 Harness 决定了模型能不能进入真实工作环境。
它决定：
- 模型能看到什么
- 能调用什么
- 能保存什么
- 能验证什么
- 能否恢复任务
- 能否控制风险
- 能否在复杂项目里持续协作
所以未来做 Agent 产品，核心竞争不只是“接入哪个模型”。
更重要的是：
你能不能为某类任务设计出一个足够好的 Harness。
写代码有写代码的 Harness。
做研究有做研究的 Harness。
做销售有做销售的 Harness。
做内容运营有做内容运营的 Harness。
做 WordPress 站点自动化，也有自己的 Harness。
每个场景都需要不同的文件结构、工具、权限、验证方式和交付流程。
这也是为什么通用聊天机器人和真正的垂直 Agent，中间还有很长一段工程距离。
九、放到个人工作流里，Harness 意味着什么
这篇文章对个人创作者、独立开发者和小团队也有启发。
很多人现在用 AI 的方式，仍然停留在“打开一个聊天窗口，让它回答问题”。
这当然有价值。
但如果你希望 AI 真正成为你的长期工作伙伴，就不能只依赖聊天窗口。
你需要给它一个工作台。
这个工作台可能包括：
- 清晰的项目目录
- 稳定的命名规则
- 可复用的脚本
- 任务进展文档
- 发布检查清单
- 敏感信息边界
- 可验证的输出格式
- 每次任务完成后的记录
这些看起来不像“AI 技巧”。
但它们会极大影响 AI 的实际可用性。
因为 Agent 不是漂浮在空气里的智能。
它必须落在一个具体环境里工作。
环境越清楚，Agent 越能稳定交付。
环境越混乱，模型再强也会不断猜、不断问、不断犯错。
所以，与其只问“怎么写一个更好的 prompt”，不如再往外想一层：
我有没有给 AI 准备一个能长期工作的 Harness？
结语：Agent 的下一轮竞争，可能是 Harness 的竞争
这篇 LangChain 文章给我的最大启发是：
Agent 的能力，不是模型能力的简单外溢，而是模型和运行环境共同作用的结果。
模型是发动机。
Harness 是车身、方向盘、仪表盘、燃油系统、刹车系统、导航和安全结构。
只有发动机，不能上路。
只有 Harness，没有强模型，也跑不远。
真正有价值的 Agent，是两者结合。
这也解释了为什么未来 Agent 会越来越分化。
不是所有 Agent 都长成一个样子。
代码 Agent、研究 Agent、客服 Agent、内容 Agent、运营 Agent、数据分析 Agent，它们会有不同的工具、记忆、文件系统、权限边界和验证方式。
也就是说，未来的关键问题可能不是：
“哪个模型最强？”
而是：
“在这个具体场景里，什么样的 Harness 能把模型能力稳定释放出来？”
这个问题，才是真正进入 Agent 工程化之后必须回答的问题。
Leave a Reply