作者 | 凌敏

最近一年，几家云厂商的动作相当整齐。今年 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 的全新发布，或许只是对这些问题给出了一版现阶段的答案：把那些企业反复要做、又很难形成业务差异的工程工作，尽可能收进平台。这个答案是否成立，最终可能取决于一个更简单的问题：企业愿意把多少东西，交给平台替自己做？