你不是缺更聪明的 agent，你缺的是断了之后还能继续

如果你最近在做 AI agent、workflow automation，或者任何想把“AI 能替客户继续做事”卖出去的产品，应该会感觉到一个微妙变化：

大家嘴上还在比模型、比工具调用、比 demo 跑得有多顺。

但真正让客户犹豫的，越来越不是“它会不会做”。

而是：

• 任务跑到一半断了怎么办
• 第二天回来还能不能接上
• 中间卡住时谁来接手
• 用户到底能不能看到它现在做到哪一步了

这几天两个信号放在一起看，这个变化已经很明显。

一个是 AWS 在 2026 年 4 月 9 日把 stateful MCP client capabilities 推成 AgentCore Runtime 的正式能力，重点不是模型更强，而是 agent 能在执行中途追问用户、回传进度、保持会话连续性。

另一个是 Financial Times 在 2026 年 4 月 8 日报道，Perplexity 因从 search 转向 AI agents，月收入跳升 50%。

翻成人话就是：

平台已经开始更认真地把“替用户继续推进任务”做成生意。

而很多团队还在卖一次性 demo。

现在最值钱的，不是一次回答，而是持续接手

过去很多 AI 产品的卖法，本质上还是“让客户先看一眼”。

你演示一个流程。

它跑通了。

客户觉得挺厉害。

然后团队就默认，这条路已经足够说明产品价值。

但 agent 一旦从演示走向真实业务，这套逻辑就会立刻变窄。

因为客户买的已经不是“你能不能回答一个问题”。

客户买的是：

• 这件事能不能持续交给你
• 我不在的时候它会不会继续推进
• 中间出了偏差有没有人接
• 下一次回来时它是不是还知道做到哪了

这就是为什么我越来越觉得，很多团队现在不是缺更聪明的 agent。

而是缺一个能被客户感知到的“持续接手能力”。

AWS 这次推出来的，值得看的不是技术名词

很多人看到 stateful MCP、elicitation、progress notification 这类词，第一反应还是工程视角：

哦，又多了几个能力。

但如果你是卖产品的人，更该看到的是背后的购买逻辑。

AWS 这次公开承认了一件事：

stateless 的一次性请求，已经不够支撑真正的 agent 工作流了。

原因很简单。

真实任务不会永远一步做完。

它会：

• 中途需要补充信息
• 运行时间变长
• 需要把进度告诉用户
• 在某个节点等待确认
• 甚至隔一段时间再回来继续

如果这些都不存在，你卖的更像一个带工具的聊天框。

如果这些开始变成默认场景，你卖的才更接近“会持续接手的服务”。

问题在于，很多团队虽然在底层接了更多工具、更多 memory、更多 workflow，但前台产品承诺还停留在第一阶段：

只证明它会做。

没有证明它会继续做。

很多 agent 卖不动，不是因为第一次跑得不够惊艳

很多团队以为，成交卡住，是因为 demo 还不够强。

所以他们第一反应通常是：

• 再接一个更强模型
• 再补一个更复杂的工具链
• 再把 demo 包装得更顺

这些动作当然可能有帮助。

但如果客户真正担心的是连续性，你越卷第一次体验，越可能掩盖真正的问题。

因为客户脑子里会自动往后推一步：

今天这条路能跑。

那明天回来呢？

这个任务今天跑了 40 分钟，卡住以后谁知道它卡在哪？

客户换一个人来接手，这段上下文还能不能保住？

如果结果要人工确认，入口在哪里？

如果系统重启了，这个任务是不是就像没发生过？

这些问题不回答，客户就不会把关键流程真正交给你。

他可能会夸你 demo 很好。

但不会放心开始试点，更不会放心扩大使用。

你真正该重新设计的，是五个承诺

如果你们团队现在就在卖 AI agent，我会先回去重做五个承诺。

1. 断了之后怎么恢复

这是第一性问题。

不要默认“重新跑一次”就算恢复。

客户真正想知道的是：

• 任务是否有明确 checkpoint
• 重进之后从哪里继续
• 什么情况下会强制重开
• 用户要不要自己重新喂一遍上下文

只要这套恢复逻辑还说不清，你就还没在卖持续服务。

