阿里云的野心，不在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 都不一样，它执行一次任务可能需要跑十几个小时甚至数天，中间还要持续读写文件、调用