在建立公司级 Agent 时往往面临诸多痛点：

• LLM 只能一次性返回答案，无法实时访问数据库、业务程序 API；
• 单次推理缺乏长期任务规划和异常处理能力；
• 完全自主的 Agent 可能出现死循环、错误工具调用、越权操作或幻觉决策；
• 传统链式流程在分支、重试、人工审批等场景下会迅速膨胀，难以维护。

为什么公司 Agent 不能只靠一次 LLM 调用

在 PoC 阶段。很多 AI 应用看起来只需要一个 Prompt：使用者输入问题，模型生成答案。但进入真实业务程序后这种“输入一次、输出一次”的方式很快会遇到边界：

• LLM 本身、内部数据库、业务程序 API。
• 单次推理缺少长期任务规划能力，难以独立完成“查询、判断、执行、复核、回写”的完整流程。
• 完全自主的 Agent 又会带来不可预测性，例如死循环、错误工具调用、越权操作、幻觉决策。
• 传统链式流程可靠但僵硬。一旦出现分支、重试、人工审批、异常回滚，链会迅速膨胀。

公司落地真正需要的不是“更聪明的聊天框”，而是一个能把 AI 能力放进工程控制面里的运行时。LangGraph 的价值就在这里：它用图结构承载 Agent 流程，把 LLM、工具、规则、状态与人工干预组织成可观察、可恢复和可约束的执行程序。不过，

传统 Chain 更像一条固定流水线：

Start -> Step -> Step -> Step -> End

它的优势是确定性高。但缺点是灵活性弱，业务越复杂，分支越多，异常方法越多。链式代码越容易变成大量 if/else 和补丁逻辑。

LangGraph 将流程建模为图：

Start-> Agent Node-> Tool Node-> Agent Node-> Human Review Node-> End

图结构允许流程根据状态动态选择接下来。一个节点执行完成后不必只能进入固定的下一个节点，而是可以由边决定是否调用工具、是否重试或进入人工审批。

这使 Agent 程序从“线性脚本”变成“受控状态机”。它不是让模型随意行动，而是把模型的自主性限制在设计好的图结构中。

LangGraph 的三个基础构件

再看Status。共享的业务现场

Status 是图执行过程中的共享数据结构，可视为一次任务的“黑板”或“上下文快照”。每个节点读取当前状态，并返回对状态增量更新，而非传递长串参数。

•  使用者消息 + 模型回复 + 工具结果;
•  身份和租户上下文;
•  业务任务编号;
•  模型或规则识别出的业务意图;
•  工具调用返回结果;
•  人工审批状态;
•  风控等级;
•  重试次数;
•  最终返回给使用者结果。

说到关键点，状态要有 Schema。不要让节点随意写任意字段，否则后期排查和升级会非常痛苦。

Node的观点是，执行动作的最小单元

Node 是真正做事的位置。可以是：

• LMM 调用；
工具调用； 业务 API 调用； 规则校验； 检索步骤； 人工审批等待点；说起来， 结果格式化器。

TIP：

好节点职责单一。按理说，例如不要把 “识别意图 + 查数据库 + 生 成回复 + 写审计日志” 全塞进一个节点。其实，这样虽然初期快，但后续无法复用，也无法单独测试，更难定位失败点。

"h4"。"Edge：流程控制与决策" }