Agent Harness 范式解读：决定 Agent 成败的不是模型，而是包裹模型的那套系统

一、一个反直觉的事实：模型差不多，表现差很多

如果你观察过两个团队用同一个模型做同一个任务，会发现一个耐人寻味的现象：结果可能天差地别。一个团队的 Agent 稳定可靠，另一个团队的 Agent 频频翻车。模型的参数完全一样，为什么表现完全不同？

答案在于，决定 Agent 能否可靠完成工作的，从来不只是模型本身，而是包裹在模型外面的整套系统——提示词怎么写、能调用哪些工具、有没有记忆机制、如何验证结果、失败后是否重试、什么时候停止、下一步看到什么信息。这套系统在 2026 年被正式命名为 Agent Harness，而它正在成为 AI 工程的核心范式。

有一个来自真实工程的震撼案例：OpenAI 的 Codex 团队用这套方法论生成了超过一百万行生产代码，全程零手动输入。他们的核心经验与学术界的结论一致——模型是必要条件，但真正拉开差距的是外围系统的质量。

二、核心定义：Agent = Model + Harness

Agent Harness 的定义极其简洁：Agent 是模型与 Harness 的组合。Harness 是所有不属于模型本身的代码、配置和执行逻辑。一个裸模型不是 Agent，但当 Harness 给它提供状态、工具执行、反馈循环和可执行约束之后，它就变成了一个 Agent。

用计算机类比理解会更清晰。模型是 CPU，提供原始处理能力；上下文窗口是内存，是有限且易失的工作记忆；Agent Harness 是操作系统，负责整理上下文、处理启动序列、提供标准驱动；Agent 是应用程序，运行在操作系统之上，承载具体的用户逻辑。

具体来说，Harness 包含六个组成部分。第一是系统提示词与角色定义，这是最基础的约束层。第二是工具与技能清单，包括 MCP（模型上下文协议）接入的外部工具及其描述。第三是基础设施，文件系统、沙箱、浏览器等执行环境。第四是编排逻辑，子 Agent 调度、任务交接、模型路由。第五是记忆系统，短期对话记忆与长期事实记忆。第六是确定性钩子，上下文压缩、延续控制、语法检查等用于确保输出可用的中间件。

三、Harness 的核心工程：上下文工程

Harness 最核心的工程挑战是上下文工程——上下文窗口是有限且易失的，而真实任务需要的信息量远超窗口容量。Harness 通过四种策略管理上下文。

第一种是压缩。对话进行到一定长度后，用模型把前面的内容浓缩成摘要，后续请求只携带摘要加最近的原文。压缩的时机和粒度需要精细调校：压缩太频繁浪费 token，压缩太迟又失去意义。好的实现是分层压缩——不同粒度的摘要按需取用。

第二种是状态卸载。把中间状态（搜索结果、工具输出、计划清单）从上下文窗口移出，存入外部存储（文件、数据库、向量库），需要时再按 ID 取回。这让 Agent 能处理远超上下文容量的任务，代价是状态管理复杂度上升。

第三种是任务隔离。把一个大任务拆给多个子 Agent，每个子 Agent 只看到自己那部分上下文。这与多智能体系统共享同一套思想：用上下文隔离对抗注意力衰减，让每个执行单元都在"小而清晰"的环境里工作。

第四种是信息路由。Agent 不把所有信息都塞进上下文，而是按需获取：先检索索引，再取具体内容。这与 RAG 的思路一脉相承——上下文是稀缺资源，只装载当下需要的信息。

四、Harness vs Framework：有立场的操作系统

很多团队困惑：Agent Harness 和 LangChain、LangGraph 这类框架有什么区别？答案是立场的区别。

Framework 是中立的基础层，提供构建块：链式组件、工具调用、记忆模块、编排原语。框架基本不在乎你怎么组装这些原语——这意味着灵活性，同时也意味着你要自己解决所有生产环境问题：上下文管理怎么做、失败重试怎么做、状态持久化怎么做，框架统统不替你决定。

