企业Agent全栈账单：一个开关忘关，Token费用从1万变3万

云栖大会企业级 Agent 论坛开场之前，极客邦科技创始人霍太稳接到了一个电话。电话那头是员工，说上个月上线的一款 AI 应用，预估 Token 费用大概一万元，结果结账时花了三万。原因并不复杂：有个开关没关，应用就在后台悄悄烧钱。

把开关关上，眼前的支出是止住了，但问题留在那儿：任务是谁启动的？跑了多长时间？这笔费用算在谁头上？为什么拖到月底才被发现？这些追问指向一个基本要求——系统不能只会干活，还得说清楚它干了什么、该怎么约束它。应用一旦以 Agent 的方式自主行动，这个要求就更紧迫。

传统的问答场景里，下一轮对话由用户说了算。Agent 不是这样：任务接到手以后，它可能连着检索、调用工具、根据结果改计划，甚至重新发起尝试。一次委托到底产生多少调用、占掉多少资源，很多时候得跑起来才知道。

企业于是面对双重不确定：结果不确定，成本也不确定。更准的模型能少犯错，但替不了权限校验、预算约束和故障恢复。Token 单价降了，也不代表完成一项任务的总成本一定跟着降。更好的模型也许能减少重试，让某些补丁变得没必要。可企业一旦据此把更长、更复杂、权限更高的任务交给 Agent，原本由人做的检查、协调和兜底，就得沉淀到系统里去。

全栈协同的需求就是这么来的。算力、模型、数据、执行平台和治理机制，得围着同一项业务任务转——身份能传递，状态能恢复，费用能归属，异常能发现。

一、走向生产后，Agent 效果公式不断变长

Agent 市场的扩张预期，和企业落地的困难，眼下正一起冒出来。IDC 预测，到 2029 年全球部署的 AI 智能体将超过 10 亿个，约为 2025 年的 40 倍。Gartner 则预测，到 2027 年底，超四成 Agentic AI 项目会因成本攀升、价值不清或风险失控而被取消。

这两组数字说的不是同一件事：部署数量可以飞快膨胀，单个项目还是可能撑不下去。企业真正在意的，是演示里能完成任务的 Agent，能不能在真实业务里反复交出合格结果。技术讨论常拿“模型 + Harness”来概括 Agent。Harness 是围绕模型的执行与控制框架，管的是组织上下文、调度工具、记录状态、处理异常。模型负责理解和推理，Harness 把它们接进实际任务。

“模型决定智能上限，Harness 保障端到端交付。”基元律动联合创始人韩凯说。但放到企业环境里，光有这两样远远不够。满帮集团 AI 算法总监高艺铭把业务目标、上下文、Harness、运行环境和持续维护都算进了交付条件——先定清楚什么算完成，再配数据、工具和资源，上线之后还得持续检验效果。

这些条件要到真实交易里去验证。满帮的 Agent 涉及加价、成交和电话沟通。理解货主需求之后，系统还得查货源车辆、核实价格权限、写进交易系统，条件一变就要决定是继续、撤回还是转人工。哪一环理解错了，都可能传到后面的操作上。“错误一次，可能几百次正确都难以挽回。”高艺铭说。

易方达基金首席信息官刘硕凌博士强调，选型不能光看上限，更要看下限。他提到金融系统对“四个 9”可用性的要求。高可用和结果准确属于不同维度，却都指向同一个现实：系统得一直能用，也得把错误造成的损失压住。

所以企业对 Agent 的评估，要超出演示的成功率：失败能不能及时发现？高风险操作能不能拦住？中断以后能不能恢复？有争议时能不能查清发生了什么？这些问题，单靠模型能力答不了。

二、数据未必是护城河，关键问题在各层之间

满帮连的是货主和司机。一趟运费能到数千甚至上万元，找货、找车、议价、履约都得来回沟通。Agent 进到这些流程里，必须同时听懂人的意图和交易的当前状态。高艺铭介绍的几类问题，正好说明这种要求怎么超出了模型本身的能力。

