一个忘关的开关，与企业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 年将全球数据