正在加载，请稍候
托管式智能体云服务在一个季度内被四家厂商推到产品核心。把建设投入与持续运行成本拆成两层账，自建还是托管就有了判断依据。
不少企业的平台组走过同一条路：先花两三个月自己写任务队列、状态存储、沙箱和审批钩子，跑通之后回头看，云厂商已经把这层做成了标准件。2026 年 9 月，这条路上多了一个新路标。
9 月 16 日，阿里的 Qoder Cloud Agents 发布 1.0 版本，定位为 Agent as a Service，把原本需要企业自行搭建的生产级能力收进统一的云端底座。据阿里披露，该平台已支持超过百家大型企业持续调用，月调用量达到千万级。这个产品并非横空出世——5 月 20 日上线，1.0 之前已经跑过一轮真实生产验证。
它不是孤例。过去几个月，国内外厂商的动作密集落在同一层：
几家切入的角度并不一致。Anthropic 侧重运行层，解决 Session、Harness、Sandbox 这类长任务执行问题；阿里这条线多走了一步，除了让智能体跑得稳，还处理同一套能力怎么交付给不同终端用户——统一配置并分发 Template，再通过 Identity 为每个用户挂上各自的资产、权限与凭证。InfoQ 对这次发布的梳理把这条差异讲得比较清楚。
另一个侧面证据来自工程现场。据 AIHOT 9 月 17 日条目，GitHub 一位工程师用智能体在约 14.5 周内把 Copilot 运行时从 TypeScript/Node.js 重写为 83.2 万行生产 Rust，128 个 PR 增量合入主干并持续发布（原始条目）。运行时本身已经复杂到值得投入这种量级的重写，这解释了它为什么会从幕后走到产品台前。
先看一组调查数据。LangChain 今年对 1340 名从业者做了一次调查，89% 的组织给智能体配上了可观测能力；在已经上线智能体的团队里，这个比例达到 94%。同一家机构在 4 月的文章里把 Harness 与 Runtime 分开讲：Harness 围绕模型提供提示词、工具与技能支持，而让任务在生产环境里持续运行，底层还要提供持久化执行、多租户、人工介入、可观测与沙箱。
调度、状态管理、权限隔离、沙箱、监控、失败恢复——这六项在 Demo 阶段几乎不会被讨论，进了生产一项都省不掉。它们不吃模型预算，吃的是工程人力，而且很难靠加班压缩：每多一个并发维度，边界条件就要重新推演一遍。有一份运行时选型的复盘给出的比例很说明问题：成熟框架里 98.4% 的代码是护栏，不是模型。
麦肯锡今年 7 月的判断值得抄在墙上：按 Token 单价已经很难衡量企业真正为生成式 AI 付了多少钱。它列出的成本来源包括长上下文、反复检查与修正、多模型调度，以及执行路径波动带来的不确定性。
落地的含义很直接：同一个需求跑两遍，调用次数和最终账单都可能不同。这也是「不能只算 Token」这句话真正的分量。除了模型调用本身，另外三笔看不见的账单拆得更细，值得在立项阶段就摆到桌面上。
| 成本层 | 包含什么 | 计费特征 |
|---|---|---|
| 建设投入 | 调度、状态、权限、沙箱、监控、失败恢复 | 一次性人力，随并发维度重新推演 |
| 持续运行 | 模型调用、工具服务、执行资源 | 随任务量浮动，与执行路径长度强相关 |
| 重试开销 | 失败重跑、上下文重复装载 | 不产生产出，但计入账单 |
| 维护人力 | 排障、升级、Harness 变更后的回归 | 长期固定，最容易被低估 |
把两层账套进自己的场景，问题会收敛成三个判断。
如果任务形态还需要在多种运行模式之间做取舍，四种运行模式与评测闭环的对比可以先看一遍再定边界。
托管侧给出的确定性也在变。以公开数据为例，开发者最快 10 分钟完成业务系统首次全链路调用，平台可承载十万级并发 Sandbox 并按需拉起与释放。这类指标的价值不在数字本身，而在于它把容量评估从自有采购变成了平台配置项。
反面的案例几乎都长一个样子：团队先从调度和沙箱动手，理由是「这一层最可控」。半年后评审时才发现，托管平台已经覆盖了同一层能力，而自建版本还需要专人维护、跟着上游 Harness 的升级做回归。重复的工程投入还不是最贵的部分，最贵的是那半年里本该用来验证业务价值的时间。
更隐蔽的代价在可观测性。InfoQ 同日的一篇文章讲了具体做法：借助会话追踪与成本控制排查智能体故障，前提是链路数据采集得足够细。自建团队常常先建执行、后补追踪，等到排障时才发现关键字段没埋，只能靠日志猜。
取决于托管层暴露了什么。如果只暴露平台自己的 DSL 和状态存储，退出成本会很高；如果暴露的是 CLI、API 与多语言 SDK，业务代码与运行时的耦合度就低得多。评估时先问一个具体问题：业务代码里有多少行在调用平台私有接口。这个数字基本等于退出成本。
拆成三块：业务侧适配层的重写量、运行时能力的补齐量（调度、状态、沙箱、审批），以及排障链路的重建量。第三块最容易被低估——它不是写代码，而是重新积累一套只有真正运行过才有的经验。
可行，而且是目前最常见的落地形态：自建统一网关管理模型调用、配额与审计，把执行与沙箱交给托管运行时。好处是模型入口握在自己手里，换供应商不必重写业务；代价是多一层链路，排障时要在两套日志之间对时间线。把智能体真正接到办公场景时，移动端落地的三道工程前提和我们遇到的约束基本重合。
如果团队正卡在「Demo 能跑、上线卡住」的阶段，先把运行时的边界画清楚，再决定哪一层自建。我们做过的项目里，判断依据从来不是技术偏好，而是任务量与数据边界这两个约束。想看具体的分层做法与工期拆解，可以翻一下案例库，里面有几个从全自建转向混合架构的完整过程。