构建能运行七天的 AI 智能体：五个生产级设计模式

你花几周时间精心调整提示词、优化工具调用、压榨响应延迟。然后你的智能体需要连续运行五天——前面那些努力瞬间变得无关紧要。

真正在生产环境中起作用的工作流，往往无法放在单次对话里完成：处理数千份保险理赔、执行持续一周的销售跟进序列、跨系统对账金融数据。这些任务需要几天，而不是几秒。

当你开始尝试构建这类长期运行的智能体时，会发现一个问题：大多数智能体架构都是无状态的。它们在每次交互时从数据库里重建上下文，却丢失了推理链条、软信号和置信度梯度——那些曾经让智能体之前决策显得合理的依据。

在 Cloud Next 26 大会上，Google Cloud 宣布 Agent Runtime 现已支持最长 7 天的状态保持能力。下面分享五个在 Agent Runtime 上构建长期运行智能体的核心设计模式。这些模式，正是区分“演示级系统”与“生产级系统”的分水岭。

模式一：检查点与恢复

在多日工作流中，最常见的故障模式是上下文丢失。假设你的智能体花了四个小时处理了 200 份文档，然后在处理第 201 份时遇到了一个错误。如果没有检查点机制，你只能从头开始。

Agent Runtime 上的长期运行智能体会在安全的云端沙箱中维护持久化的执行状态。智能体可以完整访问 bash 命令和沙箱文件系统——这意味着你可以将中间结果写入磁盘、维护处理日志、并在失败时恢复。

核心理念：把你的智能体当作一个长期运行的服务器进程，而不是一个请求处理器。就像你构建一个处理百万条记录的数据管道那样：设置检查点、处理部分故障、确保幂等性。

下面是一个文档处理智能体的结构示例，它使用 Google Agent Development Kit 在每批处理完成后设置检查点：

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 份文档一个检查点，在开销和可靠性之间取得平衡。具体多少合适，取决于你每个工作单元的代价有多高。

常见问题：

• 问：检查点应该存哪些信息？
  至少存三个东西：最后处理到的位置、已产生的部分结果、时间戳。如果工作流有分支或状态机，还需要存当前所处的步骤。

• 问：恢复时如何处理已经成功但未保存的部分结果？
  设计上要保证幂等性。即使恢复后重复处理了少数文档，最终结果应该和只处理一次相同。通常通过记录文档唯一 ID 来实现。

模式二：委托审批（人机协同）

每个框架都在宣传“人机协同”。

但实际落地时，大多数实现方式是这样的：把状态序列化成 JSON，发一个 webhook，然后祈祷有人会去查看。问题很快就来了——JSON 序列化会丢失隐式的推理上下文；通知会和几十个其他告警混在一起。当人在几个小时之后响应时，智能体需要反序列化、重建上下文，还要祈祷这期间什么都没变。

长期运行智能体采用了不同的方式。当智能体遇到一个审批关口时，它会原地暂停。完整的执行状态保持不变：推理链条、工作记忆、工具调用历史、待执行动作——全部保留。

这里的关键细节是：第 8 小时到第 32 小时，对智能体来说是死时间，但对人来说是活跃时间。智能体在暂停期间消耗的计算资源为零。而亚秒级的冷启动意味着恢复时几乎没有延迟。

Mission Control 提供了一个收件箱，让这种模式在大规模场景下变得可控。通知被分类为“需要你输入”“错误”和“已完成”。如果你在管理二十个长期运行的智能体，你不需要在 Slack 频道里翻来翻去找哪个智能体需要关注。

常见问题：

• 问：人响应时，智能体如何知道从哪里继续？
  智能体不是“重新加载”状态，而是从暂停的位置恢复。它记得自己当时正在做什么、已经做了哪些推理、正在等待什么信息。这就像你在写一封长邮件时临时离开，回来时光标还在原来的地方。

• 问：如果审批被拒绝，智能体会做什么？
  这取决于你的业务逻辑。通常它会记录拒绝原因、向协调者报告、然后执行备选路径（比如跳过该步骤或终止该工作流）。

模式三：分层记忆上下文

一个运行七天的智能体，光有会话状态是不够的。它需要记住以前会话里的东西、几周前的用户偏好、以及任何单次对话都无法容纳的组织级上下文。

这正是 Memory Bank（记忆库）和 Memory Profiles（记忆档案）协同工作的地方。

