DSH Sub-agent 空完成态分析

DeepSeek Harness Sub-agent：推理预算耗尽与空结果

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

Sub-agent 显示 completed，不一定代表任务产物已经完成。2026 年 10 月 20 日公开的一次 DSH 复现中，后台 Sub-agent 运行约 20 分钟，消耗完整输出预算，却没有调用工具、没有返回正文、也没有创建任何文件，父 Agent 最终仍收到完成状态。

这个案例的重要性不在于一次任务失败，而在于 Harness 把“Provider 正常结束响应”折叠成了“工作已经成功完成”。当任务价值全部存在于磁盘产物时，空结果与成功共用一个状态，会同时制造可靠性与成本问题。

这次 Session 实际发生了什么

复现者解压并检查 Sub-agent 的 Session Log 后，记录到：

  • 整个生命周期只有 1 个 Turn、1 个 Step；
  • Assistant Message 只有 reasoning，没有 text 与 tool_use；
  • 输入为 32,853 Token；
  • 输出为 32,000 Token，正好到达输出上限；
  • 其中 31,955 个是 Reasoning Token；
  • turn/end 仍被记录为 completed。

任务本身是机械性的 Markdown 批量改写，并且要求脚本验证 13 个文件。换言之，这不是 Agent 执行了一半，而是它在第一次可见行动之前就把整轮预算用在了内部推理上。

为什么 Harness 会把它判成完成

复现基于 DSH 0.2.0-rc.2 的 continuable background Sub-agent。报告定位到的状态折叠逻辑有两个关键点：

  1. Activation Observer 的默认停止原因为 completed；
  2. 只有 Assistant 输出包含非空内容时，结算通知才附带 Closing Message。

Provider 在 Token 上限附近干净结束，并不一定返回一个 Harness 能识别的截断错误。如果这一轮只有 Reasoning Block，既没有 Tool Call，也没有可见文本，Observer 仍可能沿用默认完成态。父 Agent 看到的就只是“已完成”，却得不到空正文、零工具调用和预算耗尽之间的因果信号。

completed 应该表示什么

Agent Runtime 至少需要区分三件事：

  • 响应结束：Provider 不再生成 Token；
  • 执行结束：Agent Loop 不再推进；
  • 任务完成：验收条件与产物已经满足。

这三个状态不能由一个 completed 代替。响应可以正常结束，但任务完全没有开始；执行也可以停止，但原因是预算耗尽、权限拒绝或工具失败。只有 Harness 验证了输出、工具行为或外部产物，才能把任务层状态交给上游继续使用。

为什么这会浪费大量 Token

对机械任务使用高推理档位时，模型可能在计划、复核和重新规划之间持续消耗预算。只要第一步没有形成工具调用，Harness 就看不到工作进展。此时再长的 Reasoning 也不会修改文件。

更危险的是父 Agent 把空 completed 当成成功后继续执行：它可能开始汇总并不存在的成果，或者再次派发相同任务，形成新的 Token 消耗。这个故障与 Sub-agent 计费盲区 和 Agentic Loop 过长问题 属于同一条可观测性链：界面状态没有完整表达实际模型调用和产物状态。

适合机械任务的调度约束

1. 降低默认推理档位

批量改名、格式修复、文件搬运和确定性代码替换，通常不需要高推理预算。为这类 Sub-agent 显式设置较低 Reasoning Effort，把预算留给工具执行和验证。

2. 让第一步产生外部进展

任务提示可以明确要求第一项动作必须是只读检查或工具调用，而不是长篇计划。对于文件任务，先列出目标文件、读取样例或创建进度记录，都比不可见推理更容易判断 Agent 是否真正启动。

3. 定义可验证的完成契约

父 Agent 不应只信任状态字符串。至少检查：

  1. Closing Message 非空；
  2. 预期文件、提交或报告存在；
  3. 验证命令已经执行并返回预期状态。

如果任务包含多个文件，可以让子任务持续写入 Heartbeat 或清单，最终以 done 标记结束。这样即使会话异常终止，也能区分“没有开始”“正在执行”和“已经验收”。

4. 限制无工具活动的预算

Harness 可以为“连续 Reasoning 但没有 Tool Call”单独设置阈值。到达阈值时，应返回 max-tokens、no-observable-progress 或其他明确状态，而不是继续沿用 completed。

Runtime 应补充哪些信号

父 Agent 的结算通知至少应包含：

  • Stop Reason；
  • 输入、输出与 Reasoning Token；
  • Tool Call 数量；
  • 非空 Assistant Text 是否存在；
  • 产物或验收检查结果。

当“输出接近上限、零工具调用、零可见文本”同时出现时，Harness 可以直接将其识别为推理预算耗尽。即使暂时不改变状态机，向父 Agent显示一行诊断，也能避免把空结果当成成功。

对 DeepSeek V4.1 Flash 调度的意义

V4.1 Flash 能支持长上下文和复杂 Agent 任务，但更大的上下文与推理预算不应成为所有子任务的默认答案。模型能力越强，Harness 越需要按任务类型分配预算：研究、架构与模糊决策可以保留更高推理强度；确定性改写、文件操作与验证任务应优先执行、及时产生产物，并使用明确上限。

参考资料

常见问题

为什么输出达到 Token 上限却没有正文？

模型可以把输出预算几乎全部用于 Reasoning Block。如果没有剩余空间生成文本或工具调用，用户可见输出就可能为空。

把 Reasoning Effort 调低会不会降低所有任务质量？

不应全局一刀切。低推理更适合确定性机械任务；复杂研究和架构任务仍可以使用更高档位。关键是按任务类型路由。

父 Agent 怎样确认子任务真的完成？

同时检查非空结算消息、外部产物和验收命令。单独的 completed 状态不足以证明交付完成。