通过 Harness Engineering 改进 Deep Agents

原文发表于 2026 年 2 月 17 日，作者是 Vivek Trivedy。

文章的核心结论是：在模型不变的情况下，仅通过改进 Agent 的 Harness（运行框架/控制层），就能让 LangChain 的 coding agent 在 Terminal Bench 2.0 上从 Top 30 提升到 Top 5。 (LangChain)

TLDR（简而言之）

我们的 coding agent（代码智能体）在 Terminal Bench 2.0 上的排名从 Top 30 提升到了 Top 5。

而我们唯一改变的，是 Harness（Agent 的运行与控制框架） 。

下面介绍我们是如何进行 Harness Engineering（Harness 工程） 的。

小提示：Self-verification（自我验证）和 Tracing（轨迹追踪）帮助非常大。 (LangChain)

Harness Engineering 的目标

Harness 的目标，是将模型本身这种天然具有"尖峰式"（spiky）的智能表现，塑造成更适合我们所关心任务的能力。

所谓 Harness Engineering ，本质上是在构建一个围绕模型运行的系统，通过各种工具和机制来优化我们真正关心的目标，例如：

任务完成效果（task performance）
Token 使用效率（token efficiency）
延迟（latency）
等等

其中可以调整的设计包括：

System Prompt（系统提示词）
Tool choice（工具选择）
Execution flow（执行流程）

那么问题来了：

我们究竟应该怎样修改 Harness，才能让 Agent 变得更好？

在 LangChain，我们使用 Traces（运行轨迹） 来大规模理解 Agent 的失败模式。

如今的模型在很大程度上仍然是 Black Box（黑盒） ，我们很难直接理解模型内部究竟发生了什么。

但是，我们可以看到模型在 文本空间（text space） 中的输入和输出，然后利用这些信息形成持续的 Improvement Loop（改进循环） 。

我们采用了一套非常简单的方法，对我们的 coding agent------deepagents-cli------进行迭代改进。

在模型始终保持不变、一直使用 gpt-5.2-codex 的情况下，我们仅仅修改 Harness，就让 Terminal Bench 2.0 的得分从：

52.8 → 66.5

也就是提升了 13.7 个百分点 。 (LangChain)

实验设置与 Harness 可以调整的"旋钮"

我们使用 Terminal Bench 2.0 来进行实验。

Terminal Bench 现在已经成为评估 Agentic Coding（智能体编程） 的一个标准 Benchmark（基准测试）。

它包含 89 个任务，涵盖：

Machine Learning（机器学习）
Debugging（调试）
Biology（生物学）
等多个领域。

我们使用 Harbor 来编排（orchestrate）这些实验运行。

它会：

启动 Sandbox（沙箱）环境；
与 Agent Loop（智能体执行循环）交互；
执行 Verification（验证）；
最后进行 Scoring（评分）。

每一次 Agent 的操作都会存储在 LangSmith 中。

其中还包括：

延迟（latency）
Token 数量
成本（cost）

等指标。 (LangChain)

Harness 中我们可以调整哪些东西？

一个 Agent Harness 实际上有很多可以调整的"旋钮"：

System Prompt（系统提示词）
Tools（工具）
Hooks / Middleware（钩子 / 中间件）
Skills（技能）
Sub-agent Delegation（子 Agent 委派）
Memory Systems（记忆系统）
等等。

不过，为了压缩优化空间，我们刻意把重点集中在三个方面：

System Prompt
Tools
Middleware（中间件）

这里 Middleware 是 LangChain 对于围绕模型调用和工具调用的 Hooks（钩子）机制的称呼。

我们从一个默认 Prompt，加上一套标准 Tools + Middleware 开始。

此时，GPT-5.2-Codex 的得分是 52.8% 。

这是一个不错的成绩------刚好排在当时排行榜 Top 30 之外，但显然还有很大的提升空间。 (LangChain)

Trace Analyzer Skill（轨迹分析技能）

