浙大×阿里云综述 Token 经济学：LLM Agent 的成本、协作与安全账本

一句话讲清楚👉🏻来自浙江大学和阿里云的研究团队把 LLM Agent 里的 token 重新定义为生产要素、交换媒介和记账单位，用一套“计算机系统 × 经济学”的框架解释单 Agent 、多 Agent 、 Agent 生态和安全治理中的成本边界。

先想一个很常见的代码 Agent 场景。

用户只说“帮我修一下这个 bug”。 Agent 第一步读取报错日志，第二步搜索仓库，第三步打开相关文件，第四步尝试修改，第五步跑测试，第六步发现另一个失败，再把前面的日志、 diff 、测试输出继续塞回上下文。最后看起来只是改了几行代码，账单上却可能多出几十万 input token ；真正贵的地方不是最后那段 patch ，而是反复读入上下文、解释工具结果、 review 自己的修改、修复失败路径。

这就是 Agent 时代最容易被低估的东西： token 已经从模型调用的计量单位，变成了智能系统的库存、现金流和损耗表。读文件是 token ，检索网页是 token ，工具 schema 是 token ，多 Agent 互相同步还是 token 。只盯模型价格，很容易把系统里最大的成本中心漏掉。

这篇 46 页综述《 Token Economics for LLM Agents: A Dual-View Study from Computing and Economics 》给了一个系统化说法。研究团队引用 OpenRouter 数据指出，平台周 token 处理量从 2024 年 12 月的 0.4 万亿增长到 2026 年 3 月的 27 万亿，约 15 个月增长 68 倍。 Agent 早已越过“偶尔多花几个 token”的阶段，推理、工具、记忆、协作和安全都变成持续消耗 token 的生产流程。

Agent 技术栈从 2022 到 2026 年快速扩展， OpenRouter 周 token 量在关键节点出现数量级增长。

我更愿意把这篇论文看成一张 Agent 成本地图。它关心的不是“如何少用 token”这么单点的问题，而是四个更工程化的判断：哪些 token 是必要生产投入，哪些 token 是协作摩擦，哪些 token 能沉淀成长期资产，哪些 token 因为不可信反而需要额外付费验证。

token 为什么成了 Agent 的经济原语

在传统 LLM 调用里， token 主要是信息处理单位。用户输入被切成 token ，模型逐 token 生成回答。这个视角适合单轮问答，却解释不了 Agent 的新成本结构。

先把 token 当成三种东西来看，会比单纯看账单更清楚。

这个分类直接影响产品埋点。很多团队只统计 prompt token 和 completion token ，却没有单独记录 reasoning 、 retrieval 、 tool schema 、 retry 、 review 、 memory write 、 memory read 、 security check 。结果就是优化时只会砍输出长度，看不到真正烧钱的输入回放和失败路径。把 token 看成记账单位后， Agent 的失败重试、通信冗余、安全校验才能进入同一张账本。

进一步拆账，可以把 Agent token 分成五类： Input Token 、 Reasoning Token 、 Communication Token 、 External Token 和 Output Token 。输入 token 来自用户提示和上下文；推理 token 来自规划、草稿和自我反思；通信 token 在多 Agent 之间流动；外部 token 来自 RAG 、工具 API 和网页检索；输出 token 是最终交付给用户的结果。

论文把单 Agent 的“Memory-Planning-Action”循环和多 Agent 的通信同步放到同一条 token 生命周期里。

一旦这样分类，很多工程现象就变得容易解释。一个 RAG 系统相当于在内部推理 token 和外部检索 token 之间做替代；一个多 Agent 系统会在专家分工之外引入通信 token 、状态同步 token 和冲突解决 token ；一个安全防护模块也不是纯粹的合规开销，它会给每个 token 增加验证、过滤、沙箱和访问控制成本。

统一目标：在质量约束下最小化总成本

这篇论文背后的总框架很朴素： Agent 推理是一个有质量约束的资源分配问题。

用文字表达就是：系统要在输出质量达到目标阈值的前提下，让总成本尽可能低。这里的总成本不只包括模型 API 费，还包括 GPU 折旧、内存带宽、推理延迟、人工参与、工具调用、通信协调、缓存状态、合规和安全防护。

