一句话讲清楚来自浙江大学和阿里云的研究团队把 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 当成三种东西来看会比单纯看账单更清楚。属性含义Agent 中的表现生产要素消耗 GPU 、内存、电力和时间推理、检索、工具调用都要消耗 token交换媒介API 市场按 token 计价token 变成 AI 服务的事实货币记账单位衡量任务复杂度和生产力可以统计推理、通信、记忆、失败重试成本这个分类直接影响产品埋点。很多团队只统计 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 优化可以不按论文清单背名词换成一个更容易落地的排查表。要省什么典型做法真实收益inputprompt 压缩、上下文裁剪少塞历史和无关文档reasoningearly exit 、 latent reasoning避免无收益的长思考prefillKV cache 、 FlashAttention降低长上下文启动成本tool更准的工具选择、 MCP少注入 schema 少失败重试memory写入、检索、遗忘策略把重复上下文变成资产这里面我最看重两类 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 风险。风险典型来源经济后果输入风险越狱、 prompt injection先污染生产输入再增加过滤成本外部风险RAG 文档投毒、网页污染检索 token 需要信任溢价内部风险潜伏行为、安全对齐失效审计和红队成本前移Agent 间风险共享记忆、工具链传播局部失败变成协作级损失市场风险DoS 、容量误报、选择性拥塞扭曲价格信号和服务可用性论文的安全成本模型强调一个取舍防御组合会增加即时成本但会降低预期攻击损失。过滤、来源审计、沙箱、冗余评估、隐私计算都不该被视为额外负担而是 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%免费】
浙大×阿里云综述 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 当成三种东西来看会比单纯看账单更清楚。属性含义Agent 中的表现生产要素消耗 GPU 、内存、电力和时间推理、检索、工具调用都要消耗 token交换媒介API 市场按 token 计价token 变成 AI 服务的事实货币记账单位衡量任务复杂度和生产力可以统计推理、通信、记忆、失败重试成本这个分类直接影响产品埋点。很多团队只统计 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 优化可以不按论文清单背名词换成一个更容易落地的排查表。要省什么典型做法真实收益inputprompt 压缩、上下文裁剪少塞历史和无关文档reasoningearly exit 、 latent reasoning避免无收益的长思考prefillKV cache 、 FlashAttention降低长上下文启动成本tool更准的工具选择、 MCP少注入 schema 少失败重试memory写入、检索、遗忘策略把重复上下文变成资产这里面我最看重两类 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 风险。风险典型来源经济后果输入风险越狱、 prompt injection先污染生产输入再增加过滤成本外部风险RAG 文档投毒、网页污染检索 token 需要信任溢价内部风险潜伏行为、安全对齐失效审计和红队成本前移Agent 间风险共享记忆、工具链传播局部失败变成协作级损失市场风险DoS 、容量误报、选择性拥塞扭曲价格信号和服务可用性论文的安全成本模型强调一个取舍防御组合会增加即时成本但会降低预期攻击损失。过滤、来源审计、沙箱、冗余评估、隐私计算都不该被视为额外负担而是 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%免费】
