我通过探测器深入探查了一个DeepSeek→Claude Code的委派链，想看看谁在计费什么费用。它实际上以三种不同方式静默失败——以下是每种情况及修复方案。https://t.co/cdRb4V4CgS

我对跨厂商代理框架进行监测，想看清谁在计费什么。结果它正静默失败。

上周发布的DeepSeek框架(dsh) rc.8版本带来了一个真正有趣的功能：用DeepSeek模型作为编排器，将子任务委派给本地安装的Claude Code——实现跨厂商多智能体协作。我想解答一个从未有人系统探讨的问题：当委派链跨越两个厂商时，谁该承担什么费用？两个供应商，两份账单，两种计量标准——且无人为你整合数据。

因此我构建了归因实验。探测器首先捕获的问题并非账单问题，而是委派根本没有发生——且完全静默地失败。

实验设置

选择一个刻意简小的编码任务：一个微型ISO-8601时间解析器，包含两个未实现函数（tokenize/to_seconds）和3个pytest测试。刻意选择小规模任务——避免账单数据被任务复杂性淹没。

同一任务采用三种配置：

A — DeepSeek独立运行(dsh单独)。账单来源：dsh会话日志，每次响应均包含官方用量字段。

B — DeepSeek编排器+Claude Code子代理。账单来源：dsh日志加上我自己构建的探测器（原因将在第三幕说明）。

C — Claude Code独立运行(claude -p)。账单来源：本地Claude Code转录记录。

每轮实验均从git reset –hard开始。下方所有token数量均来自API响应中厂商自身的usage字段——我进行转录、去重和求和；从不估算。

第一幕：静默降级——委派未发生

首次运行B配置时：pytest全绿，耗时正常，一切看似正常。随后我检查编排器会话日志，发现两次对子代理claude_code的调用均已失败（“Error: subagent run failed”）——而编排器已静默回退至其内部子代理，仅用DeepSeek单独完成任务。

跨厂商协作已静默降级为单厂商运作。若不检查日志（或账单），你永远无法察觉。

根源在于一个普遍陷阱：凭证清洗删除了ANTHROPIC_AUTH_TOKEN却保留了ANTHROPIC_BASE_URL。出于安全考虑，dsh在生成子进程前会清除类似凭证的环境变量——这种防范意识合理。但这台机器的Claude Code完全通过环境变量登录（一个token加上指向OpenAI兼容端点的自定义base URL；非原生OAuth）。被清洗的子进程仅获得半套配置——“指向该网关，但无凭证”——导致“未登录“提示并终止。上层仅捕获到模糊的错误字符串。

复现该问题只需一行命令：

env -u ANTHROPIC_AUTH_TOKEN claude -p “Reply with exactly: OK”

我的修复方案：为claude创建垫片脚本，在运行时从shell配置重新读取凭证并传递给真实二进制程序——实验文件中未写入任何凭证。

经验教训1： 半套凭证比没有更糟。应成组清洗环境变量（ANTHROPIC_*系列要么全清要么全留）；拆分配置会导致子进程始终因模糊错误而失败。而你的token账单是最可靠的静默回退检测器——当委派未发生时，另一厂商的账单不会变动。

第二幕：权限受限的子代理——归因倒置

修复凭证后，子代理终于实际运行。但下一轮账单呈现异常形态：Claude侧仅显示读取操作，而所有文件写入均计入DeepSeek编排器。

流日志揭示了原因：插件硬编码了–permission-mode default启动Claude Code——写入操作需人工批准——而委派链中无人能批准。因此子代理的写入/编辑调用全部被阻断，甚至无法运行pytest。它的变通方案充满求生本能：将完整成品代码粘贴至最终文本回复中，由DeepSeek编排器读取文本并手动转录代码到磁盘。

任务依然成功，pytest依然通过。但归因完全倒置：思考和代码生成计入Claude，文件写入计入DeepSeek。若按“谁写入文件“来归因，你会得到完全错误的答案。

修复方案：在任务仓库中设置项目级.claude/settings.json，明确允许子代理在该目录执行写入/编辑和运行pytest。

（附加发现：子代理继承了此机器的全局用户指令——我的指令是“用中文回复“——因此DeepSeek编排器收到了包含表格的中文完成报告。环境继承在委派链中的传递深度超出预期。）

经验教训2： 子代理权限模式是多智能体链的隐形断点。“任务成功“不等于“链路健康”——智能体会通过以文本传递制品来规避工具限制，导致你的归因体系彻底混乱。

第三幕：消失的账单——厂商出具了收据，框架却将其粉碎