如果做成工程指标，我会把它拆成四列：目标质量、 token 投入、隐藏成本、失败损失。目标质量用评测、人工验收或业务指标表达； token 投入按输入、推理、检索、通信、输出分桶；隐藏成本记录 latency 、 cache miss 、工具失败、人工确认；失败损失记录重试次数、回滚次数和错误外部动作。

真正有意思的是“替代”和“互补”的双重关系。

一方面，计算资本和 token 可以替代。一个小模型可以通过更多思考链、更长检索和更多工具调用弥补能力短板；一个更强的模型可能用更少 token 做出同样质量的答案。

另一方面，它们又互补。长上下文需要更大的 KV cache 和更高内存带宽；多 Agent 通信越多，对 serving 系统、缓存和调度的压力越大。 token 便宜不代表可以无限堆，算力不够时，更多 token 只会变成延迟、 OOM 或低质量冗余。

所以论文的核心目标可以压缩成一句工程判断：不要只看 token 数，也不要只看模型能力，要看每个 token 对目标质量的边际贡献是否超过它带来的真实成本。

论文的整体路线：从 token 定义和成本函数出发，依次分析单 Agent 、多 Agent 、生态级市场、安全和未来机会。

单 Agent ：在“自己想”和“调用外部工具”之间找平衡

单 Agent 的成本问题，最像一个小企业如何组织生产。它有内部能力，也可以买外部服务。内部能力对应参数化知识、推理 token 和模型自身计算；外部服务对应工具调用、 API 、 RAG 、网页检索和数据库查询。

论文把单 Agent 的核心问题定义为：在目标输出质量固定时，如何在内部推理 token 和外部工具 token 之间做最优分配。

一个金融市场分析 Agent 可以说明这个问题。如果它完全靠内部推理，可能会因为事实过时或幻觉而反复修正，消耗大量推理 token ；如果它过度依赖外部 API ，又会把大量行情、新闻和指标塞进上下文，带来高延迟、高输入成本和格式处理成本。最优点往往在中间：调用一个高信息密度的实时价格 API ，再用内部推理综合判断。

单 Agent 的最优策略是在内部推理和外部工具之间达到边际成本平衡，而不是一味多想或一味多查。

单 Agent 优化可以不按论文清单背名词，换成一个更容易落地的排查表。

这里面我最看重两类： early exit 和 memory 。

early exit 对应一个很朴素的止损问题：下一轮思考还会带来新信息吗？如果只是把同一个计划换个说法，继续生成就是负收益。代码 Agent 、数据分析 Agent 、浏览器 Agent 都应该有这种 stop-loss 机制：连续两轮没有新证据、同一测试失败重复出现、工具返回同类错误时，就该切换策略或停下来。

memory 则是另一种账。一个没有长期记忆的 Agent ，每次都要把同样背景塞进 prompt ；一个有组织的记忆系统，可以把重复 token 消费转化为一次性写入和后续检索。但记忆不是越多越好，低价值记忆会污染检索结果，占用上下文窗口。好的记忆系统要同时会写、会查、会忘。

工具和 RAG 的边界也要按成本算。 Toolformer 、 Gorilla 、 ToolLLM 、 AnyTool 、 ToolRL 等工作可以统一理解成“降低外部 token 的采购成本”：什么时候该调用工具，调用哪个工具，注入多少 schema ，如何避免错误调用造成重试。 MCP 和 Function Calling 的价值也可以放在这张成本表里理解：它们降低工具集成和格式解析成本，让外部能力更像可替代的生产要素。

我的判断是，单 Agent 阶段最容易被误用的优化，是“盲目压缩”。很多系统只盯着 token 数下降，却忽略了质量阈值。 Token Economics 的提醒更准确：压缩只有在不破坏输出质量、不增加后续修复成本时才成立。否则，前面省掉的 token 会在后面的失败重试、人工介入和安全校验里成倍还回来。

多 Agent ：专家越多，沟通税越高

多 Agent 系统看起来像把任务拆给多个专家：规划、检索、编码、验证、总结，各司其职。专业化确实会降低单个节点的生产成本，但协作会带来另一类成本：通信、同步、冲突解决和状态传递。

论文用 Coase 的企业边界理论解释多 Agent 。企业内部多一个部门，既可能带来专业化收益，也会增加会议、汇报、对齐和管理成本。多 Agent 也是如此：多一个 Agent ，可能提升专业能力，也会增加角色说明、消息传递、上下文复制和争议仲裁。

