最近，Anthropic、OpenAI、LangChain、Perplexity等全球顶流团队不约而同地将目光投向Harness Engineering。为什么偏偏是Harness？

试想这样一个场景：面对不同的开发任务，同样的Harness + 大语言模型（LLM）组合，有时丝滑流畅，有时却表现糟糕。多数人的第一反应是“大模型能力不够，换个更强的LLM就好”——但你有没有想过，问题可能出在Harness上？

最直观的佐证来自LangChain团队：他们做了一项Harness改进实验，结果出人意料！

使用同样一个大语言模型，但是没有改进Harness之前的排名是30+，但是改进Harness之后直接排到第5名

补充一个题外话，一起来看Claude Code官方修复的三个bug。

近期，围绕 Claude Code的一次性能波动，官方在《Anthropic April 23 Postmortem》[3]中进行了复盘。用户侧的直观感受是模型能力“下降”，但复盘结果表明，问题主要来自系统层（而非LLM本身）的变更。

从官方公布的信息来看，问题涉及多项因素，其中包括：

• 对模型行为约束的调整（提示或模型推理能力层的限制变化），影响了模型的表达与决策空间
• Harness运行时机制的缺陷（缓存优化），导致有效上下文未能被稳定保留或复用

这些问题的叠加，使模型在实际使用中出现了诸如重复调用工具、上下文利用不稳定、token使用额度不够用等现象，从而给用户最大的感受就是“能力退化”。

即使模型本身结构保持不变，Harness的细微改动，也可能通过影响上下文结构、约束条件或状态传递机制，显著改变LLM的实际表现与用户体验。

换句话说：

LLM 的能力不仅取决于模型本身，还强依赖于其所处的运行环境（比如，Harness之类的变化）。

---

01 怎么理解Harness Engineering?

一个概念的溯源——Beren Millidge在2023年4月的文章《Scaffolded LLMs as Natural Language Computers》中写过一句话，

"What we have essentially done here is reinvented the von-Neumann architecture and, what is more, we have reinvented the general purpose computer."

原文中的 “Scaffolded LLMs”，指的就是将大语言模型与外部工具调用、记忆管理、任务编排等“脚手架代码”相结合的系统。这个概念发展到今天，正是社区所说的“Harness Agent”。

所以，虽然Beren Millidge没有直接使用“Harness Agent”这个词，但思想内核完全一致。

那么，Harness Engineering的”萌芽“早在2023年就埋下了，并非不是凭空出现的，而是整个Agent系统演进到一定阶段，抽象出的一个核心层。 2026年的“破土”，是因为技术和实践终于成熟到需要为这个“LLM的操作系统”正式并更加系统化地构建它了。

这正好印证了那句技术圈的老话：重要的发明往往不是一蹴而就的，而是在时机成熟时被“重新发现”并赋予结构。

回顾了Harness Agent的历史，这里我们先借助一个例子来思考，怎么来理解2026年初定义的Harness？——可以站在计算机组成工作原理的角度：

如果把整个Harness结构的智能体系统看作"一台计算机"，那么LLM就是CPU、模型调用的工具就是外部设备，Harness 就是操作系统——负责任务编排、记忆管理与 LLM 之间的桥梁；而Agent就是跑在这个系统上的应用，面向具体目标自动执行任务。

LangChain’s Vivek Trivedy: "If you are not the model, you are the harness."

因此，可以将Harness理解为面向LLM的一种运行与编排环境，用于组织和调度模型调用流程。它通常包含编排循环、工具调用接口、上下文与记忆管理、错误处理以及防护机制等能力，本质上更接近一种调度与运行时框架。

实际中与之相对应的，Anthropic的Claude Code、OpenAI的Codex相关体系则是在此基础上进一步抽象出的面向Agent的运行体系——它们将工具使用、任务分解、状态管理与执行策略进行整合，同时将LLM推理决策与“系统”行动执行解耦（LLM专注于思考任务）。这类框架更准确地说是驱动LLM Agent的系统化开发与运行环境，并不是简单的工具封装。

说到这里这也能解释为什么我们最初想象的那个场景（同样的Harness+大模型，有的场景丝滑，有的场景翻车）。因为就像一台电脑，如果操作系统调度不好，再强的CPU也会卡死。Harness的威力就在于：它决定了LLM到底是一颗裸芯片，还是一台能跑流程的完整计算机。

从这个角度看，2026年大家集体关注Harness Engineering，其实是一个必然：当LLM的能力已经提升很多的时候以及面对我们日常需求的时候，自然就需要考虑“如何用好这颗裸芯片”这一层上。

既然Harness相当于LLM的“操作系统”，那么这个操作系统具体是怎么运转的？

02 Harness内部的运转原理？

Harness的工程运转可以分为三个层次：

• 提示词工程构建模型完成任务的指令；
• 上下文的管理；
• Harness Engineering则涵盖了上述两者，还包括整个应用基础设施，它是使自主智能体行为成为可能的完整系统。