Memory Bank（现已对所有人开放）会动态地从对话中生成并整理记忆，按主题归类。Memory Profiles 则提供对特定、高精度细节的低延迟访问。可以把 Memory Bank 理解为长期记忆，Memory Profiles 理解为工作记忆。

但这里有一个大多数开发者在生产环境中才会遇到的陷阱：记忆漂移。

你的智能体的行为不仅受代码和提示词的影响，还受累积经验的影响。如果一个智能体从少数几次非典型的交互中“学会”了一个流程捷径是可接受的，它可能就会开始广泛地应用这个捷径。而且，如果多个智能体读写共享的记忆池，不同工作流之间的数据泄露就成了真实存在的风险。

你不能让智能体不加检查地向向量数据库写入数据。你需要像治理微服务一样治理它们。这正是 Agent Identity（智能体身份）、Agent Registry（智能体注册表）和 Agent Gateway（智能体网关）发挥作用的地方。它们将标准的基础设施概念引入智能体生命周期：

举个例子：如果某个智能体试图将个人身份信息（PII）写入它的长期记忆库，Gateway 会直接阻止这次事务。

从第一天起就把审计能力构建进记忆层。问题不光是“我的智能体在做什么？”而是“我的智能体在记住什么？这些记忆如何改变它的行为？”

常见问题：

• 问：Memory Bank 和 Memory Profiles 有什么区别？
  Memory Bank 是长期、动态、主题化的记忆，适合存储“用户通常喜欢哪种沟通风格”这类信息。Memory Profiles 是短期、高精度、低延迟的记忆，适合存储“当前工单的优先级是 P1”这类信息。两者配合使用。

• 问：如果多个智能体共享同一个 Memory Bank，如何避免数据混淆？
  通过 Agent Identity 和 Agent Gateway 实现隔离。每个智能体有自己的身份，Gateway 会检查该身份是否有权限读写某个 Memory Bank。不同工作流使用不同的 Memory Bank，或者在同一 Bank 中使用命名空间隔离。

模式四：环境处理

并不是每个长期运行的智能体都需要和人交互。有些智能体是环境型的——它们监听事件、处理数据流、在后台自动采取行动，无需任何用户提示。

批处理与事件驱动型智能体可以直接连接到 BigQuery 表和 Pub/Sub 流。

下面是一个具体例子：一个内容审核智能体，在用户生成内容到达时实时处理。

这个智能体可以连续运行数天。它不会等人来问“请审核这段内容”，而是主动处理到达的事件、维护关于趋势和模式的自身状态、仅在必要时才升级给人工。

这里重要的架构决策，又回到了模式三中的治理层。

不要把内容策略硬编码在智能体代码里。把它们定义在 Agent Gateway 中，智能体在运行时执行这些策略。当策略发生变化时，你只需要更新一次 Gateway，所有环境型智能体就会自动遵循新规则。Agent Identity 决定哪个策略适用于哪个智能体，Agent Registry 则追踪哪个版本的智能体正在配合哪套策略集运行。

这种分离之所以重要，是因为环境型智能体会长时间无人监督地运行。如果你把策略硬编码，每次策略变更都需要重新部署每一个智能体。而如果你通过 Gateway 把策略外部化，一次更新，整个集群自动适配。

常见问题：

• 问：环境处理智能体如何知道什么时候该“醒来”工作？
  它不需要“醒来”。它持续订阅一个事件流（比如 Pub/Sub 主题），当新事件到达时，智能体会被自动触发。Agent Runtime 会处理事件到智能体实例的映射。

• 问：这类智能体如何报告错误？
  同样通过 Gateway 和 Registry。错误会被记录到 Mission Control 的“错误”分类中，运营人员可以查看。你也可以配置告警规则，比如“某个智能体在过去一小时内有超过 10% 的事件处理失败”。

模式五：集群编排

最后一个模式是关于将多个长期运行的智能体作为一个协调集群来管理。在生产环境中，你很少只有一个智能体孤军奋战。你通常会有一个协调者智能体，它把子任务委派给各个专家智能体，每个专家智能体独立运行，持续时间各不相同。

考虑一个销售拓展序列的例子：

每个专家智能体都有自己的 Agent Identity（因此只能访问它需要的工具和记忆）、通过 Agent Gateway 实施自己的策略（比如“外联智能体”不能访问本该属于“评分智能体”的财务数据）、以及在 Agent Registry 中有自己的条目（以便你追踪整个集群的版本和执行状态）。