论文把多 Agent 的总成本拆成两部分：节点生产成本和内部交易成本。随着 Agent 数量增加，节点生产成本先下降，因为任务被专业化拆分；但通信成本可能近似按网络边数超线性增长，在密集拓扑下甚至接近 Agent 数量平方级。

多 Agent 的最优规模存在边界：专业化收益下降后，通信和协调成本会主导总成本。

这解释了一个常见现象：有些任务用单 Agent 表现稳定，加几个 Agent 后反而更慢、更贵、更容易跑偏。问题未必出在模型能力，而是组织设计越过了最优边界。

举个更贴近日常的反例：一个投研 Agent 被拆成 planner 、 searcher 、 analyst 、 reviewer 、 editor 。 planner 先输出大纲， searcher 把十几篇材料塞进上下文， analyst 写初稿， reviewer 又要求补材料， editor 再把所有历史对话读一遍改写。最后文章质量可能只提升一点，但每一轮都在复制前文、材料和 review 意见。这里真正贵的是“所有人都要知道所有事”的组织设计。更经济的做法是让 searcher 只交付结构化证据卡片，让 reviewer 只看结论和引用链，让 editor 不读取原始搜索噪声。

论文总结了多 Agent 优化的几条主线。

第一，先做成本归因。 AgentTaxo 、 Tokenomics 、 MultiAgentBench 等工作尝试统计不同角色、拓扑和 pipeline 阶段的 token 分布。论文提到一个很有冲击力的数据：在软件工程场景中，迭代代码 review 消耗了 ChatDev 59.4% 的 token ；另有 SWE-bench 相关研究显示， agentic coding 的 token 消耗可能超过单轮推理 1000 倍，输入 token 主导，比例超过 150:1 。同一任务的 token 用量还可能有高达 30 倍方差。

这些数字对工程落地很有启发。我们经常优化输出长度，却忽略真正的大头在输入上下文、历史回放、重复 review 和失败路径。没有细粒度账本，多 Agent 优化只能靠感觉。

第二，裁剪通信图和 Agent 数量。 AgentPrune 剪掉冗余消息， AgentDropout 移除低贡献 Agent ， G-Designer 、 ARG-Designer 、 GTD 则尝试学习通信拓扑。经济含义很直接：不要默认所有专家都参加每一轮，也不要默认每个 Agent 都和所有人通信。

第三，压缩通信内容。 Optima 通过训练学习更紧凑的 Agent 通信协议； CodeAgents 用 YAML 角色说明和 Python 风格伪代码替代长篇自然语言系统 prompt 。这里有个朴素但锋利的结论： Agent 之间不一定需要像人类一样说话。自然语言适合给人看，却充满修辞和句法冗余；在 Agent 内部，结构化表示、伪代码、 KV 表征甚至视觉 embedding 可能更经济。

第四，复用计算和缓存。 KVComm 、 Q-KVComm 、 TokenDance 、 LRAgent 、 DroidSpeak 等工作关注跨 Agent 的 KV cache 复用、压缩和共享。多 Agent 常常重复处理相似上下文，如果每个 Agent 都从头 prefill ，同一批 token 被反复付费。共享缓存相当于把固定成本摊到多个 Agent 上，提升 GPU 资本效率。

第五，管理集体记忆。 多 Agent 的 memory 不是单 Agent memory 的简单放大版。共享记忆池会带来“公共草地悲剧”：每个 Agent 都写入自己觉得有用的信息，最后检索空间被低相关内容污染。论文提到的角色特定记忆、混合记忆拓扑、 RCR-Router 、 G-Memory 、 AgentNet 等方法，都在解决“该给谁看、看多少、多久忘”的库存管理问题。

我认为多 Agent 系统最该借鉴论文的一点，是把“协作”当成成本中心，而不是能力装饰。一个好系统不应该炫耀有多少 Agent ，而应该能回答：每个 Agent 的边际贡献是什么？每条消息是否减少了不确定性？每次 review 是否真的降低错误率？如果回答不上来，多 Agent 很可能只是在制造沟通税。

Agent 生态： token 进入市场后，价格不再只是 API 单价

