核心要点
- 仅调整 harness，而不更换底层模型，也能显著提升 agent 表现。
- LangChain 依靠 trace 分析、失败模式归纳和定向改动，形成了可迭代的 harness 优化流程。
- 重点优化点包括：更好的 system prompt、工具设计，以及 middleware 驱动的计划与自验证机制。
- 评估要围绕真实行为构建，不能只堆 benchmark 分数。
原文链接 English Original — LangChain Blog, by LangChain Team
这篇文章的核心观点很直接：Agent 性能不只取决于模型，也高度取决于 harness。LangChain 在保持 gpt-5.2-codex 不变的前提下，仅通过调整 deepagents-cli 的系统结构，就把 Terminal Bench 2.0 分数从 52.8 提高到 66.5，排名从 Top 30 提升到 Top 5。 作者先定义了 Harness Engineering 的目标：把模型这种“有尖峰、有波动的智能”，塑形成更适合目标任务的工作引擎。harness 负责的不只是 prompt，还包括工具、执行流程、middleware、技能与验证机制。真正的优化不是拍脑袋改 prompt，而是基于 trace 看失败发生在哪里、为什么发生，再决定改哪一层。 LangChain 在实验中刻意压缩优化空间，只盯三类可控杠杆：System Prompt、Tools、Middleware。他们先从一个默认配置开始跑基线，然后把所有执行过程记录到 LangSmith 里，分析模型在规划、读文件、验证、修复等环节的行为失误。为了让错误分析可复用，他们甚至把“Trace Analyzer”做成了一个 Agent Skill，用来批量拉取 traces、并行分析失败样本，再综合成具体的 harness 修改建议。 文章特别强调了两个提升杠杆。第一是把更多 reasoning compute 用在计划与验证上：不是让模型一把梭输出，而是通过中间步骤让它先想清楚、再自查。第二是用 tracing 支撑迭代：模型内部很黑盒，但文本输入输出是可观察的，因此 trace 就成了 harness 改进的事实基础。 对我们自己的 Agent 系统来说，这篇文章的价值不只是一个案例，而是一套方法论：先把 agent 当作“系统工程”而不是“模型调用”，再用可观测性把失败模式结构化，最后用小而准的 harness 改动持续推高表现。