LangGraph智能体设计模式与多智能体开发

• @before_agent：智能体启动前触发（每次调用执行一次），适合进行初始化操作（如参数校验、资源申请、上下文初始化）。例如，调用智能体前校验用户输入的城市名称是否为中文全称，避免无效流程启动。 • @before_model：每次调用模型前触发，适合动态补充上下文、修改提示词、过滤敏感信息。例如，在调用模型前，根据用户历史查询记录补充地区默认值，让模型获取更完整的输入。 • @after_model：每次接收模型响应后触发，适合处理模型输出（如格式校验、内容过滤、日志记录）。例如，模型返回响应后，检查是否包含符合要求的JSON结构，若不符合，则标记异常。 • @after_agent：智能体执行完成后触发（每次调用最多执行一次），适合进行结果汇总、资源清理、数据持久化。例如，智能体返回最终结果后，将查询记录（城市、时间、结果）存入日志文件。

内容有些过时，不太推荐。我读它的初衷很务实——想弄明白 LangGraph 的设计理念，好在工作中真正用起来。读完之后，印象最深的有几点： **1. 便签 vs 工作交接单** 书里把普通 LLM 的输出比作"一张便签"，只写最终答案；而 LangGraph 的输出是"一份带流程的工作交接单"，除了结果，还得告诉下一个环节"该谁接手、做什么"。这个类比一下子击中了我。之前我一直把大模型当成"回答问题的人"，但从没想过在 Agent 里它其实是一个"流水线上的工人"——光答对题不算完，还得知道自己往哪儿交、交什么。放回我的日常工作，这不就像写交接文档吗？只说"做完了"远远不够，得说清楚下一步。 **2. State 是那个"公共记事本"** Node、Edge、State 这三个概念里，我最有共鸣的是 State。它像一张摆在桌上的公共记事本，每个小站干完活都要往上面记一笔，下个环节读了才知道从哪儿继续。联想到我们工程里的多模块协作，最难的从来不是每个模块本身，而是模块之间的"当前状态"怎么传递、怎么不丢。LangGraph 用 Annotated 给字段加注解、用 reduce 定义消息的合并逻辑，把"大家怎么往记事本上写字"的规则也收编进了框架，而不是靠各节点自觉——这个思路很聪明。 **3. 先定好输出格式，再问大模型** "在访问大模型前就定义好输出的格式"这句话让我反思了很久。以前我调模型总是先聊再掰，拿到结果再想怎么解析，经常为解析脏数据头疼。书里的做法是倒过来：请求之前就约好格式，格式里既要有当前结果，也要有下一步建议。这跟我工作中先定接口、再写实现的路数是同构的——约定先行，后面一切顺畅。 **4. 条件分支不只是 if-else，是"指路牌"** Edge 不只是连接节点的路，还是指路牌——负责做选择。书里提到的多场景条件分支本质上是 Conditional Edge，主要用在意图识别上。这让我意识到，Agent 编排里最考验设计的地方往往不是单个节点多强，而是"什么时候该走哪条路"这个路由逻辑。也顺带解答了我一直的疑惑：为什么选 PG 而不是 MySQL 做底层——大概就是为了支撑这类复杂查询和路由判断。

废话太多，像是AI写的，书中的代码多处有错误

瑕不掩瑜。前半段确实是langgraph，后面就变成了langgraph和langchain的大杂烩，从此可见langchain的仓库冗余问题确实挺严重的。另外就是代码质量极低，可读性较差，经常出现为了“演示方便理解”而写出各种匪夷所思的模拟代码，反而显得代码多次复用现象反而不值一提了。尤其是倒了本书后面，几乎就是代码+代码总结的AI文，味道太重。 虽然上面说了这么多问题，但是本书前半段还是可以的，能大体系统地了解langgraph的机制和能力，作为头次阅读还行，不适合深入研究。

这本书写得...能直接看官方文档，我为什么看你ai写的书。