我们希望 Trace Analysis（轨迹分析）能够变成一个可重复执行的流程。

所以，我们把它做成了一个 Agent Skill（Agent 技能） 。

它实际上就是一套分析不同实验运行结果中的错误，并据此改进 Harness 的方法。

整个流程如下：

1. 从 LangSmith 获取实验 Traces

首先获取 Agent 每次运行产生的完整 Trace。

2. 并行启动多个错误分析 Agent

让多个 Agent 并行分析错误。

然后由主 Agent（main agent）综合这些分析结果和改进建议。

3. 汇总反馈，并针对性地修改 Harness

最终，根据分析结果，对 Harness 做有针对性的调整。 (LangChain)

这个过程与 Boosting（提升方法） 有些类似。

Boosting 的核心思想之一，就是重点关注之前运行过程中出现的错误。

在人类参与方面，人在第三步其实非常有帮助：

可以检查、验证，并讨论 Agent 提出的修改建议。

不过，人类并不是必需的。

需要注意的是：

如果某项修改只是针对某一个特定任务进行了过度优化（overfit），那么它可能损害系统的 Generalization（泛化能力），甚至导致其他任务出现 Regression（回归/性能倒退）。

自动化 Trace Analysis 可以节省大量时间，也让我们能够快速尝试不同实验。

我们很快会公开这个 Skill。

目前，我们还在测试它是否能够广泛用于 Prompt Optimization（提示词优化） 。 (LangChain)

究竟是什么真正提升了 Agent 的性能？

自动化 Trace Analysis 让我们能够定位：

Agent 到底在哪里做错了。

我们发现的问题包括：

Reasoning Errors（推理错误）
没有遵循任务要求
没有进行测试
没有进行 Verification（验证）
时间耗尽
等等。

下面详细介绍我们针对这些问题进行的改进。 (LangChain)

Build & Self-Verify：构建与自我验证

今天的模型已经是非常优秀的 Self-Improvement Machines（自我改进机器） 。

Self-Verification（自我验证） 允许 Agent 在一次运行过程中，通过反馈不断改进自己。

然而，模型并不会天然地进入这种：

Build → Verify → Fix → 再次 Verify

的循环。

我们发现最常见的一种失败模式是：

Agent 写出解决方案；
重新阅读自己的代码；
觉得"看起来没问题"；
然后直接结束。

但对于 Autonomous Agentic Coding（自主智能体编程）来说，Testing（测试）是非常关键的。

测试不仅能够帮助我们判断整体正确性，同时也能够给 Agent 一个明确的反馈信号，让它知道应该朝哪个方向继续优化。

因此，我们在 System Prompt 中加入了关于问题解决方法的明确指导。

1. Planning & Discovery：规划与探索

首先：

阅读任务；
扫描代码库；
根据任务 Specification（规格说明）建立初始计划；
同时考虑如何 Verification（验证）最终解决方案。

2. Build：构建

根据计划实现解决方案。

但在实现过程中就要考虑 Verification。

如果项目中没有测试，那么就创建测试。

同时测试：

Happy Path（正常路径）
Edge Cases（边界情况）

3. Verify：验证

运行测试。

阅读完整的测试输出。

然后把实际结果与：

任务要求

进行比较，而不是仅仅与：

自己写出的代码

进行比较。

这一点非常重要。

4. Fix：修复

如果发现错误：

分析错误；
回到最初的 Specification；
修复问题。

我们非常强调 Testing，因为它实际上推动了每一次迭代中的改进。

除了 Prompting（提示词设计）之外，我们还发现：

Deterministic Context Injection（确定性的上下文注入）

也能够帮助 Agent 更好地验证自己的工作。

我们使用了一个叫做：

PreCompletionChecklistMiddleware

的 Middleware。

它会在 Agent 准备退出之前拦截 Agent，并提醒它：

根据 Task Specification 再执行一次 Verification Pass（验证流程）。

这与 Ralph Wiggum Loop 的理念有些类似：通过 Hook（钩子）强制 Agent 在准备退出时继续执行。