当 Agent 跑在共享云平台、 API 市场、缓存系统和工具生态上， token 的问题就从单个系统扩展到生态层。多个用户、多个工作流、多个模型供应商争抢同一批 GPU 、 KV cache 、内存带宽、低延迟队列和合规能力。

论文把生态级总成本拆成四类：生产成本、等待成本、交易成本和合规成本。

生产成本包括实际 serving 所需的计算、内存、 KV cache 、带宽和系统效率。等待成本把排队、首 token 延迟、每输出 token 延迟和 SLA 违约转化为经济损失。交易成本包括寻找供应商、迁移 API 、适配工具协议、丢失缓存状态和迁移记忆库。合规成本则来自碳排、访问义务、数据可携带、安全要求和审计负担。

生态级 Token Economics 关注共享 serving 能力、用户需求、供应商竞争、监管约束和动态市场反馈。

这里我的判断比较明确：未来平台竞争不会只围绕 token 单价展开，而会围绕“状态资产”展开。谁掌握用户的缓存、会话、 memory 、工具授权、 SLA 和工作流适配，谁就能在核心 token 降价后继续保留议价能力。

拥塞定价会变得重要。 两个请求 token 数相同，实际成本可能完全不同。一个低峰期批处理任务和一个高峰期实时 IDE Agent ，对平台造成的等待成本和机会成本不同。论文提到 Batch API 、 provisioned throughput 、 QoS tier ，本质上都是用价格和优先级区分不同延迟偏好的需求。

缓存既省钱，也会形成粘性。 vLLM 、 SGLang 、 Mooncake 等系统通过 KV block 共享、 radix-tree 前缀匹配、跨节点缓存池提升吞吐。论文提到， Anthropic 对 cached input token 按基础输入价格的 10% 收费， OpenAI 对重复前缀自动 50% 折扣。表面看这是成本优化，深层看是平台状态资产：用户在某个供应商那里积累了缓存、会话和 memory ，迁移成本会升高。

开源模型改变议价边界。 论文讨论了 DeepSeek-V2 、 DeepSeek-V3 、 Llama-3 等开放或低价模型如何改变闭源 API 的价格锚点。即便用户没有真正迁移，只要 outside option 足够可信，闭源供应商的价格质量边界也会被压低。 token 市场的竞争不只发生在实际市场份额里，也发生在“用户随时可以离开”的预期里。

协议标准可能同时降低迁移成本和形成新护城河。 MCP 降低工具调用协议层的切换成本，但具体 host 的模型选择、认证、 UX 和记忆服务仍可能是平台特定的。也就是说，标准化不一定消灭 lock-in ，它可能把 lock-in 从 token 单价转移到接口、状态和工作流层。

成本下降不一定减少总消耗。 论文用类似 Jevons paradox 的动态解释 Agent 生态： MoE 、量化、 speculative decoding 、 prefill-decode 分离、 KV cache 池化降低单位成本后，会让更多原本不划算的 Agent 工作流变得可行。单位 token 更便宜，长期总需求反而扩大，拥塞和资源竞争继续存在。

这对行业判断很重要。很多人以为“推理成本下降后， token 焦虑会结束”。更可能发生的是：成本下降释放新需求， Agent 被嵌入更多高频场景，系统从“单次贵”进入“总量大”。 Token Economics 的问题不会消失，只会从单价优化升级为市场设计和资源治理。

安全：便宜 token 也可能很贵

论文把安全单独列为一大块，这是它比普通系统优化综述更完整的地方。原因很简单：在 Agent 系统里， token 会被读取，也会触发工具、修改文件、调用 API 、进入共享记忆，甚至影响后续多个 Agent 的决策。

安全风险会通过三条路径改变 token 经济学。

第一，它降低 token 的预期效用。被污染的检索片段、 prompt injection 、越狱输入、恶意工具输出，都会让本来有信息价值的 token 变成低质量甚至有害输入。

第二，它提高 token 的影子价格。过滤、来源验证、沙箱、访问控制、冗余评估、隐私保护都会增加延迟和额外 token 。一个外部网页片段看似便宜，但如果必须做 provenance check 、交叉验证和权限隔离，它的真实成本会明显上升。

第三，它会制造非局部损失。单 Agent 里一次错误可能只是重试；多 Agent 和共享生态里，一个污染 token 可以进入 memory pool ，经由通信图传播到其他 Agent ，再触发工具链级联失败。小攻击可能造成系统级 token 浪费和外部损害。

