原文参考：Vivek Trivedy, “The Anatomy of an Agent Harness”。本文不是翻译，而是基于原文观点做的原创解读。

Agent Harness 不是配角，而是 2026 年 AI 工程最被低估的主战场

如果你过去一年一直在看 agent 方向的文章，会发现一个很微妙但非常确定的变化：大家嘴上还在谈模型，心里其实已经开始转向系统了。

去年很多讨论的中心还是”哪个模型最适合做 agent""哪个 framework 更方便""tool use 做得稳不稳”；到了今年，真正做过一轮生产落地的人，几乎都会撞到同一个事实：同样一个模型，放进不同的工作系统里，表现会像完全不同的东西。

这也是 LangChain 那篇《The Anatomy of an Agent Harness》最值得认真读的原因。它不是单纯在介绍一个概念，而是在帮整个行业重新校正视角：真正决定 agent 实际能力的，从来不只是模型本体，而是模型外面那一层常常被忽视、却实际支配成败的运行结构——也就是 harness。

说得更直接一点：过去一年，很多团队以为自己在优化 agent；实际上，他们只是在调模型、调 prompt、加工具。而真正该下重手的，是模型如何被组织、约束、续航、验证和放进真实环境里工作。

我越来越强烈地觉得，2026 年 AI 工程最被低估的主战场，不是”模型迭代速度”，而是”harness 设计成熟度”。

一、为什么今天谈 agent，不能再只谈模型

模型当然重要。没有足够强的推理能力、指令遵循能力和工具调用稳定性，agent 很难有像样的上限。但真正进入工程现场之后，大家很快会发现一个不太舒服的现实：模型的强弱，解释不了大多数 agent 的实际表现差异。

举几个工程团队极熟悉的现象：同一个模型，在一个仓库里表现非常好，在另一个仓库里就频繁迷路；第一次会话很聪明，任务一长就开始失真；接了十几个工具以后反而更笨；单轮任务做得挺漂亮，跨多轮之后就开始”看起来进展很大，实际没完成”；在 demo 环境里神勇无比，一到生产就不断暴露成本、权限、恢复和验证问题。

这些问题，靠”再换一个更强模型”偶尔能缓解，但几乎不会根治。因为大多数症状不属于纯推理层，而属于工作系统层。

模型会不会想，是一个问题；模型有没有被放进一个能持续工作的环境里，是另一个问题。今天很多团队仍然本能地把 agent 理解为”一个会调用工具的聊天模型”，这其实已经落后于现实。

现实中的 agent，更像一个被精心封装过的执行系统。它有记忆表面，有文件系统，有工具发现机制，有代码执行环境，有权限与隔离，有验证和反馈回路，有上下文压缩与恢复机制，有多轮交接能力，甚至可能还有多 agent 分工和 orchestration。

没有这些，模型再强，也更像一个聪明但没有工作台、没有笔记本、没有仪表盘、没有实验环境的人。你可以让他回答几个问题，但你很难让他稳定完成一串真正的工作。

二、什么是 harness：它不是一个组件，而是一层工作系统

LangChain 那篇文章最有价值的一点，就是把 harness 这个词从模糊状态里拉了出来。

很多人听到 harness，会误以为是某个控制器、某个 wrapper、某个 agent framework 里的小模块。但如果只这么理解，就把它想小了。

更准确地说，harness 不是一个点，而是一层包裹模型的运行组织结构。凡是”模型本体之外，但 agent 又离不开的能力”，都应该纳入 harness 的视角去看。

从工程上看，harness 至少包含三个层次的能力支撑。

第一层是行为与交互控制：system prompt 和规则约束定义了 agent 的行为边界，tools 和 MCP definitions 提供了与外部世界交互的接口，hooks 和 middleware 则让系统可以在关键节点插入自定义逻辑。

第二层是执行与存储环境：文件系统提供持久化表面，bash 和 code execution 赋予 agent 真正的行动力，sandbox 和权限控制划定安全边界，browser 和 UI-level verification 让 agent 能感知和验证真实界面状态。