而我们把这个机制专门用于 Verification。 (LangChain)

给 Agent 提供关于运行环境的 Context

Harness Engineering 的一个重要部分，是建立一个良好的 Context Engineering（上下文工程） 机制。

Terminal Bench 的任务具有：

Directory Structure（目录结构）
Built-in Tooling（内置工具）
Strict Timeouts（严格的时间限制）

因此，Agent 必须知道自己身处怎样的环境。 (LangChain)

1. Directory Context & Tooling

我们使用：

LocalContextMiddleware

在 Agent 启动时运行。

它会告诉 Agent：

当前 cwd（current working directory，当前工作目录）
父目录
子目录
等信息。

同时，我们运行 Bash 命令，寻找：

Python 安装位置
其他可用工具

等。

环境的 Discovery（发现）和 Search（搜索）本身就很容易出错。

因此，与其让 Agent 自己不断搜索，不如直接把环境信息注入 Context。

这样可以减少错误来源，并帮助 Agent 更快理解当前环境。

2. 教 Agent 编写可测试的代码

Agent 并不知道自己的代码究竟需要以什么方式才能被测试。

因此，我们在 Prompt 中明确告诉 Agent：

它的工作最终会通过 Programmatic Tests（程序化测试）进行评估。

这就类似于真正的软件工程中提交代码时所面对的情况。

例如：

如果 Task Specification 中明确提到了文件路径，那么 Agent 必须严格按照要求使用这些路径。

因为最终的 Automated Scoring（自动评分）步骤会依赖这些路径。

同时，我们在 Prompt 中强调：

要考虑 Edge Cases（边界情况）。

这样可以避免 Agent 只测试所谓的：

"Happy Path（正常情况）"。

让模型严格遵循 Testing Standards（测试标准），是防止长期出现：

"Slop Buildup"------低质量代码/低质量实现不断累积

的一种非常有效的策略。 (LangChain)

3. Time Budgeting：时间预算

我们还会向 Agent 注入 Time Budget（时间预算）警告。

目的在于提醒 Agent：

及时完成工作；
在时间不够时转向 Verification。

Agent 在时间估算方面一直表现得很差。

所以在这种环境中，这种 Heuristic（启发式策略）非常有帮助。

现实世界的软件开发通常没有这么严格的时间限制。

但是，如果不把环境限制明确告诉 Agent，那么 Agent 根本不知道自己必须在某个时间边界内完成工作。

因此：

Agent 越了解自己的环境、限制条件以及评估标准，就越能够自主地规划和执行工作。

这也就是 Harness Engineer（Harness 工程师）的核心职责：

为 Agent 准备并交付 Context，使 Agent 能够自主完成任务。 (LangChain)

鼓励 Agent 停下来重新考虑自己的计划

Agent 一旦确定了一个计划，就可能变得非常 Myopic（短视/局部最优） 。

最终形成所谓的：

Doom Loop（死循环）

也就是不断对同一个已经错误的方法进行微小修改。

在某些 Trace 中，我们甚至看到 Agent 对同一种错误方法进行了：

10 次以上

的尝试。

为了解决这个问题，我们使用：

LoopDetectionMiddleware

它通过 Tool Call Hooks（工具调用钩子）追踪：

每个文件被修改了多少次。

当同一个文件被修改达到 N 次之后，它会向 Agent 添加类似：

"......请考虑重新思考你的方法。"

这样的 Context。

这能够帮助 Agent 从 Doom Loop 中恢复出来。

不过，如果模型仍然坚信当前方法是正确的，它还是可能继续沿着同一条路走下去。

这里需要特别强调：

这是一种针对今天的模型存在的问题而设计的工程启发式策略。

随着未来模型能力不断提升，这些 Guardrails（护栏/防护机制）很可能不再需要。

但是：

在今天，它确实能够帮助 Agent 更正确、更自主地完成任务。 (LangChain)

决定应该为 Reasoning（推理）投入多少 Compute

