Alibaba Cloud's Zhou Qi on Building Certainty for Enterprise Agents

撰稿：白默

企业做 Agent，最该担心什么？

花了钱换不来效率？安全和组织跟不上？系统不够稳定，模型一换，整套架构推倒重来？

阿里云智能集团研发副总裁、云原生应用平台负责人周琦没有从中挑一个。他讲起了电力的发展。

“过去的产业变革靠大发电厂、一根大传动轴，能量输出方是集中的。你不可能每家每户都在家里造一个巨大的机械电机。”

电能让能量的使用变得平权。AI 则让智能变得平权。

传动轴是工业史上一件具体的东西。19 世纪末的美国工厂里，一台蒸汽机带动贯穿厂房的长轴，皮带从轴上垂下，连接一台台机器。电动机进入工厂后，不少企业最初只是用大电机替换蒸汽机，轴和皮带原样保留。

经济史学家保罗·戴维在 1990 年的研究中指出，到 1899 年，电动机在美国工厂机械动力中的占比仍不足 5%；直到 20 世纪 20 年代，电气化才开始显著反映在制造业生产率上。

今天的企业也有自己的“传动轴”。

过去三四十年积累下来的代码、程序和系统，连同团队的协作方式和管理理念，大多建立在形式逻辑之上。传统软件是符号系统，输入、条件和结果原则上都应当确定；但 AI 的底层却是概率。

“这里有一个天然的矛盾。这是这件事情的本质。”周琦说。

个人用 AI 生成一张图片，出现一点像素偏移，笑一笑也就过去了。企业把资金投入一个场景，等待的却是一年甚至五年后的收益。它必须回答：系统能不能持续运行，最终能否形成回报。

“企业是一个 ROI 的场景，它需要确定性。”

周琦以飞天团队第一位实习生的身份加入阿里云，参与飞天操作系统从 0 到 1 的研发。此后，他的工作逐渐延伸到日志处理、系统监控与诊断。

这次访谈发生在 2026 年云栖大会之后。大会期间，阿里云发布了智能体构建和治理平台 AgentCore，将企业级 Agent 基础设施进一步标准化和托管化。

开头提到的那些担心——效率、安全、组织和稳定性——其实都指向这种矛盾。如何在概率之上建立确定性，这也成了 Agent 进入生产环境必须解决的问题。

一、从灯座上取电

电刚进入美国家庭时，线路主要为照明铺设。人们如果想使用熨斗、电扇或者吸尘器，往往要先拧下灯泡，再把电器接到灯座上。

1904 年，哈维·哈贝尔获得“可分离插头”专利。插头可以直接拔插，但与之配套的底座仍然要拧进灯头。

真正的问题很快从“有没有电”变成“怎么接入电”。

随着墙壁插座增多，不同厂商采用的规格却各不相同。1919 年哈贝尔与通用电气等厂商的诉讼记录显示，1915 年前后，美国市场上存在 15 至 20 种插片和 15 至 30 种插座，不同厂商的产品无法互换。判决也明确记录了当时市场对标准化的迫切需求。

周琦第二次讲到电，谈的正是这套配套设施。

“最初的 30 年，用的都是一个照明体系。直到大家把电的规格，以及继电器、变压器、插座等配套的东西标准化之后，才带来一个非常繁荣的经济周期。”

企业里的 Agent，也走到了类似的阶段。

如果没有公共底座，每个团队都只能在自己的“小作坊”里接模型、写工具、配权限：今天做一个“电锅炉”，明天再造一个“电风扇”。不同 Agent 的身份无法识别，权限无法继承，系统之间也无法顺畅衔接。最终做出了大量 Demo，却很难真正进入生产环境。

这并非一家厂商面对的独有问题。随着 Agent 从试验走向生产，行业关注点已经从“能不能做出 Agent”，转向长任务如何持续运行、状态能否恢复、凭证如何管理、行为怎样审计。相应地，承载 Agent 的运行时和治理基础设施正在成为企业落地的公共需求。

企业之所以迫切需要这套基础设施，是因为它们正在把更多工作交给 AI。

此前的 AI 应用，大多集中在单点提效：研发人员用它辅助编程，产品经理让它生成 PRD，市场人员借它整理资料。随着模型解决复杂任务的能力增强、调用成本下降，AI 开始从边缘环节进入企业的核心生产流程。

“当 Agent 比人更强，成本又越来越便宜，大家就会把 AI 的应用，从原来边角料的场景移到企业最核心的生产场景上。”

但 Agent 一旦进入核心流程，作坊式的接法便难以支撑。

“这不是企业缺乏行业认知。恰恰相反，企业往往比平台更了解自己的业务。”周琦表示，AI 能力趋于普及后，真正稀缺的是另一种能力：在看过足够多行业和场景之后，面向长期演进规划系统架构。