头一个是上下文。物流对话很少按预设顺序走。用户可能中途补条件、改要求，也可能一句话里同时询价、议价还要执行。团队试过把任务拆成单一意图来提确定性，结果反倒限制了模型对完整任务的理解。

"真实场景里几乎不存在纯粹的单意图。"高艺铭说。

任务还是得拆，但拆开之后的每一步，得共用同一份业务状态——哪些条件已经确认过了，哪些要求刚刚发生变化，哪些操作已经执行完毕。不然的话，每一步单看都说得通，拼到一起却做了用户压根没提过的事。上下文工程要解决的，就是让模型在每一步都能拿到跟当前相关的、有效的信息。

信息背后的业务含义也不能忽视。高艺铭拿"标箱车"举例：在满帮的语境下，这指的是拉标准集装箱的平板车，可通用模型很可能把它当成厢式货车。文字模型认得，不代表行业术语它用得准。

那把这些内部文档全丢进知识库行不行？也不行。团队发现，有些文档记的是怎么用心理学技巧去议价的经验。员工在特定场合用过的手段，能不能让 Agent 自动去执行，这是要重新判断的。

知识进系统之前，企业得把业务定义、操作规则、个人经验分开，来源、适用条件、有效期、权限都得标注清楚。检索管的是找到内容，规则和权限管的是这些内容在当前任务里能不能用。数据走完这套处理，才谈得上稳定支撑行动。

执行规模又会带来另一种压力——Agent 系统说到底是个高并发系统。满帮第一次把 Agent 扩到 2000 个的时候，那套原本服务数百万用户的系统居然出了故障。

这两个数字没法直接比。人会停下来等、会读、会想；Agent 却可能一直在查状态、调接口、发起重试。系统真正扛多少负载，取决于并发量、调用频率和重试方式。要是还按面向真人的容量假设来估，很可能会低估压力。

所以运行平台得存任务状态，等待时挂起、收到事件再恢复，队列、限流和重试上限也要设好。应用层减少无效调用，数据库和中间件去接新增的负载，基础设施按需配资源。光堆模型算力，堵在业务接口上的问题消不掉。

满帮后来搞出了"一朵云、两套生产系统、一层桥接"的架构。传统系统管交易规则和确定流程；Agent 系统负责长时任务和多 Agent 编排；桥接层做鉴权、风控、语义转换和沙箱隔离。

举个例子：传统系统返回"219 错误"，Agent 就不知道该怎么往下走了。桥接层把它转成"车长字段缺失，需要补充"。这么一转，模型能看懂问题出在哪，原来的业务校验也没丢。

模型可以提操作，执行服务照样得核对身份、参数和业务条件。"Agent 处理不确定性，工程保证确定性"这句话，在这里有了具体的落点：能明确校验的交给机制，没法可靠处理的交回给人。

维护也变成了架构的一部分。满帮每天收到数千个失败案例，团队不停地调框架、加工具、补技能，可第一代 Agent 的评测成绩却慢慢不动了。为单个问题新加的规则，可能跟已有的规则打架；为旧模型设计的补偿机制，升级之后可能就不管用了。

修好一个案例，还得回到原来的任务集上重新跑一遍，确认没伤到别的任务。维护不光是修新问题，也是把旧设计简化掉，持续做熵减。

这些问题在同一条任务链上是缠在一起的。车辆知识错了，就引出无效查询，无效查询又触发重试，最后表现出来就是延时变长、成本上升。各层只顾盯自己的局部指标，企业就很难把整个过程还原出来。

三、阿里云争取的，正是系统协同的位置

当问题横跨模型、数据和业务系统时，企业就得做取舍：哪些能力自己建，哪些交给平台，衔接之后的结果由谁来负责？

这就给阿里云打开了新的市场空间——它提供的不只是模型和算力，还有企业把 Agent 接进生产环境所需要的运行和治理能力。

