生产级 AI Agent 的关键，不是更会聊天，而是能长期保存状态、治理记忆并协同工作。
原文标题：从 Demo 到生产：构建长期运行 AI Agent 的五大设计模式
原文作者：图灵编辑部
冷月清谈：
怜星夜思：
2、文章里说不要把策略硬编码进智能体，你觉得这在实际团队里真的做得到吗？
3、A2A 和 MCP 这种协议会不会成为未来 Agent 生态的“USB-C”？还是又一个昙花一现的标准？
4、长期运行 Agent 听起来很强，但哪些业务场景其实根本没必要上这套复杂架构？
原文内容
大多数智能体架构其实都是无状态的：每次交互都近似从头开始，无法可靠保留执行进度和中间上下文。在这篇文章中，Addy Osmani（Google Cloud 总监）与 Shubham Saboo（Google Cloud 高级 AI 产品经理）深入探讨了一个关键问题：
如何构建真正能够长期运行（Long-Running）的 AI Agent，而不仅仅是一次性完成任务的 Agent。
文章分析了现实生产环境中 Agent 面临的核心挑战，并总结出五种关键架构模式，帮助开发者构建具备持续记忆、状态管理、任务恢复和长期协作能力的 Agent 系统，从而跨越从原型 Demo 到生产级应用之间的“生产落差（Production Gap）”。
为什么大多数 AI 智能体在生产环境中难以落地
开发者们常常花费数周时间，精雕细琢提示词工程、工具调用和响应延迟。但当你的智能体需要连续运行五天时，这些努力都变得微不足道。
现实生产环境中真正重要的流程——比如处理成千上万份保险理赔、执行为期一周的销售流程、跨系统对账财务数据——根本无法在一次对话回合内完成。这些任务以天为单位，而不是几秒钟。可一旦你尝试实现这些需求，就会撞上一堵墙：大多数智能体架构每次交互都要从头重建上下文。它们会丢失推理链条、隐性信号以及支撑先前决策的信心梯度。
这就是“生产落地鸿沟”。演示 Demo 可以用简短、干净的任务掩盖这个问题，但真实系统可没有这种奢侈。
在 Google Cloud Next '26 大会上，我们宣布 Agent Runtime 现已支持最长可维持七天状态的长时间运行智能体。接下来，我们将分享五种经过生产验证的设计模式，帮助你打造真正能经受现实考验的智能体。
模式一：检查点与恢复
多天流程中最常见的失败原因就是上下文丢失。比如，智能体花四小时处理了 200 份文档，结果在第 201 份时出错。如果没有检查点机制，只能从头再来。
解决思路其实很简单，但架构意义重大：把你的智能体当作一个长时间运行的服务进程，而不是简单的请求处理器。就像你设计一个处理百万级数据的流水线一样——要定期保存进度、处理部分失败、确保幂等性。
from google.adk import Agent, ToolContext
class DocumentProcessor(Agent):
"""使用检查点与恢复机制处理大批量文档。"""
async def process_batch(self, docs: list, ctx: ToolContext):
checkpoint = self.load_checkpoint()
start_idx = checkpoint.get("last_processed", 0)
for i, doc in enumerate(docs[start_idx:], start=start_idx):
result = await self.classify_and_extract(doc)
self.results.append(result)
# 每处理50份文档保存一次检查点
if (i + 1) % 50 == 0:
self.save_checkpoint({
"last_processed": i + 1,
"partial_results": self.results,
"timestamp": datetime.now().isoformat()
})
return self.compile_final_report()
注意这里的检查点粒度。每份文档都保存一次，太浪费；只在最后保存，风险又太大。每 50 份文档保存一次，兼顾了持久性和性能。具体数值要根据每个任务的复杂度来调整。
模式二：委托审批（人机协同的正确姿势）
几乎所有智能体框架都宣称支持“人机协同”。但实际落地时，大多数做法不过是：把状态序列化成 JSON，发个 Webhook，指望有人能及时处理。
问题很快就会暴露。JSON 序列化会丢失隐含的推理上下文，通知又和其他几十条告警混在一起。等到人类几个小时后才回复，智能体还得反序列化、重建上下文，并祈祷这期间没有任何变化。
长时间运行的智能体处理方式有所不同。当智能体遇到审批环节时，会原地暂停，完整的执行状态得以保留：推理链、工作记忆、工具调用历史、待执行动作等都不会丢失。等待期间，智能体不会消耗任何算力。恢复时，冷启动只需不到一秒，因此几乎没有延迟损耗。
关键在于时间的计算方式。如果智能体在第 8 小时暂停等待人工审核，而审核者在第 32 小时才回复，这 24 小时对智能体来说是“死时间”，但对人类来说却是有效的工作时间。智能体不会漂移、不会退化，也无需重新初始化，可以无缝衔接到上次中断的地方继续执行。
在大规模场景下——比如你要同时管理二十个长时间运行的智能体——你需要一个统一的收件箱来分类待处理事项。不能靠 Slack 频道，也不能靠邮件线程，而是要有结构化的队列，比如“待你处理”、“出错”、“已完成”等分类。
模式三：分层记忆上下文（以及为什么必须治理它）
一个运行七天的智能体，光有会话状态远远不够。它还需要记住前几次会话的信息、组织上下文（这些内容单靠一次对话无法涵盖），以及几周前用户的偏好。
这正是架构变得有趣的地方——也是大多数团队低估风险的地方。
可以把长期记忆类比为知识库：它会积累智能体在各种交互中学到的所有内容，并按主题进行组织。相比之下，工作记忆则提供对当前所需、准确性极高的具体细节的低延迟访问。这两层记忆需要协同工作，但必须保持区分。
大多数开发者直到上线才会遇到一个问题：记忆漂移。
智能体的行为不仅受代码和提示词影响，还会被其积累的经验所塑造。如果智能体在几次非典型交互中“学会”某个流程捷径是可行的，它可能会开始在更多场景下滥用这个捷径。而且，如果多个智能体同时读写共享记忆池，不同工作流之间的数据泄漏就成了现实风险——这种问题很难发现，更难向合规团队解释。
这就要求治理层不可或缺。不能让智能体随意写入共享记忆库，治理方式要像管理微服务一样严格。具体来说，需做到以下三点：
智能体身份。 每个智能体都需要有加密身份，明确其被授权访问哪些记忆库和工具。可以类比 IAM（身份与访问管理），但对象是智能体。
集中式注册表。 当你有几十个长时间运行的智能体时，必须有一个权威来源，记录哪些智能体在运行、它们使用的提示词和代码版本，以及当前的执行状态。
边界上的策略管控。 在智能体与记忆之间设置治理层，每一次访问请求都要根据组织策略进行评估。如果智能体试图将个人敏感信息（PII）写入长期记忆，这一操作应在发生前被拦截，而不是事后审计。
你需要问自己的问题，不仅是“我的智能体在做什么？”，更要问“我的智能体记住了什么？这些记忆又是如何影响它们行为的？”
模式四：后台常驻处理
并非所有长时间运行的智能体都需要与人类交互。有些智能体是后台常驻型的：它们在后台默默监控事件、处理数据流，并在无需用户干预的情况下自动采取行动。
现实中的智能体网络大致如上图所示。例如，内容审核智能体会从 Pub/Sub 系统中获取新上传内容，并将被标记的内容转交人工审核；数据质量智能体则实时监控 BigQuery 中的新增数据行，发现异常后通过 A2A 机制委托数据工程师处理；客户事件智能体则负责接收工单并实时分类，将账单问题、技术故障、VIP 案例等分别分发给专门的下游智能体。这些智能体无需等待指令，而是持续运行，实时响应事件流。
这里最关键的架构决策，仍然回到模式三的原则：不要把策略硬编码进智能体内部。
应当在治理层定义策略，由智能体在运行时动态执行。当策略发生变化时，只需更新一次，所有环境感知型智能体即可立即应用新规则。这种分离至关重要，因为后台常驻型智能体往往长时间无人监管。如果策略被硬编码，每次变更都需要重新部署所有智能体；而如果策略外部化，只需一次更新，整个智能体集群即可无缝适应，无需停机、无需重部署，也不会出现某个智能体还在执行过时合规规则的风险。
模式五：智能体集群编排
最后一个模式，关注如何将多个长时间运行的智能体作为一个协调有序的集群进行管理。在实际生产环境中，单个智能体独立工作的情况极为罕见。通常会有一个协调智能体负责分解任务，并将子任务分派给各自的专业智能体，每个智能体独立运行，持续时间各不相同。
以销售线索挖掘为例，协调智能体会将整个流程拆分为调研、评分、流程编排、外联、跟进等环节。每个环节由专门的智能体独立负责，拥有各自的身份、工具权限和注册信息。
协调智能体负责维护全局状态，并在各专业智能体之间完成任务交接。这其实就是分布式系统中沿用多年的“协调者 / 工作者”模式。不同的是，现在可以通过基于图的工作流声明式地定义协调逻辑，框架本身会强制执行流程结构，而不再依赖于 LLM 在系统提示中“自觉”遵循流程。
将每个专业智能体视为独立单元的最大优势在于：可以单独升级和维护。如果评分逻辑需要优化，只需部署新版本，监控其表现，只有效果达标才正式替换。即便某个智能体部署失败，也不会影响到其他智能体。
A2A 与 MCP：智能体互操作层
上述五种模式还有一个未完全解决的问题：大多数企业不会从零开发所有所需的智能体。真正的价值在于，不同团队（甚至不同公司、不同编程语言）开发的智能体能够互相发现、协作。
这里有两种开放协议正在成为连接各类智能体的“胶水”。A2A（Agent-to-Agent）协议规范了智能体之间的通信方式；MCP（Model Context Protocol）则统一了智能体与各类工具、数据源的交互接口。两者结合后，意味着用 Python 写的协调器可以把任务交给用 Go 实现的专家智能体，后者又能再委托给用 Java 开发的合规检查智能体，整个过程无需各团队为集成而单独协商接口格式。
所有兼容 A2A 的智能体都会在一个约定的网址上发布一张“卡片”，说明自身的能力、认证要求和调用频率限制。你可以把它理解为专为智能体间通信设计的 OpenAPI 规范，而不是传统的客户端 - 服务器接口。再加上一个中心注册表，其他智能体就能在组织内发现各种能力，无需知道具体的网址。这个注册表就像是你智能体生态系统的服务网格。
上图展示了实际运作的场景。协调器智能体无需知道财务分析智能体的具体 URL，也不用关心它是用 Python 写的，甚至不必了解其认证机制。它只需查询注册表，找到相应的卡片，然后直接连接。当文档处理团队发布了新版 Java 智能体时，只需更新卡片，组织内所有协调器都能自动获得升级。
MCP 协议则解决了另一端的问题：让智能体通过统一协议连接数据库、企业系统和 API。没有 MCP 时，每种数据连接都要单独开发集成代码；有了 MCP 后，无论是 Stripe 连接器还是 BigQuery 连接器，对智能体来说都一样——协议就是接口，后端可以随意切换。
治理在这里同样重要。每个组织都能维护自己的治理边界。你的策略控制层可以规定：哪些数据可以与合作方智能体共享，合作方的响应允许触发哪些操作，以及可以请求哪些信息。跨组织协作通过协议完成，双方各自独立执行自己的安全模型。
多语言、跨团队的协作也正如你所期待的那样。例如，一个客户入职流程可能涉及：由 Python 写的协调器、由安全团队维护的 Go 身份验证智能体、由风控团队负责的 Java 信用评估智能体、由平台团队开发的 Go 账户开通智能体，以及由市场团队维护的 TypeScript 沟通智能体——各团队独立迭代，互不掣肘。
img
如何选择合适的模式
这些模式可以灵活组合。例如，合规系统可能会用“检查点 - 恢复”模式处理文档，用“委托审批”模式把关审核环节，用“分层记忆”模式管理跨会话知识，再用“智能体编排”模式协调各类专家智能体。
关键的判断标准是：你的智能体需要连续执行的最长任务时长是多少？
如果只需几分钟，通常不必用到长时间运行的智能体。如果任务需要持续数小时甚至数天，那么上述这些模式就成了必需品，治理和互操作层也变得不可或缺。
如今还在开发孤立、无状态智能体的公司，一年后大概率都要重构。而那些一开始就考虑持久化、治理和互操作性的团队，每天都在积累优势。
如果你对手搓自己的专属 AI 智能体感兴趣，推荐你学习李博杰的「Agent 实战营」。
490+ 同学已加入，好评连连！
Agent 实战营主讲人：李博杰
Pine AI 联合创始人 & 首席科学家｜中科大少年班 + MSRA 联培计算机博士
-
《图解大模型》《图解 DeepSeek 技术》译者——你看过的那两本“图解 ”系列，就是他翻的
-
华为首批 " 天才少年 " 项目入选；曾任华为 2012 实验室计算机网络与协议实验室副首席专家
-
顶会硬核履历：SIGCOMM / SOSP / NSDI / USENIX ATC / PLDI 多篇论文，ACM 中国优秀博士论文奖、微软学者奖学金
-
现在在 Pine AI 做的事：让 Agent 能像真人一样接打电话、操作电脑——实时语音 / 快慢思考结合 / RL / 知识系统 / Computer Use 全套工程化都已落地
“学界硬底子 + 产业第一线踩坑——这两件事同时在一个人身上，是这门课最大的稀缺资源。市面上要么是只发论文的学者，要么是只做 Demo 的博主，能两边都站住的人，掰着手指都数得过来。
常见问题
什么是长时间运行 AI 智能体？
长时间运行 AI 智能体是一类能够在数小时甚至数天内持续保存执行状态、记忆和工作流程连续性的 AI 系统，而不是每次交互后都重置。
为什么大多数 AI 智能体在实际应用中会失败？
大多数智能体本质上是无状态的。它们在每次交互之间会丢失推理历史、上下文和操作状态，导致多步骤流程和长时间任务难以持续。
什么是 AI 智能体的“检查点 - 恢复”机制？
“检查点 - 恢复”机制允许智能体在执行长流程时保存当前状态，这样即使遇到故障或暂停，也能从中断处继续，无需从头再来。
AI 系统中的 A2A 是什么？
A2A，即 Agent-to-Agent，是一种标准化协议，用于规范不同 AI 智能体之间的通信，使它们能够互相发现并协同工作。
什么是 MCP？
MCP，即模型上下文协议（Model Context Protocol），用于规范 AI 智能体如何接入工具、API、数据库及外部系统。
为什么长时间运行智能体需要治理？
长时间运行的智能体会随着时间积累记忆、权限和操作上下文。治理层负责统一管理身份、内存访问、合规性和策略执行，以保障整个智能体集群的安全与合规。