第三层是认知与记忆管理：memory 和 retrieval 解决信息召回，compaction 和 tool-output offloading 控制上下文质量，progressive disclosure 决定能力如何按需暴露，而 logging、tracing、metrics 与 verification loops 则让整个系统变得可观测、可调试、可优化。

这三层合在一起，才构成了完整的 harness。

看到这里，很多人会意识到一件事：这其实已经非常接近软件系统设计，而不只是 prompt design。

这也是我越来越不喜欢”agent engineering = 写好提示词”这种说法的原因。那种说法只适合 demo 时代，不适合现在。现在的 agent engineering，更像是把一个会推理的核心放进一套可运行、可恢复、可扩展、可验证的工作环境中。

换句话说，模型是脑子，harness 是神经系统、记忆系统、手脚、工作台和安全护栏。

单靠大脑，当然能解释问题；但做不了工程。

三、文件系统为什么会重新变成 agent 的核心基础设施

这篇文章里我最认同的一点，是它把文件系统抬得很高。很多团队在 agent 设计里会优先思考模型路由、工具 catalog、planner prompt、memory database，看起来都很先进，但真正跑过长任务之后，最朴素的文件系统经常重新成为整个系统的支点。

为什么？因为文件系统天然解决了一个大模型一直解决不好的问题：把脆弱、临时、昂贵的上下文，变成稳固、可回读、可共享的外部事实。

1. 文件系统是最便宜的长期记忆

模型上下文非常昂贵，而且会腐烂。会话一长，旧信息和新信息开始互相覆盖；中间步骤一多，真正重要的约束就容易被埋掉。你当然可以做 memory injection、vector recall、summary stitching，但很多时候，一个计划文件、一个 progress log、一个阶段产物文档，比任何 fancy memory pipeline 都更稳。

原因很简单：文件可读、可写、可版本化、可回查，天然适合交接，不会因为对话滚动而被”注意力稀释”。

一个会把任务过程写回文件的 agent，和一个把一切都留在上下文里的 agent，稳定性经常不是一个量级。

2. 文件系统让多轮任务真正”有地方落地”

很多 agent 系统看起来在工作，实际只是连续生成文本。它做了很多推理、给了很多计划、输出了很多中间分析，但这些东西没有真正落到一个工作台上，于是下一轮接不上、人也接不住。

文件系统的价值就在这里：它给任务提供了一个真正的外部表面。研究结果可以落到 findings.md，计划可以落到 task_plan.md，进度可以落到 progress.md，代码可以直接写进仓库，运行结果可以落到日志，失败原因可以变成错误记录，下一轮 agent 可以直接接着读。

这是为什么我越来越觉得：agent 的”记忆”不该主要理解为模型脑内的东西，而该理解为一个以文件系统为核心的外部工作记忆层。

3. Git 让文件系统升级成恢复基础设施

文件系统本身已经很重要了，一旦和 git 结合，它立刻从”存东西的地方”升级成”恢复和审计系统”。

这对 agent 来说太关键了。因为 agent 的尝试天然会犯错，甚至会在你没注意的时候做出一串错误动作。如果没有 git，你只能”希望它别弄坏”。有了 git，你至少拥有回滚能力、差异可视化、阶段性交付、多轮交接的时间线，以及失败尝试的可审计记录。

很多人把 git 视为开发协作工具，但在 agent 场景里，它更像是运行安全装置。

所以今天最有效的 agent harness，往往都不是”更会想”的，而是”更会写回文件、更会留下历史、更会让下一轮继续”。

四、代码执行为什么不是附加能力，而是 agent 真正的行动力来源

如果文件系统解决的是”记忆与外部化”，那代码执行解决的就是另一个更根本的问题：agent 怎么获得通用行动力。

