多 Agent 的成本怎么核算？拆开细算

多智能体协作的成本核算，难点在于开销不止发生在模型调用这一处：每多一个协作方，就多一份提示词拼接、一次结果传递、一层重试可能，这些隐性消耗不记账，月底对账时就会发现实际支出远超预期。

类比公司项目核算：只算员工工资不算会议时间，账面必然偏乐观。失效之处在于，智能体之间「开会」的成本是按 token 和调用次数计的，而且失败重试也会花钱，这部分在人工流程里几乎不存在。

账面成本和真实开销差在哪

账面通常只记模型调用费，真实开销至少还有三块：工具调用与外部接口费用、执行环境和存储的占用、失败重试的重复消耗。扣子这类平台的用量面板一般按应用汇总，需要自己再往下拆到单个流程、单个环节，才能看清结构。

账面之外还有三块开销，记不记差别很大。

重试和失败也要算进去

一笔任务的名义成本是各环节之和，实际成本要除以成功率：成功率为一半时，真实单价翻倍。重试率高的环节不但拖慢进度，还在持续烧额度，这类环节优先治理，效果比压模型单价明显得多。失败任务的残料也要算：跑了一半被丢弃的中间产物，同样是花出去的额度。

多 Agent 之间怎么分摊

常用两种口径：按调用链路直接归因，谁发起谁承担，适合主从结构；按环节计价，每个协作方公布自己的单价，上游按使用量计入，适合平级协作。分摊口径要提前定死并写进记录，事后重算口径会引发数字对不上的麻烦。

哪些环节最容易超支

经验上有三处：上下文越滚越长的多轮协作，每轮都带着全部历史，越到后面单轮越贵；无上限的自主重试，问题没解决却一直烧钱；重复规划，多个协作方各自理解任务、各做一遍。给协作轮数和重试次数设上限，是性价比高的两道闸。纳米AI、扣子等平台的用量明细可以辅助定位这类环节。

成本核算速查表

• 账面之外补记接口、环境、重试三块开销
• 真实单价等于名义成本除以成功率
• 分摊口径提前定死并写进记录
• 给协作轮数与重试次数设上限

一句话记住：看不见的开销才是大头。

成本数字要和效果数字放在一起读：单价降了但完成率掉了，属于假省钱，效果口径见Agent 评测是怎么打分的？完成率。开销异常波动往往能在运行指标里找到对应环节，见长时任务看哪些监控指标？内部门道在这。权限混乱导致的无效重试也烧钱，见Agent 的安全边界怎么划？一次划清；来源可疑的输入触发的大量无效调用，见提示注入在 Agent 上为什么更危险？；工具准入没管好同样会产生浪费，见工具白名单是怎么配的？过程拆开看。省钱的第一步，是把账拆到能看清的程度。

向非技术同学汇报成本时，换一种讲法更有效：不说 token 数，说「每完成一件任务平均花多少钱、比上一版多了还是少了」，再把波动归因到具体事件，比如某天重试激增是因为对方接口故障。账目细节留给工程侧，汇报层面给结论和趋势，沟通效率会高很多。另外建一个习惯：每次大规模放量前，先按新并发水平预估一版成本，跑完再对账，偏差大的环节单独复盘，几轮下来估算会越来越准。成本核算的意义不在省钱本身，而在让每个环节的投入产出变得可比较，砍哪留哪才有依据。

关于成本核算，问得最多的三个

• token 数怎么估？：按平均输入加输出乘以预估次数粗算，再用小批量实测校准，比空估靠谱。
• 多个模型混用怎么记账？：每个环节记录所用模型与用量，汇总时按环节归因，别只记总额。
• 要为失败预留多少额度？：用近期失败率反推，波动大就再上浮一成，随数据滚动调整。