一个忘关的开关，与企业Agent的全栈技术账单

云栖大会企业级 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 月宣布，计划未来三年至少投入 3800 亿元建设云和 AI 基础设施。2026 年云栖大会上，公司进一步提出，到 2032 年将全球数据中心规模扩展至 20GW 以上，并把芯片、云、模型、模型服务和智能体应用纳入全栈布局。

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

阿里云的计算、存储、网络和数据库等构成的底层基础设施，与千问大模型、千问 AI 平台在同一体系内协同，为这种连接提供了产品基础：Agent 运行时以沙箱隔离和弹性扩缩容支撑工具的可靠执行；Router、Planner、上下文管理、身份权限与计量计费构成的编排控制层，让模型在授权边界内调用数据；千问 AI 平台把生产、评测、发布串成可回溯的链路，运行记录得以沉淀为排查和改进的依据；AI 应用安全、AI 数据安全与 AI 合规治理三条纵深贯穿其中。产品的广度已经铺开，能否转化为客户在集成、运维和迭代中的实际收益，仍要在真实业务中检验。

阿里云智能集团资深副总裁、公共云事业部总裁刘伟光 在云栖大会论坛上说，有效的 Agent 需要模型、合作伙伴和数据共同演进，"不是把产品卖给客户就结束了"。模型会升级，业务规则会变化，真实使用会不断暴露新的问题，交付因此要延伸到上线之后。

这种变化在软件开发领域已经显现。AI Coding 可以加快代码生成，但投产还牵涉代码库、测试、持续集成与交付、安全审查以及上线后的运维。代码产量上去了，验证能力也必须跟上。

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

据他介绍，团队已经很少手写代码，接下来的重点是建立验证机制，检查架构、编码过程与最终产物。生成与验证共同决定交付效率——错误代码不断流入后续流程，前端省下的时间，终将变成后端的返工。

Agent 进入办公系统后，需要衔接的则是组织关系与权限。

据论坛介绍，阿里云内部曾为公共云事业部总裁构建一个名为 Patrick 的"领导力分身"。它可以整理经营看板、生成早报、调查数据波动，把任务同步给执行人，并在一周后回收结果。

Patrick 拥有独立工号，可以被拉进钉钉群、被同事 @，也能在权限范围内参与协作。两三个月后，阿里云公共云事业部已有 60 个拥有工号的 Agent。

工号让 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。委托范围扩大的同时，企业也需要把相应的责任落实到系统中。模型完成一次推理之后，由此产生的操作、成本与业务结果，终究要有人负责。