第47个代理上线时，财务部门终于坐不住了。30个代理以内，Anthropic的账单只是月度报表上一个可以容忍的数字——通常低于2.5万美元，没人追问具体去向。超过30个，这条线目突破2.5万。到了47个，ZopDev客户的中位数舰队月开销达到8万美元，财务总监带着一个问题走进预算评审会：到底是哪个代理花的钱。
没人能回答。成本仪表盘按AWS账户、团队、服务、标签分桶。但这些桶里都没有"代理"，因为代理消费的资源不会打上自己的身份标签。它们消费的是token，记在单一的Anthropic或OpenAI账户下，每次调用的账单对云成本系统完全不可见。资源标签能捕捉到基础设施，却完全漏掉了大语言模型的账单。
解决方法是建立成本台账：每次大语言模型调用时，代理运行时打上一个五字段记录，与现有的MCP工具调用审计日志配对。有了台账，任何分摊问题——按代理、按团队、按功能、按客户——都变成一条SQL查询。没有它，代理舰队对财务总监来说就是一条无法拆解的线目。
本文提供的是这套方案的数据结构、双轴归因模型，以及台账与现有系统形成的闭环模式。它建立在代理式AI财务运营和功能级token预算的前期工作之上，无需重构任何一方。
大多数代理舰队的增长曲线惊人地相似。前10个代理是试点项目，挂在工程师个人的API密钥下，没有中央追踪。第11到30个代理有了共享预算和松散的中央监管，月度总和在5000到2.5万美元之间，CFO懒得过问。
突破30个是拐点。这条线目现在跻身云成本前15大驱动因素，财务要求拆解，工程却拿不出来。事后补救需要六周的考古工作——翻遍Anthropic发票、OpenTelemetry追踪记录和Slack线程。而那些在突破30个之前就部署了单代理归因的团队，完全跳过了这个恐慌月。
云成本分摊体系围绕AWS成本与使用报告构建。资源有标签，标签被拉进CUR，CUR feeding仪表盘，仪表盘按标签分桶。这套机制有效，是因为云资源的身份与消费存在一对一映射。
代理从三个维度打破了这种映射。
基数不对。单个AWS账户托管47个代理，拥有数百个云资源，每个只打一次标签。代理共享基础设施——同一个Lambda、同一个Postgres、同一批MCP服务器——所以资源标签无法识别是哪个代理触发了特定查询。基础设施标签写着"共享大语言模型运行时"，成本系统一无所知。
真相来源不对。Token支出记在Anthropic，不在AWS。Anthropic发票每月来一次，汇总到账户级别。CUR对此毫无视野。即使每个代理使用单独的API密钥（真实舰队中没人这么配置的配置噩梦），密钥也只是账户级别的分组，无法映射到具体调用。
时间粒度不对。云资源按小时计费，可以回溯打标签。大语言模型调用按毫秒计费，发票在调用完成后生成。成本系统的设计假设是"先知道谁在花钱，再花钱"，代理的世界是"先花钱，再想办法知道是谁"。
五字段台账是这套方案的核心。每个大语言模型调用出口时，代理运行时写入：时间戳、代理ID、团队ID、功能标签、客户ID（如适用）。这行记录与MCP审计日志中的工具调用ID关联，后者已经捕获了调用的输入输出和延迟。
双轴归因模型解决"谁花的钱"和"为什么花钱"两个问题。横轴是组织归属：代理ID→团队ID→成本中心。纵轴是业务归属：功能标签→产品特性→客户合同。任何一笔支出都可以在这两条轴上定位，财务问"哪个团队超预算了"和"哪个功能最烧钱"都能得到答案。
闭环模式把台账与现有系统缝合。台账数据流入数据仓库，与CUR做外连接——不是替代，而是补充。财务仪表盘增加一个"大语言模型支出"切片，与原有的基础设施视图并列。代理运行时保留一个采样模式，在调试时输出完整台账行，生产环境只写聚合摘要。
部署这套方案的团队报告了三个变化。预算评审时间从三小时压缩到二十分钟，因为争议数据当场可查。代理设计评审增加了"预估月度token成本"环节，产品经理开始用token数思考功能范围。最意外的是，工程师主动下线了七个"僵尸代理"——它们还在定时调用，但业务价值早已归零，只是之前没人看得见。
没有台账的团队在47个代理处撞上墙。有台账的团队，80万美元的月开销只是仪表盘上的一个可下钻数字。财务总监的问题"哪个代理"——答案在五字段里，查询时间不到一秒。
热门跟贴