LangGraph 是负担还是利器？个人助手的 Agent 框架选型反思

2026-06-26，我认真评估过用 LangGraph 重构自己的个人助理。结论是：不适合。不是 LangGraph 不好，是它解决的问题和个人助手要解决的问题不是一回事。

这篇文章不黑任何一个框架，只把"什么时候该上、什么时候是负担"的判断标准讲清楚。

先客观说 LangGraph 强在哪

LangGraph 的图（node + edge）抽象不是花架子，它解决的是可控的有状态流程：

• 多模型协作（一个节点用 GPT，一个节点用 Gemini，按条件路由）
• 分支 / 循环逻辑（审批被拒 → 回到上一节点重跑）
• 客服流程 / 审批流（需要可视化地看清楚每一步走到了哪）

这类场景里，图的好处是状态、回溯、分支都显式可调试。如果你要的是"把一段复杂业务流程跑得可控"，LangGraph 是合理选择。

我自己的 QPC 里也记下了它适合的场景：

适合 LangGraph 的场景 —— 多模型协作 / 分支循环逻辑 / 客服流程审批流

个人助手的核心诉求是另一套东西

个人助理（personal assistant）每天面对的请求，结构完全不同：

• 记忆驱动：长期记忆、工作记忆、用户偏好要持续读写
• 技能路由：80% 的请求是固定模式，不需要复杂推理，命中一个 skill 比跑一个 Agent 更稳、更便宜、更快
• 平台对接：要原生连上飞书 / Discord / 日历，而不是自己写一堆适配层
• token 优化：要持续压低上下文成本，不能每次都把整个状态图塞进去

我对比过两套方案的实际覆盖：

关键不是"谁功能多"，是个人助手的核心链路，LangGraph 一个都不原生管。