2. 进度怎么被看见

长任务最怕黑箱。

不是因为用户没有耐心，而是因为没人知道现在是在“继续执行”，还是已经“静默失败”。

进度展示不只是一个体验细节。

它决定的是客户愿不愿意把更长、更贵、更关键的任务交给你。

所以你至少要能说清：

• 当前在做哪一步
• 哪一步完成了
• 哪一步在等输入
• 哪一步失败了

如果用户看到的只有一个 spinning 状态，信任会掉得非常快。

3. 哪些节点必须人工接手

人工接手不是败笔。

很多时候，它正是你把 agent 从“玩具”做成“可交付服务”的关键。

一条路径里，总会有些节点更适合转人工：

• 需要业务判断
• 涉及对外发送
• 可能带来不可逆动作
• 结果需要最终确认

你越早把这些节点定义清楚，客户越容易信任你。

因为这说明你不是假装全自动，而是真的知道哪里该让人接。

4. 会话边界在哪里

所谓“断了之后还能继续”，不是无限记住一切。

恰恰相反，真正的产品能力，是知道什么该保留，什么该清掉。

客户会越来越在意这些问题：

• 这段上下文会保留多久
• 换一个用户还能不能看到
• 重开任务时哪些历史会带上
• 敏感内容什么时候失效

如果你把“持续接手”偷换成“无限记忆”，很快就会踩到新的信任问题。

5. 销售到底承诺了什么

很多产品真正出事，不是在技术层。

而是在销售话术层。

如果你现在还在把“一次 demo 跑通”包装成：

• 可以持续交付
• 可长期托管
• 默认自动推进
• 出问题也能自恢复

那你卖出去的不是产品价值，而是未来要补的坑。

现在最危险的错觉，是把持续接手当成底层能力问题

很多人会把这个问题收进工程团队：

等我们把状态、记忆、session、runtime 都做完，再说。

我不这么看。

因为客户不会用这些词来表达他的担心。

客户只会说：

• 我昨天那条任务怎么没了
• 为什么今天回来还要重来
• 现在做到哪一步了
• 为什么卡住了没人提醒我
• 出错以后是谁负责

这意味着，“持续接手”不是等底层彻底完工后才对外说的技术能力。

它本身就是产品定义的一部分。

如果你今天还没把这件事定义清楚，就不该继续把自己包装成“可以替客户持续做事”的 agent。

这篇真正想提醒的，不是技术升级，而是卖法要升级

Perplexity 的收入信号说明，平台越来越愿意为“继续推进任务”收费。

AWS 的能力更新说明，基础设施也在朝这个方向补齐。

而 Reddit 上 persistent agents、observability、agentic forgetting 这些讨论一起升温，本质上都在指向同一个现实：

真正开始影响下一轮成交的，不是 agent 第一次有多像人。

而是它像服务一样，能不能持续接住这条活。

所以这周如果你只打算回去优化一个地方，我会建议你别再只补 demo。

先把这五个问题拉出来过一遍：

1. 断了之后从哪里恢复？
2. 用户能不能看到当前进度？
3. 哪些节点必须人工接手？
4. 哪些状态会被保留，哪些会被清掉？
5. 销售现在承诺的，和产品真实能持续做到的，是不是同一回事？

只要这里面有两个以上你们答不清，问题就不是 agent 还不够聪明。

而是你还没准备好卖“持续接手”。

参考信号

• AWS 官方博客在 2026-04-09 发布《Introducing stateful MCP client capabilities on Amazon Bedrock AgentCore Runtime》，新增 elicitation、sampling、progress notification，并明确说明 stateless 模式无法处理中途追问用户、长任务进度更新和跨请求连续性。
• AWS 官方博客同时说明 stateful session 可由独立 microVM 承载，并通过 session ID 保持连续路由，说明“续跑”已经被当成正式产品能力处理。
• Financial Times 在 2026-04-08 报道 Perplexity 月收入因转向 AI agents 跳升 50%，说明市场正在为“继续推进任务”付钱。
• Agent Brief 在 2026-03-27 的 persistent agents / Reddit 讨论汇总里，把 observability、forgetting 和 production data hygiene 一起列为 agent 走向生产时的核心瓶颈。