【Google ADK】 深度剖析构建可暂停、恢复且永不丢失上下文的长时运行 AI Agent写在前面Google 官方博客最近发布了一篇重量级文章——“Build Long-running AI agents that pause, resume, and never lose context with ADK”。它提出了一个极其尖锐的问题无状态聊天机器人无法管理跨天/跨周的企业工作流。HR 入职流程可能持续两周中间需要等待签名、审批、硬件配送——Agent 如何在等待三天后精确恢复而不是忘记进度或幻觉已完成的步骤ADKAgent Development Kit给出的答案是三个核心设计模式持久状态机、检查点-恢复、事件驱动空闲。今天我们深入拆解这篇文章的每一个核心设计决策。 文章目录 一、无状态 Agent 的三种失败模式️ 二、持久状态机从对话历史到显式状态 三、检查点-恢复与事件驱动空闲 四、多智能体委托与生产化 一、无状态 Agent 的三种失败模式1.1 为什么更大的上下文窗口不是答案Google ADK 文章开篇就给出了一个明确的判断“The fix isn’t a bigger context window. It’s a fundamentally different architecture.”修复方案不是更大的上下文窗口而是根本不同的架构。这个判断基于对无状态 Agent 三种失败模式的深入分析失败模式一Prompt 上下文污染。标准无状态模式将每条用户消息和模型响应追加到不断增长的对话历史中然后将整个历史喂给下一次 LLM 调用。在五分钟的 QA 会话中这没问题但在两周的入职流程中对话历史会充满无关闲聊、过时的工具输出和重复的指令。模型开始混淆当前处于哪个步骤——它可能认为文档已经签署了但实际上还在等待签名。失败模式二Token 成本爆炸。每次推理调用都重放完整的两周对话历史会快速消耗 Token 预算。一次入职运行可能产生数千轮对话——其中大部分与当前决策无关。在 GPT-4 级别模型上这意味着每次调用的成本随时间线性增长而推理质量却在下降。失败模式三空闲期推理幻觉。当 Agent 暂停三天等待文档签名然后带着大量上下文恢复时模型经常幻觉出从未发生的中间步骤。它记得已经获得了尚未给出的批准或者跳过它认为已经完成的步骤。这不是模型能力问题——而是架构问题用对话历史作为状态的代理在长时间间隔后必然产生幻觉。1.2 根本原因对话历史 ≠ 状态三种失败模式的根本原因相同对话历史不是状态。对话历史是线性的、冗余的、无结构的——它记录了说了什么但不记录到了哪一步。一个入职流程有明确的步骤顺序欢迎→签文档→IT配置→硬件→完成但对话历史中这些步骤的信息散落在数百条消息中模型必须从中推断当前进度——这就是幻觉的根源。1.3 ADK 的解法架构层面的范式转变ADK 的解法不是更好的 Prompt或更大的窗口而是三个架构层面的范式转变问题传统方案ADK 方案状态存储对话历史隐式显式状态机持久化空闲处理轮询/阻塞线程事件驱动休眠Webhook唤醒崩溃恢复从头重跑从检查点恢复️ 二、持久状态机从对话历史到显式状态2.1 定义状态 SchemaADK 的第一个核心设计是显式状态机。不再依赖对话历史推断进度而是定义一个明确的状态 Schema告诉 Agent 它在工作流中的精确位置# app/state_schema.pyclassOnboardingStep:STARTSTARTWELCOME_SENTWELCOME_SENTDOCUMENTS_SIGNEDDOCUMENTS_SIGNEDIT_PROVISIONEDIT_PROVISIONEDHARDWARE_DELIVEREDHARDWARE_DELIVEREDCOMPLETEDCOMPLETED六个状态零歧义。Agent 无法跳步或幻觉进度因为状态机强制执行步骤顺序。current_step存储在session_state中不在对话历史中——这意味着即使对话历史被截断状态也不会丢失。2.2 将状态注入 System PromptAgent 的 System Prompt 直接从 session_state 变量读取当前位置——而不是重放旧消息instructionYou are an HR Onboarding Coordinator. Current Step: {current_step} New Hire Details: {new_hire_details} Pending Signals: {pending_signals} 1. If current_step is START: Invoke send_welcome_packet. 2. If current_step is WELCOME_SENT: Wait for document signature. 3. If current_step is DOCUMENTS_SIGNED: Delegate to it_agent. 4. If current_step is IT_PROVISIONED: Check hardware delivery. 5. If current_step is HARDWARE_DELIVERED: Send day-one schedule. 6. If current_step is COMPLETED: Confirm onboarding is done. Always stay grounded in your tools and current state. Do not skip steps.关键设计{current_step}、{new_hire_details}、{pending_signals}是 Python 格式化占位符——每次 Agent 运行时这些占位符会被 session_state 中的实际值替换。模型始终看到工作流的精确状态无需猜测或翻阅历史消息。2.3 工具推进状态机每个工具函数通过 ADK 的ToolContext.state原子地更新检查点defsend_welcome_packet(name:str,email:str,start_date:str,tool_context:ToolContext)-dict:statetool_context.state state[new_hire_details]{name:name,email:email,start_date:start_date}state[current_step]OnboardingStep.WELCOME_SENT state[pending_signals][document_signed]return{status:success,message:fWelcome packet sent to{name}.}每次工具调用都创建一个自动检查点。如果容器在send_welcome_packet执行后立即崩溃状态已经被写入。当 Agent 重启时它读取current_step WELCOME_SENT并从断点继续——不需要从头重跑。2.4 初始化回调ADK 提供before_agent_callback机制确保状态机键始终被初始化asyncdefinitialize_onboarding_state(callback_context:CallbackContext)-None:statecallback_context.stateifcurrent_stepnotinstate:state[current_step]OnboardingStep.STARTifnew_hire_detailsnotinstate:state[new_hire_details]{}ifpending_signalsnotinstate:state[pending_signals][]这个回调在每次 Agent 运行之前执行确保所有状态键都有默认值——防止因缺失键导致的运行时错误。 三、检查点-恢复与事件驱动空闲3.1 持久化 Session从内存到 SQLite/Cloud SQL状态机只有在底层 Session 存储能存活重启时才是持久的。在容器化环境如 Cloud Run中容器会冷启动、缩容到零、意外重启。如果 Session 存在于易失性内存中每个进行中的入职流程都会丢失。ADK 的解法是DatabaseSessionService——用 SQLite本地开发或 Cloud SQL生产环境替代内存 Sessionfromgoogle.adk.sessions.database_session_serviceimport(DatabaseSessionService)session_serviceDatabaseSessionService(db_urlsqlite:///./onboarding_sessions.db)切换只需改一行配置——从InMemorySessionService到DatabaseSessionService。Agent 代码不需要任何修改。这意味着同一个 Agent 可以在本地用 SQLite 开发在生产环境用 Cloud SQL 部署——零代码变更。3.2 事件驱动空闲Agent 真正休眠传统 Agent 在等待外部信号时要么阻塞线程浪费资源要么轮询浪费 Token。ADK 的方案是事件驱动空闲——Agent 在等待时真正休眠零资源消耗外部 Webhook 触发时通过state_delta原子更新状态并唤醒。暂停阶段当 Agent 执行完send_welcome_packet后状态变为WELCOME_SENTpending_signals设为[document_signed]。此时 Agent 不再运行——它休眠了。没有线程阻塞没有轮询循环没有 Token 消耗。唤醒阶段当外部系统如 DocuSign通过 Webhook 通知文档已签署时OnboardingResumeHandler水化持久化的 Session转换状态机并使用runner.run_async和state_delta唤醒 AgentclassOnboardingResumeHandler:def__init__(self,runner:Runner):self.runnerrunnerasyncdefreceive_signed_documents_callback(self,user_id:str,session_id:str)-None:asyncforeventinself.runner.run_async(user_iduser_id,session_idsession_id,new_messagetypes.Content(roleuser,parts[types.Part.from_text(textResume onboarding: Contract signed.)]),state_delta{current_step:OnboardingStep.DOCUMENTS_SIGNED,pending_signals:[],},):logger.info(fWake-up event:{event})3.3 state_deltaADK 的魔法按钮state_delta是 ADK 恢复机制的关键——它在 Agent 的下一次推理调用之前原子地应用状态转换。这意味着模型看到的 System Prompt 中{current_step}已经是新值DOCUMENTS_SIGNED不需要重放历史来推断当前步骤状态转换和推理调用是原子操作不会出现中间状态这就是为什么 ADK Agent “永不丢失上下文”——不是因为上下文窗口大而是因为状态根本不在上下文里而在持久化存储里。上下文窗口只是当前步骤的描述而不是完整历史的重放。 四、多智能体委托与生产化4.1 协调者-子 Agent 架构ADK 不推荐把所有逻辑塞进一个单体 Agent。相反它采用协调者-子 Agent 委托模式——主协调者管理状态机和流程编排子 Agent 专注特定领域的执行it_agentAgent(nameit_agent,modelGemini(modelgemini-3.1-flash-lite),instructionYou are an IT Provisioning Agent. Provision corporate software accounts for the new hire. Current Step: {current_step} New Hire Details: {new_hire_details} 1. Collect the desired corporate username prefix. 2. Invoke provision_software_accounts. 3. After provisioning, transfer control back.,tools[provision_software_accounts],)root_agentAgent(namehr_onboarding_coordinator,modelGemini(modelgemini-3.1-flash-lite),instructioninstruction,tools[send_welcome_packet,check_hardware_delivery,send_day_one_schedule],sub_agents[it_agent],before_agent_callbackinitialize_onboarding_state,)当协调者到达DOCUMENTS_SIGNED步骤时它将执行权转移给it_agent。子 Agent 独立处理账号配置更新共享状态为IT_PROVISIONED然后交还控制权。每个 Agent 有聚焦的 Prompt 和狭窄的工具集——这减少了幻觉提高了可靠性。4.2 三大设计模式总结ADK 长时运行 Agent 的三大设计模式模式一持久状态机。显式定义工作流步骤状态从session_state读取不从对话历史推断。状态机强制步骤顺序Agent 无法跳步或幻觉进度。模式二检查点-恢复。每次工具调用自动检查点。崩溃后从最近检查点恢复。Session 持久化到 SQLite/Cloud SQL容器缩容到零也不丢状态。模式三事件驱动空闲。空闲时 Agent 真正休眠零资源消耗。外部 Webhook 触发时state_delta原子更新状态并唤醒。不轮询、不阻塞。4.3 生产部署ADK 支持三种部署模式本地开发SQLite 持久化 FastAPI 本地服务 agents-cli dev。适合开发和调试。Cloud RunCloud SQL 持久化 自动缩容到零 Webhook 集成。适合生产环境。容器在空闲时缩容到零Webhook 到来时冷启动——但 Session 已经持久化在 Cloud SQL 中所以不会丢失状态。Agent Runtime全托管服务 agents-cli deploy一键部署 Cloud Trace 集成。Agent Runtime 自动处理 Session 持久化、自动缩容和追踪——无需额外配置。同一个检查点-恢复架构在本地和生产环境之间零代码变更。4.4 适用场景Google 文章最后指出入职 Agent 只是一个例子。任何具有以下特征的工作流都适用 ADK 架构Human-in-the-loop 暂停等待人类审批、签名、确认跨系统交接HR 系统 → IT 系统 → 物流系统多天时间线流程跨越数天或数周具体场景包括发票争议处理、采购审批、销售跟进序列、合规审计——模式相同定义状态机、持久化检查点、空闲休眠、唤醒恢复。 总结速查卡ADK 核心概念概念一句话解释持久状态机状态从 session_state 读取不从对话历史推断state_deltaWebhook 唤醒时原子更新状态——ADK 的魔法按钮DatabaseSessionServiceSQLite/Cloud SQL 持久化 Session容器缩容到零不丢状态事件驱动空闲Agent 空闲时真正休眠Webhook 触发时唤醒协调者-子 Agent主协调者管理状态机子 Agent 专注领域执行before_agent_callback每次运行前初始化状态键防止运行时错误无状态 vs 有状态对比维度无状态 AgentADK 有状态 Agent状态来源对话历史显式状态机空闲处理轮询/阻塞事件驱动休眠崩溃恢复从头重跑从检查点恢复Token 消耗随时间线性增长恒定只读当前步骤幻觉风险高长间隔后低状态机强制一句话总结Google ADK 用三个核心设计模式——持久状态机、检查点-恢复、事件驱动空闲——将 Agent 从无状态聊天机器人升级为有状态后台进程。状态从对话历史迁移到显式状态机空闲从轮询迁移到 Webhook 唤醒存储从内存迁移到 SQLite/Cloud SQL。state_delta 是魔法按钮——Webhook 触发时原子更新状态Agent 立即知道到了哪一步。这不是更大的上下文窗口而是根本不同的架构——Agent 不是聊天机器人而是可暂停、可恢复、永不丢失上下文的后台进程。参考链接Google 官方博客原文ADK GitHub 示例仓库ADK 官方文档