上线 28 天烧掉 37 万：你的 Agent 是按聊天计费，还是按架构烧钱？

前七篇我们讲清了 Token 是什么、日常写代码怎么省、指令文件与 README 怎么瘦身、两个 CLI 各有哪些省 Token 的开关。这一篇把视角拉到架构层——当你开始写 Agent、做多智能体编排时，成本不是线性增加，而是乘数级爆炸。本文拆解“代理乘数效应”的底层逻辑，给出从 Skill 加载、上下文路由、A2A 通信到记忆系统的 8 个架构级开关，每个都有真实数字可对比。

开篇：那个上线 28 天就烧掉 37 万的客服 Agent

2026 年 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 的构成是这样的：

看到问题了吗？系统提示和工具定义是“固定税”——不管你第几轮，这部分每次都要付；对话历史是“累进税”——轮数越多，雪球越大。

第 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 之间的消息传递。*。

直觉上很多人做 A2A（Agent-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 烧了几万，任务毫无进展。如果你的系统没有明确的停止条件，这种失败不会触发任何告警，直到月底账单下来你才知道。

三个硬约束必须设：

1. 步数上限（max_steps）：单个任务最多允许多少轮 LLM 调用。代码类任务建议 15~25 步，研究类任务可以放宽到 50 步。到点强制停止，返回当前最佳结果+未完成原因。
2. 预算阈值（budget_limit）：单个任务消耗 Token 超过预设值（比如 5 万 Token）就停下来，请求人工介入。这比步数上限更准，因为有些轮次工具返回结果特别长（比如读了一个大文件），步数没到预算已经爆了。
3. 质量门（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% 的完整过程，外加四个反模式。