各个职能部门都知道怎样改进自己手里的工作。更困难的是，让这些能力接得上——一个部门完成的任务，另一个部门可以继续处理；一个 Agent 使用过的工具和数据，另一个 Agent 能在权限范围内复用；局部效率提升，最终能够汇入一条完整的生产流程。

这套架构需要解决四个问题：稳定、安全、性能和成本。

稳定，不只是“服务不宕机”，还包括让 AI 在发挥能力的同时，沿着企业需要的路径运行。每一家企业都代表着对其细分行业的一套抽象，系统要把这种抽象转化为规则、边界和评价标准。

安全则要守住企业过去赖以生存的基础：岗位体系、权限、合规和隐私。传统软件控制的是确定的程序调用，Agent 却可能自主规划、连续调用多个工具。一旦进入生产流程，安全治理的对象便从模型输出扩展到身份、权限、数据、工具、记忆、行为和运行环境。

在电力的比喻里，阿里云开源 AI Infra 和相关组件相当于已经出现的插座标准。企业可以直接使用它们，开发自己的“冰箱”和“电风扇”。AgentCore 则是一站式的企业级 Agent 构建与治理平台。企业不必从头接电线、修变压器、做断电保护，可以把精力放在具体业务上。

基础设施标准化，并不意味着企业原有的软件系统会被抛弃。

恰恰相反，传统系统长期积累下来的流程、接口和数据，正是 AI 发挥作用所需要的“手脚”。

“如果没有手脚，AI 就没法充分发挥价值。”周琦说。

二、一个人盯五个系统

满帮集团的案例可以解释，这些“手脚”究竟是什么。

满帮的平台连接货主和货车司机。2025 年，其平台履约订单达到 2.36 亿单，同比增长 19.8%。对于这类已经成为社会物流基础设施的平台，一次系统故障可能意味着车辆无法调度、货物延迟送达。

一次调度需要穿过货车端、司机手机、货主 App 和后台调度系统。网络、数据库或者应用服务的任何一次抖动，都可能导致任务失败。

排查故障的人也要沿着这条链路逐层寻找原因。据满帮案例材料，运维人员一个人要盯 5 个系统，应急时一次要打开 6 个平台。排查故障，需要在不同平台之间切换、查询，再把分散的信息拼在一起。

“修有时候五分钟就够，找要半个小时。”一位在类似平台做过多年稳定性值班的工程师说。

AgentCore 接手的正是这部分工作。

第一步，是把企业原来用于运维排查的工具 MCP 化，转化为 Agent 可以调用的标准接口。第二步，则是把现有的权限体系一并带入。

下线一台机器、重启一个应用、修改一项配置，企业原本就有相应的角色和审批制度。哪些人拥有权限，什么级别的故障可以自动处理，哪些操作必须由人确认，这些规则不会因为执行者从人变成 Agent 就消失。

完成这两步之后，运维系统不再完全由人推动，而是拥有一个能够全天候运行的“大脑”，再配上查询、诊断和处置故障的手脚，它可以在一分钟内执行上千行命令。

据满帮在云栖大会上的分享，其稳定性数字人在所披露的重大风险定位场景中，可在 1 分钟内定位原因，准确率超过 90%。

“过去，运维人员半夜接到电话、登录系统，完成的主要是应急操作。这类工作未必能带来成长，却长期占用人的注意力。”周琦说，现在他们可以关注更重要的工作。

工具从哪里来、任务做到什么程度，仍然需要企业定义。

周琦把业务流程和数据统称为“企业上下文”。每个行业的上下文都不同，这部分无法由通用平台代替。企业需要完成四件事：定义任务，定义工具，定义 Agent 的身份和编排方式，以及准备它工作所需的上下文。

平台负责的则是公共问题。

有些生产任务需要连续运行几天几夜，不能因为一台机器故障而中断；任务重新启动后，也不能丢失此前的状态。哪些数据可以访问、哪些操作可以执行、失败之后从哪里恢复，都由底层系统统一管理。

不同场景还需要采用不同的构建方式。

对于“高度可控”的任务，可以采用高代码方式，把关键步骤写成确定的逻辑。“这在某种意义上又回到了传统软件的符号系统。”周琦表示，对于希望快速投入使用的场景，则可以采用 Harness，并通过 Skills、规则和评价体系约束 Agent 的行为。

更大的变化发生在任务规划上。

传统软件先定义 Workflow：第一步做什么，第二步调用哪个接口，出现异常进入哪条分支。AI 原生的规划方式则更像做一道菜——先准备原料，明确依赖条件和最终目标，再设定中间过程的边界，具体步骤交给 Agent 动态完成。

