本文整理自阿里云智能集团云原生应用平台负责人周琦和 AgentCore 产品经理李国强在云栖大会的分享。
Agent 投入已成共识，但生产化仍是少数派。
过去一年，基于高代码 Agent Framework 自主构建 Harness、复用产品化的 Harness、基于模型构建 Agent、在云产品的预置能力之上快速构建 Agent，都在迅速发展。Agent 已经成为个人办公的界面已，企业也开始把 Agent 设计进客服、营销、研发、运维、生产制造等业务流程。但生产化仍是少数派。
原因并不复杂。构建一个自己使用的 Agent，效果偶尔有波动，重新执行一次，或调整上下文就可以了；但把真实工作交给 Agent，要求则完全不同。它可能要长时间运行，调用多个企业系统，访问敏感数据，与其他 Agent、在多人之间进行协作，并最终对业务结果负责。
这意味着，Agent 落地企业生产环境，正面临着四大变化：
- 从概率智能走向可靠生产力；
- 从粗放使用走向精细化使用；
- 从单点试验走向智能基础设施；
- 从 Agent 孤岛走向智能组织。
阿里云刚刚发布的 AgentCore，正是面向这一阶段推出的企业级 Agent 构建与治理平台。
从概率智能到可靠生产力，差的是什么？
模型的输出具有概率性。同一个问题，在不同时间询问，答案可能并不完全相同。进入 Agent 之后，不确定性还会进一步扩大。
个人使用时，这种不确定性通常可以接受。结果不满意，可以修改提示词或重新运行。但在企业生产环境中，Agent 可能正在处理一次故障、修改一条客户记录，或者执行一项跨系统业务操作。企业不能把"多试几次"当成稳定性方案。
模型输出可以有概率，生产过程必须有边界，业务结果必须可验收。
因此，把 Agent 投入生产，需要回答一组传统 Demo 很少面对的问题：
任务运行很久，状态如何保存？执行中断后，能不能从失败的位置恢复？多个任务同时运行，如何隔离上下文？Agent 调用了哪个工具、修改了什么资源，能否完整追溯？当它准备执行高风险操作时，人能否及时接管？
AgentCore 将这些问题放进同一个运行与治理体系中。
Runtime 和 Sandbox 提供隔离、弹性调度以及长任务运行所需的环境；Harness 管理会话、状态和任务恢复；Agent Identity、AI 网关和审计能力约束 Agent 的行动边界；观测与评估能力记录执行过程，并判断任务结果是否达到要求。
这套体系关注的不只是 Agent 有没有返回结果，而是任务有没有被持续、正确、可控地完成。
AgentCore 到底是什么？
AgentCore 是阿里云面向企业推出的一站式 Agent 构建与治理平台。
它并不要求企业使用唯一的 Agent 形态。 企业可以通过高代码或托管 Harness 构建 Agent，也可以将已有的云端、桌面端 Agent 纳管到统一观测与治理体系；并在 AgentCore 上快速创建和注册 Agent，平台同时提供 Runtime、Sandbox、记忆、知识库、模型服务、AI 网关、观测与评估等构建、运行、治理和调优能力。
但如果只把 AgentCore 理解成一个 Agent 开发平台，就低估了它要解决的问题。
AgentCore 管理的对象，是一项任务从构建、执行到验收和改进的完整生命周期， 包括构建和接入，运行和治理，人和 Agent 间的协作，以及如何使用知识与工具，对输出结果验收、沉淀经验、持续改进智能体的效果。
使用 AgentCore 搭建多智能体行业调研系统，生成汽车行业调研报告：mp.weixin.qq.com/s/Oig3_21US...
从粗放使用到精细化使用，企业要看见什么？
在试验阶段，团队通常先看一个结果：Agent 能不能把任务做出来。
进入生产后，这个问题会被拆得更细。回答是否准确，只是其中一项。企业还需要知道 Agent 的规划是否合理、工具是否选对、参数是否正确、知识检索是否相关、执行过程中是否出现了无效循环，以及完成任务消耗了多少时间和 Token。
这要求观测对象从单次模型请求，扩展到 Agent 的完整执行轨迹。
一条轨迹会记录用户提出了什么任务，Agent 做出了哪些判断，调用了哪些模型、工具和知识库，每一步得到了什么结果，以及这些结果如何影响后续行动。工程人员可以从用户、会话、单轮请求等不同层级回看执行过程，定位问题究竟发生在哪一步。
看见过程之后，还需要判断过程和结果是否正确。
AgentCore 深度集成阿里云 AgentLoop，对于格式、数值阈值、API 参数等确定性问题，提供 Code Judge；对于单轮问答、文本质量和语义匹配，提供 LLM Judge；对于多轮会话、工具调用、RAG、Skill 或跨系统任务，则提供 Agent Judge 读取完整轨迹，调用工具核验事实，并按照企业自己的业务规则给出判断。
评估也不能停留在一次打分。线上运行产生的低分样本和失败案例，需要进入 Dataset；经过修改的新版本，要用评测集进行回归；确认没有退化之后，再逐步发布到生产环境。这样，Agent 的改进才不是"感觉这版更好了"，而是有数据、有对照、有验证。
成本也需要同样的精细化管理。每次调用产生的 Token、费用、时延和成功率，AgentLoop 可以按调用者、Agent 和模型进行分析；不同人员、团队和模型可以设置额度，发生异常突增或超限时，系统能够告警、限流、降级或阻断。
粗放使用关心能不能跑，精细化使用关心为什么这样跑、结果是否值得。
当质量、过程和成本都能够被度量，Agent 才真正具备持续优化的基础。
从单点试验到智能基础设施，需要改变什么？
企业刚开始使用 Agent 时，通常由少数团队自行选择框架、连接模型、配置工具和部署环境。这种方式适合验证想法，却很难支撑规模化运行。
因为 Agent 一旦增多，企业很快会面对重复建设：每个团队都在维护自己的运行环境，重新接入模型和知识库，各自处理身份、凭证、日志、评估和成本问题。不同 Agent 之间没有统一的版本、权限和质量标准，出了问题也很难快速确定负责人。
如果 Agent 的使用规模进一步走向千万级日活，平台需要管理的就不再是几个应用，而是一套新的智能基础设施。
AgentCore 的思路不是把所有 Agent 改造成同一种形态，而是提供共同的运行和治理底座。
周琦在分享 AgentCore 的平台治理能力
在构建层面，高代码 Agent、不同类型的 Harness 以及企业已有 Agent，可以按照各自场景选择合适方式；在运行层面，平台提供隔离、弹性和会话管理；在连接层面，模型、Skill、MCP、知识库和企业系统可以统一接入；在治理层面，不同形态的 Agent 进入同一套身份、权限、观测、评估、审计和成本体系。
工作流也不会因此消失。在高确定性、强合规的环节，工作流仍然适合表达明确步骤；在需要自主规划和动态决策的任务中，Agent 可以承担更多工作。企业需要的不是在几种技术路线中选出唯一答案，而是让它们在统一基础设施上各自发挥作用。
智能基础设施的价值，不是统一 Agent 的构建范式，而是让不同 Agent 都能在同一套规则下运行。
只有形成这层共同底座，企业才可能从一位员工用好 Agent，走向整个组织都可以稳定、可靠的使用 Agent。
从 Agent 孤岛到智能组织，协作方式会怎样变化？
复杂业务很少能由一个 Agent 独立完成。
例如，一次故障调查可能同时需要分析异常日志、检查调用链路、关联近期变更，并核验恢复方案。如果所有工作都交给一个 Agent，它的上下文会越来越长，任务边界也会越来越模糊。
AgentCore 选择了更合理的方式，是根据任务性质选择不同的协作结构。
李国强在分享 AgentCore 的协作能力
第一种是即时并发。主 Agent 将问题拆成多个相互独立的探索分支，由临时创建的子 Agent 并行处理，结果返回后立即释放。Deep Research 就是典型场景。
第二种是按需编队。企业把稳定的任务链定义为可复用模板，在任务开始时为不同 Agent 分配能力、权限和上下文，任务完成后回收。例如一项内容任务，可以依次由研究、写作和审查 Agent 完成。
第三种是长期服务。稳定的企业能力可以进一步沉淀为长期存在、可被发现和调用的数字员工。它拥有明确的职责、权限和服务边界，能够跨任务持续积累经验。这是企业多智能体协作继续演进的方向，目前尚在规划中。
在 Team 模式中，Leader Agent 负责理解意图、拆解任务和监控进度，Worker Agent 承担不同领域的专业工作。团队共享完成任务所必需的上下文，不同任务之间保持隔离。人可以直接查看 Agent 之间的交流和推演，也可以补充信息、打断执行，或者在关键节点完成审批。
这种协作方式改变的不只是系统架构，也会改变组织分工。
业务负责人定义目标、验收结果并处理例外；领域专家维护知识、Skill 和评测集，复盘失败案例；平台团队提供运行、权限、观测、预算和发布等共性能力。Agent 承担执行工作，但结果仍然需要明确的负责人。
智能组织不是让更多 Agent 同时工作，而是让人和 Agent 围绕同一个结果协作。
如果没有共同目标、上下文边界和验收责任，多 Agent 只会带来更多调用，而不会带来更好的交付。
一次成功，怎样变成企业能力？
Agent 每完成一次任务，都会产生新的信息：哪些知识真正有用，哪些工具调用方式有效，哪条推理路径更稳定，哪些失败需要避免。
如果这些信息只停留在一次会话里，任务结束后，经验也就消失了。下一个 Agent 仍然要从头摸索。
因此，企业需要沉淀的并不只是对话记录，而是一组可以被重新装配、验证和管理的智能资产。
知识与记忆回答"执行任务时依据什么"；Skill 回答"这类事情应该怎样做"；MCP 和工具负责连接真实业务系统；Agent 模板将角色、Skill、工具和配置组合成可复用方案；评测集与评估器则保存企业对"什么叫做好"的定义。
其中，Skill 正逐渐成为企业经验的重要载体。一个 Skill 从编写、生成和打包开始，还需要经历版本管理、安全扫描、分发、权限管理、评估和调优。只有这样，个人总结的方法才能从一个文件，变成可以安装、追溯和持续维护的企业能力。
AgentCore 通过个人、企业和外部市场组成的多层 Catalog 管理这些资产。个人创建的能力可以先自用和测试，经过质量验证后进入企业目录；从外部引入的 Agent、Skill 和 MCP，则需要经过安全与合规审查。进入企业目录的资产，需要登记负责人、版本、权限、质量标准和使用反馈。
这套机制解决了两个问题：好的能力怎样被更多人发现，出现问题时又由谁负责。
更重要的是，资产不是发布以后就不再变化。生产中的轨迹、评估结果和用户反馈会继续回流，推动 Skill、知识、工具配置和 Agent 版本迭代。通过验证的新版本，再重新进入生产环境。
企业真正需要沉淀的，不是更多 Agent，而是经过验证、可以复用的能力。
当一次任务的成功方法能够被复用，一次失败能够变成新的评测样本，Agent 的运行过程才会持续增加企业自身的能力，而不是只增加模型调用量。
构建只是起点，生产化才是分水岭
Agent 的价值最终仍然要回到业务结果。
它有没有达到质量标准？端到端时间有没有缩短？需要多少人工介入和返工？完成一次任务的总成本是多少？这些问题，比企业创建了多少个 Agent 更重要。
AgentCore 所代表的方向，是把构建、运行、协作、资产、评估和治理连接起来，对所有 Agent 和其构建方式保持开放。平台承载任务执行，让知识和经验进入任务，人与多个 Agent 围绕目标协作，生产数据再用于评估和改进。
这个过程不会消除模型的不确定性，也不会让所有业务自动运行。它所做的，是让不确定性能够被看见，让行动受到约束，让结果可以验收，让有效经验可以留下来。
周琦在分享团队"吃自己的狗粮"的实践
AgentCore 所在团队也在"吃自己的狗粮"，基于 AgentCore 重塑前台、中台、后台的协作实践，把沉淀能力产品化、服务化。例如在前台运营中，DataAgent Mamba 承载了运营的经营分析工作，通过多个 Agents 串联了开源需求的收集、分类和评估、修复和 Merge，作为中台协同。后台基建层面，则是在从 SPEC、编码、代码审查、测试、发布，到修复的整个软件交付流程进行智能化提效，打造10倍样板间。（后续我们将逐步分享一些优秀的实践案例）
构建决定 Agent 能不能出现，生产化决定它能不能进入业务、承担结果，并最终留下来。
当企业不再满足于拥有一些 Agent，而是开始建设一套让 Agent 持续交付的运行方式，智能体才真正从一次技术试验，变成企业生产力的一部分。