DSH Sub-agent 用量与计费分析：会话统计与账单差异

DSH 主会话显示的 Token 并不一定等于供应商账户的总用量。社区一组运行记录中，界面显示 7,874,011 Token，12 分钟的供应商账单为 54.77 元；检查 Session 后发现任务创建了 42 个 Sub-agent。三个数字分别来自主会话事件、子会话调用和供应商计费系统，统计范围不同。

本文把这次记录作为审计样本，拆解 DSH 主会话、Sub-agent Session 和供应商账单之间的关系，并给出可以复用的核对方法。

案例数据

这些数据来自单次社区运行，不能直接外推为 DSH 或 V4.1 Flash 的固定成本。它提供了一个清晰的排查入口：界面统计和账单差异较大时，先确认是否存在主界面之外的子会话。

三套统计口径

主会话事件

DSH 界面汇总当前 Session 事件中供应商返回的 Usage。父 Agent 自己发起的模型请求、工具循环和上下文处理会进入这组数字。

Sub-agent Session

Sub-agent 使用独立 Session 和日志。父会话可以看到子任务创建与完成，但父界面的 Token 总数不一定把每个子 Session 的模型 Usage 加回来。42 个 Sub-agent 同时工作时，父会话显示值只能解释其中一部分调用。

供应商账单

供应商按账户或 API Key 汇总实际请求。账单还可能区分输入、输出、缓存读取、缓存写入和推理 Token。最终费用应使用供应商账单与定价表核算，不能只用界面总 Token 乘一个单价。

并发怎样放大用量

Sub-agent 的价值在于并行探索和任务拆分，成本也会随并发分支增加。每个子 Session 都可能携带系统提示、任务上下文、工具结果和自己的历史。一个父任务创建 42 个子任务时，即使每个分支只运行少量 Step，也会重复处理大量共同上下文。

成本可以按下面的结构理解：

总用量
  = 父 Session 模型调用
  + 所有子 Session 模型调用
  + 恢复、重试与继续执行产生的调用

如果子任务还会继续创建子任务，需要按完整 Session 树统计，不能只查看父 Session 的直接孩子。

为什么不能只对比 Token 总数

两个相同的 Token 总量，价格可能不同。核对账单时至少拆出：

• 输入 Token 与输出 Token；
• 缓存命中读取与缓存写入；
• 推理 Token 或供应商特有的计费项；
• 不同模型 ID 与路由；
• 成功、重试和中断请求；
• 父 Session 与每个子 Session 的调用。

社区案例提到平均 1.45 秒一次请求和约 67K 上下文。高频率与长上下文同时出现时，短时间内也能积累较高输入量。

一套可复用的审计方法

1. 固定时间范围

记录任务开始与结束时间、时区、API Key 和模型 ID。在供应商账单中只查看相同窗口，避免把其他应用的请求混入。

2. 导出 Session 树

从父 Session 开始，列出全部直接和间接 Sub-agent。每个 Session 至少记录：

3. 按 Session 汇总

先分别计算父会话和每个子会话，再汇总整棵树。不要一开始就把所有事件混成一行，否则很难识别异常分支。

4. 对齐供应商明细

按时间、模型和请求数量对齐供应商数据。差异仍然存在时，再检查缓存计费、推理 Token、重试和账单延迟。

5. 记录统计缺口

把“DSH 当前界面可见”“DSH 日志可导出”“供应商账单可见”分成三列。缺失字段应标记为空，不要用估算值冒充明细。

如何控制 Sub-agent 成本

缩小任务拆分

明确允许创建的子任务数量、每个子任务的交付物和停止条件。一个文件定位任务不需要同时创建多条相似探索分支。

限制并发

根据供应商速率、预算和工作区承载能力设置并发上限。v0.1.6-alpha.1 的实验性 Team 默认 Teammate 创建上限提高到 16，更需要在 Profile 和供应商侧设置自己的限制。

避免重复上下文

给子任务传递必要文件、接口和验收条件，减少整段父会话历史的重复输入。返回结果时优先使用结构化摘要，不把所有探索日志重新注入父会话。

使用供应商预算

固定提交的源码分析没有发现 maxCost、costLimit 或 spendLimit 形式的整轮费用熔断。生产环境应使用供应商提供的预算、额度和告警作为最后边界，并保留人工取消入口。

监控完整 Session 树

监控面板应同时显示父 Session、活动子 Session 数、累计请求数、累计 Usage 与预计费用。只显示当前页面的 Token，会把并发成本留在视野之外。

与长 Agent Loop 的区别

一个简单任务运行 50 轮的案例主要发生在单个 Turn 内：模型持续检查，历史不断增长。本案例的重点是多条子会话并发执行。两种情况都能放大 Token，但治理方式不同：前者需要 Step 和停止边界，后者需要 Session 树统计、并发限制与账户级预算。

常见问题

DSH 显示的 Token 是错的吗？

它反映当前 Session 可见事件中的 Usage。问题在于统计范围：子 Agent 使用独立 Session 时，父会话数字不等于账户总用量。

54.77 元可以直接换算出一个 Token 单价吗？

不可以。需要知道输入、输出、缓存和推理 Token 的明细，以及每个请求实际使用的模型和路由。

最先应该检查什么？

先查看 Session 树和活动 Sub-agent 数，再把所有子 Session 的 Usage 汇总到同一时间窗口，与供应商账单核对。