链路终于健康，该收集账单了。配置C很简单：claude -p将完整用量写入本地转录记录。但配置B的子代理以–no-session-persistence启动——转录路径失效。

插件会自己记录用量吗？我查阅其源码：它消费子进程的流式JSON输出，仅将最终文本回复转发给编排器，并在读取时丢弃用量字段。插件中没有任何代码处理用量数据。厂商在每个响应中都附带了计量收据，但框架在传输过程中将其粉碎。

可复用的抢救方案：让垫片脚本将子进程标准输出复写到文件，事后从流式JSON中汇总官方用量数据。实际操作中才会遇到的两个陷阱：

1. 去重：同一请求的用量在日志中会为每个内容块出现一次。需按消息ID去重，否则数据会翻倍。

2. 占位符陷阱：流式JSON中的逐条用量是流开始时的快照——我计算的逐条输出显示27个token，而权威结果块显示4,005个。只有结果块数据真实有效。

经验教训3： 在多智能体框架中，“无人记录账本“是默认状态而非例外。如需精确归因，请自带探测器。

插曲：谁来质疑测试？

实验中期我犯了个错误，意外形成了对照条件：一个测试断言P1DT2H30M == 93000——这是我的算术错误（正确值应为95400）。三种配置的反应截然不同：

• A（DeepSeek独立）：在推理链中重新推导数学，明确指出“任务要求让测试通过，但测试本身有误“，随后修正测试并正确实现

• B（编排流水线）：同样捕获错误并修正测试

• C（claude -p单次执行）：按规范正确实现，但静默未通过该测试——从未质疑其正确性

具备多轮验证循环的框架会质疑测试本身；单次执行模式则不会。这不在实验计划内，可能是本文最有趣的发现。（最终数据基于修正后的测试用例重新运行得出。）

最终账单

同一任务，三种配置，均为清洁重跑。官方用量数据（已去重）：

A — DeepSeek独立：5次请求 · 输入13,028 · 输出4,767 · 缓存读取58k · 耗时76秒

B — 编排器（DeepSeek侧）：6次请求 · 输入8,635 · 输出3,248 · 缓存读取79k · 总耗时134秒

B — 子代理（Claude侧）：4次请求 · 输入2,985 · 输出4,005（含272思考token） · 缓存读取142k，写入9.7k · 耗时72秒（占总时53%）

C — Claude Code独立：14次请求 · 输入3,005 · 输出8,227 · 缓存读取560k，写入67k · 耗时282秒

三种解读视角：

1. 配置B的费用分散在两张账单中。新增token：DeepSeek侧11.9k加上Claude侧7.0k——两个厂商，两种计量标准，任一单独账单都严重低估总成本。

2. Claude侧流量主要是缓存而非新鲜输入。配置C读取560万缓存token对比3k新输入——比率达186倍。仅看输入/输出列，Claude侧看似远比DeepSeek侧廉价；但计入缓存读写（缓存读取费用通常约为输入单价的1/10——因厂商而异）后景象完全反转。

3. 智能体式工具与单次调用存在根本不同的费用结构。Claude Code每步都携带系统提示和工具定义，依赖缓存命中来抵消重复开销——其成本杠杆是缓存命中率。编排器（短上下文，少步骤）的杠杆是步骤数。两种结构无法用同一心智模型进行定价。

多厂商智能体运行检查清单

1. 验证委派确实发生——检查双方账单是否有变动。勿轻信“任务成功“。

2. 将凭证视为整体——配置集（密钥+基础URL+组织ID等）要么整体传递给子进程，要么完全不传。

3. 明确配置子代理权限——通过项目级设置授权其应执行操作，否则它会通过文本传递制品来求生。

4. 自带用量探测器——默认假设链路中无人记录账本，除非有证据反证。

5. 信任结果块数据——流中的逐条用量仅为占位符。

附录：方法与局限

• 环境：dsh rc.8（@deepseek-ai/dsh-subagent-claude-code插件），Claude Code 2.1.237，deepseek-v4-pro-0813；模型通过OpenAI兼容端点访问。

• 任务：ISO-8601时间解析器的两个函数实现 + 3个pytest测试；每轮前执行git reset –hard至基线状态。

• 样本：最终对比为每种配置n=1（清洁轮次）；配置B经历5轮调试才获得该结果。耗时受网络与负载影响——视为数量级参考而非基准测试。

• 所有token数量均为API响应中厂商官方usage字段数据，经消息ID去重后求和；无任何估算值。

• 三种故障层（凭证清洗、权限模式、用量数据丢弃）在上述版本均可复现；若后续版本修复此问题，以更新日志为准。

• 本系列前文：“GLM-5.3思考参数：未配置即最大值”。