很多团队喜欢一开始就设计很多专用工具，这当然有用。专用工具让权限边界更清楚、动作更可控、调用更容易监控。但只要任务稍微复杂一点，你就会遇到工具设计无法穷尽的问题。

真实环境里的任务变化太快了：数据格式临时变化、需要做额外清洗、需要把两个工具输出拼起来、需要写一段短脚本验证假设、需要批量处理文件、需要临时做一次聚合、过滤、轮询、重试。

如果每件事都要预制一个工具，系统很快会变成一个脆弱的能力博物馆。相反，给 agent 一个可以安全运行代码的表面，等于给了它在执行现场自己造小工具的能力。

这也是为什么我非常认同文章的判断：bash / code execution 不是某种可选附加项，而是 agent 从”会调函数”走向”能解决问题”的关键一跃。

1. 固定工具给的是能力清单，代码执行给的是能力放大器

固定工具像菜单，代码执行像厨房。菜单再丰富，也会遇到菜单外的问题；有厨房，才能真正现场组合。

这并不是说所有事都应该让 agent 写代码来做，而是说：一旦场景复杂、路径不固定、结果需要进一步加工，代码执行会让整个系统变得灵活很多。

2. 真正成熟的 harness，不是把所有事交给模型，而是把程序化工作迁回程序

很多现在看似”模型在干”的工作，本来就不应该由模型反复参与。例如批量筛选数据、格式转换、结果合并、轮询等待、失败重试、输出压缩、中间值脱敏——这些事情如果都通过模型一轮轮来 orchestrate，不仅贵，而且脆弱。

更合理的方式，是让模型决定要做什么，再让代码环境完成机械部分，然后把真正有价值的摘要送回模型。

这不是削弱模型，而是让模型回到更适合它的位置：做高价值判断，不做重复搬运工。

五、sandbox 为什么会从”安全附属项”变成 harness 的核心部分

一旦你接受 agent 应该有更强的行动力，另一个问题就一定会浮出来：边界怎么管？

很多人讨论 sandbox 时，总带着一点”安全团队的额外要求”那种味道，好像它主要是为了 compliance。但在 agent 场景里，sandbox 不只是安全设施，它本身就是产品能力和工程稳定性的组成部分。

为什么这么说？因为没有 sandbox，代码执行能力会很快变成失控点。你必须回答：在哪里执行？能访问哪些目录？能联网吗？能装依赖吗？能持续跑多久？资源上限是多少？出错后怎么清理？能不能被审计？

这些问题看起来像运维问题，实际上直接影响 agent 的可用性。一个没有清晰边界的 agent，往往不是”更灵活”，而是”更难用、更难信任、更难恢复”。

这也是为什么我越来越倾向把 sandbox 看成 harness 的一等公民。它和代码执行、文件系统、验证一样，不是独立组件，而是同一个运行设计的不同面向。

更直白地说：如果一个 agent 能动手，却没有边界，那不是能力，是事故预备役。

六、context rot 才是很多 agent 系统真正的隐形死因

如果你问我过去一年最被低估的 agent 问题是什么，我很可能会答：context rot。

很多失败表面上看像推理错误、规划错误、工具选择错误，但往下挖，常常会发现真正的问题不是 agent 不会，而是 agent 的工作上下文已经坏掉了。

上下文是会老化的。它不是一个静止容器，而是一个越来越混乱的动态堆积层。当任务变长，你会发现上下文开始”变质”：旧目标像幽灵一样残留在对话中，新的约束试图覆盖却覆盖不完全；工具输出一层层堆积，中间失败的路径没有被清理；真正重要的信息被淹没在次要细节的洪流里，模型开始更依赖那些局部显眼的信息，而渐渐遗忘全局目标。

这时你会看到一个非常典型的错觉：agent 仍然在”努力工作”，甚至还能不断输出看起来合理的东西，但它离目标越来越远。

LangChain 文章里提到的 compaction、tool-output offloading、skills/progressive disclosure，我认为本质上都在解决同一个问题：让上下文重新保持可用。

