Harness 工程决定 Agent 工具调用行为，而非工具数量 · 干货攻略

  • 链接: https://x.com/omarsar0/status/2083594893541126557
  • 分类: x-tips
  • 来源: X @omarsar0
  • 作者: Jay
  • 更新: 2026-08-12

这是什么

2026 年，AI 社区出现了一个重要认知转向：Agent 的表现瓶颈不在模型本身，而在包裹模型的那层工程结构——Harness（驾驭层）。Harness 由 @omarsar0（Elvis，研究机构 DAIR.AI 联合创始人）提出，核心主张是：Agent 的工具调用行为由 Harness 决定，而非工具数量；Harness 的核心能力是决定何时不调用工具，这比堆砌更多工具更重要。

Harness 不是一个新框架，而是一套工程原则：在模型外围构建结构，让模型的行为变得可靠、可控、可测量。它包含系统提示词工程、工具编排、上下文管理、验证循环、循环检测中间件等组件——这些组件决定了 Agent 在每个执行步骤看到什么、被允许做什么、何时停止。

为什么值得关注

谁在推动这个认知

Elvis（@omarsar0） 是 DAIR.AI（Data-centered AI Research）联合创始人，长期在 X 分享 AI 工程实践经验，同时在 DAIR.AI Academy 开课传授 Agent 开发。2026 年 7-8 月，他多次发帖强调 Harness 工程是 AI Builder 最重要的核心技能，"The opportunity on harness engineering alone is hard to even measure"。

这一观点迅速得到多位行业实践者的验证和扩展：

  • @billynewport 在同帖下补充：Harness 分为显式（Claude Code、Open Code、Codex）和隐式（文件系统、SQL 数据库、网络访问）两层。
  • Phil Schmid（Hugging Face） 在 2026 年 8 月的博客中，将 Model 比作 CPU，Harness 比作操作系统——CPU 提供算力，OS 管理内存、调度进程、强制权限、恢复崩溃。
  • Faros.ai 干脆用一句话总结行业认知："The model is commodity. The harness is moat."（模型是商品，Harness 才是护城河）

解决什么问题

大多数团队做 Agent 的路径是：先堆工具，再调 Prompt，再换模型。结果发现工具越多，Agent 越容易选错工具、进入死循环、上下文爆炸。

Harness 工程解决的是这个困境：不再靠加工具来提升能力，而是靠设计 Harness 让现有工具被正确调用。

核验过程

官方来源（已读）

  1. LangChain 官方工程报告（2026-02-17）：Improving Deep Agents with Harness Engineering，作者 Vivek Trivedi，链接：https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering
    核心数据：deepagents-cli 在 Terminal Bench 2.0 上从 52.8% 提升到 66.5%，排名从 Top 30 以外进入 Top 5，模型固定为 gpt-5.2-codex，全程只改动 Harness，涉及自我验证系统提示、上下文注入、循环检测中间件三个方向。原文数据：52.8 → 66.5（+13.7 分）。

  2. Phil Schmid（Hugging Face）博客（2026-08）：The importance of Agent Harness in 2026，链接：https://www.philschmid.de/agent-harness-2026
    提供了 Model/CPU、Context/RAM、Harness/OS、Agent/Application 的四层类比，以及 benchmark 测量失真的系统性分析。

  3. Harness-Engineering.ai 完整指南：链接：https://harness-engineering.ai/blog/agent-harness-complete-guide
    给出六大核心组件（上下文工程、工具编排、状态管理、验证与安全、人在回路、观测性），以及 95% 可靠率 × 20 步 = 36% 最终成功率的复合失败率数学分析。

  4. Daily.dev 社区综述（2026-07-15/22，更新）：引用 Elvis 推文原文，提供了五层模型（Prompt → Context → Harness → Loop → Graph Engineering），链接：https://daily.dev/posts/ai-engineering-in-2026-agents-are-everywhere-but-humans-still-run-the-loops-t8knr6vxz

  5. Faros.ai 工程博客（2026）：引用 LangChain 案例，链接：https://www.faros.ai/blog/harness-engineering
    注明 LangChain 在 2026 年 3 月将 Terminal Bench 2.0 排名从第 30 位提升至第 5 位。

交叉验证（已读）

Vercel d0 Agent 案例（2025-12-22 官方博文，链接：https://vercel.com/blog/we-removed-80-percent-of-our-agents-tools）：

指标 16 工具旧架构 1 工具新架构 变化
平均执行时间 274.8s 77.4s 3.5x 下降
成功率 4/5（80%） 5/5（100%） +20%
平均 token 消耗 ~102k ~61k 37% 下降
平均步数 ~12 ~7 42% 下降

