换智能体平台要重建什么：运行状态不在导出里

一条采购对账流程在生产里跑得好好的。它被搬到了另一个运行时上，提示词、模型配置和工具清单都带了过去。头 2 天没有异常。第 3 天，一次失败重试的计数没有跟过来，于是流程从头又把已经提交过的 3 张单据提交了一遍。

平台开始把执行环境当成商品卖

9 月 29 日，Manus 发布 2.0，自称这是一次架构重建而不是版本更新。它带来三样东西：一个名为 Cascade 的智能体 harness，一套按项目购买的持久执行环境 Cloud Computer，以及由事件触发而不是按时间表触发的自动化。厂商给了一组效率数字：token 用量减少 23.2%，任务完成时间缩短 28.2%，运行成本降低 32%（InfoWorld）。

这 3 个百分比只能当方向看。原因很具体：没有任务集，就分不清那 28.2% 是省在调用更少，还是省在任务更容易。换句话说，这组数字无法被复现，也无法被证伪。

更值得记下来的是另一句话：执行环境可以单独购买。这意味着一条工作流赖以运行的那台机器，已经成了一个有边界、有生命周期、可以单独计价的资产。凡是有边界的东西，就有归属问题。这就是商品化的含义：机器的所有权需要被写清楚，而且不能只写在供应商的文档里。

Gartner 分析师 Anushree Verma 在同篇报道里的判断是：编排层正在成为更大的差异点，尤其在企业部署里。但它是底层模型的补充，不是替代。最强的系统，是能用的模型配上懂得选择性调用它的运行时。问题是，这句判断没有告诉你换一台机器要付多少代价。

这句话把采购问题挪了个位置。所以我们不再问谁家的模型最好，而要问这条工作流跑在哪台机器上，这台机器归谁。

还有一个连带影响容易被漏掉。harness 换掉之后，同一条流程的评测分数不能直接沿用，因为评测跑的是模型加运行时的组合，不是模型本身。历史分数要按新组合重跑一遍，而这件事在采购时间表里通常没人安排。

同一周还有一条容易跳过的数字：AWS 称 Amazon 内部早期近 90% 的智能体原型从未上线（The Next Web）。从演示走到生产之间那段距离，恰好就是运行状态、凭证和记忆这几样东西，而它们都不会出现在演示里。真正的问题是，这段距离在采购评审里通常没有人负责。

运行状态分 4 层，只有 1 层天然能带走

把运行状态当成一个词来讨论，是这类评估最容易失手的地方。拆开看，它至少有 4 层，而且一层比一层难带走。这 4 层里，供应商最愿意帮你搬的只有第 1 层。

• 任务中间态：重试计数、已经完成的子步骤、等待人工审批时挂起的位置。它决定这条流程能接着往下跑，还是只能从头再来。
• 产物与血缘：哪个产物由哪一次运行生成、当时用的是哪一版指令和哪一版工具。它决定出事之后能不能回溯到具体某一次执行。
• 连接器凭证与授权：哪条凭证能读哪个系统、什么时候过期、谁有权吊销。它决定这套系统能不能被停下来。
• 长期记忆：跨会话累积的事实、偏好与纠正。它决定这个智能体越用越准，还是每次都从零开始。

这 4 层里只有一层天然可导出。提示词和模型配置本来就是文本，复制粘贴就能走。剩下 3 层在实现里通常是一张表里的行、一条凭证记录、一段向量索引。它们不属于配置，属于数据。而数据从来不在导出按钮的义务范围里。

IDC 亚太网络安全服务研究总监 Sakshi Grover 给了一个更严的判据。按她的说法，企业该用 3 个问题评估平台：它能接触哪些系统、它留存什么状态、这个状态多快能在别处恢复。

她还要求企业说清楚 6 样东西分别在哪里被处理与存放：提示词、中间任务状态、产物、日志、备份、连接器凭证，包括模型供应商和其他分包方。然后她点出一句：仅有一个导出按钮，不能证明运行状态可迁移。也就是说，评估对象从产品能力变成了状态归属。对高影响部署，她的建议是 4 条：窄范围短时凭证、外部审计日志、关键动作的审批门、能快速吊销的通道。

