这篇文章发布于公众号：移动开发那些事 用 LangGraph 落地飞书 Bug 自动修复 Agent 实践

先看成品。配好 .env终端敲一行：

uv run python main.py

接下来这个 Agent 会自己把下面这条链路跑完：

• 从飞书项目拉出挂在我名下、状态是「新提交」的 bug；
• 把每个 bug 的描述、复现步骤、日志附件拉下来喂给本地 claude 做根因分析；
• 在一个隔离的 git worktree 里调 claude -p 直接改代码；
• 把 git diff 打到终端给我过目，我敲 approve 之后才 commit、push 修复分支；
• 回到飞书项目。在这条 bug 下留一条评论，写清楚处理结果和分支名。

一条处理完，游标自动挪到下一条。中间某条挂了也不影响这一批里剩下的。

再看背景，痛点与需求

痛点：

• 手工抓取 Bug 与日志耗时长、重复性高。
• Bugs 需要多步交互：拉取 → 分析 → 修改 → 提交 → 回写。
• Bugs 串行处理时容易出现冲突或污染工作区。

"这些胶水和护栏，就是这篇文章这个 Agent 要干的活。claude 负责动脑动手，Agent 负责调度和兜底。"

为什么选 LangGraph？对比 CrewAI 的适用场景与决策理由

CrewAI 简介与局限性

CrewAI 是一个多智能体协作框架。适合开放式、多角色协作任务，例如写内容线或方案头脑风暴。只是它不擅长固定、线性的流水线，因为其主要优势在于让 AI 自主决定接下来动作。 而我们的 Bug 修复流程需要可预测、可控的顺序执行。

LangGraph 的三大主要优势

• 流程确定且线性：从拉取 Bug 到回写评论，全程可预测。
• 中途卡住等待人工审批：通过 interrupt 暂停图执行，让人确认 diff 再继续。
• 断点续跑支持：每个节点后都持久化状态，可中断后继续执行剩余 Bugs。

主要概念拆解

StateGraph

"整个 Agent 就是一张有向图：节点是干活的函数，边是干完这步走哪。" 只需声明节点与边，再 compile 即可得到可运行图。

State

"图里所有节点共享一份状态，每个节点读/写增量 dict 更新它。" 数据在节点之间流动，全靠这份 State，节点彼此不直接调用。从示例代码如下来看，

class AgentState:
从bugs来看，list
cursor这方面，int
current: Optional
log_text: Optional
fix_plan: Optional
worktree_path: Optional
说到branch。Optional
require_human_approval: bool
approved: bool
outcome: Optional # fixed / no_change / rejected / error
bug_failed: bool # 当前 bug 是否已失败
说到error，Optional
results: list

Node 与 Conditional Edge

"Node 是普通 Python 函数 -> dict。边分普通边与条件边，通过路由函数按 state 决定走哪个分支。" 如队列空就收尾，无改动则跳过审批等逻辑全部靠条件边实现。

Checkpointer

"给图挂一个 SqliteSaver。每个节点后将 State 落盘，并用 thread_id 支持跨进程恢复。" 人工审批时能“停下来等”，全靠它实现中断与恢复机制。不过，

interrupt