用 LangGraph 理清重试与状态流转

求职助手 JobCopilot 的检索、结构化输出和重试逻辑各自能跑，串起来却变成层层嵌套的函数调用。作者首次用 LangGraph 将它改成状态图，把一次运行的数据放进 Pydantic 模型，再用条件路由控制重试。改造过程中，一条错误连线还让所有任务都返回了失败。

目前能确认什么

作者遇到的问题很具体：模型没按格式回答时谁负责重试，谁负责停止，解析后的评分又存在哪里？此前，这些责任散落在闭包和回调里。

改造后，节点接收状态，完成一步工作，只返回发生变化的字段。检索节点填充简历上下文，判断节点写入评分等结果，后续走向由图上的连接决定。

路由规则也集中起来：没有解析错误就结束；有错误且调用次数未达上限就重试；达到上限则进入失败节点。节选代码把调用上限设为 3 次。

状态合并同样需要明确规则。作者的顺序执行示例中，后写入的列表覆盖前值；需要累积时，则显式配置合并函数。列表不会因为类型是 list 就自动追加。

我的判断

这次改造最有用的地方，是让重试责任和结果归属变得可检查。

对同时涉及检索、模型调用和解析修复的程序，开发者可以沿着状态字段与路由判断追踪失败原因。作者还通过注入模拟模型客户端，在零网络调用下检查流程，这为测试成功、重试和放弃分支提供了具体办法。

但图连接本身也会出错。作者最初给判断节点接了通向失败节点的固定边；已知信息确认，这条错误连线造成了全部失败。模型回答正确，并不保证流程结果正确。

另一个边界是 Pydantic：节选展示了模型实例化时的校验，尚不能据此认定每次状态更新都会完整校验。具体校验时机，以及修复连线后的完整测试覆盖，还需要完整原文或官方文档确认。