摘要
1) 一句话总结
通过优化系统提示词、中间件等脚手架工程并引入自我验证与追踪分析，在保持模型（gpt-5.2-codex）不变的情况下，编程智能体在 Terminal Bench 2.0 上的得分提升了 13.7 分，排名从前 30 跃升至前 5。
2) 关键要点
- 性能提升结果：仅通过调整脚手架，智能体在 Terminal Bench 2.0 上的得分从 52.8% 提升至 66.5%。
- 自动化追踪分析：利用 LangSmith 追踪数据构建了“追踪分析器技能”，通过并行的错误分析智能体汇总反馈，指导脚手架的快速迭代改进。
- 强制自我验证：通过系统提示词和
PreCompletionChecklistMiddleware（完成前检查清单中间件）拦截智能体退出，强制其进入“规划-构建-验证-修复”循环，要求其运行测试并根据完整输出修复错误。 - 环境上下文注入：使用
LocalContextMiddleware自动注入目录结构和工具路径，并添加时间预算警告，帮助智能体在严格的超时限制内完成工作。 - 打破“死亡循环”：部署
LoopDetectionMiddleware监控单文件编辑次数，当对同一文件进行 N 次（如 10 次以上）无效编辑时，强制智能体退一步重新评估计划。 - 优化算力与推理分配：为平衡超时限制与性能，采用
xhigh-high-xhigh的“推理三明治”策略（规划和验证用最高算力，构建用高算力），该策略得分为 66.5%，优于纯xhigh模式（因超时降至 53.9%）和纯high模式（63.6%）。 - 模型定制化：脚手架需针对特定模型进行定制迭代，例如使用为 Codex 优化的脚手架运行 Claude Opus 4.6 仅获得 59.6% 的分数。
3) 风险与差距
- 过度拟合风险：针对单一任务过度拟合脚手架更改会损害泛化能力，并可能导致其他任务的性能倒退。
- 上下文组装缺陷：智能体在未见过的环境中自主组装上下文、发现目录和搜索工具时极易出错。
- 时间感知缺失：智能体在时间估计方面表现极差，在没有外部时间预算警告的情况下，容易在有严格超时限制的任务中失败。
- 短视与固执：智能体在确定初始计划后容易变得短视，倾向于接受第一个看似合理的解决方案，且容易陷入对同一错误方案进行微小变动的“死亡循环”。
- 缺乏主动验证倾向：当前模型缺乏自然进入“构建-验证”循环的倾向，通常在阅读自己的代码认为无误后就会停止，而不去运行实际测试。
正文
简而言之：我们的编程智能体在 Terminal Bench 2.0 上的排名从前 30 名跃升至前 5 名。我们仅仅改变了脚手架（Harness）。以下是我们进行脚手架工程的方法（剧透：自我验证和追踪起到了很大作用）。
脚手架工程的目标
脚手架的目标是塑造模型固有的、参差不齐的智能，使其适用于我们关注的任务。脚手架工程关乎系统，即围绕模型构建工具，以优化任务性能、Token 效率、延迟等目标。设计决策包括系统提示词、工具选择和执行流程。
那么，应该如何改变脚手架来提升智能体呢？
在 LangChain，我们使用追踪（Traces）来大规模理解智能体的失败模式。如今的模型很大程度上是黑盒，其内部机制难以解释。但我们可以在文本空间中看到它们的输入和输出，并将其用于我们的改进循环中。
我们使用了一个简单的秘诀，通过迭代将 deepagents-cli（我们的编程智能体）在 Terminal Bench 2.0 上的得分提高了 13.7 分（从 52.8 提升至 66.5）。我们仅仅调整了脚手架，而保持模型（gpt-5.2-codex）不变。
实验设置与脚手架的调节旋钮
我们使用了 Terminal Bench 2.0，这是一个目前用于评估智能体编程能力的标准基准测试。它包含跨越机器学习、调试和生物学等领域的 89 个任务。我们使用 Harbor 来编排运行。它启动沙盒（Daytona），与我们的智能体循环交互，并运行验证和评分。
智能体的每一个动作都存储在 LangSmith 中，其中还包括延迟、Token 计数和成本等指标。
我们可以调节的旋钮
智能体脚手架有很多旋钮：系统提示词、工具、钩子/中间件（hooks/middleware）、技能、子智能体委派、记忆系统等等。我们刻意压缩了优化空间，重点关注三个方面：系统提示词、工具和中间件（我们用来指代围绕模型和工具调用的钩子的术语）。
我们从默认的提示词以及标准的工具和中间件开始。使用 GPT-5.2-Codex 的得分为 52.8%。这是一个不错的分数，刚好排在目前排行榜的前 30 名之外，但还有提升空间。
追踪分析器技能
我们希望追踪分析是可重复的，因此将其转化为一种智能体技能（Agent Skill）。这作为我们分析跨次运行错误并对脚手架进行改进的秘诀。流程如下：
- 从 LangSmith 获取实验追踪数据。
- 生成并行的错误分析智能体 → 主智能体综合发现和建议。
- 汇总反馈并对脚手架进行有针对性的更改。
这与专注于纠正先前运行错误的 Boosting 算法类似。人类在第 3 步中可以提供很大帮助（虽然不是必需的），以验证和讨论提议的更改。过度拟合某个任务的更改不利于泛化，并可能导致其他任务的性能倒退。
自动化的追踪分析节省了数小时的时间，使快速尝试实验变得容易。我们很快就会发布这项技能，目前正在测试它在一般提示词优化中的效果。
真正提升智能体性能的因素
自动化的追踪分析使我们能够调试智能体出错的地方。问题包括推理错误、未遵循任务指令、缺乏测试和验证、超时等。我们在以下部分详细介绍这些改进。
构建与自我验证
如今的模型是卓越的自我改进机器。
自我验证允许智能体在一次运行中通过反馈进行自我改进。然而，它们并没有进入这种“构建-验证”循环的自然倾向。
最常见的失败模式是：智能体编写了一个解决方案，重新阅读了自己的代码，确认看起来没问题，然后就停止了。测试是自主智能体编程的关键部分。它有助于测试整体的正确性，同时为智能体提供用于爬山算法（hill-climb）优化的信号。
我们在系统提示词中添加了关于如何解决问题的指导：
- 规划与发现：阅读任务，扫描代码库，并根据任务规范和如何验证解决方案构建初始计划。
- 构建：在考虑验证的情况下实施计划。如果测试不存在则构建测试，并测试正常路径（happy paths）和边缘情况。
- 验证：运行测试，阅读完整输出，将其与要求的内容进行比较（而不是与你自己的代码进行比较）。
- 修复：分析任何错误，重新审视原始规范，并修复问题。
我们非常关注测试，因为它推动了每次迭代中的更改。我们发现，除了提示词之外，确定性的上下文注入也有助于智能体验证其工作。我们使用了一个 PreCompletionChecklistMiddleware（完成前检查清单中间件），它在智能体退出前对其进行拦截，并提醒它根据任务规范运行验证。这类似于 Ralph Wiggum 循环（通过钩子强制智能体在退出时继续执行），我们将其用于验证。
为智能体提供环境上下文
脚手架工程的一部分是为上下文工程构建一个良好的交付机制。Terminal Bench 任务带有目录结构、内置工具和严格的超时限制。
- 目录上下文与工具：
LocalContextMiddleware在智能体启动时运行，以映射当前工作目录（cwd）以及其他父子目录。我们运行 bash 命令来查找 Python 安装等工具。上下文发现和搜索容易出错，因此注入上下文可以减少这种错误面，并帮助智能体熟悉其环境。 - 教导智能体编写可测试的代码：智能体不知道它们的代码需要如何具备可测试性。我们添加了提示词，说明它们的工作将通过程序化测试进行衡量，类似于提交代码时的情况。例如，任务规范中提到的文件路径应被严格遵循，以便解决方案在自动评分步骤中有效。强调边缘情况的提示词有助于智能体避免仅检查“正常路径”情况。强制模型符合测试标准是避免随着时间推移产生“劣质代码堆积（slop buildup）”的有效策略。
- 时间预算：我们注入了时间预算警告，以促使智能体完成工作并转向验证。智能体在时间估计方面出了名的糟糕，因此这种启发式方法在这种环境中很有帮助。现实世界的编程通常没有严格的时间限制，但如果不添加任何关于约束的知识，智能体就不会在时间限制内工作。
智能体对其环境、约束和评估标准了解得越多，它们就能更好地自主引导其工作。
脚手架工程师的目的：准备并交付上下文，以便智能体能够自主完成工作。
鼓励智能体退一步并重新考虑计划
智能体一旦决定了计划就可能变得短视，这会导致“死亡循环（doom loops）”，即对同一个错误的方案进行微小的变动（在某些追踪中达到 10 次以上）。
我们使用了一个 LoopDetectionMiddleware（循环检测中间件），它通过工具调用钩子跟踪每个文件的编辑次数。在对同一个文件进行 N 次编辑后，它会添加诸如“……考虑重新审视你的方法”之类的上下文。这可以帮助智能体从死亡循环中恢复，尽管如果模型认为自己是正确的，它仍可能继续沿着同一条路走下去。
重要提示：这是一种设计启发式方法，旨在解决当今感知到的模型问题。随着模型的改进，这些护栏可能将不再需要，但在今天，它有助于智能体正确且自主地执行。
选择在推理上花费多少算力
推理模型可以自主运行数小时，因此我们必须决定在每个子任务上花费多少算力。你可以在每个任务上使用最大的推理预算，但大多数工作都可以从优化推理算力支出中受益。
Terminal Bench 的超时限制带来了一种权衡。更多的推理有助于智能体评估每一步，但可能会消耗超过 2 倍的 Token/时间。gpt-5.2-codex 有 4 种推理模式：low、medium、high 和 xhigh。
我们发现推理有助于规划以完全理解问题，一些 Terminal Bench 任务非常困难。一个好的计划有助于更快地获得有效的解决方案。
后期的验证也受益于更多的推理，以捕捉错误并提交解决方案。作为一种启发式方法，我们选择 xhigh-high-xhigh 的“推理三明治（reasoning sandwich）”作为基准。
仅在 xhigh 模式下运行得分较差，为 53.9%，原因是智能体超时；相比之下，在 high 模式下得分为 63.6%。在不同推理预算分配的试验运行中没有巨大差异，因此我们坚持了我们的方法，将分数推高至 66.5%。
模型的自然方法是自适应推理（Adaptive Reasoning），这在 Claude 和 Gemini 模型中可以看到，模型自己决定在推理上花费多少算力。
在多模型脚手架中，平衡推理预算的体现可能是使用大模型进行规划，并将其移交给较小的模型进行实施。
构建智能体脚手架的实用要点
智能体的设计空间很大。以下是我们从实验和构建 deepagents 整体过程中得出的一些一般原则：
- 代表智能体进行上下文工程：如今，上下文组装对智能体来说仍然很困难，尤其是在未见过的环境中。为模型提供目录结构、可用工具、编程最佳实践和问题解决策略等上下文，有助于减少因搜索不佳和规划中可避免的错误而产生的错误面。
- 帮助智能体自我验证其工作：模型偏向于它们的第一个看似合理的解决方案。积极地提示它们通过运行测试和完善解决方案来验证其工作。这在没有人类参与的自主编程系统中尤为重要。
- 将追踪作为反馈信号：追踪允许智能体进行自我评估和调试。将工具和推理结合起来进行调试很重要（例如：模型走错路是因为它们缺乏工具或缺乏如何做某事的指令）。
- 在短期内检测并修复不良模式：如今的模型并不完美。脚手架设计师的工作是围绕当前的缺点进行设计，同时为未来更智能的模型做规划。盲目重试和不验证工作就是很好的例子。这些护栏几乎肯定会随着时间的推移而消失，但为了在今天构建健壮的智能体应用程序，它们是值得尝试的有用工具。
- 为模型量身定制脚手架：Codex 和 Claude 的提示词指南表明，模型需要不同的提示词。使用早期版本的脚手架对 Claude Opus 4.6 进行的测试运行得分为 59.6%，具有竞争力但比 Codex 差，因为我们没有对 Claude 运行相同的改进循环。许多原则是通用的，比如良好的上下文准备和对验证的关注，但为你的任务运行几轮脚手架迭代有助于最大化智能体在各项任务中的性能。
在脚手架设计方面还有更多开放性研究要做。有趣的途径包括多模型系统（Codex、Gemini 和 Claude 协同工作）、用于持续学习的记忆基元（以便智能体能够自主改进任务），以及衡量跨模型的脚手架变化。
对于改进智能体的外部循环，我们正在寻找像 RLM 这样的方法来更有效地挖掘追踪数据。我们将继续致力于改进脚手架，并公开分享我们的研究。
我们创建了一个追踪数据集与社区分享。
Deep Agents 是开源的，提供 Python 和 Javascript 版本。
向更多的爬山算法优化和开放研究致敬。
相关文档
- Deep Agents 的上下文管理；关联理由：上下游；说明：该文解释了 Deep Agents 在长任务中的上下文压缩机制，对本文提到的
LocalContextMiddleware与上下文工程形成直接技术补充。 - 智能体可观测性：驱动智能体评估的核心动力；关联理由：解说；说明：该文系统阐述了追踪如何驱动评估闭环，与本文“用 LangSmith 追踪分析迭代脚手架”的方法论一一对应。