超越线性脚本：LangGraph的节点、边与持久状态

为何线性脚本无法适应智能体的需求

构建能够应对混乱语言和不断变化目标的智能体，与实现一个遍历列表的for循环是两码事。线性脚本擅长处理确定性步骤；而当模型需要在执行过程中回退、重试或改变意图时，这类脚本就会失效。智能体图则用明确的映射关系取代了直线式流程：你可以直接掌控状态对象和状态转换规则，而无需将它们隐藏在晦涩的链式辅助函数中。

对于普通软件而言，传统的控制流依然很重要，但它无法通过三项针对智能体的测试。执行路径十分僵化——当模型返回意外的工具结果时，没有合适的方式可以调整方向。上下文的传递也很困难：重复发送提示语很容易，但在不同阶段之间保留完整的对话记录却并非如此。内存则变成了穿插在函数中的临时参数，一旦加入暂停或人工审核环节，整个系统就会变得极其脆弱。

节点、边与状态作为工作集

三种基本元素就能涵盖大多数设计场景。节点是执行工作的单元——调用模型、访问存储、验证数据等操作都由节点完成。边则是指示下一步该执行什么的操作路径。状态则是会在每次跳转后依然保留的共享记录，这样系统就不会忘记之前的执行进度。

在实际应用中，这种交互非常简单。节点读取所需的字段，执行相应操作，然后将更新结果写回。边则会检查已更新的记录并选择下一个节点。状态则负责确保这些节点间的跳转逻辑保持一致。一旦这种模式清晰起来，图结构就能实现基于推理的迭代，而不仅仅是按固定脚本执行一次操作。

设计状态以保持内存可用性

持久化功能正是区分一次性聊天工具与可长期运行的智能体的关键。多轮交互、长时间等待以及暂停后继续执行等功能，都依赖于整个图结构所信任的架构。

建议使用诸如extracted_entities这样的明确键名，而非含义不明的data1。保持数据结构扁平化；嵌套字典容易导致部分更新相互冲突或覆盖相邻字段。使用类型化的架构（例如 Python 的TypedDict）可以让所有节点都清晰地了解数据结构规范：

from typing import TypedDict
# TypedDict provides structural type hints for our shared state
class SupportAgentState(TypedDict):
    user_input: str      # The raw query from the user
    agent_response: str  # The output generated by the LLM
    issue_type: str      # Categorization (e.g., 'billing' or 'tech')
    retry_count: int     # Counter to manage resilience logic

当内存结构确定后，专用节点便成为在之上运行的功能模块。

采用专用节点而非构建庞大整体

优秀的设计会拆分任务。处理节点用于重新格式化文本或API数据；验证节点在流程继续之前检查质量；集成节点则负责与工具和数据库交互；决策节点则用于检测状态并触发分支逻辑。

节点之间不应相互调用。标准的处理流程为读取→执行→更新。正是这次更新为下一次边缘计算提供了依据。如果某个节点无法单独进行测试，那就说明它已经过于庞大。

分支、循环与人工审核环节

图表化的方式能够构建出在原始脚本中难以实现的控制逻辑。条件边可以在retry_count值上升时将任务提交给人工审核，而非反复尝试失败的模型调用。通过人工干预机制，高风险操作会在得到批准前暂停执行，之后再在完整保留上下文的情况下继续运行。时间回溯调试功能则可以回到之前的检查点，从而准确判断是哪个字段导致了流程变化。

这些机制使得复杂的流程更加易于观察，也让系统从脆弱的自动化模式转变为具备恢复能力的结构。

将失败视为图的一部分

对于生产环境中的代理程序而言，单纯的反应式try/except结构是不够的。需要在图中体现系统的弹性：包括用于处理短暂超时的重试节点、在多次失败后记录错误并升级处理的异常节点，以及当集成服务出现故障时仍能返回安全结果的备用路径。

那些一直困扰团队的问题包括：承载多个任务的过大节点、层级过深的状态结构，以及被搁置到“以后再处理”的错误处理路径。应在正常流程还停留在白板上的时候就规划好错误处理节点。

客户支持的具体演进方式

传统的客服机器人可能会不断循环直到账户ID得到验证。但在循环过程中，如果有用户称丢失了卡片，就会打乱原有的处理流程。借助图结构，系统可以分支出安全处理路径、重新进行验证，或暂停等待主管处理，同时保持对话历史记录的状态不变。将逻辑（节点）与内存（状态）分开，正是让这些边缘情况得以妥善处理的关键。

在编写代码之前先用Mermaid绘制相同的设计图，这样审查人员就能更清楚地看到分支结构，循环问题也更容易被发现。

易于推广的实用规则

从简短的节点链开始，再逐步添加循环和分支。需明确设计结构，以避免嵌套状态错误滋生。将节点视为可独立测试的单元。尽早规划重试与备用路径。可视化图表，以便人们能够审查运行时所遍历的相同结构。

保持图表准确性的操作习惯

那些在智能工作流方面取得成功的团队，会将最初的图表视为假设而非最终成品。每次试点之后，他们都会分析哪些节点实际被执行过、哪些边从未触发过，以及哪些状态字段在没有任何读取操作的情况下仍在变化。未被使用的字段属于冗余负担：它们会增加检查点数量，还会让那些认为所有键都重要的新人感到困惑。应果断删除这些冗余部分。

工具配置应与图表定义一同存在。记录节点的进入和退出状态，以及决定下一步流程的状态信息。当人工审核触发时，需记录审批人及变更内容，然后从相同的线程标识继续处理，以便审计跟踪整个流程。这样的做法能将“时间回溯”这一演示技巧转化为处理异常的工具。

最后，不要只将业务规则编码在提示文本中。应优先使用能够检查结构化字段——如分数、枚举值、计数器等——的决策节点，这样规则变更只需通过代码审查即可实现，而无需对提示文本进行繁琐分析。虽然提示文本对语言表达很重要，但它不应成为所有关键流程规则的唯一存储位置。

当利益相关者要求“再增加一个功能”时，在起草任何建议之前，务必明确新节点的名称、它所写入的状态字段以及它所关联的故障边。这样的流程能确保演进是有目的性的，避免图表悄然变成另一个带有多余仪式感的线性脚本。