开发者花几周打磨 Prompt 工程、工具调用和响应延迟。但当你的 Agent 需要连续运行五天时，这些都不重要了。
真正重要的生产级工作流（处理数千份保险索赔、运行为期一周的销售序列、跨系统对账财务数据）无法塞进单次对话。它们需要天，不是秒。
一旦尝试构建这类长周期 Agent，就会意识到大多数 Agent 架构是无状态的。每次交互从数据库重建上下文，丢失推理链、软信号和让 Agent 之前决策有意义的置信度梯度。
Google Cloud 在 Cloud Next 26 上宣布 Agent Runtime 支持最长 7 天状态持久化，同时分享了 5 个生产级长周期 Agent 设计模式。
模式一：Checkpoint-and-Resume
多日工作流最常见的失败模式是上下文丢失。Agent 处理了 200 份文档，四小时后第 201 份出错了——没有 checkpoint，就从头开始。
长周期 Agent 在安全云沙箱中维护持久化执行状态，可以写中间结果到磁盘、维护处理日志、从故障恢复。
把 Agent 当作长期运行的服务器进程，而不是请求处理器。构建方式类似数据管道：checkpoint 进度、处理部分失败、确保幂等性。
关键在于 checkpoint 粒度：不是每份文档后都 checkpoint（浪费），也不是只在最后（危险）。每 50 份文档一次 checkpoint 在持久性和开销之间取得平衡。
模式二：Delegated Approval
大多数实现号称"人在回路"，实际上是把状态序列化到 JSON、发 webhook、等人来看。问题在于：JSON 序列化丢失隐式推理上下文，通知和大量告警竞争，人回复时 Agent 要反序列化、重建上下文、祈祷没变化。
长周期 Agent 处理方式不同：Agent 到达审批门时原地暂停，完整执行状态保持完整——推理链、工作内存、工具调用历史、待处理操作。等待期间 Agent 消耗零算力。恢复时亚秒级冷启动，零延迟惩罚。
Mission Control 提供可扩展的收件箱：通知分类为"需要你的输入"、"错误"、"已完成"。同时管理 20 个长周期 Agent 时，不需要在 Slack 频道里追踪哪个需要关注。
模式三：Memory-Layered Context
7 天 Agent 需要的不只是 session 状态。它需要记住前几个 session 的事情、几周前的用户偏好、以及任何单个对话都无法包含的组织上下文。
Memory Bank（现已向所有人开放）从对话中动态生成和维护记忆，按主题组织。Memory Profiles 增加对特定高精度详情的低延迟访问。Memory Bank 是长期记忆，Memory Profiles 是工作记忆。
但大多数开发者没预料到的问题是记忆漂移（memory drift）：Agent 的行为不仅由代码和 Prompt 塑造，还由积累的经验塑造。如果 Agent 从几次非典型交互中学到某个程序化捷径是可接受的，它可能开始广泛使用它。如果多个 Agent 读写共享内存池，不同工作流之间的数据泄露成为真实风险。
不能让 Agent 随意向向量数据库写入。需要像治理微服务一样治理它们。Agent Identity、Agent Registry、Agent Gateway 把标准基础设施概念引入 Agent 生命周期：
- Agent Identity：为 Agent 提供密码学身份，决定它能访问哪些 Memory Bank 和工具
- Agent Registry：当有数十个长周期 Agent 时，集中追踪哪些 Agent 是活跃的、运行哪个版本的 Prompt 和代码、当前执行状态是什么
- Agent Gateway：在 Agent 与其记忆和工具之间评估请求，对抗组织策略
模式四：Batch and Event-Driven Ambient Agents
并非每个长周期 Agent 都与人类交互。有些是 ambient 的——它们监视事件、处理数据流、在后台采取行动，无需任何用户提示。
这类 Agent 直接连接 BigQuery 表和 Pub/Sub 流。例如：内容审核 Agent 持续处理用户生成的内容，维护关于趋势和模式的自身状态，只在必要时升级。
关键架构决策：不要把内容策略硬编码到 Agent 里。在 Agent Gateway 中定义策略，Agent 在运行时执行。当策略变化时，更新 Gateway 一次，每个 ambient Agent 都获取新规则。通过 Agent Identity 确定哪些策略适用于哪个 Agent，Registry 追踪哪个版本的 Agent 在运行哪套策略。
ambient Agent 在无人监督下长期运行。如果硬编码策略，每次策略变更都需要重新部署每个 Agent。通过 Gateway 外部化策略后，更新一次，fleet 自动适应。
模式五：Fleet Orchestration
生产中很少有单个 Agent 独立工作。通常是一个协调者 Agent 把子任务委托给专家 Agent，每个专家独立运行不同持续时间。
每个专家有自身的 Agent Identity（只能访问其需要的工具和记忆）、通过 Agent Gateway 执行自身策略（外联 Agent 无法访问财务数据）、在 Agent Registry 中有自身条目（可以追踪版本和执行状态）。
协调者维护全局状态并处理专家之间的交接。这与分布式系统中使用了数十年的协调者/工作者模式相同。ADK 原生地用基于图形的工作流处理这个问题，用声明方式定义协调逻辑。
把每个专家当作独立单位也能独立更新。如果 Scoring Agent 的排序逻辑需要改进，可以部署新版本，通过 Agent Observability 监控其性能，只在结果站得住脚时才晋升。由于每个 Agent 运行在独立容器中（支持 Bring Your Own Container 以满足现有 CI/CD 和安全需求），一个专家的坏部署永远不会级联到其他专家。
关键问题：你的 Agent 需要执行的最长不间断工作单元是什么？如果是分钟级，可能不需要长周期 Agent。如果是小时级或天级，这些模式就是起点。
这些模式可以组合。合规系统可能同时使用 Checkpoint-and-Resume 处理文档处理、Delegated Approval 处理审查门、Memory-Layered Context 处理跨 session 知识、Fleet Orchestration 协调专家。