一句话：让模型负责不确定性，让代码负责确定性。 判断是否要学某个框架，先问「它解决的问题，我真的有吗？」而不是「现在流行什么」。
最近几年学 AI，我越来越有一种感觉：
我们是不是花了太多时间学习 ” 怎么使用工具 “，而没有先问 ” 这个工具到底还在解决什么问题 ”？
从最早的 Prompt，到 Dify、Coze，再到 Workflow、LangChain、LangGraph、Multi-Agent，后来又出现 MCP、Skills、Claude Code、Codex……技术越来越多。
但模型本身也越来越强。
于是我最近开始反过来思考一个问题：
当 Claude Code、Codex 这样的 Agent Harness 已经可以自己读文件、执行 Shell、调用工具、检查结果、失败重试，再配合 Skills、MCP 和 CLI，我为什么还需要自己用 LangChain/LangGraph 再编排一次 Agent？
这让我重新思考了一遍：AI 时代到底什么值得学？
一、从 Workflow 到 Agent：我们以前到底在解决什么？
以前模型能力不够的时候，我们不太敢把决策权交给模型，所以很自然地会设计：
分类 → 检索 → 判断 → 调用工具 → 检查结果 → 失败重试 → 输出Dify、Coze 把它变成了可视化 Workflow；LangChain 把模型、Prompt、Retriever、Tool、Agent 抽象出来；LangGraph 又进一步把 Agent 变成：
State → Node → Conditional Edge → Node → Loop这些东西当时都非常合理，因为我们需要用代码弥补模型能力不足。
但今天的问题是：模型还需要我们把所有步骤都画出来吗？
假设我要修复一个 Bug，以前可能会设计：
读取 Issue → 分析代码 → 制定方案 → 修改 → 测试 → 判断是否失败 → 再修改 → Review但现在完全可以给 Claude Code 或 Codex 一个 Skill：
理解问题 → 找到 Root Cause → 建立可复现条件 → 修改代码 → 运行测试
→ 检查 Regression → Review Diff → 如果失败继续分析和修改 → 直到满足完成条件然后 Agent 自己决定：
Search → Read → Edit → Bash → Test → Edit → Test → Git Diff → ...这里我第一次意识到：很多过去所谓的 ” 编排 “，其实只是因为模型以前不会自己编排。 现在这部分正在越来越多地被 Agent Harness + Skills 吃掉。
二、那强约束怎么办？
这是我之前最大的疑问。模型可以自由判断，但事务呢？幂等呢？权限呢？比如：
创建订单 → 扣款 → 锁库存 → 创建物流难道也交给 Skill？
后来想清楚以后，我发现这个问题本身问错了。为什么我要让 Agent 负责数据库事务？ 正确方式应该是直接提供一个 place_order()，然后工具内部自己保证：权限校验、事务、库存校验、幂等、Rollback、Audit。
Agent 只需要判断「什么时候应该调用 place_order()」，而不是判断「扣款成功、库存失败以后应该怎么回滚」——后者本来就是普通软件工程应该解决的问题。
于是我慢慢形成了一个很简单的原则：
让模型负责不确定性，让代码负责确定性。
- Skills 负责：什么时候做、为什么做、通常应该怎样做。
- Tool / Service 负责：这个操作一旦执行，必须满足什么约束。
- 数据库负责事务，Scheduler 负责时间，权限系统负责授权，Queue 负责可靠投递。
这样一来，我突然发现：很多场景真的没有 LangGraph 的位置了。
三、那 LangChain / LangGraph 还有什么意义？
这是我继续思考后觉得最容易走向另一个极端的地方——不能因为个人场景不需要，就认为 LangChain/LangGraph 没价值。问题应该换成：
我是在使用一个 Agent，还是在开发一个 Agent 产品？
这是完全不同的事情。
如果我是个人开发者，或者只是想提高公司内部工作效率：
Claude Code / Codex + Skills + MCP + CLI + 几个确定性的业务 Tool对我来说往往已经够了，甚至更简单——依赖更少、调试成本更低、模型升级以后还能直接获得能力提升。这时候为了 ” 架构完整 ” 再加入 LangChain/LangGraph，我得到的收益可能远低于增加的复杂度。
但换一个场景：
10 万用户、500 个企业租户、每天几十万 Agent Run
多个模型、多个 Agent 版本、长任务、Human Approval
Streaming、Trace、Eval、成本统计、权限隔离问题已经完全不同。此时我要解决的不再只是「Agent 能不能把事情做完」，而是「我怎么管理大量非确定性的 Agent Execution？」
这时候 LangGraph 的 State、Checkpoint、Interrupt、Resume、Durable Execution 就开始有意义了。LangChain/LangGraph 官方目前也越来越把两者区分为 Agent Framework 与 orchestration runtime。
换句话说：LangGraph 的价值并没有消失，只是它解决的问题变得更明确了。
四、我现在怎么看 LangChain 的优缺点？
如果站在个人实用角度，我会这样看。
LangChain / LangGraph 的优势：
- 有统一的 Model、Tool、Agent 抽象；
- 可以管理显式状态和复杂执行流程；
- 更方便做持久化、暂停、恢复和 HITL；
- 更容易形成团队统一的 Agent 开发方式；
- 配合 Trace、Eval、Deployment 生态，更适合产品化。
但代价同样明显：
- 又增加了一层框架抽象；
- 学习和调试成本上升；
- 很多简单任务会被过度工程化；
- 模型本来可以自己判断的流程，被重新硬编码成 Graph；
- 如果已经使用 Claude Code/Codex，部分能力实际上与 Harness 重叠。
反过来看 Agent Harness：
Codex / Claude Code + Skills + MCP / CLI最大的优势恰恰就是简单——目标给出去，Agent 自己规划，Skill 给它方法，Tool 给它能力，代码给它边界。这可能才是个人开发者最需要的组合。
五、所以还要不要学 LangChain / LangGraph？
我的答案现在变成了：要学，但不一定要把它当成核心技术栈。
为什么还是要学？ 因为如果我要面试的是 AI 产品、Agent Platform、企业 AI SaaS 相关岗位，那么迟早会碰到：
State、Checkpoint、Streaming、HITL、Trace、Eval
Multi-Tenant、Long-running Workflow理解 LangChain/LangGraph，至少可以让我真正理解这些问题是怎么被工程化解决的。而且现在很多 AI 岗位本身也会把 LangChain、LangGraph、CrewAI 等框架经验作为筛选条件。
但如果我的目标只是「用 AI 提高自己的开发效率」或「给公司内部做几个自动化流程」，那我现在不会优先投入大量时间研究 LangGraph API，我更愿意研究：
Agent Harness、Skills、MCP、CLI、Tool Design、Context Engineering、Evaluation以及更传统、但更加重要的软件工程：
API、数据库、事务、幂等、权限、Scheduler、Queue、Observability六、最后：我现在判断一项 AI 技术值不值得学的三个问题
第一个问题：模型自己能不能解决？ 能通过 Agent + Skill 解决，就不要急着写 Workflow。
第二个问题：普通代码能不能更可靠地解决？ 事务、权限、幂等、强校验，优先写成 Tool / Service，而不是 Prompt。
第三个问题：我到底有没有 Framework 才能解决的问题？ 如果真的出现了跨进程状态、长任务恢复、大规模 Agent Run、Human-in-the-loop、统一 Trace/Eval，再引入 LangGraph 或其他 Runtime。而不是因为「这是一个 AI 项目」所以「先装 LangChain」。
结语
这是我最近对 AI 学习最大的变化。
以前我会想：现在流行什么框架，我是不是应该学？
现在我更愿意问：它解决的问题，我真的有吗？ 如果答案是否定的，那可能暂时不学，反而才是更合理的技术选择。
AI 时代变化太快，框架一定还会继续换。真正值得学习的，可能不是怎么把一个 Agent 画成越来越复杂的图，而是：
什么时候应该相信模型，什么时候应该相信代码，什么时候复杂度真的值得被引入。
这比记住任何一个框架的 API，对我来说更有价值。