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

Sun, 12 Jul 2026 00:00:00 +0000

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

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

先客观说 LangGraph 强在哪

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

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

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

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

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

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

维度	LangGraph	我的方案（skill + memory + tool + platform）
持久记忆	❌ 无原生	✅ 分层记忆直接落库
技能路由	❌ 要自己接	✅ 原生
平台对接	❌ 无原生	✅ 原生飞书 / Discord
token 优化	❌ 不负责	✅ 工具链 + 上下文裁剪
图可视化调试	✅ 强	❌ 不需要

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