上线 28 天烧掉 37 万你的 Agent 是按聊天计费还是按架构烧钱前七篇我们讲清了 Token 是什么、日常写代码怎么省、指令文件与 README 怎么瘦身、两个 CLI 各有哪些省 Token 的开关。这一篇把视角拉到架构层——当你开始写 Agent、做多智能体编排时成本不是线性增加而是乘数级爆炸。本文拆解“代理乘数效应”的底层逻辑给出从 Skill 加载、上下文路由、A2A 通信到记忆系统的 8 个架构级开关每个都有真实数字可对比。开篇那个上线 28 天就烧掉 37 万的客服 Agent2026 年 4 月Hacker News 上两篇帖子同一天冲上首页。一篇讨论 Claude Opus 4.7 新分词器导致同样文本的 Token 数最多增加 35%621 分另一篇直接问“AI Agent 的成本是不是也在指数级增长”220 分评论区一片哀嚎。底下有个真实案例一个团队花了三个月做的多 Agent 智能客服系统上线仅 28 天OpenAI API 账单冲到 37.2 万人民币比之前 20 个人工客服的月度成本还高 30%不得不临时下线优化。而他们上线前的估算是每月 6000 元左右。差在哪差在他们按“聊天”算成本但实际跑的是“Agent”。前面讲过一次单轮对话输入几百到几千 Token输出几百 Token单次成本几分钱。但 Agent 不是这样——它是一个循环读任务→规划→调用工具→读结果→再规划→再调用……每一轮都会把整个历史从头到尾重发一遍。当你再加一个“协调器”和三个“子代理”每个代理都在重复这个循环最后的协调器还要把所有子代理的输出读一遍再汇总。这就是代理乘数效应Agent Multiplier Effect从“一问一答”到“多 Agent 协作”Token 消耗不是加几倍是乘几十倍。一、同样的模型不同用法账单差近百倍先看一张实测对比图用同一个模型Claude Sonnet 4做同一个“回答用户一个关于订单状态的问题”三种调用方式的 Token 消耗天差地别。单轮聊天用户直接问模型直接答。一轮输入约 800 Token输出约 400 Token总成本约 0.008 元。单 Agent 5 步工具调用Agent 先理解意图→调用查询订单工具→读结果→发现还需要查物流→再调用工具→组织语言回复。5 轮下来累计输入约 2.8 万 Token输出约 6000 Token约 0.23 元——是单轮聊天的 28 倍。多 Agent 编排1 协调 3 子代理协调器拆解任务→分发给订单查询 Agent、物流 Agent、退款政策 Agent→三个子代理各自多轮调用工具→协调器汇总所有结果再回复。整套走完输入约 8.5 万 Token输出约 2.2 万 Token约 0.75 元——是单轮聊天的 89 倍。注意这只是一个用户、一次会话的成本。如果你的系统日均处理 2000 个请求日成本就是 1500 元月成本 4.5 万——还没算失败重试、死循环和缓存失效。这就是为什么那个团队估算和实际差了 62 倍他们按“单轮聊天”估但跑的是“多 Agent 编排”。二、乘数从哪来上下文是一个不断膨胀的雪球为什么会乘数级增长核心机制只有一句话每一轮请求模型都要重读整个历史。一个典型的客服 Agent 在单轮调用中输入 Token 的构成是这样的组成部分典型 Token 数是否累加系统提示角色定义、规则2,000~4,000每轮都重发固定成本工具定义JSON Schema每个工具 200~8005 个工具约 1,500每轮都重发固定成本对话历史第 1 轮 50第 10 轮约 4,500线性增长工具返回结果一次几百到几万不等累加到历史里当前用户消息50~200每轮新增看到问题了吗系统提示和工具定义是“固定税”——不管你第几轮这部分每次都要付对话历史是“累进税”——轮数越多雪球越大。第 N 轮的输入 Token 固定成本 前 N-1 轮所有输出之和 新消息。数学上这是 O(N²) 的。如果每轮平均输出 500 Token到第 10 轮单轮输入已经比第 1 轮多了 4,500 Token到第 20 轮光历史就占了近 1 万 Token。而这些历史里可能有一大半是几轮前读错了工具、又纠正的废话模型根本不需要——但你照样付钱。多 Agent 场景下这个雪球滚得更快。协调器把任务分给 3 个子代理每个子代理都有自己的系统提示和工具定义3 份“固定税”每个子代理的输出回到协调器时会被整段打包进协调器的历史最后协调器还要基于这三份完整输出再做一次推理。82% 的多 Agent 开发者把“Token 成本过高”列为落地第一大障碍平均而言完成同一任务多 Agent 的 Token 消耗是单 Agent 的4.7 倍来源《2024 大模型应用落地报告》多 Agent 协作损耗统计。三、把“全量加载”改成“按需加载”三级 Markdown 技能系统既然“每次都重发全部内容”是成本膨胀的根源最直接的优化就是不要把所有东西一次性塞进上下文。很多人写 Agent习惯把所有规则、工具说明、示例代码统统堆进一个巨大的 system prompt几千上万字起步。这在单轮聊天时还凑合一上 Agent 循环这几千 Token 每轮都要重发——一个 3000 Token 的 system prompt跑 10 轮就是 3 万 Token 的“固定税”跑 20 轮就是 6 万。更好的做法是把内容拆成三级按需要才加载——这就是目前主流 Agent 客户端Claude Code、Cursor 等已经在做的三级 Skill 架构第一级元数据常驻~100 Token / Skill会话启动时Agent 只读每个 Skill 的name和description。你装 50 个 Skill这部分也就 5000 Token 左右。description 是唯一的命中开关——写得含糊Skill 永远不会被触发写得精准只有相关任务才会把它调起来。第二级SKILL.md 主体 5000 Token当用户请求与 description 语义匹配时Agent 才把SKILL.md一次性读入上下文。主流规范包括 Claude Code 官方要求 SKILL.md 不超过 500 行再长就挤压推理空间。第三级references / scripts延迟加载容量无上限SKILL.md 里写“详见 references/method-patterns.md”Agent 只有在真的需要那段细节时才会 Read 那个文件。一个 Skill 可以打包几万行参考资料、模板代码和脚本但只有被点名的那部分才进入上下文。三者对比把所有内容塞进 system prompt装 50 个 Skill 就有 15 万 Token 常驻用三级按需加载启动时只有 5000 Token 常驻真正命中某个 Skill 时才追加约 8000 Token——比全量加载省了约 95%。写 Skill 的第一性原理不是“写得全”而是“内容放得对”description要精准回答“做什么 什么时候用”它永远在线SKILL.md正文控制在 500 行内只放高频流程、约束和速查references/里放所有低频细节长文档、完整代码模板、历史案例、API 参考需要时才加载。四、上下文路由为“以防万一”塞进去的每句话都在烧钱三级 Skill 解决的是“能力封装”的按需加载问题但还有一个更隐蔽的浪费源头路由决策本身的模糊。很多 Agent 在系统提示里写一堆“如果用户问 A就调用工具 X如果用户问 B就参考文档 Y否则……”再附上长长的背景资料原因是“以防万一”。但问题是这些“以防万一”的信息每轮都在上下文里既增加歧义模型要从更多无关信息里找正确指令又增加成本。上下文路由Context Routing的核心思路很简单把“决定要不要加载某块信息”的判断从“每次都带着”变成“先判断再加载”。具体落地有三种常用手段1. 工具定义延迟加载如果你的 Agent 有 100 个可用工具把所有工具的 JSON Schema 一次性塞进上下文光这一项就可能吃掉 2~8 万 Token每个工具 Schema 约 200~800 Token。更好的做法是只暴露一个“搜索/发现工具”的元工具让 Agent 先查“有没有适合的工具”按需拉取对应工具的完整定义。Google A2A 协议里的 Agent Card 机制就是这个思路先看名片~100 Token确认匹配后才加载完整能力说明。 这里只讲“为什么要这样做”Schema 怎么瘦身、用法说明怎么封装成按需加载的 Skill完整展开见第十篇《把重复的 MCP 用法封装成 Skill》。2. RAG 检索按需注入不要把整个知识库塞进系统提示。用户提问时先通过向量检索找出最相关的 3~5 段每段控制在 300~500 Token只把这些片段注入本次上下文。不相关的文档一页都不要带。3. 规则分层把规则分成“全局铁律”安全红线、输出格式500 Token常驻和“场景规则”只在特定任务类型下生效按需加载。比如“不要泄露 API Key”是常驻铁律“Python 项目遵循 PEP8、用 pytest 写测试”只在写 Python 代码时才需要。五、给 Agent 配一个记忆库别让它每次都重新发现Agent 另一个巨大的浪费来源是同样的坑每次会话都踩一遍。你可能见过这种情况用 Claude Code 改一个项目第一轮它不了解你的代码规范乱 import、写错路径、用了项目里不存在的工具你纠正了三回才走上正轨开个新会话它又犯同样的错——因为之前的“踩坑经验”随着会话清空了。解法是给 Agent 配一个项目级记忆库跨会话持久化。最有效的是四格结构active-task当前任务、decisions已定决策、gotchas踩过的坑回报率最高的一格、project-summary项目概览。关键设计只有一条记忆库不是整个塞进上下文——每轮只加载 active-task约 200~500 Token其余三格按需检索引用。有了它Agent 不必每个会话都花几千 Token “重新认识”你的项目。 这一节只交代“为什么必须有记忆库”四格各自的写法、目录怎么建、怎么接进 Claude Code / Cursor / Codex、加载策略与四个常见误区完整展开见第十二篇《给 Agent 配一个记忆库》。六、多 Agent 通信把消息当数据传输别当聊天当系统里有多个 Agent 协作时最大的单一浪费点往往不是单个 Agent 的推理而是Agent 之间的消息传递。*。直觉上很多人做 A2AAgent-to-Agent通信时会把上游 Agent 的完整输出“复制粘贴”给下游 Agent——就像人类在群聊里转发消息一样。但对 Token 来说这是最糟糕的做法。四种典型的 A2A 传递方式Token 开销差了整整 100 倍-全量转发把上游 Agent 完整的推理过程 工具调用日志 最终输出原样发给下游。典型 8000 Token/次。最浪费——下游根本不需要看到上游的思考链。链-摘要传递让上游 Agent 在完成任务后输出一段结构化摘要结论 关键数据 引用位置只把摘要发给下游。约 2000 Token/次已能省 75%。%。引用传递上游只输出“结果已写入 shared://task-123/result.md”下游按需读取所需片段。约 150 Token/次省 98%。共享存储推荐多个 Agent 直接读写同一块共享存储文件系统、数据库、KV 缓存消息里只传递状态变更信号和指针。约 80 Token/次省 99%。2026 年 3 月正式发布 v1.0 的 Google A2A 协议已捐赠给 Linux 基金会150 组织支持在设计原则里明确写了一条叫“不透明执行Opaque Execution”——Agent 协作时无需暴露内部思维链、执行计划或工具实现只通过标准消息交换结果。这正是引用传递和共享存储思路的协议化体现A2A 应该像 RPC 传对象引用而不是像群聊转发聊天记录。还有一个常被忽略的优化点前缀缓存Prefix Caching。如果多个 Agent 共享同一段系统前缀比如同一个公司的安全规则、同一个项目的基础说明把这段固定前缀放在消息最前面、确保一字不改就能命中服务端的 Prompt Cache——缓存读取价格只有输入的 1/10以 Claude Sonnet 为例缓存读取 $0.3/MTok vs 输入 $3/MTok vs 输出 $15/MTok最贵和最便宜差 50 倍。协调器给子代理发派任务时如果前几百 Token 是固定的项目背景 安全规则别让它动态变化一个时间戳、一个轮次计数器都可能让缓存全部失效。效。七、给 Agent 设停止条件别让死循环吃掉你的预算失控的自主循环是 Agent 系统里最贵的失败模式——而且它不报错只是默默地烧 Token。常见场景Agent 调用一个工具返回了错误它“觉得”换个参数再试一次就行试了发现还是错再换一个参数……十几轮之后还在原地打转Token 烧了几万任务毫无进展。如果你的系统没有明确的停止条件这种失败不会触发任何告警直到月底账单下来你才知道。三个硬约束必须设步数上限max_steps单个任务最多允许多少轮 LLM 调用。代码类任务建议 15~25 步研究类任务可以放宽到 50 步。到点强制停止返回当前最佳结果未完成原因。预算阈值budget_limit单个任务消耗 Token 超过预设值比如 5 万 Token就停下来请求人工介入。这比步数上限更准因为有些轮次工具返回结果特别长比如读了一个大文件步数没到预算已经爆了。质量门quality_gate让 Agent 每完成一步自检——“这一步是否在向目标推进是否在重复之前的动作”连续 2~3 步判定为“无进展”就停止避免无效重试。这三个约束加起来代码不超过 50 行但能挡住 90% 以上的“失控烧钱”场景。八、架构决策什么时候该拆什么时候不该拆讲完所有优化手段最后回到一个更根本的问题什么时候用单 Agent什么时候该拆成多 Agent不是所有任务都值得上多 Agent 编排。多 Agent 有通信开销、协调开销、上下文重复加载的开销即使做了前面所有优化它还是比单 Agent 贵。一个简单判断标准单 Agent 能搞定的简单任务改一个 bug、写一个函数、查一个数据坚决用单 Agent甚至用小模型Haiku、GPT-4o-mini 级别的就够。智慧模型路由Smart Model Routing——简单任务分给小模型、复杂任务才用大模型——企业实测平均能降低 40%~60% 的 API 成本。可并行分解、子任务之间边界清晰的复杂任务比如“调研 5 个竞品并出对比报告”拆成多 Agent 并行处理总耗时缩短的收益大于协调成本。但要确保子 Agent 之间用共享存储/引用传递通信不要全量转发。需要不同领域专业能力的长流程任务比如“前端改 UI 后端改接口 写测试 提交 PR”多 Agent 各司其职比一个 Agent 硬扛更稳但协调器要做边界压缩——只传每个子 Agent 需要的最小上下文。还有一个被低估的武器语义缓存Semantic Cache。对客服、FAQ、常见查询类场景把之前回答过的相似问题语义相似度 0.95的结果缓存起来直接返回不用再调一次模型。实测客服场景命中率可达 30%~50%等于直接砍掉三分之一到一半的调用量。结尾架构决定成本上限回看那个 28 天烧 37 万的案例问题出在哪不是模型选错了也不是提示词写得不好而是架构设计本身——系统提示塞了太多常驻内容、工具定义全量加载、Agent 之间在全量转发消息、没有步数上限、没有记忆库所以每次都在重新踩坑。坑。每一个单独看都是“小问题”叠在一起就把成本乘了几十倍。前六篇讲的是“写提示词、用客户端”层面的技巧这一篇讲的是“搭架构”层面的决策——三级 Skill 按需加载、上下文路由、记忆库、A2A 通信方式、停止条件、模型路由、语义缓存。架构层面的优化影响的是成本上限比任何提示词技巧的杠杆都大。关注weixin-物联网老王更多 AI 咨询、物联网智能体等你来看。下一篇预告从这一篇开始你会发现架构层面的 Token 黑洞一大半来自MCP 工具的响应体——一次查询返回 200 条订单全字段只为回答 12 个字日志查询一次拉回 1.8 万 Token模型其实只看最后 3 行。下一篇《MCP 工具输出的“过滤—聚合—分页—缓存”四件套》——用真实的 MCP Server 代码对比演示过滤把 12,000 Token 压到 42-99.6%、分页再砍 70%、缓存再砍 90% 的完整过程外加四个反模式。