论文把风险分成五类：输入 token 风险、外部 token 风险、内部 token 风险、 Agent 间 token 风险和市场级 token 风险。

论文的安全成本模型强调一个取舍：防御组合会增加即时成本，但会降低预期攻击损失。过滤、来源审计、沙箱、冗余评估、隐私计算都不该被视为额外负担，而是 Agent token 生产系统里的质量控制和市场制度。

我的理解是， Agent 安全最容易被低估的成本不是一次拦截本身，而是“未拦截导致的连锁反应”。如果一个 poisoned retrieval token 被写入长期记忆，后续每次检索都可能继续付费消费它、验证它、修复它。安全缺陷会从一次性 bug 变成持续折旧的坏资产。

未来方向：从静态 token 统计走向动态预算系统

论文最后给出六个趋势和五个机会。完整路线图如下，但如果按落地顺序看，我会把它压成三件事：先做成本归因，再做预算控制，最后才是动态市场和可微预算。

论文把未来方向分为系统基础、协作鲁棒性、基础设施与市场三个层级。

最先落地的是成本归因。 现在不同论文和不同产品对 cached token 、失败尝试、输入输出单价、工具调用成本的统计口径不统一。工程团队可以先做统一账本：每次任务记录 input 、 reasoning 、 retrieval 、 tool schema 、 communication 、 memory 、 retry 、 security 八类 token ，再按成功路径和失败路径分开看。

第二步是预算控制。 现在很多 Agent 只设一个 max tokens ，太粗。更合理的是按阶段设预算：检索最多几轮，工具失败最多几次， reviewer 只看哪些证据， memory 每次最多注入多少，安全验证触发条件是什么。这样的系统即便不用新模型，也能明显减少无效消耗。

更远的是动态市场和可微预算。 固定 token 单价很难表达供需、时段、缓存状态、任务紧急度和质量要求。未来可能出现 spot pricing 、竞价机制、保底容量合约；研究侧也可能把 token 成本直接写进训练目标，让模型在训练时学会把预算分配到推理、检索和工具调用中。

对工程团队的几个直接启发

如果把这篇论文落到 Agent 产品和平台实践，我会提炼成五条。

第一，先做 token 成本账本，再谈优化。 成本要按输入、输出、推理、通信、检索、记忆、重试、安全校验分开统计。只看总 token 数意义有限，因为真正的浪费常常藏在输入回放、失败路径和 Agent 间通信里。

第二，给每个循环设置 stop-loss。 Agent 最贵的部分往往不是第一次生成，而是反复计划、反复调用工具、反复修错。循环预算、错误中断、观察截断、最大重试次数，本质上都是经济系统里的止损机制。

第三，记忆要有折旧和淘汰。 长期 memory 不是无限仓库。每条记忆都应该有写入成本、检索收益、过期概率和污染风险。只写不删的 memory 会从资产变成负债。

第四，多 Agent 要先证明边际收益。 新增 Agent 、 reviewer 、 planner 、 verifier 前，先估算它带来的质量提升是否覆盖通信成本。组织结构常常比单个 prompt 更影响 token 成本。

第五，安全成本应进入主预算。 对 Agent 来说，安全不是上线前 checklist ，而是每次 token 流动时的成本项。外部内容、共享记忆和工具调用越多，越要把验证、权限、沙箱和 provenance 纳入成本函数。

结语

这篇综述的贡献，是把分散在系统优化、 Agent 架构、 RAG 、 memory 、多 Agent 协作、 API 市场和安全治理里的问题，统一到一张 token 成本地图里。

在单 Agent 层，关键是内部推理与外部工具之间的替代；在多 Agent 层，关键是专业化收益与通信税之间的边界；在生态层，关键是拥塞、缓存、定价、开源 outside option 和切换成本；在安全层，关键是把不可信 token 的风险溢价计入真实成本。

Agent 的下一阶段竞争，不会只是谁的模型更强，也不是谁能堆更多 token 。更关键的是谁能把 token 当成资源来经营：该花的地方敢花，不该花的地方停手，能复用的变成资产，有风险的先做验证。

当 token 成为智能生产的共同货币， Token Economics 可能会成为 Agent 系统设计的底层语言。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】