状态归属为什么会变成采购问题

自建时代，这 4 层状态都躺在企业自己的库里，谁来读、怎么读都自己说了算。搬上托管平台，等于把这 4 层的物理存放一起交出去。

反过来，从平台搬回自建，或者从 A 平台搬到 B 平台，是没有文档路径的。结果是，团队往往在迁移当天才发现要重做的东西。因为这条路对任何一家厂商都不产生收入。Manus 在发布里把 Cloud Computer 描述成给自动化提供一个永久归宿，而永久这个词是站在厂商那一侧说的。

3 种最常见的缺件

• 重试计数丢失：流程重复写入外部系统，在采购、对账、开票这类场景里直接变成资金差错。
• 凭证到期没人知道：不是读不到，而是某一天开始静默失败，失败的表现看起来像业务数据本来就是空。
• 记忆导出后不可读：文件是导出来了，里面是向量而不是事实，换一个运行时等于把偏好重新养一遍。

这 3 件事都不会在迁移当天暴露。它们通常在两到六周后，以业务异常的形式出现。所以复现检验必须用一条正在跑的流程：只有跑在真实状态上的流程，才会在头几天把缺件抖出来。

放到一条具体流程上会更清楚。假设一条理赔初审流程，记忆里存着这家公司最近三个月对某类单据的处理偏好。迁移之后偏好没了，智能体不再按原来的口径判断，初审通过率一夜之间挪动几个百分点。报表上看不出原因，因为流程本身是跑通的，监控也没有响。状态丢失通常就是这样表现成业务数字的变化，而不是一次可见的故障。

我们的判断：切换成本的第一变量是状态归谁

过去两年，企业问的是换模型要改多少代码。这个问题正在变轻，因为真正会被换掉的东西变了。今天要换的是运行时：换一家平台、换一套 harness、把同一批智能体从自建搬到托管。这时候决定成本的第一变量，是运行状态的归属。

平台把执行环境商品化的同一时刻，也把状态收进了自己的表里。这谈不上阴谋，是架构的必然。要支持持续运行、断点续跑、跨会话记忆，就必须有地方存这些状态，而最省事的存法就是存进自家数据库。

所以验收动作也要跟着换。也就是说，先确定谁持有状态，再谈换不换平台。有效的检验是复现，不是清单。兼容性清单能列出协议、API 和 SDK 版本，却列不出你的第 3 次重试计数存在哪一列。

复现检验的好处是它可证伪。重建之后，第一条流程要么跑通，要么缺什么当场就能看见，没有第 3 种结果。这里必须给反方留位置：如果一条任务无状态、单步、每次从零开始，上面这套基本不成立。它的切换成本接近改一个配置项，把复现检验花在这类任务上是浪费。分层检验只在长跑、带审批门、会写回外部系统的流程上才有意义。

把这笔成本算清楚只需要 3 个数：重建一条流程要多少工时、必须重做的配置项有几个、有多少条数据留在平台里取不出来。前 2 个可以估，第 3 个只能测。复现检验正好落在第 3 个数上。

供应商的 3 种常见回答

问到状态能不能迁走时，通常能收到 3 种回答。回答我们提供 API，意思是从这里开始是你的事。回答导出能力在路线图上，意思是现在没有，而且没有时间承诺。回答我们可以协助迁移最有价值，因为它把问题从产品能力挪成了交付义务。这时候要追问一句：迁移完成的标准是什么，由谁来判定。

平台侧正在做同一个动作

同一天，MongoDB 在投资者日发布 Atlas Agent Engine，把检索、记忆和治理合成一层。官方描述是每一次动作都对应一个真实身份、策略不能被悄悄关掉，并声明以 MCP 与 A2A 这类开放标准为基础（厂商说法，PR 转载）。把状态、记忆与治理托管给本来就存放数据的那一层，正在成为默认做法。原因很简单：数据本来就在那里。