Reasoning Models（推理模型）现在已经可以自主运行数小时。

因此，我们必须决定：

每一个子任务到底应该投入多少计算资源用于 Reasoning？

当然，你可以让每一个任务都使用最大的 Reasoning Budget（推理预算）。

但是对于大多数工作来说，更重要的是：

优化 Reasoning Compute Spend（推理计算资源的投入）。

Terminal Bench 的 Timeout（超时）限制形成了一个 Trade-off（权衡）：

更多 Reasoning → Agent 可以更仔细地评估每一步；
但同时可能消耗超过 2 倍的 Token 和时间。

GPT-5.2-Codex 提供四种 Reasoning Mode（推理模式）：

low
medium
high
xhigh

我们的实验发现：

Reasoning 对 Planning（规划）非常有帮助，因为它能够让 Agent 更完整地理解问题。

Terminal Bench 中有一些任务非常困难。

而一个好的 Plan，往往能够帮助 Agent 更快得到一个可以工作的解决方案。

在后期的 Verification 阶段，更多 Reasoning 同样有帮助，因为它能够让 Agent 更容易发现错误并最终提交正确答案。

因此，我们使用了一个启发式的：

xhigh → high → xhigh "Reasoning Sandwich"（推理三明治）

作为基准方案。 (LangChain)

为什么不一直使用 xhigh？

如果全程只使用 xhigh，结果反而很差：

53.9%

原因主要是 Agent 频繁 Timeout（超时）。

而使用 high 时，得分达到：

63.6%

在不同 Reasoning Budget 分配方案的试验中，我们没有看到特别巨大的差异。

因此最终采用上述方案，并把最终成绩推到了：

66.5% 。 (LangChain)

Adaptive Reasoning：自适应推理

对于模型来说，一个更自然的方式其实是：

Adaptive Reasoning（自适应推理）

目前 Claude 和 Gemini 等模型已经可以根据任务自己决定：

应该投入多少计算资源进行 Reasoning。

在一个 Multi-Model Harness（多模型 Harness） 中，我们还可以进一步平衡 Reasoning Budget。

例如：

使用一个更大的模型负责 Planning，然后把任务 Hand Off（交接/委派）给一个更小的模型进行 Implementation（实现）。

这可能是一种非常有潜力的架构。 (LangChain)

构建 Agent Harness 的实践经验

Agent 的设计空间非常大。

下面是我们在这些实验以及 Deep Agents 的长期开发过程中总结出来的一些通用原则。

1. 代表 Agent 做 Context Engineering

今天的 Agent 仍然很难自己完成 Context Assembly（上下文组装），尤其是在它完全陌生的环境中。

因此，我们应该主动为模型提供：

Directory Structure（目录结构）
Available Tools（可用工具）
Coding Best Practices（编程最佳实践）
Problem-Solving Strategies（问题解决策略）

这些 Context 可以：

减少因为 Search 不佳而产生的错误；
减少规划过程中本可以避免的错误；
降低整体 Error Surface（错误面）。

2. 帮助 Agent Self-Verify

模型往往倾向于相信自己找到的第一个"看起来合理"的解决方案。

因此，要非常积极地 Prompt Agent：

验证自己的工作。

具体而言：

运行测试；
检查结果；
发现问题；
进一步修改解决方案。

对于没有 Human-in-the-Loop（人在回路中的人工监督）的 Autonomous Coding System（自主编程系统），这一点尤其重要。

3. 把 Tracing 当作 Feedback Signal（反馈信号）

Trace 可以帮助 Agent：

自我评估；
自我 Debug；
发现问题。

这里一个重要的原则是：

Tooling 和 Reasoning 必须一起 Debug。

例如：

模型走错方向，有时候并不是因为模型推理能力不足，而是：

它缺少一个必要的工具，或者不知道如何使用某个工具。

因此，只 Debug Model，而不 Debug Tooling，是不完整的。 (LangChain)

4. 短期内检测并修复不良模式

今天的模型仍然并不完美。