OpenAI、Anthropic等公司认为，Harness的重要组成可分为11个部分，且这些部分相辅相成，支撑着Agent稳定运行——编排循环、工具（比如各种MCP服务器工具）、记忆、上下文管理、提示词管理、状态点检测、错误处理、护栏、验证与反馈、子Agent编排、初始化与环境搭建。

这里我们详细分析部分组成的意义，其余分析可以参考[1]：

1.工具

在Harness工程中，工具调用方式会在上下文组织时被重组为提示词并做格式化转化，作为提示词动态注入LLM，让模型了解自己可以调用哪些工具。

比如，Claude Code提供了文件操作、搜索、命令执行、网络访问、Web工具、代码智能和子智能体生成等多类工具能力。

但在越来越重视LLM工程化落地的时代，一些厂商倾向于在模型后训练阶段就直接引导模型学习如何调用工具。例如DeepSeek V4采用了基于XML的标记系统来组织工具调用（如DSML标记系统），这样可以规避JSON转义失败导致的调用错误。

这似乎给我们一个启示：未来Harness是否会被“内化”为LLM自身的能力，直到不再需要它？我们先把这个问题留在这里。

2.记忆

过去智能体系统中的记忆机制往往容易出现混乱或遗忘。其表层原因通常归因于上下文窗口有限以及信息随时间步逐渐退化，但更本质的解释在于：系统缺乏跨时间尺度的记忆调度与压缩机制。

因此，记忆不应在单一上下文窗口中的被动存储，而需要在不同时间尺度上进行分层管理与信息压缩（即对历史信息进行选择、重构与保留），以提升长期一致性与推理稳定性。

在当前主流的智能体框架设计中包括Claude Code等所体现的思路，通常可以观察到一种分层记忆范式这种范式（在一定程度上借鉴了人类记忆的分层特征，是一种工程上的抽象），整体上可以概括为三层：

短期记忆：即当前上下文窗口中的信息，用于支撑即时推理，但容量受限且易被覆盖；

中期记忆：通过外部存储（如SQL向量数据库或日志）保存历史交互，在需要时检索相关片段，并经过压缩或摘要后重新注入上下文；

长期记忆：对稳定、高价值的信息（如用户偏好、任务经验）进行结构化总结，并以较低频率更新，作为持续行为的指导信号。

需要强调的是，这里的“长期记忆更新”并不是模型参数层面的学习，而是通过外部机制（如总结、筛选与写回）实现的显式记忆管理过程。

类似的设计理念也出现在一些开源系统（如Hermes Agent）中，体现出一个共识趋势：即通过分层记忆 + 检索 + 压缩来在有限上下文窗口下近似实现长期一致性与持续改进能力。

3.安全

OpenAI SDK设了三道护栏：输入防护、输出防护和工具防护，一旦触发立即“断线”停止。Anthropic则在架构上将权限执行与模型推理分开——模型决定要做什么，工具系统决定允许做什么。

Claude Code对约40种工具能力进行独立管控，分为三个阶段：项目加载时建立信任、每次工具调用前做权限检查（比如代码编辑权限等）、高风险操作需用户明确确认。

4.验证与反馈

即便经过精心设计的Agent框架，LLM仍然基于概率分布进行生成，其会有不可避免地存在一定程度的不确定性（例如事实性偏差或格式错误的“幻觉”）。那么，在模型完成一个完整任务后，引入外部校验与反馈机制是必要的。

具体而言，可以通过代码执行验证、格式约束检查、规则校验等方式，对模型输出进行自动检测，并在必要时触发修正或重试流程。

这样的设计本质上是在Agent系统中引入一个“生成—验证—修正”闭环，以降低模型自身生成偏差对最终结果的影响，从而提升整体系统的可靠性与稳定性。

Boris Cherny, creator of Claude Code, noted that giving the model a way to verify its work improves quality by 2 to 3x.

5.子Agent编排

当任务复杂度持续提升时（例如涉及多个专业领域、大量工具调用或长流程依赖），单一智能体往往会面临上下文负载过高、决策路径冗长以及工具调度混乱等问题，从而影响整体表现。

在这种情况下，可以通过将系统从单智能体扩展为多智能体协作模式来进行结构性优化。

多智能体系统的核心思路在于：将复杂任务拆分为多个子问题，并分配给具备不同职责或能力侧重的“子代理”，从而实现并行处理或模块化协作。

这种方式本质上是一种计算结构的重构，而不仅仅是简单的“多调用几次模型”。

以Claude Code为例，其提供了多种代理协作的执行模式（如Fork、Teammate、Worktree），分别对应不同程度的上下文共享、通信机制与执行隔离。

另一方面，在一些LLM的后训练或能力增强研究中（如Kimi、GLM等相关工作），也可以观察到类似的运作理论：通过构造多角色交互数据、模拟协作式推理流程或引入结构化任务分解信号，来间接提升模型在复杂任务中的表现。

不过，这类方法更多是在训练阶段对“协作能力”的建模或蒸馏，但是并不等同于推理阶段真正运行一个多智能体系统。

03 一个周期内如何动态循环，完成任务？

Harness的完整流程是一个循环，分七步：

