LangChain与LangGraph:角色、用户及何时选择使用其中之一
LangChain与LangGraph的差异:链式结构与持久图结构,这两个库各自的适用场景,以及选择其一的操作检查清单。
本指南旨在为《LangChain与LangGraph详解:它们是什么、谁在使用以及如何用它们构建AI智能体》重建一条可操作的实现路径。重点介绍合约、校验机制以及可直接放入代码库而无需猜测其用途的代码。在修改代码之前,应先明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤,而无需猜测其中的隐藏状态。配置信息应置于应用程序代码之外,环境文件、密钥存储及功能标志应集中存放于一个位置,以便操作人员无需查看整个架构即可进行审核。
llm = ChatOpenAI()
if (userAskedForFlights()) {
callFlightApi();
}
if (resultsAvailable()) {
summarizeResults();
}
User Question
↓
Reason
↓
Search Tool
↓
Analyze Result
↓
Answer
User Request
|
+---- Search
|
+---- Database
|
+---- Human Approval
|
v
Continue
from langchain_openai import ChatOpenAI
llm = ChatOpenAI(
model="gpt-4o"
)
def get_weather(city):
return weather_api(city)
tools = [get_weather]
Need weather information
weather = get_weather("Bangalore")
{
"temperature": 34,
"condition": "Sunny"
}
The current temperature in Bangalore is 34°C and the weather is sunny.
from langchain_openai import ChatOpenAI
llm = ChatOpenAI(
model="gpt-4o"
)
response = llm.invoke(
"Explain microservices in simple terms."
)
print(response.content)
User Request
|
v
Analyze Request
|
+---- Search Agent
|
+---- Database Agent
|
+---- Human Review
|
v
Generate Final Response
from langgraph.graph import StateGraph
builder = StateGraph(AgentState)
builder.add_node("search", search_node)
builder.add_node("answer", answer_node)
builder.set_entry_point("search")
builder.add_edge("search", "answer")
graph = builder.compile()
class AgentState(TypedDict):
question: str
search_result: str
answer: str
Example:
{
"question": "What is LangGraph?",
"search_result": "",
"answer": ""
}
def search_node(state):
...
builder.add_node("search", search_node)
builder.add_node("answer", answer_node)
builder.add_edge(
"search",
"answer"
)
builder.set_entry_point("search")
graph = builder.compile()
State
│
▼
┌─────────────┐
│ Search │ ← Node
└─────────────┘
│
│ ← Edge
▼
┌─────────────┐
│ Answer │ ← Node
└─────────────┘
│
▼
Updated State
AI Mind 发来的消息
在修改代码之前,需为“AI Mind 发来的消息”明确输入参数、该步骤的负责人以及终止条件。操作人员应能够从已知的检查点重新运行该步骤,而无需猜测隐藏状态。 需同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及死信处理都是产品功能的一部分,而非后续需要补充的内容。 需严格限制工具架构的灵活性。过宽的自由文本参数容易引发注入攻击,还会增加审计成本。
操作检查清单
对于操作检查清单,应在修改代码之前明确输入参数、各步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新执行该步骤,而无需猜测隐藏状态。
在功能结果旁记录耗时与成本。提前了解这些信息可以避免在从演示环境过渡到共享环境时出现意外费用。
在耗资较高的模型调用之后设置检查点,这样重新尝试时就不会重复计算相同的工作。
保持图结构简洁且类型明确。嵌套的数据结构会掩盖哪个节点修改了哪个字段的信息,还会导致中断后无法继续执行。
编写简短的操作手册:说明如何轮换密钥、如何清空队列以及如何回滚最近的更改。
优先选择小型、可测试的单元,而非庞大的脚本。当某个步骤失败时,故障应能指向具体的责任主体,而非复杂的流程链。
在推广该技术栈之前,应先冻结版本,为关键路径生成标准化的操作记录,并明确回滚步骤。共享环境需要设置速率限制、进行租户验证,同时要指定专人负责密钥轮换工作。与其展示花哨的一次性演示,不如注重扎实的可靠性。
针对强化措施第0点,在修改代码之前需明确输入参数、该步骤的负责人以及完成标准。操作人员应能够从已知的检查点重新执行该步骤,而无需猜测隐藏的状态。
配置信息应与应用程序代码分开存放。环境文件、密钥存储以及功能开关都应集中管理,这样操作人员无需查看整个系统结构即可进行审计。
规划与工具执行应分开处理。规划者负责提出方案,执行者负责实际操作,验证者则根据目标检查结果是否达标。
针对强化措施1,在修改代码之前需明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤,而无需猜测隐藏状态。
优先选择小型、可测试的单元,而非冗长的脚本。当某个步骤失败时,故障应能指向单一责任主体,而非复杂的流程链。
严格限制工具的架构。过长的自由文本参数容易引发注入攻击,还会增加审计成本。
针对强化措施2,在修改代码之前需明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤,而无需猜测隐藏状态。
在功能结果之外还需记录执行时间和成本。提前了解这些信息,可避免在从演示环境过渡到共享环境时出现意外费用。
在昂贵的模型调用之后设置检查点,这样重试时就不会重复计算相同的工作。
针对强化措施第3点,在修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤,而无需猜测隐藏状态。
需同时记录正常流程和故障恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的组成部分,而非后续需要补充的功能。
将规划与工具执行分开。规划者负责提出方案,执行者负责实际操作,验证者则根据目标检查结果。