Harness Designer（Harness 设计者）的职责，就是：

针对今天模型的缺陷进行工程设计，同时为未来更聪明的模型做好准备。

例如：

Blind Retries（无脑重试）
不进行 Verification

都是今天模型常见的问题。

这些 Guardrails 几乎肯定会随着模型进步而逐渐消失。

但如果我们希望今天就构建可靠的 Agent Application（智能体应用） ，这些机制仍然非常值得实验。 (LangChain)

5. 根据不同模型定制 Harness

不同模型需要不同的 Prompting（提示词策略）。

例如 Codex 和 Claude 的官方 Prompting Guide 都体现了这一点。

我们曾经使用较早版本的 Harness 测试 Claude Opus 4.6：

59.6%

这是一个有竞争力的结果，但仍然低于 Codex。

原因之一是：

我们没有针对 Claude 执行同样的 Improvement Loop（改进循环）。

当然，有很多原则是可以跨模型泛化的，例如：

良好的 Context Preparation（上下文准备）
强调 Verification

但是，如果希望最大化 Agent 在各种任务上的性能：

最好针对你的具体任务，运行几轮 Harness Iteration（Harness 迭代优化）。 (LangChain)

未来还有大量 Harness Research（研究）空间

Harness Design 仍然有大量开放研究问题。

一些非常有意思的方向包括：

Multi-Model Systems（多模型系统）

例如同时使用：

Codex
Gemini
Claude

让不同模型承担不同职责。

Memory Primitives（记忆原语）

建立支持 Continual Learning（持续学习） 的 Memory 机制，让 Agent 能够自主从过去的任务中学习并不断改进。

跨模型衡量 Harness Changes

研究：

一个 Harness 的修改究竟在多大程度上能够跨不同模型产生稳定收益？

这些都值得进一步研究。 (LangChain)

更外层的 Agent Improvement Loop

对于改善 Agent 的 Outer Loop（外层循环） ，我们正在研究类似 RLMs 的方法。

目标是：

更加高效地从大量 Traces 中挖掘有价值的信息。

我们会继续改进 Harness，并且公开分享我们的研究成果。

我们还创建了一个 Trace Dataset（轨迹数据集） ，与社区分享。

Deep Agents 本身也是 Open Source（开源） 的，目前提供：

Python
JavaScript

版本。 (LangChain)

结语

To more hill climbing and open research.
继续进行更多的迭代优化，也继续推进开放研究。

后话

你真正应该从这篇文章理解什么？

如果把整篇文章压缩成一个核心观点，其实就是：

Agent 的能力 ≠ Model 的能力。

更准确地说：

Agent Performance ≈ Model + Harness + Tools + Context + Verification + Feedback Loop

也就是说，一个非常强大的 LLM，如果没有好的 Harness，也未必能够在真实任务中发挥全部能力。

这篇文章最值得注意的地方恰恰是：

他们没有换模型。

模型一直是：

GPT-5.2-Codex

但通过修改：

System Prompt
Tools
Middleware
Context Injection
Self-Verification
Loop Detection
Reasoning Budget
Trace Analysis
Improvement Loop

就把：

52.8% → 66.5%

提升了 13.7 个百分点 ，并让排名从 Top 30 之外进入 Top 5 。 (LangChain)

所以，这篇文章实际上提出了一个非常重要的 Agent Engineering 思维：

不要只想着"换一个更强的模型"，也应该思考"怎样设计一个更好的 Harness，让现有模型发挥得更好"。

尤其值得注意的是，LangChain 把 Trace → 分析失败 → 修改 Harness → 重新运行 → 再分析 Trace 做成了一个持续循环。

这已经非常接近：

Agent Engineering → Evaluation → Trace Analysis → Harness Optimization → Agent Engineering

的闭环。

如果您正在研究 AI Agent / Coding Agent / Deep Agent / Harness Engineering ，这篇文章其实非常值得精读。原文可直接查看：LangChain：Improving Deep Agents with harness engineering