模型趋同之后，外围工程如何决定智能体的应用上限

当基础模型的能力逐渐收敛，行业内一个越来越清晰的事实浮出水面：同一个模型，放在不同的外围工程封装下，任务通过率可以出现数个百分点的差距。这个差距不足以颠覆“模型是基础”的判断，却足以让人重新审视一个问题——当模型能力已经相对固定，外围工程究竟改变了什么？

本文尝试从工程视角拆解这一问题，讨论外围工程（下文统称 harness）能够挪动的空间在哪里、边界在哪里，以及开发者应当如何为自己的项目算账。

一、什么是 harness：模型之外的“信息通道”

可以把 harness 理解为模型周围的一整层工程结构，它至少包含四个组成部分：

• 提示词组织：系统提示、任务描述、上下文注入的顺序与粒度；
• 工具定义与暴露方式：向模型暴露哪些工具、工具的描述精度、参数约束；
• 工具结果的回传形式：工具执行后返回给模型的内容结构、截断策略、错误信息表达；
• 执行循环：模型与工具之间的多轮交互如何驱动，何时终止，何时重试。

这四者共同决定了模型“接收到什么信息”以及“如何连续做事”。换一层 harness，本质上就是换一种信息供给方式与任务推进节奏。模型本身的参数没有变，但它所面对的问题被重新表述了。

一个直观的类比是：同一个经验丰富的工程师，交给他的需求文档质量不同、可用工具不同、反馈闭环不同，最终交付质量会有明显差异。harness 做的就是这份“文档 + 工具 + 反馈”的工程化工作。

二、差距从何而来：几个百分点的通过率说明了什么

行业内已有公开的对照数据表明，同一模型在不同 harness 下，长任务基准的通过率可能相差数个到十个以上百分点。这类数据通常来自厂商自测，每个任务跑多次 trial，因此不能直接等同于某个具体项目可获得的收益。但它至少说明一个方向性结论：harness 的差异是真实存在的，且在某些任务类型上影响显著。

需要强调的是，这类对照数据的正确读法是“参考区间”而非“承诺收益”。厂商自测环境、任务分布、评分口径都与真实业务不同，直接套用数字容易产生误判。开发者更应当关注的是差距背后的机制，而不是差距的具体数值。

三、harness 能挪动的空间在哪里

结合工程实践，harness 的影响主要集中在三类场景，且每一类的优化逻辑并不相同。

3.1 长任务：上下文管理与阶段推进

长任务的核心矛盾是上下文窗口的有限性与任务信息量的增长之间的冲突。harness 在这里的作用体现在：

• 阶段化拆解：把长任务拆成可验证的子目标，每个子目标只向模型暴露必要上下文，避免无关信息稀释注意力；
• 中间状态持久化：把已完成步骤的结论写入外部存储（如结构化文件或状态记录），而不是全部堆在对话历史里；
• 检查点机制：在关键节点设置显式校验，失败时回退到最近的检查点而非从头重来。

这些手段不改变模型能力，但显著降低了模型在长链条中“迷失”的概率。

3.2 多工具：工具描述与结果结构的精度

工具数量增多后，模型面临的是选择成本与结果解析成本的双重上升。harness 的优化点包括：

• 工具描述的约束化：明确参数的取值范围、必填项、典型用法，减少模型试错；
• 结果回传的结构化：工具返回内容做裁剪与归一化，把冗长的原始输出转换为模型易消费的摘要加关键字段；
• 错误信息的可操作性：失败时返回可据以修正的具体原因，而不是笼统的异常堆栈。

一个示意性的结果回传结构如下：

{
  "status": "partial_success",
  "summary": "已读取配置文件，但目标字段缺失",
  "key_fields": {"config_path": "...", "missing": ["timeout"]},
  "next_action_hint": "请补充 timeout 字段后重试"
}

相比直接回传原始日志，这种结构让模型更容易判断下一步动作。

3.3 重复上下文：缓存与去重

多轮交互中，大量上下文会被反复送入模型。harness 可以通过上下文去重、稳定前缀的组织、以及对外部知识的按需检索，降低重复信息的占比。这既影响准确率（减少干扰），也直接影响成本（输入 token 数量）。

四、准确率、成本、速度要分别算账

harness 优化很少是“全面变好”，更常见的是三者之间的权衡。因此评估时必须分开核算：

• 准确率：以任务通过率或人工抽检合格率为指标，按任务类型分层统计，避免平均值掩盖长尾失败；
• 成本：区分输入与输出 token、工具调用次数、重试次数，按单任务完成成本计算，而非按单次请求；
• 速度：关注端到端完成时间而非单次响应延迟，长任务中重试与等待工具返回往往才是耗时主体。

同一套工程思路在不同模型上会交出不同成绩单：某些模型在准确率与成本上更优，但端到端耗时可能上升。是否接受这种交换，取决于业务对时延的敏感度。脱离场景谈“哪套 harness 更好”没有意义。

五、给开发者的实践建议

1. 先建评估集，再谈优化：用自己业务的真实任务构建小规模评估集，固定 trial 次数与评分口径，任何 harness 改动都在同一评估集上对比。
2. 分层归因：把失败案例按“提示词问题、工具问题、结果解析问题、循环控制问题”分类，避免笼统归因于模型能力。
3. 优先优化长任务与多工具场景：这两类场景中 harness 的杠杆最大，重复上下文场景则优先做去重与缓存。
4. 三项指标同时记录：准确率、单任务成本、端到端耗时缺一不可，避免单指标优化带来的隐性退化。
5. 谨慎对待外部对照数据：把厂商自测数据当作方向参考，不当作项目收益预期。

结语

模型趋同并不意味着工程空间消失，而是意味着竞争重心从“选哪个模型”部分转移到“如何组织模型周围的信息与流程”。harness 的决定性作用集中在长任务、多工具与重复上下文三类场景，且其收益必须以准确率、成本、速度三项分别核算。对开发者而言，扎实的评估集与分层归因，比追逐任何单一对照数字都更有价值。