1. Compaction 不是摘要，而是注意力重建

很多人把 compaction 理解成”压缩对话”，这太轻了。真正有效的 compaction，做的不是缩短，而是重新组织注意力焦点。

好的 compaction 需要回答：当前真实目标是什么？哪些尝试已经失败过？哪些约束必须保留？哪些细节应该迁出上下文？下一轮从哪里继续最合理？

如果只是把原话变短，那不叫 compaction，那只是文字瘦身。

2. Tool-output offloading 是 agent 时代的新”日志设计”

大工具输出直接回注给模型，是现在很多系统最大的隐性成本来源之一。结果不是模型看不懂，而是模型被迫消耗注意力去看太多根本不该占用上下文的内容。

所以越来越成熟的系统都在做同一件事：把大结果落盘、落日志、落文件，只把必要摘要带回上下文。

这背后的思想非常传统，甚至有点像老派软件系统设计：

热路径只留高价值信息，原始数据留在外部系统。

区别只是现在的”热路径”变成了 prompt context。

3. Progressive disclosure 解决的是”能力注入过量”

很多团队一开始特别喜欢把所有能力说明、所有规则、所有工具定义一次性塞给模型，觉得这样”更完整”。但现实恰恰相反：越是把一切提前灌进去，越容易让模型在真正执行时失焦。

Progressive disclosure 的价值就在于，它承认了一个基本事实：上下文不是百科全书，而是工作记忆。

工作记忆的关键不是尽可能全，而是尽可能相关。

七、真正的 agent 续航能力，来自可恢复的多轮结构，而不是单轮超神

LangChain 这篇文章让我特别有共鸣的一点，是它默认接受了一个现实：长任务从来都不是一次推理能解决的，而是一个跨多回合、多阶段、多工件、多失败恢复的过程。

这看起来像常识，但很多 agent 产品到今天还在赌一件事：希望一次会话撑得够久、模型够聪明、上下文够大，就能把复杂任务一路做完。

我越来越觉得，这条路大概率会持续让很多团队失望。因为复杂任务不是”更长的问答”，而是”更像项目执行”。既然像项目执行，就一定有阶段划分、外部工件、失败恢复、工作交接、目标重申、结果验证、边界条件更新。

也就是说，真正的续航能力来自多轮结构设计，而不是单轮魔法。

一个成熟的 harness，至少应该让这些事情变得自然：当前轮做什么、下一轮怎么接、接续时先读什么、失败后怎么回退、哪些状态必须写回外部、什么条件下允许标记完成。

这类设计看起来不”酷”，但它们决定了 agent 究竟是 demo 还是 worker。

八、为什么我认为未来最强的团队，不会把模型和 harness 分开看

现在很多公司内部还存在一种很明显的分工错位：模型团队在看 benchmark，应用团队在堆 prompt，平台团队在补工具和权限，最后每个人都觉得自己做的是 agent 的一部分，但没有人真正拥有”agent 系统整体表现”这个问题。

这会带来一个很糟糕的结果：大家都在优化局部，却没人对整体稳定性负责。

而 harness 这个视角的真正价值，就是把这些分散问题重新聚合到一起。它提醒我们：prompt 不是独立变量，tool catalog 不是独立变量，memory 不是独立变量，sandbox 不是独立变量，eval 也不是独立变量。

这些东西共同组成了一个工作系统。你不能只把其中一个拉满，然后期待 agent 自然变强。

我越来越相信，未来最强的 agent 团队，竞争力不会只来自”拿到最新模型”，而会来自以下几件事情组合得有多好：他们是否知道哪些事应该留给模型、哪些该交给系统；他们是否有稳定的外部记忆表面；他们是否把验证做成硬约束，而不是礼貌动作；他们是否能让 agent 在长任务中持续保持方向感；他们是否能在失败后恢复，而不是从头再来；他们是否能控制上下文负债，而不是不断堆 context。