Harness 建立在 Framework 之上，或者完全替代它，提供一个有主观立场的基础设施层。它内置了上下文管理、工具执行、状态持久化和验证的默认架构。你不需要从零组装，只需定制和扩展 Harness 提供的能力。类比而言：Framework 是给你一堆零件和说明书，Harness 是给你一台装好操作系统的电脑，你只需安装自己的应用。

对开发者而言，Harness 范式最大的价值是视角转换。过去构建 Agent 应用，你需要同时是提示词工程师、上下文管理专家、工具集成工程师和可靠性工程师；而在 Harness 范式下，这些重复劳动被基础设施接管，你可以把精力聚焦在应用层的独特逻辑——定义 Agent 要完成什么、如何判断成功、怎么与业务系统交互。

五、一个警示：Harness 复杂化并不总是有效

Harness 范式带来一个新趋势：自我进化。工程师观察 Agent 为什么失败，然后修改提示词、添加工具、调整记忆、重写编排逻辑；而 Harness Evolution 更进一步，让 Agent 自己完成这些改进——Agent 不仅能完成任务，还能修改支撑自己工作的系统，从而一轮比一轮更强。

这个愿景很诱人，但 2026 年的研究给出了冷静的警示。在一项把 Harness Evolution 与最简单的"多跑几遍"放在同等条件下的对照实验中，复杂的 Harness Evolution 并没有稳定胜过简单的 test-time scaling（测试时扩展算力）。更值得注意的是，当进化出来的 Harness 被拿去解决从未参与优化的新任务时，提升只剩下了很小一部分。

这个结果的含义深远：Agent 的"自我进化"提升，可能很大一部分来自它比普通 Agent 多获得了几次尝试机会，而不是真的学会了更好的工作方式。对工程实践的启示是：不要盲目追求复杂的自我进化机制，先把"失败重试、结果择优、轨迹分析"这些简单手段用到极致——很多时候，花哨的架构不如多跑几遍。

六、Harness 范式的落地路径

Harness 范式不是学术概念，而是可以立即落地的工程方法论。落地的第一步是盘点现有系统：你当前的 Agent 应用中，哪些 Harness 组件是缺失的？多数团队的现状是只有系统提示词，没有验证钩子、没有状态持久化、没有失败重试机制。逐个补齐，往往比换更强的模型提升更大。

落地的第二步是建立 Harness 的评估闭环。因为 Harness 的每个组件都可能影响最终表现，必须能量化"改动是变好了还是变差了"。做法是准备一个覆盖典型任务的评估集，每次修改 Harness 组件后跑分对比。没有评估闭环的 Harness 优化，就是在黑暗中调试。

落地的第三步是渐进式引入。不要一次性把全套 Harness 组件堆上，而是从最痛的点开始：如果 Agent 频繁输出格式错误，先加验证钩子；如果长任务经常丢失上下文，先加状态卸载；如果失败后不会恢复，先加重试机制。每一个组件都解决一个真实发生的问题，再决定是否引入下一个。

七、Harness 时代的开发者角色

最后讨论 Harness 范式对开发者角色的重塑。在"模型 + Harness"的世界里，模型能力会持续提升，Harness 组件会越来越标准化，但有一个角色不会消失：决定 Harness 如何设计的架构师。

原因在于，Harness 的本质是"把不确定性转化为确定性"的系统：模型输出是概率性的，而业务需要确定性的行为。谁来定义"什么算是成功"？谁来设定"失败后怎么办"？谁来划定"哪些信息该进入上下文"？这些决策无法被标准化，因为它们依赖对具体业务的深刻理解。模型可以越来越强，Harness 可以越来越完善，但"如何定义问题、如何判定成败"的判断力，始终是人的工作。

这也解释了为什么 Agent Harness 被称为"2026 年 AI 工程的核心范式"：它把 AI 工程的重心，从"调教模型"转移到"设计系统"。理解并掌握这套系统设计方法论的团队，将在 AI 应用的下半场获得决定性的工程优势。