转载说明：本文译自 Improving Deep Agents with harness engineering。原发布方：LangChain。原文发布日期：2026-02-17。本文为基于原文结构与论证路径的完整中文翻译与适配。通过 Harness Engineering 提升 Deep Agents 性能 TLDR：我们的编码 Agent 在 Terminal Bench 2.0 上从 Top 30 提升到了 Top 5。我们只改了 harness。下面是我们做 harness engineering 的方法（先剧透：自验证和 tracing 很关键）。Harness Engineering 的目标 Harness 的目标，是把模型那种“峰值很高但波动也很大”的智能，塑造成更适合我们目标任务的执行能力。Harness Engineering 关注的是系统层：你围绕模型构建一整套工具链，用来优化任务完成率、token 效率、延迟等目标。可调设计项包括系统提示词、工具选择和执行流程。 那到底该怎么改 harness，才能真正提升 agent？ 在 LangChain，我们用 Traces 来规模化理解 agent 的失败模式。如今的模型在很大程度上仍是黑盒，其内部机制不易解释；但我们可以观察文本空间里的输入输出，并把这些信号放进改进闭环。 我们用一套简单方法，迭代改进 deepagents-cli（我们的编码 agent），在 Terminal Bench 2.0 上把分数从 52.8 提升到 66.5，提升了 13.7 分。整个过程中我们只调整 harness，模型保持不变，仍是 gpt-5.2-codex。 实验设置与 Harness 的可调旋钮 我们使用 Terminal Bench 2.0（当前用于评估 agentic coding 的标准基准之一）。它包含 89 个任务，覆盖机器学习、调试、生物等多个领域。我们用 Harbor 来编排实验：它会拉起沙箱（Daytona）、驱动我们的 agent loop，并执行验证与打分。 每一步 agent 动作都会存入 LangSmith；同时记录延迟、token 数量和成本等指标。我们能调哪些旋钮 一个 agent harness 有很多旋钮：系统提示词、工具、hooks/middleware、skills、子 agent 委派、记忆系统等。我们有意压缩优化空间，只聚焦三个维度：System Prompt、Tools 和 Middleware（我们对模型调用和工具调用周边 hook 的称呼）。 我们从默认提示词和标准工具+middleware 起步。在 GPT-5.2-Codex 下起始分数是 52.8%。这个分数并不差，今天大致在榜单 Top 30 之外一点，但还有明显提升空间。 Trace Analyzer Skill 我们希望 trace 分析流程可复用，于是把它做成了一个 Agent Skill。它是我们“跨多次运行分析错误并改进 harness”的固定配方，流程如下：从 LangSmith 拉取实验 traces。启动并行错误分析 agents，再由主 agent 汇总结论与建议。聚合反馈，并对 harness 做有针对性的修改。 这种方法类似 boosting：重点盯住上一轮的错误样本。第 3 步里，人类参与（虽然不是必须）通常很有价值，用于核验并讨论候选修改。对单任务过拟合会损害泛化，还可能在其他任务上引入回归。 自动化 trace 分析节省了大量时间，也让我们能快速试验。我们很快会发布这个 skill；目前它正在用于更通用的 prompt 优化测试。 到底哪些改动真正提升了 Agent 性能 自动化 trace 分析让我们能更快 定位 agent 的失败点。常见问题包括：推理错误、未遵循任务指令、缺少测试与验证、超时等。下面按改进点展开。Build & Self-Verify 当下模型本质上是很强的“自改进机器”。 自验证让 agent 能在单次运行内借助反馈自我改进。但模型并不会天然进入这种 build-verify 循环。 最常见失败模式是：agent 写完方案，回看一遍代码，自认为没问题，然后就停了。测试是自治编码 agent 的关键环节：它既验证整体正确性，也给 agent 提供可用于爬坡优化的反馈信号。 我们在系统提示词中补充了问题求解流程：Planning & Discovery： 阅读任务、扫描代码库，基于任务规格和验证方式制定初始计划。Build： 按“可验证”目标实现方案；若没有测试则补测试，覆盖 happy path 与边界场景。Verify： 运行测试并完整阅读输出，对照的是任务要求，而不是你自己写的代码。Fix： 分析错误，回到原始规格，…