在大模型时代，我们已经能让 AI 写代码、总结文档、回答复杂问题。但当真正把它们投入知识工作（企业搜索、研发辅助、复杂决策支持）时，很多人会遇到同一个隐形天花板：token 成本失控、多轮工具调用低效、输出可靠性不足。

这不是模型本身不够强，而是我们缺少一层关键的工程抽象——Harness（马具/外壳）。

本文基于 Tony Gentilcore（Glean 联合创始人，前 Google Chrome 速度团队创始人）在 X 上的长文重构，将这一正在快速成为行业共识的模式进行系统拆解，帮助技术团队理解为什么 Harness 正在从“可选优化”变成知识工作 AI 系统的必备层。

知识工作的真实痛点：不是模型弱，而是调用方式原始

大多数人使用大模型的方式仍然停留在“直接 prompt + 工具调用”阶段：

• 每次需要外部信息，就发起一次工具调用（search、code interpreter、database query 等）
• 复杂任务需要多次来回（agent 思考 → 工具 → 观察 → 再思考）
• 不同模型有不同能力边界，切换模型就得重写大量 prompt 和工具逻辑
• token 消耗随任务复杂度指数级增长

结果就是：即使模型很强，整体系统依然贵、慢、不可靠。

在知识工作场景中，这种原始调用方式的问题被进一步放大。因为知识工作通常涉及：

• 多源异构数据
• 长上下文推理
• 需要可靠、可验证的输出
• 对成本敏感（企业级使用）

单纯堆模型参数或 prompt engineering，已经无法根本解决这些结构性问题。

Harness 到底是什么？

Harness 不是另一个 Agent 框架，而是一个围绕模型的工程外壳，它负责：

1. 标准化输入输出：把业务上下文、工具能力、输出格式统一抽象
2. 智能工具编排：让模型在一次思考中规划并批量调用多个工具，而不是多次往返
3. 模型无关性：底层可以无缝切换 Claude、GPT、Gemini 等模型，而上层业务逻辑几乎不变
4. 成本与可靠性控制：通过缓存、路由、验证、回退等机制降低 token 消耗并提升稳定性

简单说，Harness 把“模型 + 工具”的原始组合，升级成了一个可生产、可观测、可优化的系统。

Tony Gentilcore 在文中强调的核心观点是：Harness 的出现，让知识工作 AI 从“玩具”走向“工具”。这和当年浏览器性能优化、Web 标准演进的逻辑高度一致——底层能力再强，也需要正确的中间层才能发挥最大价值。

一个关键优化：从多次往返到单次批量工具调用

这是目前 Harness 带来的最直接收益之一。

传统 Agent 模式：

• 模型思考 → 调用工具 A → 拿到结果 → 思考 → 调用工具 B → 拿到结果 → 思考…

每次工具调用都是一次完整的模型推理 + 网络往返，token 和延迟成本都很高。

使用良好设计的 Harness 后，模型可以在一次前向推理中完成：

• 规划整个任务
• 决定需要哪些工具
• 以结构化方式一次性请求多个工具

后续由 Harness 负责并行/串行执行工具、汇总结果、再喂回模型继续推理。

实际案例显示，这种模式能让某些知识工作任务的 token 成本降低近 50%，同时显著减少延迟和失败率。

这不是模型变聪明了，而是调用范式变聪明了。

Harness vs 原始 Agent 调用的核心对比

维度	原始模型/简单 Agent 调用	成熟的 AI Harness 系统
工具调用方式	多次串行往返	单次规划 + 批量/并行执行
模型依赖性	强绑定特定模型（prompt 高度定制）	模型无关，可平滑切换
Token 效率	随任务复杂度快速上升	通过编排和缓存显著降低
可靠性	容易因单点失败或幻觉导致整个流程崩盘	内置验证、回退、重试机制
可观测性	黑箱，难排查	完整链路追踪、成本归因、性能监控
工程维护成本	每次换模型或加工具都要重写大量逻辑	上层业务逻辑稳定，变化集中在 Harness 层
适合场景	简单聊天、原型验证	企业知识工作、复杂多步推理、生产环境

为什么 Harness 会成为知识工作 AI 的标配？

从工程角度看，Harness 解决了三个根本矛盾：

1. 模型能力 vs 系统可靠性
   再强的模型也会有幻觉。Harness 通过结构化输出约束、结果验证、多模型投票等机制，把“偶尔出错”变成“可控风险”。

2. 灵活性 vs 成本控制
   知识工作对成本极度敏感。Harness 通过智能路由（简单任务用便宜模型、复杂任务用强模型）、结果缓存、工具调用优化等手段，让系统在保持能力的同时大幅降低长期使用成本。

3. 快速迭代 vs 长期稳定
   模型更新极快（每月都有新版本）。没有 Harness 层，每次模型升级都可能需要重构整个 Agent 逻辑。有了 Harness，模型变化被隔离在上层业务几乎无感知。

这和当年 Chrome 速度团队做浏览器性能优化的思路完全一致：不要只盯着底层引擎，要在正确的位置建立抽象层。

在生产环境中落地 Harness 的关键思考

如果你正在构建或评估知识工作 AI 系统，以下几个问题值得认真回答：

• 你的当前 Agent 是否还在做“一次只调用一个工具”的低效循环？
• 当底层模型更换时，业务逻辑需要改动多少？
• 你是否能清晰地归因每次任务的 token 消耗和失败原因？
• 在复杂多步任务中，是否已经实现了“规划 + 批量工具调用”的能力？

这些问题的答案，直接决定了你的系统是停留在“能用”阶段，还是真正进入“可用且可规模化”阶段。

Harness 不是银弹，但它可能是当前阶段，知识工作 AI 从实验室走向生产环境最重要的一层工程抽象。

正如 Tony Gentilcore 所指出的：Harness 正在重新定义我们与大模型协作的方式。那些率先把 Harness 做扎实的团队，将在下一阶段的 AI 竞争中占据明显优势。

---

实践建议：
下周内，挑一个你目前用 Agent 处理的知识工作任务（比如文档总结 + 多源检索 + 代码生成），尝试用“单次规划 + 批量工具调用”的思路重新设计流程，看看 token 消耗和成功率能提升多少。

如果你已经在使用或构建类似 Harness，欢迎分享你在工具编排、成本优化或模型切换上的具体经验。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。