Agent Harness 组件效应:工具、上下文压缩与 Sub-agent

作者
DeepSeekAgent.io 编辑部
发布
更新

Agent Harness 经常把工具、规划、Skill、上下文压缩与 Sub-agent 一起交付,因此很难判断性能究竟来自哪一层。论文 Beyond the Model: Demystifying Harness Effects in Software Engineering Agents 先比较 mini-SWE-agent 与 OpenCode,再构建模块化 NanoHarness,分别加入五类能力,对 Qwen3.7-Max 与 DeepSeek V4 Pro 进行组件消融。

这组实验给出了一个清晰结论:Harness 的收益主要来自有方向的结构化交互,而不是简单增加步骤、Token 或 Agent 数量。

DeepSeek V4 Pro 的单组件结果

配置ProgramBench 得分相对基础线
mini-SWE-agent 基础线45.14—
结构化工具注册48.68+3.54
显式规划小幅提升—
Lazy Skills中等、模型相关的提升—
上下文压缩41.29-3.85
任务型 Sub-agent49.60+4.46
通用 Sub-agent低于基础线—
完整 NanoHarness51.35+6.21

工具注册和面向具体任务的 Sub-agent 是两项最稳定的正向组件。完整组合并不是把单项收益机械相加,但仍将 DeepSeek V4 Pro 从 45.14 提升到 51.35,接近同一实验中的 OpenCode 52.48 与 Claude Code 52.76。

为什么上下文压缩降低了得分

DeepSeek V4 Pro 的压缩配置把平均 Prompt Token 从 10,065,204 降到 2,312,701,减少 77.02%;与此同时,得分下降 3.85 个百分点,步骤和工具调用也分别减少 61.91% 与 68.87%。

ProgramBench 要求 Agent 在长轨迹中保留接口约束、行为要求和调试状态。过早摘要可能删除后来仍然需要的细节。压缩确实显著节省 Token,但它不是无损优化;阈值、保留比例和摘要内容必须按任务调整。

这与 DSH 的 Compaction 设计直接相关:更早触发可以避免窗口溢出,却不能只追求最小上下文。长任务应把关键需求、失败证据和未完成检查项保留在摘要中。

为什么任务型 Sub-agent 有效,通用 Sub-agent 反而拖累

任务型 Sub-agent 为 DeepSeek V4 Pro 增加了 73.10% 的工具调用,却把 Prompt Token 降低 9.54%,并提升 4.46 个百分点。工作被拆成明确的仓库探索、实现或验证职责,新增调用仍然围绕交付目标。

通用 Sub-agent 的工具调用增加 82.65%,Prompt Token 增加 51.86%,结果却低于基础线。没有清晰职责和交付协议时,委派会产生重复探索、上下文复制与协调开销。

因此,多 Agent 的关键不是数量,而是任务边界:

  1. 每个成员只负责可验证的子目标;
  2. 明确输入、输出与停止条件;
  3. 避免多人同时读取和总结同一批文件;
  4. Lead 只接收结论、证据位置和未解决问题;
  5. 对没有独立价值的小步骤,直接由主 Agent 完成。

工具越多也不等于 Harness 越强

论文中表现最稳定的是“结构化工具注册”,不是无限扩大工具目录。模型需要清楚知道工具何时适用、参数如何填写、失败会返回什么,以及结果怎样进入下一轮上下文。

完整 NanoHarness 在 DeepSeek V4 Pro 上使工具调用增加 83.58%,Prompt Token 只增加 7.26%,得分提高 6.21。有效的 Harness 把更多交互导向任务,而不是让上下文与调用量同步膨胀。

对 DSH Profile 的直接启示

  • **Minimal:**适合短任务与模型本身已经能稳定操作工具的场景。
  • **Standard:**工具、续轮和检查机制更完整,但要监控无进展循环。
  • **Compaction:**以任务连续性为目标配置,不要把 Token 最少当作唯一指标。
  • **Sub-agent:**优先建立任务型角色,限制通用委派和上下文复制。
  • **Skills:**按需加载程序性知识,避免把所有说明放进每轮系统提示词。

一套合理的 DSH 实验不应只比较“开或关某个插件”。应该同时记录完成率、工具调用、Prompt Token、压缩次数、子 Session 数量与失败类型。

相关阅读

参考资料