阿里云的野心，不在 Agent Builder
最近一年，几家云厂商的动作相当整齐。今年 8 月，阿里云将 Agent 相关的服务能力，升级成为 All In One 企业级 Agent 全栈服务平台——Agent Studio，并正式上线阿里云百炼；在 6 月的 Microsoft Build 上，Microsoft Foundry 把重点明显往生产环节推了一步，Hosted Agents、Toolboxes、Memory 等能力被陆续补进平台；4 月，Google Cloud 推出 Gemini Enterprise Agent Platform，把 Build、Scale、Govern、Optimize 塞进同一套平台；去年 10 月，AWS 的 Bedrock AgentCore 把 Runtime、Memory、Gateway 等能力拆成一组可组合的服务，目的就是让开发者不用再为每个 Agent 重新搭一遍运行底座。
一些具备足够工程能力的大型公司，也在做类似的事情。今年 7 月，美国最大的外卖配送服务平台 DoorDash 将 Memory、模型访问、Tracing 等通用能力抽象成共享的基础设施，并专门搭建了一层 Agent Gateway，把 Agent 调用内部工具时的身份、权限、凭证、限流和审计统一收到了一个地方。
当大众的注意力普遍停留在 Agent 又能完成什么任务、又出现了哪些爆款应用时，鲜少有人注意到，越来越多的公司开始把大量工程精力，花在一些听上去并不那么 AI 的事情上。
原因很简单。大家撞上的都是同样的问题：Agent 变多、任务变长、调用链变复杂之后，过去那套基础设施的组织方式，开始不太够用了。
更有意思的是，连做模型的公司，自己也没能绕开这个“坑”。今年 4 月，Anthropic 罕见地复盘了一次 Agent 基础设施的“返工”：最初为了简单，它把 Session、Agent Harness 和 Sandbox 塞进同一个 Container，真正跑起来后，却发现故障隔离、状态保存和网络扩展都成了问题，最后只好把三者重新拆开。
这次返工多少说明了一件事：模型做得再好，Agent 真正跑起来之后，该补的工程课一门也少不了。但问题是，每家公司都需要自己把这套基础设施再造一遍吗？
真正的瓶颈，在模型之外
当我们把视角拉向 Agent 执行一项具体任务时，就会发现，真正麻烦的事情往往发生在模型之外。
今年 7 月，麦肯锡公布了一项 Enterprise AI FinOps 调研。当企业从零散的 AI 用例走向更大范围的部署，整体 AI 支出接近增长到原来的四倍；93% 的受访组织表示，AI 支出已经超过预算。波士顿咨询在今年 6 月甚至专门讨论了 Agentic AI 的成本问题。它把成本拆成了两类：一类是一次性的建设成本，包括云接入、网络连接等；另一类是持续运行的成本，这部分成本除了模型调用，还会受到 Agent 的编排方式、工具调用频率、监控强度和系统集成方式影响。
显然，Agent 用得越深，企业账单越难简单地用“调用了多少 Token”解释清楚，计算、存储、数据接入、工具服务、运行时和运维治理都在算钱，并且这些投入中的相当一部分很可能是纯投入，很难直接创造业务差异。
这也是当下让很多企业十分头疼的一道难题：做 Agent，企业到底还需要自己造多少东西？目前来看，业内围绕这个问题大致出现了三种探索路径。
第一种是完全自建，企业自己搭 Agent 平台。典型的就是前文提到的 DoorDash，它在今年 7 月公开的技术文章中，专门拆解了 Ask DoorDash 背后的平台：Restaurant、Grocery、Reservations 等业务 Agent 仍由各团队自己负责，但 Session State、Memory、Artifacts、模型访问、Tracing、Evaluation 和 Rollout Controls 这些每个 Agent 都会重复碰到的能力，被统一放到了平台层。
这套工程的重点在于，它尽可能把 Agent 之间重复的那部分拿掉。DoorDash 的判断是，只有当多个业务都需要同一项能力，并且各做一套会带来可靠性或运维问题时，才值得把它做成公共基础设施。 最终的效果也比较明显：Reservations Agent 复用 Restaurant 和 Grocery 的生产链路，一周就成功上线，速度提升了 10 倍；每个新 Agent 采用统一的 Tracing 能力，也能节省近一个月的可观测性建设工作。
不过，DoorDash 没有披露这套平台究竟花了多少钱、投入了多少人力和时间，但平台本身就是一个需要持续建设的产品。这条路径对 DoorDash 能够成立，很大程度上是因为它有足够多的 Agent，也有足够强的工程团队。但对更多公司来说，为了做好 Agent，先养一支团队做 Agent Infra，并不是一笔轻松的账。所以更多公司倾向于选择第二种路径：先用开发框架把 Agent 搭起来。
近几年，LangChain、LangGraph、微软 AutoGen、CrewAI 等一批框架先后出现，把很多原本需要开发者手写的逻辑，变成了更容易复用的组件，也降低了企业搭 Agent 的门槛。美国网约车平台 Lyft 此前公布的客服 Agent 搭建案例提到，它用 LangGraph 来编排多个专业 Agent，把过去大约需要半年开发的 Agent，压缩到了几周。
但开发框架目前能解决的，主要还是开发 Agent 过程中最先碰到的问题，Agent 跑起来之后的问题，仍是一重山。
这也是为什么，最近一年很多云厂商、企业软件平台、数据平台，甚至是模型公司，都开始趋向第三条路径：企业级 Agent 平台。除了前文提到的 AWS、Google 和 Microsoft，Salesforce 推出了 Agentforce 360，把数据、业务流程和 Agent 放进统一平台；Snowflake 也进一步扩展 Cortex Agents，开始强调 Build、Managed Runtime、MCP 接入、代码执行等能力。
在国内，这条路线也开始变得清晰，典型的就是阿里云。在 8 月 14 日的阿里云飞天发布时刻上，全新发布的 Agent Studio，试图解决的就是将原本零散的各项能力，收敛成一套围绕 Agent 的服务层，让企业能够一站式搞定 Agent 开发，拖拽就能搭 Agent。
但更值得讨论的，是对企业来说，原本需要在每个 Agent 项目里重复做的工程工作和琐碎的事，有多少可以不用自己做了？Agent Studio，正好提供了一个观察切面。
Agent Studio 已上线阿里云百炼，体验链接：agent.console.aliyun.com
Agent Studio 替企业接管了哪些“脏活”？
Agent 真正开始干活后，企业操心的地方明显变多了。
将一个 Agent 从“搭出来”到“真正干活”，整条链路拆开后会发现，运行只是最基本的能力。但并不意味着这事简单。
Agent 和传统应用，以及 ChatBot 都不一样，它执行一次任务可能需要跑十几个小时甚至数天，中间还要持续读写文件、调用工具，往往是一个有状态的服务。Anthropic 今年 4 月做的那次重构，把 Session、Agent Harness 和 Sandbox 拆开，解决的就是让状态不再跟着某一个执行容器共存亡。
到云平台这里，同一类问题已经变成可以直接调用的服务了。Agent Studio 里的 Managed Agent，本质上就是一套托管式的 Agent Runtime，开发者只需要定义 Agent 做什么，剩下的运行、隔离、状态与凭据这些琐事都可以交给 Managed Agent。
帮助企业省掉的一整套工程，效果最终都会落到业务结果上：同样的人力，可以处理更多任务，交付速度更快，结果也更稳定。
以企业保单条款审查为例，过去一份复杂保单往往需要核保人员自己完成解析、条款对齐、风险定级和合规检查。封装成 Managed Agent 后，这套流程可以在云端连续执行，人只需要处理最后需要确认的关键项即可。根据阿里云披露的数据，一份审查由原来的三四个小时缩短到约 15 分钟，效率提升十倍以上，核保员每天能够处理的保单量也翻了好几倍，一份保单的成本只有 0.12 元。
“Managed Agent 其实就是专门为那种要跑很久、步骤很多的复杂任务而生，让业务 Agent 从只会聊变成真正能干活。”Managed Agent 产品负责人提到，Managed Agent 背后有五层能力：最底层是运行时底座，把会话状态、沙箱、工具执行、事件记录以及 Agent Harness 一并托管起来，支持长任务中断后继续执行；往上是上下文管理，让文件、代码仓库和跨会话记忆能够被持续复用；再往上是工具扩展，通过 MCP 和 Skills 接入外部系统，并把成熟流程封装成可复用能力；安全层负责沙箱隔离和密钥托管；最上层则是可观测与集成，记录 Agent 的执行和工具调用过程，并通过 API、Deployment 等方式接入业务系统。
把这五层能力放在一起看就会发现，Agent 长任务运行中最麻烦的一批底层工作，已经可以交给 Managed Agent 托管。但这只是第一步，Agent 跑起来之后，还得解决怎么接工具。
MCP 把不同工具接入 Agent 的方式标准化了一部分，但并没有完全消灭接入成本。每接一个 MCP 服务，开发者往往还得单独注册账户、申请 API Key、处理鉴权，再分别管理账单。服务一多，原本省下来的开发工作，很容易又变成新的运维负担。
这也是为什么，Agent Studio 这次升级的 One Key Service 体系，能够迅速在社区内引发讨论。它试图实现真正的“One Key All Server”，用统一的 API Key，就能把原来 N 条认证链路压成一条。
据阿里云透露，首批 One Key MCP 接入了 14 家云市场合作伙伴，覆盖电商、地理信息、金融、法律、产业研究和物流等领域；接下来将有接近 50 家 MCP 生态服务商进入 One Key Service 体系；后续支持 A2A 协议的 Agent Studio 相关服务，也会逐步纳入这套体系。
如果说 One Key MCP 解决的是“连得上”，那重新设计后的 Skill 体系，解决的就是“怎么用得更好”。Agent Studio 这次把 Skill 分成广场严选、服务商直供和用户自定义三层：通用能力可以直接装，行业服务商可以把 MCP 连同 Prompt、调用示例和最佳实践一起封装，企业也可以把自己的工具、数据和流程沉淀成私有 Skill。
当 Agent 能跑起来，也拿到了工具，面向复杂业务时，还得知道“现在缺什么信息”，以及“过去已经知道什么”。一次搜索显然不够，这也是传统 RAG 在复杂任务里容易吃力的地方。Agent Studio 这次升级的 Agentic Search 能力，解决思路是让 Agent 能像专家一样，持续搜索、交叉验证信息，并根据任务动态调整检索⽅向。
具体来说，它会先理解意图、拆分子问题，再分别去对应知识库检索；如果中途没有找到足够的信息，还会改写 Query、更换检索策略或重试检索工具，沿着已有结果继续往下搜。除了语义搜索，背后还提供章节浏览、章节精读、页面浏览等不同的检索方式。
这条路，阿里云其实已经铺了一段时间。今年 7 月，阿里云推出企业级 Agentic RAG 服务 Knowledge Studio，提供多模态搜索回答、Agentic Search、多库混合检索问答等能力，支持 15 个知识库联合检索。为了提高 Agent 长期记忆能力，阿里云在今年 4 月还上线了记忆库，内置“提取 - 存储 - 检索 - 注入”四大模块，用户每次与 Agent 对话结束后，系统可以按照规则提取关键信息、保存下来，在后续对话中再召回。到了这次 Agent Studio 发布，记忆能力进一步被组织成 Memory Studio，并被拆成观察记忆、用户记忆和技能记忆三类。观察记忆回答的是发生过什么，用户记忆回答的是“你是谁”，技能记忆回答的是“这件事过去是怎么做的”。
把 Agentic Search 和 Memory Studio 放在一起看，逻辑就比较清楚了：一个负责回答现在缺什么，一个负责回答过去知道什么。这样一来，Agent 在面对复杂任务时，既能根据当前问题主动搜索，补齐信息，也能把过去的经验和状态接着用，不必每次都从零开始。
做到这里，Agent 怎么跑、怎么调用工具、怎么找信息、怎么记住过去，几块关键能力基本都被 Agent Studio 串起来了。但阿里云还想再往前走一步：想用一个入口，把阿里云 Agent 的全栈能力变成人人可以亲自上手的样板。Agent Studio Playground，就是阿里云这次给出的最后一块拼图。
据介绍，Agent Studio Playground 把 Flow Agent、Managed Agent、RAG、Memory、MCP 和 Skill 等能力放进统一的体验中心，并且预置了场景模板。开发者可以先直接跑一个现成场景，再看背后用了哪些能力，也可以通过 Vibe Builder，用自然语言生成工作流和 Agent。
明面上看或许只是体验层的变化，内里其实是换了一种组织云服务的方式。过去，开发者需要自己选择、接入、组合各项云服务。到了 Agent Studio，这些能力开始围绕具体任务被提前组合起来，变成 Agent 可以直接调用的服务。当越来越多的服务开始以这种方式被 Agent 消费，Agent 和云之间的关系，似乎也变得不一样了。
Agent 开始成为云服务的新入口？
过去，云服务的消费者主要是人。现在，多了 Agent。
这可能会改变云厂商看待 Agent 的方式。Token 消耗当然仍然重要，但一笔模型调用已经不是全部，而是向更长的一条链路延伸：Agent 完成一次任务时，会经过谁的平台、调用谁的服务，又把状态和数据沉淀在哪套生态里。
但现在就断言 Agent 会成为云服务的主要入口，或许还太早。当下还有很多未竟之题，比如可靠性。微软今年在讨论 Agent 治理时提到，企业已经开始规模化部署 Agent，但“信任”并没有同步跟上：一方面，Agent 的行为会随着上下文、工具和权限变化，很难靠一次测试判断它上线后会不会一直做对；另一方面，安全和运行控制往往散落在 Prompt、代码、Gateway 和不同框架里，一旦链路拉长，出了问题也很难快速定位。
此外，生态标准也是一道没有完全解开的题。MCP、A2A、Skill 正在降低不同 Agent、工具和服务之间的连接成本，协议和格式打通了，但不同平台在身份、权限、运行时和记忆上的差异仍然存在，真正做到跨平台协作，还有一段路要走。
这次 Agent Studio 的全新发布，或许只是对这些问题给出了一版现阶段的答案：把那些企业反复要做、又很难形成业务差异的工程工作，尽可能收进平台。这个答案是否成立，最终可能取决于一个更简单的问题：企业愿意把多少东西，交给平台替自己做？
本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：凌敏，36氪经授权发布。