如果这些做得好，即使模型不是最新的，系统也可能非常强。反过来，模型再顶尖，harness 一塌糊涂，最后还是会变成”偶尔惊艳，经常失控”。

九、这篇文章最值得带走的，不是术语，而是判断问题的方式

我觉得读完《The Anatomy of an Agent Harness》，最有用的不是记住 harness 里有哪些组件，而是学会换一种方式看 agent 问题。

以后当一个 agent 系统表现不稳定，你第一反应不该只是”模型不够强？prompt 不够好？tool description 不够详细？“，而应该先问：它有没有清晰的外部工作记忆？上下文是不是被大结果污染了？执行动作是不是太依赖模型逐步 orchestrate？有没有安全、可恢复的代码执行环境？任务是不是缺少阶段性交接点？完成标准是不是没有真正绑定验证？当前失败，到底是 reasoning 问题，还是 harness 让它注定会失败？

这组问题非常重要，因为它会把你从”继续折腾模型参数”的惯性里拉出来，转向真正更有杠杆的位置。

十、我对 2026 年 agent 工程的一个判断：重心会继续从模型转向工作系统

我不认为模型不重要。相反，模型只会继续变强，推理能力、长上下文、工具使用能力还会持续进步。但也正因为模型越来越强，harness 的重要性反而会进一步暴露出来。

原因很简单：当基础模型能力接近时，系统设计的差异会被放大。就像程序员水平接近时，项目工程组织能力的重要性会迅速上升一样。

所以我对未来一两年的一个很强判断是：

AI 工程的竞争，会越来越像”谁更会搭工作系统”，而不是”谁更会喊模型口号”。

真正能把 agent 从”看起来很聪明”推进到”值得长期信任”的，往往不是某一条惊艳的 prompt，不是某一个新框架，也不是某一项 benchmark 的领先，而是这些看上去不性感的基础设施：文件系统、代码执行、sandbox、context engineering、verification loop、durable memory、orchestration discipline、可恢复的多轮执行结构。

这些东西加在一起，才构成了 harness。

十一、为什么很多团队至今仍然低估 harness

如果还要在结尾前保留一个补充段，我认为最值得保留的就是这一层：很多团队并不是不知道 harness 重要，而是组织激励天然让人更容易高估模型、低估系统。

原因通常不复杂：demo 更奖励”看起来聪明”的表现，benchmark 更容易放大模型差异，模型、平台、产品被不同团队分开负责，买模型比建设工作系统更容易讲故事、也更容易获批。

所以 harness 常常不是败在没人提，而是败在没有人真正拥有它、也没有人愿意为它的长期收益提前投资。

结语：当你说自己在做 agent，其实你真正做的是一套工作系统

《The Anatomy of an Agent Harness》之所以值得读，不是因为它提出了一个很新的 buzzword，而是因为它把一个本来已经在工程现场发生的变化，讲清楚了。

今天谈 agent，如果还只谈模型和工具，其实已经不够了。更准确的说法应该是：当你在做 agent 时，你真正构建的，不是一个会说话的模型增强器，而是一套围绕模型展开的工作系统。

系统强，模型会被放大；系统弱，模型也会被拖垮。

所以如果你问我，这篇文章最值得留下的一句话是什么，我会把它改写成这样：

未来的 agent 工程，不会输在”模型智力”本身，而更可能输在”有没有把智力放进一套能稳定工作的系统里”。

这就是 harness 的意义。

它不是配角。它才是主战场。

---

谁应该读这篇

这篇更适合下面几类读者：

• 正在把 agent 从 demo 推向生产的工程团队
• 已经感觉”模型明明很强，但系统还是不稳”的 AI 工程师
• 在做 Claude Code、Cursor、OpenHands、Devin 类工作流设计的人
• 在设计 MCP、skills、tool runtime、agent orchestration 的平台团队
• 对”为什么 agent 一长就失真”有切身痛感的人