1.组装提示：把系统提示、工具模式、记忆、对话历史和当前用户消息拼成完整输入，重要信息放在开头和结尾。

2.大模型推理：提示词组装好的提示送入模型，生成文本或工具调用请求。

3.输出分类：无工具调用则结束；有工具调用则执行；如果请求交接，就切换当前智能体并重启循环。

4.工具执行：校验参数和权限，在沙箱中运行，只读操作可并行，变更操作必须串行，并捕获结果。

5.结果打包：将工具结果格式化为模型可读的消息，错误也当作结果返回，便于模型自我纠正。

6.上下文更新：结果追加到对话历史，接近上下文窗口上限时触发压缩。

7.回到第1步，直到触发终止条件：模型不再调用工具、达到最大轮次、Token预算耗尽、安全护栏触发、用户中断或返回安全拒绝。简单问题只需1~2轮，复杂任务可能串联几十次工具调用。

对于跨多个上下文窗口的长任务，Anthropic采用了“Ralph Loop”两阶段模式：初始化智能体先设置好环境（初始化脚本、进度文件、特性列表和首次 Git 提交），为后续系统工作提供了连续性。

04 真实框架如何实现该模式？

LangGraph 将Harness明确建模为状态图，用llm_call和tool_node两个节点配合条件边：有工具调用则走工具节点，否则结束。它脱胎于已弃用的AgentExecutor，LangChain的Deep Agents则直接称之为“agent harness”，内置了工具、规划、文件系统、子智能体生成和持久记忆[1]。

这里还有其他的应用实例，感兴趣的小伙伴可以看一下参考资料的第一个链接。

05 Harness应该和LLM的能力协同进化？

这里可以回到前文在讨论 Harness 组成部分——“记忆”时留下的一个问题：

一个有意思的现象是：在一些实际系统与工程实践中，比如Mauns等团队在简化Agent框架（即减少显式编排与外部控制逻辑）之后，整体表现并未下降，反而在任务表现上有所提升。这一现象提示我们：Agent性能并不完全依赖外部框架的复杂程度。

一种更合理的解释是，随着大规模语言模型能力的提升，模型在训练过程中已经“内化”部分Harness结构（例如工具使用、分步推理，甚至在数据中体现出的多“智能体”模拟交互模式）。

因此，在一定范围内，模型或许可以“隐式地”承担部分原本由Harness显式实现的功能。当外部框架过于复杂或约束过强时（LLM的推理依赖于合适的条件约束；当约束过强或不匹配时，可能会压缩其生成空间），反而可能限制模型的生成空间与策略灵活性，从而影响整体效果。

不过，这并不意味着Harness不再重要，而是说明其设计需要在“外部控制”与“模型自主性”之间取得平衡。

回到前面的问题，目前仍然缺乏一个统一而明确的答案。但可以较为确定的一点是——目前，记忆的跨时间尺度管理仍然是一个核心挑战。

在以原版Transformer为基础、且依赖有限上下文窗口进行推理的设定下，模型本身并不具备稳定的长期记忆能力，因此仍然需要通过分层记忆、检索与压缩等机制进行补充。

06 总结

我们可以从7个角度来回顾：

1.单智能体 vs 多智能体

先把单个智能体推到极致，考虑到多智能体系统会增加额外开销（用于路由的额外LLM调用、交接时的上下文丢失）。只有在工具过载或存在明显分离的任务域时，才考虑拆分。

2.ReAct vs 计划-执行

ReAct模式每一步都交织推理与行动（灵活但单步成本更高）。计划-执行模式将规划与执行分离，可获相较于前者3.6 倍的速度提升。

3.上下文窗口管理策略

五种生产级方法：基于时间清除、对话摘要、观察屏蔽、结构化思考过程，以及子智能协作。

ACON research showed 26 to 54% token reduction while preserving 95%+ accuracy by prioritizing reasoning traces over raw tool outputs.

4.验证循环设计

计算验证 + 推理验证（比如，LLM作评判者等办法）能捕捉语义问题，可以提升模型完成任务的可靠度，但会增加延迟。

5.权限与安全架构

放任式（快速但有风险，自动批准大部分操作）对比限制式（安全但缓慢，每项操作都需批准）。具体选择取决于部署场景，在安全与LLM完成任务过程中trade-off。

6.工具范围策略

工具越多，往往性能越差。Vercel从中移除了 80% 的工具，结果反而更好。Claude Code通过“via lazy loading”实现了 95% 的上下文缩减。原则是：仅为当前步骤暴露所需的最少工具集。

7.控制Harness厚度

多少逻辑驻留在控制层，多少交给模型。Anthropic应该在LLM自身能力提升的过程中减少Harness的厚度。因此，随着LLM自身将工程能力“内化”，Anthropic会定期从Claude Code的控制层中删除规划步骤（更多发的挥空间还给LLM本身）。

07 参考资料

[1]https://x.com/akshay_pachaar/status/2041146899319971922
[2]https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro/blob/main/DeepSeek_V4.pdf
[3]https://www.anthropic.com/engineering/april-23-postmortem