想让 DSH 接管机器人之前，我算了一下 token

机器人自带的 agent 不靠谱，这个不是听说的，是我被它坑过好几次：让它改个插件配置，它理解偏；让它查个服务日志，它做一半就停在那了。

所以我想，在服务器上部署一个 DSH（DeepSeek Harness），写个插件让群里的命令能触发它，把这类活转过去。

两条路

一条是用现成的适配器。社区里有人把 DSH 直接接到 QQ 开放平台，填 AppID / AppSecret 就能用，还自带"每个群、每个用户独立会话"的管理。

但我这边的机器人已经有一整套东西——点歌、查分、图源，十几个插件。整个搬过去等于另起一摊，我得维护两套。这条放弃。

另一条是让 AstrBot 去调 DSH。机器人还是那个机器人，只在遇到"真需要干活"的任务时把活转出去。落地有两种写法：让 DSH 常驻、暴露 HTTP 接口，AstrBot 发请求；或者在插件里用 subprocess 直接调 dsh run "问题"。

子进程那种每次都要拉一个新进程，开销大。我倾向 HTTP 那套，DSH 常驻，AstrBot 这边只负责转发问题和收回结果。

然后我算了一下账

我问了最要紧的一个问题：让 DSH 接管会不会多花很多 token。

会，而且不是多一点。

普通聊天一次大概 250 token 量级。而 DSH 这类 Agent，光系统提示词本身就要 2000–5000 token，还要走 ReAct 的多轮工具调用，中间每一轮的思考过程还要回传，加起来大约 4650 token。

差了 15 到 20 倍。

这个数字把我的想法改了。

我这个机器人是给几个群用的，日常被叫来叫去主要是闲聊和查东西。"重活"是少数，但按这个方案，所有请求都会走那条贵 20 倍的链路。为了少数几次重活，把日常成本抬高十几倍，不划算。

我改成按需转交

只有明确触发的重活才交给 DSH，日常聊天继续走原来的轻链路。

这样做的好处是日常成本不变（那才是消耗大头），需要真本事的时候手上有个后手，而且 DSH 挂了不影响机器人正常聊天。

这个架构我最后没实施，后面忙别的去了。但算这笔账挺值的，它让我意识到：Agent 能力强不强，和值不值得用，是两个问题。

能力强的方案自带三个代价——token 成本、延迟、故障面。所以现在我看到任何"接入"方案，会先问三个问题：

这个能力多久用一次？每次调用大概什么成本量级（250 还是 4650）？它挂了会不会把主流程一起带走？