perf(api): state 查询改用零工具骨架图,秒级降到毫秒级 - #1013
Conversation
|
Codex Review: 仅供参考:本轮预 review 基于 [P1] 骨架图丢失 checkpoint 中的中断任务,审批/提问无法从状态接口恢复。 chat_service.py:1730–1740 只注册 已执行最小复现:使用本 PR 的真实 请保留原执行图的中断/待处理写入语义,或在 checkpoint 读取边界完整恢复它们;只断言 schema 包含字段不足以证明状态等价。应增加真实“审批中断 → 刷新状态接口 → 展示审批 → resume”的回归,同时覆盖普通已完成状态。 验证:该 head 快照执行 |
骨架图只有 state_reader_noop 节点,aget_state 无法按原图节点重建 tasks, 等待审批的 checkpoint 在骨架图下 tasks 为空、_extract_interrupt_info 取不到 中断,用户刷新状态接口会丢失审批/提问的继续入口。 改为直接从 CheckpointTuple.pending_writes 的 __interrupt__ channel 恢复, 不依赖执行图结构。仅在 Run 状态为 interrupted 时回退读取,普通状态查询 零额外开销。
|
感谢 review,复现准确,已修复(最新 head [P1] 已修复:中断不再依赖图结构,从 checkpoint 原始写入恢复确认根因: 修复:新增 骨架图继续负责 回归测试(真实 LangGraph checkpoint,非 mock)新增
tracked decision: 验证
未运行 PostgreSQL/HTTP/浏览器 E2E;中断值恢复这一层用真实 LangGraph checkpoint 对照验证,完整「审批中断 → 刷新 → resume」的浏览器回归如需要我再补。 |
|
建议完成真实场景的测试 |
补真实场景测试:用真实 PG 的 AsyncPostgresSaver 构造停在 interrupt 的 checkpoint, 验证 _read_pending_interrupt 从持久化 pending writes 的 __interrupt__ channel 恢复 中断;并覆盖已完成、无中断的 checkpoint 返回 None。这是 InMemorySaver 单测覆盖不到 的存储后端差异。
|
感谢 review,已补真实场景测试(最新 head 补真实 PostgreSQL 集成测试之前只有 InMemorySaver 的单元测试,现补
2 个用例真实 PG 通过(另附 InMemorySaver 的 4 个单元用例)。「审批中断 → 刷新状态接口 → 展示审批 → resume」的浏览器回归我可以再用 playwright 补一轮截图,如需要请说。 |
现象
前端 state 面板(查看状态)查询很慢,重型 Agent 要 60-80 秒,用户点「状态」后长时间空白。子智能体 workdir 各异,缓存更是全 miss。
机理
_read_checkpoint_state为了拿 checkpoint,调用了 完整的agent.get_graph(context=context):问题在于:完整构图需要连接全部 MCP server 装配工具(重型 Agent 60-80s),而这整条链路的目的只是为了「读一个 checkpoint」——state 读取根本不需要工具。
改进方法
新增 state 查询专用骨架图:
_build_state_reader_schema():用_resolve_schemas合并 middleware 注入字段(TodoListMiddleware/TokenUsageMiddleware/SkillsMiddleware+ChatBotState),得到与真实 agent graph 一致的 state schema;_get_state_reader_graph():全局单例的零工具StateGraph(一个 noop 节点 + entry),毫秒级编译,复用同一个 checkpointer;_read_checkpoint_state改读骨架图。效果
state 面板查询从秒级(重型 Agent 60-80s)降到毫秒级(骨架图全局单例、编译一次永久复用)。子智能体 workdir 各异导致的缓存 miss 问题一并消失。新增单测断言骨架图 schema 含
todos/token_usage/activated_skills/subagent_runs/artifacts。