聊《同样是LangGraph,为什么有的能上线、有的只能演示?》之前,先说一句实在的:别急着背概念,先看它在真实项目里到底解决什么问题。
摘要
上周,有个朋友跟我聊他做的一个 Agent 项目。原型跑得很顺,能自动查数据库、发邮件、甚至生成报告。可一放到生产环境,不到三天就出问题了:有人误删了生产数据,有人调用了未授权接口,日志里连“谁在什么时候做了什么”都查不到。
我问他:“你有权限控制吗?”他说:“我还没想好,等上线后再加。”我问:“你有审计日志吗?”他说:“我只记录了模型调用的结果,没记谁调的。”
我直接说:“别上了。你这不是在做 Agent,这是在埋雷。”
这不是危言耸听。我去年带团队落地一个自动化运维 Agent,同样从 Demo 起步,结果上线第一天就因权限失控被安全团队叫停。教训来得太快,也太痛。
我们总以为 Agent 的核心是“智能”,是“自动执行”,但真正决定一个 Agent 能不能被团队接受、能不能上线、能不能长期运行的,不是它的 Prompt 有多炫,也不是它调模型有多快,而是——它有没有权限边界,有没有操作留痕,有没有可追溯的流程控制。
而 LangGraph,恰恰是解决这些问题的骨架。
---
目录
- 为什么需要图工作流?
- State 与 Node:把 Agent 当“进程”看
- Edge 与条件分支:流程不是死路一条
- 人工审批节点:让 Agent 有“刹车片”
- 工程化落地:日志、权限、文档是“隐形资产”
- 总结
为什么需要图工作流?

用传统的链式调用(Chain)写 Agent,看起来简单,一复杂就崩。比如:
- 一个 Agent 需要先查库存,再审批,再发货,最后通知客户。
- 每个步骤可能涉及不同系统、不同权限、不同责任人。
- 如果某一步失败,回滚?重试?通知谁?
用链式结构,你只能靠 if-else 硬写。一旦分支多了,逻辑就乱,权限和日志根本插不进去。
而图工作流(Graph)不一样。它以“状态”为中心,每个“节点”是一个可执行的动作,每条“边”是一个条件判断。你可以在每个节点里插入权限校验、日志记录、异常处理,甚至人工介入。
更重要的是:图结构天然支持流程可视化、可调试、可审计。你可以一眼看出谁在哪个节点做了什么,哪个节点被跳过了,哪个节点失败了。
---
State 与 Node:把 Agent 当“进程”看

在 LangGraph 里,你定义一个 State,它就像 Agent 的“当前上下文”:
from typing import TypedDict, Annotated
class AgentState(TypedDict):
user_id: str
action: str
data: dict
permissions: list[str]
log: list[str]
每个节点就是一个函数,接收 AgentState,返回更新后的状态:
def check_permissions(state: AgentState) -> AgentState:
if "admin" not in state["permissions"]:
raise PermissionError("用户无权限执行此操作")
state["log"].append(f"[{state['user_id']} 执行了权限检查]")
return state
def execute_action(state: AgentState) -> AgentState:
state["log"].append(f"[{state['user_id']} 执行了 {state['action']}]")
# 实际业务逻辑...
return state
注意:每个函数都是纯函数,不直接修改外部状态,只返回新状态。这样日志、权限、状态变更才能被统一记录。
---

Edge 与条件分支:流程不是死路一条
图的关键在于“边”——什么时候从 A 走到 B?
from langgraph.graph import StateGraph, END
workflow = StateGraph(AgentState)
workflow.add_node("check", check_permissions)
workflow.add_node("execute", execute_action)
workflow.add_edge("check", "execute")
workflow.add_conditional_edges(
"execute",
lambda state: "success" if state["action"] != "delete" else "rollback",
{
"success": END,
"rollback": "rollback",
}
)
workflow.add_node("rollback", rollback_handler)
这里的关键是:你可以在每个边里做判断,甚至触发人工审批节点。比如“删除操作”必须经过审批,不能自动执行。
---
人工审批节点:让 Agent 有“刹车片”
在生产环境,有些操作不能自动执行。比如删除数据、修改配置、访问敏感接口。
这时候,你可以加一个“人工审批”节点:
def approve_action(state: AgentState) -> AgentState:
# 这里可以调用审批系统、发钉钉消息、等人工确认
if not is_approved(state["action_id"]):
raise Exception("审批未通过")
state["log"].append(f"[人工审批通过 {state['action_id']}]")
return state
这个节点可以放在图中间,作为“ gate ”。只有审批通过,流程才能继续。这不仅安全,也方便事后审计——谁审批的、什么时候审批的、为什么审批,全都有记录。
---
工程化落地:日志、权限、文档是“隐形资产”
很多团队做 Agent,只关注“它能做什么”,不关注“谁允许它做”、“它做了什么”、“出了谁负责”。
但上线后,这些问题会一个一个冒出来:
- 用户投诉:“为什么我的数据被删了?”
- 安全团队查日志:“找不到操作记录。”
- 运维问:“这个 Agent 能重启吗?谁有权限改它的配置?”
所以,你必须把权限、日志、文档当成第一类问题来处理。
1. 权限控制:每个节点都要检查当前用户的角色、Scope、Action 权限。
2. 日志记录:每个节点执行前后都要记录操作人、时间、输入、输出、结果。
3. 文档化:把整个图结构画出来,标注每个节点的责任人、权限要求、异常处理方式。
这些不是“锦上添花”,是“救命稻草”。
---
总结
LangGraph 不是让你写一个更复杂的 Agent,而是让你把一个“黑盒脚本”变成一个“可观测、可控制、可审计”的系统。
当你开始思考“这个操作谁允许做?”、“操作过程有没有记录?”、“失败了谁来兜底?”的时候,你就已经走对了方向。
不要等到上线了才去补权限和日志。从一开始,就把它们作为工作流的一部分,写在每个节点里,画在每张边上。
Agent 不是要取代人,而是帮人更高效地做事。但前提是——它得有人管,有记录,有边界。
否则,再聪明的 Agent,也只是一颗定时炸弹。
资料展示
下面是我整理的AI大模型学习资料和工具包预览,适合收藏后按主题逐步学习。



如果你想看完整资料目录,可以在评论区留言「资料」;也欢迎告诉我你更关注AI大模型里的哪类内容。

853



被折叠的 条评论
为什么被折叠?