2025年2月，阿里巴巴对外公布了一项计划：未来三年，云和AI基础设施上的投入不会低于3800亿元。到了2026年云栖大会，目标又被抬高一档——2032年之前，全球数据中心规模要做到20GW以上。芯片、云、模型、模型服务、智能体应用，这些环节被统一收进全栈布局之中。

投入标明了战略方向。企业能不能从中受益，还取决于基础设施与具体业务之间的连接：模型能不能在授权范围内访问数据，工具能不能可靠执行，运行记录能不能用来排查和改进。

千问大模型、千问AI平台，跟阿里云的计算、存储、网络、数据库等底层设施长在同一套体系里，彼此打通，产品层面的底座就这样搭了起来。Agent运行时靠沙箱隔离和弹性扩缩容，让工具调用能稳定跑起来；编排控制层由Router、Planner、上下文管理、身份权限与计量计费组成，模型只能在被授权的范围内取用数据；千问AI平台则把生产、评测、发布连成一条可以回溯的链路，运行记录留下来，日后排查问题、做改进都有据可依。AI应用安全、AI数据安全、AI合规治理这三条线，从头到尾贯穿其间。产品铺得够宽了，但客户在集成、运维、迭代中到底能不能拿到实惠，还得看真实业务里的表现。

阿里云智能集团资深副总裁、公共云事业部总裁刘伟光在云栖大会论坛上表示，一个能打的Agent，要靠模型、合作伙伴和数据一起往前跑，"不是把产品卖给客户就结束了"。模型会迭代，业务规则会调整，真实使用中问题会一个接一个冒出来，所以交付这件事，得一直管到上线之后。

软件开发行业已经能感受到这种变化。AI Coding确实能让代码生成更快，可真要投产，代码库、测试、持续集成与交付、安全审查、上线后的运维，哪一环都少不了。代码产出量涨上去了，验证能力就得同步跟上。

小红书质效 &AI 应用总架构师飞鸿把问题问得直接："大家确实变快了，但变快的是价值，还是生产垃圾的速度？"

他提到，现在团队里手写代码已经很少了，下一步的重点是搭起验证机制，把架构、编码过程、最终产物都检查一遍。生成和验证两头一起使劲，交付效率才起得来——错误代码要是源源不断流进后面的环节，前端省下来的时间，最后都得在后端返工里还回去。

一旦 Agent 走进办公系统，要对接的就不只是软件，还有组织架构和权限体系。论坛上提到，阿里云内部给公共云事业部总裁做过一个叫 Patrick 的"领导力分身"：整理经营看板、出早报、查数据波动，把活儿派给执行人，一周后再把结果收回来。

Patrick 有自己的工号，能被拉进钉钉群，同事可以 @ 它，它也能在权限范围内参与协作。两三个月下来，阿里云公共云事业部已经有 60 个带工号的 Agent。工号解决的是"组织认不认它"，真正划出行动边界的其实是授权——它替谁干活，能读什么数据、调什么工具，出了岔子谁来接手。

论坛披露的设计里，Patrick 每调一次 MCP 工具都得过鉴权，身份信息一路贯穿整条交互链路；用的是当前对话人的身份，不是公共账号。

等 Agent 开始独立扛任务，人的职责也跟着挪了位置：精力更多放在授权、监督、验收和处理例外上。业务越靠近交易、医疗、金融这些核心地带，这些职责就越得写进系统规则里。

满帮的交易桥接、小红书的研发验证，加上 Patrick 的身份管理，几个案例指向的要求差不多：模型给出的计划，必须走业务系统能看懂、能执行的接口；业务系统回传的状态，又得成为 Agent 下一步动作的依据。

这既是阿里云全栈布局的商业机会，也是一把检验的尺子：能不能少让企业自己去连各层系统，身份、任务、数据和费用之间的对应关系能不能一直有效。