一年前，企业对长任务的信心有限，更倾向于用 AI 调用小工具、解决小问题。如今模型对复杂任务的支持能力增强，企业开始尝试只定义目标、资源和约束，让 Agent 自己寻找路径。

“后者的不确定性更高，但天花板也更高。”周琦说。

三、五千个爱因斯坦

这个天花板究竟能有多高？

“一个原本由一名员工承担的复杂任务，在紧急情况下，能不能瞬间变成由 5000 名员工同时处理？如果这些员工都拥有顶尖的推理和执行能力，又会发生什么？”周琦问道。

“甚至可以让 5000 个爱因斯坦去编排。有人做研发，有人做调研，有人做推广，最后把方案串起来。”

但紧接着而来的问题是：5000 个爱因斯坦同时工作，谁听谁的？谁可以查看什么数据？出现分歧时由谁决策？

一家连锁零售企业的区域运营经理，过去最怕晚上十点之后出来的盘点结果。发现某家门店缺货后，他要在店长群里一个个询问，再挨个打电话确认。

“有时候打过去没人接，接了也不一定有货。”

零售业长期承担着高昂的协调成本。门店分散在不同地点，每家店都需要有人负责补货、对账和运营。如今，这家企业尝试在 AgentCore 上为不同门店构建 Agent 团队：有的角色负责补货，有的负责对账，还有的负责管理和协调。

“这已经不只是 SaaS 的延伸。”周琦说。

SaaS 主要把物理世界搬进数字系统，让业务变得可见、可管理和可控制。Agent 进一步处理的是生产力问题——系统不再只是记录一项工作，还可以参与并完成工作。

电动机进入工厂后，生产率之所以等待几十年才明显提升，也与此有关。工厂最初只用电动机替代蒸汽机，随后发展到一台电机带动一组机器，最后才形成“一台机器配一台电机”的单机驱动模式。机器由此摆脱传动轴的约束，可以按照工序和物料流向重新排列，工厂也逐渐从多层结构转向更灵活的单层布局。真正的生产率提升，来自围绕新技术重新设计生产系统。

在周琦看来，Agent 团队需要完成的，同样是一次重新布置，只不过对象从机器和厂房变成了岗位与组织。

在人类组织中，如果研发流程的并行度不够，企业通常会招聘更多员工；如果某个岗位出现瓶颈，也可能将它拆成岗位 A 和岗位 B，让两个人协作完成。

但 Agent 的拆分和重组会更加频繁。它不需要经历传统意义上的人员交接，也可以更快地并发处理任务。“企业会先从局部创新开始，获得单点效率提升，再逐步形成以 AI 为主、固定流程为辅的生产模式。”周琦说。

具体如何协作，取决于任务。

软件开发需要把规划、研发、测试和运维串联起来，每个 Agent 代表一种角色和视角。面对创新性任务，则可以让多个 Agent 与人共同发散讨论，再把不同意见收束为相对确定的结论。

“这有点像概率。让一个人天天关在房子里想，他可能永远在自己的思维里。但让意见不同的人一起讨论，就有可能爆发出一些点子。”

在周琦看来，这种多 Agent 将会成为未来的主流。

但 Agent 越多，管理也越复杂。求解空间扩大之后，如果没有合理的分工、评价和退出机制，它们也可能不断重复劳动、相互消耗，最终无法得到更好的结果。

安全风险同样会随协作链路增加。Cloud Security Alliance 发布的一项企业调查显示，65%的受访组织在过去一年里至少遇到过一次与 AI Agent 相关的事件，常见影响包括数据暴露和运营中断。这意味着，多 Agent 系统不能只解决“如何分工”，还要回答“权力怎样分配”。

回到那家零售企业，一次门店调货需要经过几道关卡。

A 店的补货 Agent 拥有自己的身份，系统知道它代表哪家门店、承担什么角色。它只能读写本店的数据，看不到其他门店的完整经营信息。它可以向 B 店的 Agent 发出调货请求，由 B 店根据库存决定让出多少；一旦调拨量超过设定数额，流程便暂停，等待区域经理确认。

“现在早上来看到的，都是已经谈好的单子，大的我来批。”区域运营经理说。

这套机制最难处理的是权限。

Agent 与很多系统交互，每一次调用都可能成为风险入口。因此，密钥不应长期暴露给 Agent，而应在运行时按需发放给对应的工具和客户；真正调用之前，再检查身份、任务和权限是否完整匹配。

大额异常操作通常容易被发现，更隐蔽的风险是大量小额操作。例如，Agent 如果通过许多笔小额转账逐步转移资产，系统不仅要检查单次调用，还需要从历史轨迹中识别异常模式。