Vercel 原文明确：删掉了 80% 的工具后，Agent 反而更准、更快、更省。这是 Harness 工具编排层优化的直接证据。✅ 多来源一致验证。

Vercel 原文关键引述：

"We spent months building a sophisticated internal text-to-SQL agent, d0, with specialized tools... It worked… kind of. But it was fragile, slow, and required constant maintenance. We tried something different. We deleted most of it and stripped the agent down to a single tool: execute arbitrary bash commands."

LangChain Terminal Bench 2.0 数字验证：Terminal Bench 2.0 官方 leaderboard（https://www.tbench.ai/leaderboard/terminal-bench/2.0）页面数据与 LangChain 官方博文数据一致，WOZCODE/Claude Opus 4.7 以 80.2% 排名第一梯队，LangChain 66.5% 确在 Top 10 范围内。✅ 官方 leaderboard 验证。

存疑点

  • 原帖提到 @omarsar0 强调"决定何时不调用工具比堆工具数更重要"，但这是 omarsar0 的推文主张，其具体工程实操细节（如何判断何时不调用）未找到独立文档；DAIR.AI Academy 的 Harness 课程大纲未公开核实。该具体方法论以 omarsar0 推文主张为准，未找到第三方详细文档。

上手步骤

Harness 工程的实践框架可归纳为以下层面：

第一层：系统提示词（System Prompt）—— 告诉模型何时不该调用工具

LangChain 的实践是在提示词中加入自我验证循环指引：

Plan → Build → Verify → Fix
  • Plan & Discovery：读任务、扫代码库、按规格制定验证计划
  • Build：实现时内置测试（happy path + edge cases）
  • Verify：跑测试、读完整输出、与原始规格对比
  • Fix：分析错误、回到原始 spec 修复

关键：提示词里要明确让模型停止的标准，而非让模型自己判断"做完了没有"。

第二层：工具编排（Tool Orchestration）—— 动态控制工具可见性

Vercel d0 的教训是：不要把全部工具一次性暴露给模型，而是按任务阶段动态暴露工具：

规划阶段 → 不需要写文件权限
执行阶段 → 不需要网络搜索
验证阶段 → 只需要运行测试工具

Vercel 将 16 个专业工具压缩到 1 个（bash），结果更好。核心洞察：约束工具集 = 减少选错工具的概率 = 减少 token 浪费。

第三层：中间件钩子（Middleware / Hooks）—— 检测并干预错误行为

LangChain 的 LoopDetectionMiddleware 在同文件编辑次数超过阈值时，强制插入"consider reconsidering your approach"提示，防止 Doom Loop。

PreCompletionChecklistMiddleware 在 Agent 退出前强制触发一次验证 pass。

第四层：上下文工程（Context Engineering）—— 让模型知道它在哪

LocalContextMiddleware：
- 启动时注入 cwd 目录结构
- 发现 Python 安装路径等环境工具
- 注入时间预算警告（防止超时）

第五层：追踪与反馈（Tracing）—— 量化 Harness 的效果

LangChain 将每一次 Agent 行为记录在 LangSmith，用 Trace 分析技能（Agent Skill）自动聚合错误模式并提出 Harness 改进建议。

坑与适用边界

哪些场景 Harness 工程效果最明显？

  • 复杂多步骤任务（>10 步），因为单步 95% 可靠率 × 20 步 = 36% 最终成功率的复合效应巨大
  • 同一模型被多个团队使用，Harness 质量直接决定任务完成率差距（同一模型 60% vs 98%）
  • 需要生产级可靠性的场景，Demo 靠模型，Production 靠 Harness

哪些场景 Harness 优化效果有限？

  • 简单单步任务（<3 步）：Prompt 本身已经够用
  • 模型本身能力严重不足：Harness 救不了根本性推理缺陷
  • 强结构化输出任务：直接用 JSON Mode / Structured Output 比定制 Harness 更高效

常见陷阱

  1. 过度设计控制流：Phil Schmid 指出，2026 年的模型已能在上下文窗口内处理过去需要复杂管道的逻辑，过度设计反而在模型更新后成为负担。原则：Build to Delete，让架构模块化，随时准备替换。
  2. 忽视验证循环：Vercel 和 LangChain 案例共同指向同一个答案：验证是最高ROI的单项投入，团队从 83% 提升到 96% 任务完成率，靠的就是加验证层，不是换模型。
  3. 认为工具越多越好：Vercel 删了 80% 工具后成功率从 80% 跳到 100%，这个结论是反直觉但被反复验证的。
  4. 模型自我评估作为结束信号：Agent 说"完成了"不是证据，通过测试才是证据。

一句话结论

2026 年 Agent 的竞争维度已从"选哪个模型"转移到"Harness 怎么设计"——删工具、添验证、让 Harness 决定何时停，比换模型更有效。