协调者智能体维护全局状态，并处理专家之间的交接。这就是分布式系统中使用了数十年的协调者/工作者模式。新的地方在于，ADK 通过基于图的工作流原生支持这种方式，让你用声明式的方式定义协调逻辑。

把每个专家智能体作为独立单元来管理，带来的操作优势是：你也可以独立地更新它们。

如果你的评分智能体的排序逻辑需要改进，你可以部署新版本，通过 Agent Observability 监控它的表现，只有在结果稳定可靠时才推广它。而且，由于每个智能体在自己的容器中运行（通过“自带容器”支持来满足你现有的 CI/CD 和安全要求），一个专家的不良部署永远不会波及到其他专家。

常见问题：

• 问：协调者智能体本身会成为一个单点故障吗？
  协调者也可以使用检查点模式来保证自身状态的可恢复性。此外，你可以运行多个协调者实例（通过 Agent Registry 进行主备或负载均衡）。协调者只负责任务分发和状态追踪，不执行重计算任务，所以它本身比较轻量。

• 问：如何调试一个跨多个专家的工作流？
  Mission Control 提供了整个集群的执行轨迹视图。你可以看到协调者在什么时间把什么任务交给了哪个专家，该专家返回了什么结果，以及任何报错信息。这种端到端的可观测性是生产级部署的关键。

如何选择合适的模式

这些模式是可以组合使用的。一个合规系统可能会同时使用：

• 检查点与恢复——处理文档批量
• 委托审批——设置审核关卡
• 分层记忆上下文——跨会话的知识保留
• 集群编排——协调多个专家智能体

关键问题在于：你的智能体需要执行的最长连续工作单元是多久？

常见问题（FAQ）

问：长期运行智能体和无状态智能体在成本上有什么不同？
长期运行智能体在暂停期间（比如等待人工审批）几乎不消耗计算资源。Agent Runtime 的亚秒级冷启动意味着你不会为闲置时间付费。只有在智能体实际执行代码、调用工具或进行推理时才会产生计算成本。所以，从成本角度看，长期运行模式可能反而比反复重建上下文更高效。

问：7 天状态保持是硬性上限吗？我可以延长吗？
文件明确提到 Agent Runtime 目前支持最长 7 天。如果你需要更长的周期，通常的做法是将最终状态持久化到外部存储，然后启动一个新的智能体实例来加载该状态。7 天对于绝大多数业务场景（理赔处理、销售序列、对账等）已经足够。

问：我的智能体在运行过程中，如果 Agent Runtime 本身重启了怎么办？
检查点模式就是为了应对这种情况。智能体的状态会持久化保存，Agent Runtime 重启后可以从最后一个检查点恢复。这和你用数据库保存数据处理任务的进度是同一个道理。

问：我可以用自己现有的 CI/CD 和容器基础设施吗？
可以。文件提到 Agent Runtime 支持“Bring Your Own Container”，即你可以使用自己已有的容器镜像、CI/CD 流水线和安全扫描工具，只需符合 Agent Runtime 的接口规范即可。

问：这些模式只适用于 Google Cloud 吗？
文件内容聚焦于 Google Cloud 的 Agent Runtime、ADK 和 Mission Control。但模式本身（检查点、审批、分层记忆、环境处理、集群编排）是通用的架构设计思路。你可以用其他平台或自建系统来实现类似的模式。

问：从哪里可以开始尝试？
长期运行智能体现在可以在 Gemini Enterprise Agent Platform 上使用。你可以用 ADK 构建，部署到 Agent Runtime，通过 Mission Control 进行监控。7 天状态保持、人机协同审批、长期记忆——这三者的结合，是把智能体从“聊天机器人”变成“自主工作者”的关键。

总结

构建能运行数天的 AI 智能体，不是简单地把“无状态”架构打个补丁。它需要一套不同的设计思维：

• 把智能体当作服务器进程，而不是请求处理器（检查点模式）
• 让人和智能体各自在最适合的时间工作（委托审批模式）
• 区分长期记忆和工作记忆，并治理记忆的写入（分层记忆上下文模式）
• 让智能体在后台自主运行，策略外部化（环境处理模式）
• 像管理微服务集群一样管理智能体集群（集群编排模式）

这些模式不是为了炫技，而是为了解决真实的生产问题：上下文丢失、审批等待、记忆漂移、策略变更成本、以及多智能体协作时的隔离与可观测性。

现在，去构建那些能真正为你连续工作好几天的智能体吧。