READ · UNDERSTAND · TRANSFER
阅读理解，按需巩固
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · 确定流程与局部探索的组合
先理解核心原理
先备概念：状态机、数据契约、幂等执行
已知业务规则应决定允许走哪些路径，模型只在允许的范围中探索未知步骤。图提高流程可观察性，循环提供局部适应性；二者都不能替代外部写操作的幂等和版本验收。
先问“不确定发生在哪里”
订单退款的资格校验、批准和执行顺序由业务决定，排查一份资料为何矛盾则常要根据新证据继续查。前者适合明确状态迁移，后者适合受控循环。把所有不确定性都交模型，会把必须完成的校验变成可选建议；把每个搜索动作都画成图，则会把本来需要探索的任务锁死。
混合的接口需要稳定
外层图可以规定“取证—草稿—审核—发布”，取证节点内部允许多轮只读搜索。节点结束时交出证据 ID、覆盖缺口和输入版本，分支根据这些字段走，不能猜一段自然语言是否算通过。模型探索失败可以返回缺口，不应绕过外层审核。
图不是事务
检查点保存图状态，无法与邮件服务的发送原子提交。恢复可能再次进入节点，节点内副作用仍要去重。LangGraph 中断恢复从所在节点开头重跑，正是这个边界的具体例子。选型时画恢复点和外部动作位置，比比较框架名字更有用。
回到问题：怎样回答？
流程步骤和验收规则确定时，我优先用状态图；路径必须根据运行结果探索时，在受控节点里使用 Agent 循环。两者可以混合，例如外层固定执行检索、草稿、审核、发布，草稿节点允许模型多轮调用只读工具。图结构不自动提供业务幂等，持久化也不等于外部操作只执行一次。恢复时必须知道从哪里重放，并把写操作、审批和状态版本设计清楚。
实现与取舍
先分析变化来自哪里
如果步骤顺序由业务决定，例如资料入库、权限检查、生成草稿、人工审核，控制流程应显式建模。若下一步由证据决定，例如定位未知故障、搜索多种资料，模型需要探索空间。LangGraph 官方区分预定路径的工作流与动态决定动作的 Agent；工程上不必二选一。外层工作流承载合规和生命周期，节点内循环处理可变的研究过程，节点输出必须经过稳定的数据契约进入下一阶段。
图负责状态，循环负责局部决策
状态不要只是消息数组。至少包含任务标识、输入版本、当前阶段、证据引用、产物引用、预算与审批记录。节点读状态并返回变更，分支依据结构化值，避免从自然语言中猜“通过”还是“失败”。并行分支写同一字段时需要明确合并规则，例如按文档标识去重，而不是依赖到达顺序。对于确定的权限拒绝和预算耗尽，直接走明确终态；不让模型反复争取被禁止的动作。
恢复与审批的关键取舍
持久化检查点记录线程的运行状态，长期存储保存跨线程知识，二者用途不同。生产恢复使用持久化存储和稳定 thread_id；内存检查点只适合演示。LangGraph interrupt 会暂停并等待恢复输入，恢复时所在节点会重新执行，所以审批前的操作必须能安全重放，或拆到独立节点。审批应绑定产物版本或摘要，恢复后重新校验权限和数据版本，不能让旧审批批准随后变化的内容。外部写操作仍需要业务幂等键和结果查询。
如何证明选型正确
设计三类演练：一个节点异常后重启进程、审批等待期间修改产物、两个分支同时完成。检查已完成证据是否保留、审批是否失效、聚合结果是否稳定、外部副作用是否重复。再比较图节点数、调试成本和模型轮次。简单问答没必要拆成几十个节点；长期任务也不能只靠把对话存到数据库。能说清恢复点与故障边界，才是选型的依据。
工程推演
- 场景
- 假设工程场景：文章生产包含研究、撰写、核验、审核和发布，研究步骤可能反复搜索。
- 设计决策
- 采用外层状态图；研究节点允许有限循环，审核和发布是独立节点，并绑定草稿版本。
- 验证目标
- 预期行为：重启后继续等待审核；修改草稿会要求重新审核；研究失败保留已找到的来源。
- 适用边界
- 图框架只管理状态和调度；内容质量、审批有效性与发布幂等仍由业务实现。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层并行节点同时修改证据列表，应怎样合并？
并行图把串行读写变成合并问题，需要明确同一字段的语义。
参考解答
让节点返回增量而非覆盖全量列表，并定义按证据 ID 与版本合并的 reducer。同 ID 同版本同内容可去重，同 ID 出现不同内容则留下冲突或拒绝合并，不能依到达先后静默覆盖。若展示需要顺序，先按稳定字段排序，避免把网络返回顺序当作事实顺序。
第 1 层恢复会重跑节点，审批前发送通知会发生什么？
恢复点决定哪些代码重放，持久化不等于外部动作只执行一次。
参考解答
恢复后可能再次发送通知，因为 interrupt 前的代码会重跑。将通知改成独立、有稳定业务键的动作，或移到审批成功后的节点；仍须防止该节点执行后、检查点保存前崩溃。仅把发送语句挪位置不能保证无重复，通知网关需保存投递状态并核对回执。
沿着这个回答继续深入
第 2 层通知独立成节点后，发送成功而检查点保存失败怎么办？
拆节点降低重放范围，但仍留下远端执行与本地落库之间的窗口。
参考解答
恢复会把节点看成未完成，因此用同一通知操作键查询或重放旧结果。远端有幂等支持则复用键；没有时先凭业务编号核验，无法核验就保留未知状态。检查点记录运行进度，通知账本记录外部事实，两者各司其职。
沿着这个回答继续深入
第 3 层人工把未知通知判断为未发送，后续才收到成功回执怎么办？
结果最终到达时必须纠正事实，而不是只维护流程状态的一致外观。
参考解答
保留原操作与人工判断的时间线，迟到回执按同一键更新事实并标出判断冲突；若已经发出第二条，记录实际重复，按业务补救。不能丢掉迟到事件来维护“只发送一次”的表象，避免自动重试通常更适合高影响未知动作。
第 1 层怎样防止审批时看到的草稿与发布内容不同？
审核节点与发布节点之间存在内容变化窗口。
参考解答
批准绑定草稿内容摘要、附件版本和发布目标，发布前重新计算并比较。任何影响实际动作的变化都使旧批准失效；纯展示元数据能否复用应由策略明确。最好批准的是不可变发布对象，发布节点只读取该对象，避免另一个可写字段替换正文。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
探索式故障定位
改变的条件：任务路径事先未知，下一步依赖观测
延伸问题：还需要外层图吗？
推导与参考解答
可以用很小的外层状态机管理运行、等待权限、结束与预算，内部 Agent 自主选择只读诊断工具。每次观测保存版本，写修复动作退出探索并进入明确批准与验收步骤。没必要为每种错误写固定路径，但仍要固定哪些动作能改变生产状态。
保持不变的原理：不确定的是探索路径，执行边界和终态仍可确定。
严格结算流程
改变的条件：路径基本固定，模型只负责解释
延伸问题：是否还要循环规划结算步骤？
推导与参考解答
不必。资格、金额与事务提交由确定程序完成，模型把已核验结果翻译成用户说明；信息缺失时返回固定状态。允许模型重排结算顺序会增加风险却无探索收益，只在无法结构化的材料解释处加入受限模型节点。
保持不变的原理：将模型放在真实需要判断的地方，业务规则留在可审查的控制流程中。
易错点
- 认为采用状态图就获得 exactly-once 副作用
- 用内存检查点声称支持生产进程恢复
- 在分支条件里解析模型一句“已通过”
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 区分固定业务流程与开放探索任务。
- 中高级信号
- 能给出确定性状态图与局部自主循环混合的边界。
- 资深信号
- 按失败代价、可观测性和维护成本解释选型与退出条件。
巩固练习 按需完成 · 建议 15 分钟
给报告生成流程选择固定步骤与自主探索步骤，并说明理由。
展开验收要求与检查点
- 关键写动作有确定性控制
- 探索有预算
- 选择依据来自任务约束
重点检查
- 按业务不确定性选择编排而非按框架热度选择
- 能解释检查点、线程状态和长期记忆的区别
- 识别节点恢复重跑与副作用重复的风险