学习一个框架的设计思想远比其技术更加重要

最近几天在学习人工智能开发框架——Langgraph，虽然其理论看起来很简单，但等真正开始使用的时候才发现其经典的架构设计远比其技术更经典，更优雅。

作为一个技术人员，很多时候都在学习各种各样的开发框架；而且很容易沉迷于其技术实现无法自拔，但事实上一个经典的框架都有着其经典的设计哲学。

从javaweb的spring框架，到人工智能开发框架Langchain和Langgraph等；其核心的技术都在其设计哲学，很多时候学习一个框架觉得很累，学不明白，原因就在于你只看到了技术而没看到其中的哲学思想。

以Langchain和Langgraph为例；Langchain的设计哲学在其名字中体现得淋漓尽致——chain也就是链；链式组合是Langchain框架的核心，其本质是把与人工智能应用开发的流程使用一个链式结构串联起来；整个业务流程和业务数据都在这个链中进行流转。

首先这样做的好处就是，整个业务流程显得很直观，因为所有的步骤都是在链中一步一步的执行；不管是调用大模型也好，还是调用业务逻辑也好，亦或者是处理输出也好；上一层的输出可以直接作为下一层的输入，一旦其中某个环节出现问题，那么链式调用就会终止。

而Langgraph的设计思想也在其名字中体现——图(graph)，图结构相对于链式接口，其行为方式更复杂；但这里就有一个问题，链式结构中由于其逻辑比较连贯，数据只需要一层一层的传递即可，但在图中怎么处理？

因此，这里就引申出Langgraph中的经典设计状态图，给图加一个状态；当然，状态并不仅仅是Langgraph中特有的东西，在前端框架VUE中同样有状态管理的设计思想。

状态图的核心思想是，使用一个字典或用户自定义参数作为数据管理工具；然后这个参数在整个图中进行流转，任何需要数据操作的节点，在完成处理流程之后，就把数据更新到状态参数中，这样只要能拿到状态参数，就可以获取到之前所有节点的处理结果(当然，这里可以根据具体的业务需求进行调整)。

# 定义状态图class State(TypedDict):    # Messages have the type "list". The `add_messages` function    # in the annotation defines how this state key should be updated    # (in this case, it appends messages to the list, rather than overwriting them)    messages: Annotated[list, add_messages]graph_builder = StateGraph(State)

除了状态之外，Langgraph中还一个经典的设计就是节点；所谓的节点就是一个个功能模块；节点和图是无关的，一个业务模块中可以存在任意多个节点，而且节点可以处于任意位置，只需要在合适的地方使用边把节点串联起来即可。

这种低耦合的设计方式，使得框架使用起来会非常轻松，并且可以根据具体的需求进行随意调整，而不会影响到其它。