2026-06-26，我认真评估过用 LangGraph 重构自己的个人助理。结论是：不适合。不是 LangGraph 不好，是它解决的问题和个人助手要解决的问题不是一回事。
这篇文章不黑任何一个框架，只把"什么时候该上、什么时候是负担"的判断标准讲清楚。
先客观说 LangGraph 强在哪
LangGraph 的图（node + edge）抽象不是花架子，它解决的是可控的有状态流程：
- 多模型协作（一个节点用 GPT，一个节点用 Gemini，按条件路由）
- 分支 / 循环逻辑（审批被拒 → 回到上一节点重跑）
- 客服流程 / 审批流（需要可视化地看清楚每一步走到了哪）
这类场景里，图的好处是状态、回溯、分支都显式可调试。如果你要的是"把一段复杂业务流程跑得可控"，LangGraph 是合理选择。
我自己的 QPC 里也记下了它适合的场景：
适合 LangGraph 的场景 —— 多模型协作 / 分支循环逻辑 / 客服流程审批流
个人助手的核心诉求是另一套东西
个人助理（personal assistant）每天面对的请求，结构完全不同：
- 记忆驱动：长期记忆、工作记忆、用户偏好要持续读写
- 技能路由：80% 的请求是固定模式，不需要复杂推理，命中一个 skill 比跑一个 Agent 更稳、更便宜、更快
- 平台对接：要原生连上飞书 / Discord / 日历，而不是自己写一堆适配层
- token 优化：要持续压低上下文成本，不能每次都把整个状态图塞进去
我对比过两套方案的实际覆盖：
| 维度 | LangGraph | 我的方案（skill + memory + tool + platform） |
|---|---|---|
| 持久记忆 | ❌ 无原生 | ✅ 分层记忆直接落库 |
| 技能路由 | ❌ 要自己接 | ✅ 原生 |
| 平台对接 | ❌ 无原生 | ✅ 原生飞书 / Discord |
| token 优化 | ❌ 不负责 | ✅ 工具链 + 上下文裁剪 |
| 图可视化调试 | ✅ 强 | ❌ 不需要 |
关键不是"谁功能多"，是个人助手的核心链路，LangGraph 一个都不原生管。
图抽象对个人助手为什么是负担
最大的反直觉点在这里：
对于个人助理场景，相比最先的 React 控制器模式，skill 技能路由更适合：80% 请求是固定模式，不需要复杂推理，技能比 Agent 更稳定、成本更低、响应更快。
图的"灵活性"恰恰是过度设计。当你 80% 的请求都能被一个确定性 skill 命中时，图节点 + edge 的抽象只是增加了：
- 状态序列化的心智负担
- 每次调用的 token 开销
- 调试时要先理解图结构，而不是读一段直线逻辑
我的个人助理里，真正需要"动态规划"的请求是少数。把少数动态请求交给一个轻量规划层，把多数固定请求交给 skill 路由，整体更稳。
判断标准（可直接照用）
一句话判断：
如果你的 agent 核心是 memory + skill + tool，LangGraph 是负担而非帮助。
更细的决策表：
| 你的核心诉求 | 该用 LangGraph 吗 |
|---|---|
| 记忆驱动 + 技能路由 + 平台对接 | ❌ 否，用 skill/memory 架构 |
| 轻量级对话 agent | ❌ 否 |
| 多模型协作编排 | ✅ 是 |
| 复杂分支 / 循环 / 审批流 | ✅ 是 |
| 需要可视化调试的团队流程 | ✅ 是 |
不黑 LangGraph：什么时候该上
为了避免误导，把该用的场景再明确一遍：
- 多模型协作：不同节点用不同模型，按条件路由
- 分支 / 循环逻辑重：审批流、需要回退重跑的业务
- 团队级流程：需要把流程可视化给非技术人员看
这些场景我一个都不拦。只是个人助手不在这张清单里。
我的落地：比 graph 更轻
最终方案是三件套，都不需要图：
- Skill 路由 接住 80% 固定请求（详见已发的 Skill 路由系列）
- 分层记忆 管长期 / 工作 / 语义 / 情景记忆
- 原生平台对接 直接连飞书 / Discord，不绕一层适配
配合 1GB VPS 上的 Hermes-lite 裁剪（已发文），整条链路常驻内存才几百 MB，比跑一个图引擎轻得多。
小结
选型不是追新，是让框架解决的问题和你的问题对齐。
LangGraph 解决"复杂有状态流程的可控执行"，个人助手要解决的是"记忆 + 技能 + 平台 + 成本"。两套问题重合度很低，硬塞进去只会得到一个又重又贵的助手。
下次有人问"要不要上 LangGraph"，先问他一句话：你的 agent 核心是 memory+skill+tool，还是复杂流程编排？ 答案基本就出来了。