【Google ADK】 深度剖析：构建可暂停、恢复且永不丢失上下文的长时运行 AI Agent

【Google ADK】 深度剖析：构建可暂停、恢复且永不丢失上下文的长时运行 AI Agent

写在前面：Google 官方博客最近发布了一篇重量级文章——“Build Long-running AI agents that pause, resume, and never lose context with ADK”。它提出了一个极其尖锐的问题：无状态聊天机器人无法管理跨天/跨周的企业工作流。HR 入职流程可能持续两周，中间需要等待签名、审批、硬件配送——Agent 如何在等待三天后精确恢复，而不是"忘记"进度或"幻觉"已完成的步骤？ADK（Agent 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 调用。在五分钟的 Q&A 会话中这没问题，但在两周的入职流程中，对话历史会充满无关闲聊、过时的工具输出和重复的指令。模型开始混淆当前处于哪个步骤——它可能认为文档已经签署了，但实际上还在等待签名。

失败模式二：Token 成本爆炸。每次推理调用都重放完整的两周对话历史，会快速消耗 Token 预算。一次入职运行可能产生数千轮对话——其中大部分与当前决策无关。在 GPT-4 级别模型上，这意味着每次调用的成本随时间线性增长，而推理质量却在下降。

失败模式三：空闲期推理幻觉。当 Agent 暂停三天等待文档签名，然后带着大量上下文恢复时，模型经常幻觉出从未发生的中间步骤。它"记得"已经获得了尚未给出的批准，或者跳过它认为已经完成的步骤。这不是模型能力问题——而是架构问题：用对话历史作为状态的代理，在长时间间隔后必然产生幻觉。

1.2 根本原因：对话历史 ≠ 状态

三种失败模式的根本原因相同：对话历史不是状态。对话历史是线性的、冗余的、无结构的——它记录了"说了什么"，但不记录"到了哪一步"。一个入职流程有明确的步骤顺序（欢迎→签文档→IT配置→硬件→完成），但对话历史中这些步骤的信息散落在数百条消息中，模型必须从中"推断"当前进度——这就是幻觉的根源。

1.3 ADK 的解法：架构层面的范式转变

ADK 的解法不是"更好的 Prompt"或"更大的窗口"，而是三个架构层面的范式转变：

🏗️ 二、持久状态机：从对话历史到显式状态

2.1 定义状态 Schema

ADK 的第一个核心设计是显式状态机。不再依赖对话历史推断进度，而是定义一个明确的状态 Schema，告诉 Agent 它在工作流中的精确位置：

# app/state_schema.pyclassOnboardingStep:START="START"WELCOME_SENT="WELCOME_SENT"DOCUMENTS_SIGNED="DOCUMENTS_SIGNED"IT_PROVISIONED="IT_PROVISIONED"HARDWARE_DELIVERED="HARDWARE_DELIVERED"COMPLETED="COMPLETED"

六个状态，零歧义。Agent 无法跳步或幻觉进度，因为状态机强制执行步骤顺序。current_step存储在session_state中，不在对话历史中——这意味着即使对话历史被截断，状态也不会丢失。

2.2 将状态注入 System Prompt

Agent 的 System Prompt 直接从 session_state 变量读取当前位置——而不是重放旧消息：

instruction="""You 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:state=tool_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":f"Welcome 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:state=callback_context.stateif"current_step"notinstate:state["current_step"]=OnboardingStep.STARTif"new_hire_details"notinstate:state["new_hire_details"]={}if"pending_signals"notinstate:state["pending_signals"]=[]

这个回调在每次 Agent 运行之前执行，确保所有状态键都有默认值——防止因缺失键导致的运行时错误。

💾 三、检查点-恢复与事件驱动空闲

3.1 持久化 Session：从内存到 SQLite/Cloud SQL

状态机只有在底层 Session 存储能存活重启时才是持久的。在容器化环境（如 Cloud Run）中，容器会冷启动、缩容到零、意外重启。如果 Session 存在于易失性内存中，每个进行中的入职流程都会丢失。

ADK 的解法是DatabaseSessionService——用 SQLite（本地开发）或 Cloud SQL（生产环境）替代内存 Session：

fromgoogle.adk.sessions.database_session_serviceimport(DatabaseSessionService)session_service=DatabaseSessionService(db_url="sqlite:///./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_SENT，pending_signals设为["document_signed"]。此时 Agent 不再运行——它"休眠"了。没有线程阻塞，没有轮询循环，没有 Token 消耗。

唤醒阶段：当外部系统（如 DocuSign）通过 Webhook 通知"文档已签署"时，OnboardingResumeHandler水化持久化的 Session，转换状态机，并使用runner.run_async和state_delta唤醒 Agent：

classOnboardingResumeHandler:def__init__(self,runner:Runner):self.runner=runnerasyncdefreceive_signed_documents_callback(self,user_id:str,session_id:str)->None:asyncforeventinself.runner.run_async(user_id=user_id,session_id=session_id,new_message=types.Content(role="user",parts=[types.Part.from_text(text="Resume onboarding: Contract signed.")]),state_delta={"current_step":OnboardingStep.DOCUMENTS_SIGNED,"pending_signals":[],},):logger.info(f"Wake-up event:{event}")

3.3 state_delta：ADK 的"魔法按钮"

state_delta是 ADK 恢复机制的关键——它在 Agent 的下一次推理调用之前，原子地应用状态转换。这意味着：

1. 模型看到的 System Prompt 中{current_step}已经是新值（DOCUMENTS_SIGNED）
2. 不需要重放历史来"推断"当前步骤
3. 状态转换和推理调用是原子操作，不会出现中间状态

这就是为什么 ADK Agent “永不丢失上下文”——不是因为上下文窗口大，而是因为状态根本不在上下文里，而在持久化存储里。上下文窗口只是"当前步骤的描述"，而不是"完整历史的重放"。

🤖 四、多智能体委托与生产化

4.1 协调者-子 Agent 架构

ADK 不推荐把所有逻辑塞进一个单体 Agent。相反，它采用协调者-子 Agent 委托模式——主协调者管理状态机和流程编排，子 Agent 专注特定领域的执行：

it_agent=Agent(name="it_agent",model=Gemini(model="gemini-3.1-flash-lite"),instruction="""You 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_agent=Agent(name="hr_onboarding_coordinator",model=Gemini(model="gemini-3.1-flash-lite"),instruction=instruction,tools=[send_welcome_packet,check_hardware_delivery,send_day_one_schedule],sub_agents=[it_agent],before_agent_callback=initialize_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 Run：Cloud 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 核心概念

无状态 vs 有状态对比

一句话总结

Google ADK 用三个核心设计模式——持久状态机、检查点-恢复、事件驱动空闲——将 Agent 从"无状态聊天机器人"升级为"有状态后台进程"。状态从对话历史迁移到显式状态机，空闲从轮询迁移到 Webhook 唤醒，存储从内存迁移到 SQLite/Cloud SQL。state_delta 是"魔法按钮"——Webhook 触发时原子更新状态，Agent 立即知道"到了哪一步"。这不是"更大的上下文窗口"，而是"根本不同的架构"——Agent 不是聊天机器人，而是可暂停、可恢复、永不丢失上下文的后台进程。

参考链接：

• Google 官方博客原文
• ADK GitHub 示例仓库
• ADK 官方文档