手里有一份产品目录，这只是开头。

四、算清每项任务的成本，才谈得上持续运行

系统打通之后，企业还得回答开头那通电话留下的疑问：钱花到哪儿去了，换回来什么，下次超支能不能提前拦住？

阿里云智能集团资深技术专家孙廷韬把 Agent 观测分成三层：并发、吞吐、延时和 Token 这类运行指标；任务从开始到结束的执行轨迹；技术指标和业务结果之间的关联。

三层各管各的问题。运行指标提示哪里出了异常，轨迹帮忙定位到具体哪次调用，业务结果则说明这些调用有没有干成有价值的事。串起来看，企业才分得清一次合理的高成本任务，和一段没有产出的反复重试。

所以记录里要留下模型版本、输入输出、工具调用、重试和异常，再按权限处理其中的数据。轨迹能帮人重建系统做过什么，可模型自己生成的解释不能单独证明判断对，结果还是得过规则、测试或业务人员这一关。成本同样要按任务归属。小红书就是把 AI 费用摊到业务经营单元，让使用部门看清消耗了多少 Token、完成了什么工作，再决定要不要接着投。算回报的时候，工具服务、基础设施、人工复核和失败重做的钱都得计进去。企业真正该比的，是每完成一项合格任务的总成本。

观测之外，执行中还得有约束。企业可以按用户、任务和时间周期设预算，限制执行时长、调用次数和重试次数——快碰到阈值就告警，到了阈值就暂停或者转交。前提是身份系统、任务调度和计费记录认的是同一项任务，这些限制才落得了地。

上下文治理和模型路由，则能砍掉不必要的消耗。前者清掉当前步骤已经用不上的信息，同时留好重新读原始记录的口子；后者按任务要求挑模型，再给处理不了的情况留一条升级路径。

小红书质效 &AI 应用总架构师飞鸿分享说，通过裁掉低价值调用记录、保留恢复指针，团队在部分峰值场景里把上下文成本压低了约 20%；模型路由在他讲到的场景中带来过约 69% 的成本下降，团队也没看出体验有明显下滑。

众阳健康科技集团产品研发中心总经理郭龙领强调：医疗应用不能拿诊疗质量去换 Token 消耗的降低。成本优化得在保住业务质量的前提下做，系统调整完还要持续盯着诊断准确率这些核心业务指标。

还有一笔钱容易被漏掉，那就是系统升级的成本。

高艺铭管这种变化叫"水涨船高"：底层模型和框架可能几个月就迭代一轮，企业架构必须允许 Harness 和模型被快速换掉。满帮换过一次基座模型——适配得好的 Agent，成本掉到原来的四分之一；那些补丁堆满、跟旧模型绑得太深的 Agent，成本没降，准确率反倒更差。

孙廷韬由此提出，要把记忆、Skills、Tool Proxy 和 LLM Router 这些能力服务化，让 Agent Core 能热切换。哪怕行业里冒出什么新框架，也要争取一周内换完上线。

也就是说，成本管理不该是一次性的调优，而该是一种能持续吃到技术进步红利的架构能力。

"传统 App 功能上线，可能已经完成 80%；Agent 上线，就像种下一颗种子。"高艺铭说。往后它还得不断接收反馈、修正行为、清理技术债、更新知识。

刘硕凌博士把话说得更直白："过去很多工作在上线之前就做完了，如今越来越觉得，上线才意味着工作真正开始。"

再说回霍太稳接到的那个电话。把开关关了，眼下的支出是止住了，可要想不再出现下一次超支，得靠好几个环节一起发力：预算要跟任务挂钩，任务要跟身份对应，执行过程要留下记录，出了异常得能触发处置。

模型能力越强，企业就越有底气把更多活儿交给 Agent 去干。委托的范围一扩大，相应的责任也得落进系统里。模型跑完一次推理，随之而来的操作、花出去的成本以及业务上的结果，说到底总得有人来扛。