模型代理、工具访问和外部系统连接因此要进入统一控制面，让分散在不同 Agent 手中的权力能够被收拢、审计和撤回。

那么，并发的 5000 个“爱因斯坦”究竟谁听谁的？

答案并不是设立一个永久的中央大脑，而是给每个 Agent 分配清晰的身份和上下文，让协作发生在一个个“房间”里。

房间内的成员共享完成任务所需的上下文。Leader Agent 负责拆解任务：哪些工作交给团队成员，哪些由自己完成，最后如何汇总。遇到需要人类承担责任或者作出判断的环节，流程暂停并交回给人；此前的每一步操作都留下记录，供后续审计。

“出了这个房间，这些信息可能就跟其他人没有关系了。”解释这个概念时，周琦打了个比方，“这就像今天我们做讨论一样。”

四、那些留下的轨迹

房间会消失，轨迹却会留下。

“过去建设一套企业系统，周期通常按年计算。一年前的设计也许能够覆盖 80%的场景，剩余 20%的长尾需求，却可能因为投入过大而长期无人处理。企业往往要等到下一轮预算，才有机会重构系统。”

AI 的泛化能力让这些长尾需求第一次有可能被接住，而 Agent 完成任务的过程本身，也可以成为企业资产。

周琦早年从事的是日志处理和系统监控诊断。这里的记录对象则进一步延伸到工作过程：不仅要知道系统出了什么问题，还要知道一个任务经过了哪些尝试，调用了哪些工具，最后为什么成功或失败。

在 AgentCore 中，负责收集这些轨迹的组件叫 AgentLoop。它记录人或 Agent 做过的尝试、调用过的工具以及最终结果，再供后续整理、评估和复用。

一次成功经验可以被整理成 SOP、一项工具、一个 Skill，或者一段记忆。当相似请求再次出现时，系统便可能直接调用已有经验，而不必从头规划。

满帮的运维排查具有类似价值。已知故障的定位和解决过程，可以沉淀为相应的 Skills 和知识库。下一次再出现同类问题，不会因为员工遗忘或者团队换人而重新冷启动。

人的经验过去往往散落在工单、聊天记录和个人记忆里。员工离职或者岗位调整后，企业可能只保留了结果，却不知道当时为什么这样判断。Agent 运行轨迹则让企业第一次有机会系统记录“工作是怎样完成的”。

但经验只有被找到，才有复用价值。

另一个组件是 Agent 资产管理，负责统一管理 Skill、MCP 工具、模型和 Agent 模板等，并记录不同版本，跟踪它们的调用量、评价和评估结果。理想状态下，每个新加入的员工或 Agent 都不必从零开始，而是“踩在别人的肩膀上”。

数据库只是这些资产的一种存储介质。客服记录、发货订单、客户偏好，以及企业在长期信息化建设中积累的数据，都可以成为后续任务的上下文。已经完成信息化建设的企业，也可以利用存量数据为 AI 项目冷启动。

但轨迹沉淀下来并不意味着它会永远有效。

模型版本升级、工具发生变化、任务目标调整之后，过去成功的路径可能失效。企业需要用历史案例持续做回归评估，验证新版本的效果究竟是提升还是下降。

“不能把所有东西都赌在概率上面。”周琦说。

这种评估有点像每年给员工打分：目标是否完成，过程消耗了多少资源，质量是否达标，有没有越过权限边界。

成本也要在这个过程中计算。不同任务可以通过智能路由选择不同模型；Agent 不活跃时，系统可以自动缩容，减少闲置资源。每一次调用产生的 Token、费用、时延和成功率，也需要按调用者、Agent 和模型分别观测。

因此，构建 Agent 只是第一步，更困难的是未来持续运营它。

“企业要把有效的方法保留下来，在模型和任务变化时重新评估，再根据结果调整身份、工具、流程和协作关系。”周琦说，传统软件的架构可能以季度或者年度为周期变化，而 Agent 系统的结构，理论上每天都可能演进。

企业从哪里开始？

周琦给出的建议很简单：先找到一个相对确定、高频、容易数字化、结果也容易衡量的场景，通过统一平台跑通完整路径；再逐渐把上下游更多的人、更多团队纳入，让任务从单点走向复杂协作。

最后回到组织。

周琦表示，无论个人还是企业，未来都要追求成为“时间的朋友”，持续沉淀能够产生复利的资产。这些资产包括业务知识、任务轨迹、隐性经验，也包括人与人、人与 Agent 以及 Agent 之间形成的协作方式。

越早开始，积累的复利就越明显。

执行性的工作可以逐步交给 Agent，人则更多承担分工、判断和复核。

记者追问：这样的组织里，人最重要的价值是什么？

“Review，定义好标准。”