隐性成本一：上下文膨胀
单 Agent 把制度、案例、历史对话都塞进提示词后，回答开始漏条件，团队便不断加规则补丁，提示词越来越长。这条成本曲线不体现在账单上，而体现在每次改动的回归时间与准确率的缓慢下滑，最后无人敢删。怎么止损，先删掉无人引用的规则，再做一次全量回归。
隐性成本二：调用放大
多 Agent 的一次任务可能触发十几轮调用，每轮都带上下文；并行还会抬高瞬时配额。按任务量估算月度调用次数，比按用户数估算更接近真实，扩容前应先测单任务平均调用数，再定扩容量。为什么容易被忽略，因为它不在账单上，只在排障时间里。
隐性成本三：排障与重放
多 Agent 出问题要定位到节点与交接，需要调用链日志、消息留存与重放能力。这些能力要么自建要么采购，且要有人日常看；没有它，一次线上问题可能耗掉几天，成本远高于当初省下的开发费。怎么做重放，保留消息与工具返回，按任务号串起来。
隐性成本四：评测拆分
拆分后评测集要按节点维护，端到端用例还要单独保留，两份都要随业务变化更新。人力不足时最常见的做法是只留端到端，结果出问题无法定位，等于把评测成本转成了排障成本，还拖慢迭代。边界是人力，节点级评测至少要一个人固定维护。
止损做法：先设上限
给项目设三个上限：单任务调用次数、单任务 P95 延迟、月度排障工时。任一项连续两周超标就回退到上一个版本；把上限写进项目确认单与运维手册，比事后争论值不值得更有效。为什么设上限有效，因为它把争论变成可核对的数字。
适用与不适用
适合谁
- 只看首年开发报价、不看运维的采购流程
- 已发现账单或排障工时异常增长的项目
- 需要在方案评审中评估长期投入的负责人
不适合谁
- 只看首年开发报价、不看运维的采购流程
- 没有调用日志、无法统计真实用量的团队
典型场景
某零售企业的客服 Agent 上线半年后，账单涨幅超过咨询量涨幅。排查发现多 Agent 链路里同一份订单信息被重复传入四次，合并环节还有重试。团队给单任务调用次数设上限、把重复上下文改成引用编号，并把排障工时纳入月度复盘，一个月后曲线回到可解释的范围。
可执行步骤
- 统计单任务平均调用次数与 P95 延迟，作为成本基线，连续记两周
- 标注哪些上下文被重复传入，改为引用编号或摘要片段，压缩上下文体积
- 为排障工时与评测维护设定月度上限，并指定复核责任人，写明时间表
- 把三项上限写进项目确认单与运维手册，作为验收项之一，由双方逐条核对
- 每月复核一次，超标即回退或降级，记录处理结论，并由责任人签字
常见坑
- 只算开发费与订阅费，把上下文维护与评测更新当成人情，第二年预算无处安放，只能临时追加。
- 重试策略没有退避与去重，失败一次就整链重跑，账单在故障日突然出现尖峰，事后很难解释。
- 排障靠翻聊天记录，一次线上问题耗掉数人日，团队因此不敢改提示词，系统逐渐僵化，最后被绕开。
- 评测只保留端到端，节点级问题长期潜伏，等到业务量上来才集中爆发，想回退也缺少可比基线。
自检与验收清单
- 是否统计过单任务调用次数与 P95 延迟
- 重复上下文是否已改为引用或摘要片段，验证效果
- 重试是否有退避、去重与次数上限，并有测试
- 排障工时是否纳入月度复盘与考核，且有记录
- 三项上限是否写进项目确认单与运维手册正文
常见问题
隐性成本能提前估算吗？
可以估区间。用一批真实任务跑两周，记录调用次数、延迟与人工介入时长，再按业务量放大；区间比单点更诚实，也便于在预算里留出余量，避免中途反复追加审批，拖慢项目节奏。
回退会不会很贵？
要看设计。若编排层与业务规则分离、交接字段结构化，回退只是换一个入口；若规则写死在多个提示词里，回退等于重做。设计阶段多花一天，回退时能省一周，这个账值得算清楚。
要不要把成本写进验收？
建议写。至少约定单任务调用次数与延迟上限，以及超标后的降级方式；这不是斤斤计较，而是让系统在业务增长时仍然可解释、可预算，也便于运维团队提前准备容量预案。