这对买方意味着两件事。第一，评估对象从模型供应商换成了数据平台。它已经握着你的数据，再加上状态与记忆，迁移面比换一次模型大得多。第二，主动权还在买方手里。把可迁移性写进验收条款，比事后索要一个导出按钮有用。导出按钮是产品特性，可迁移性才是合同权利。问题在于，合同里通常不写状态怎么带走。

上线前可以做的 5 件事

1. 挑一条正在跑、带人工审批门和失败重试的流程作为复现对象。不要用演示用例，演示用例不会暴露状态归属。
2. 在目标运行时重建它，只允许使用对方的公开文档，不许提前问原供应商的工程师。卡住的位置和次数就是结论。
3. 把 4 层状态逐层点名：中间态存在哪、产物血缘靠什么关联、凭证由谁签发与吊销、记忆能不能导出成可读格式。
4. 走一遍吊销路径：从决定吊销一条凭证到它实际失效需要多久，谁有权发起，有没有旁路。
5. 把前 4 步的结论写进合同而不是售前承诺：状态导出格式、可选复现、离场支持期，都做成验收条款。

这 5 步的成本是几天。换回来的是对换平台要几个月这个问题的第一手答案，而不是一份别人替你写的承诺。你自己试一次就会知道，缺件清单通常只有几行，但它决定了迁移是两周还是两个月。

做复现检验有 3 个前提，缺一个结论就不可信。环境由你自己控制，不能借供应商的沙箱。用一条真实流程的副本，数据可以脱敏，用例不能换。跑够 14 天，让失败重试、审批挂起和凭证轮换这几件事至少各发生一次。

这份记录本身可以只有一页：4 行对应 4 层状态，3 列写清存在哪、怎么取回、哪天验证过，末尾一行写谁签的字。它不需要好看。它需要的是下一次有人问起运行时，你能直接翻到具体那一格。

边界条件和仍然不确定的地方

无状态单步任务不适用这套检验。凭证已经收进企业自有保管库的实现，第 3 层本来就不在平台内。处在试点期或短期合同阶段时，检验可以缩到第 1 层与第 4 层。

还有一类情况容易被忽略：企业内部已经有两套运行时并存，状态各存一半。这时要做的不是先选一个赢家，而是先确定哪一层是权威来源。权威来源定不下来，复现检验的结果每次都不一样，也就失去了作验收依据的资格。

还有一处要标明不确定性。本文引用的 23.2%、28.2%、32% 是厂商自述，未公布配置与任务集。引用它只为说明执行环境已被商品化，不构成对其效率的背书。

把这次检验放进时间表会更清楚。一次完整的复现通常要 14 天：前 3 天搭环境并接通 2 套外部系统的测试凭证，中间 7 天跑真实流量，最后 4 天核对缺件清单。如果第 7 天还没有出现第一次失败重试，说明这条流程选得不对，换一条更忙的重来。

最费时间的一步通常不是搭环境，而是把 4 层状态一层层问清楚。谁来答、答得对不对，比技术本身更花时间。所以这份清单最好由写代码的人和管凭证的人一起过一遍。你自己在旁边听他们答，缺什么立刻就能听出来。

如果你只剩 5 分钟，问 3 个问题就够。换运行时的时候，你的第 3 次重试计数存在哪里？你的连接器凭证由谁签发、多久轮换一次？你能不能在 10 分钟之内吊销其中一条？3 个问题里有 1 个答不上来，这次验收就没有做完。关键在于，这 3 个答案要能落到具体一行数据上，而不是落在口头承诺上。

来源：InfoWorld，Manus 2.0 与 IDC、Gartner 评论，2026-09-29；The Next Web，OpenAI 与 Amazon Bedrock Managed Agents，2026-09-29；PR 转载，MongoDB Atlas Agent Engine，2026-09-29。