让 Agent 工作流经得起业务约束

一个有用的 Agent 工作流通常不是从模型开始，而是从重复发生的业务任务开始。这个任务需要有明确输入、可重复的判断路径，以及能让人判断输出是否可用的复核点。

当任务形状足够清楚，流程就可以拆成更小的步骤：收集上下文、检索参考资料、选择工具调用、生成初稿，并在结果被视为最终答案前进入人工复核。

脆弱点往往不只是生成质量，而是缺少复核边界。如果工作流无法说明使用了什么、跳过了什么、哪里信心不足，业务侧就没有稳定方式继续改进。

在应用 AI 工作里，我更倾向显式复核状态，而不是隐藏在后台的自动化。这样 prompt 变化、检索变化和工具调用失败都更容易被诊断。

实际可用的工作流需要在检索不足、工具调用失败或生成内容不够具体时有兜底路径。兜底可以很简单，比如要求补充上下文，或者把任务退回人工复核。

这不如完全自主的 Demo 看起来激进，但通常更接近团队可以信任和维护的形态。

兜底路径要写进状态流，而不是只写进说明文档。否则一旦出现异常，系统就会退化成人工猜测：到底是输入缺失、工具失败、模型误判，还是业务规则没有覆盖。

很多 Agent 项目早期会把注意力放在 prompt 上，但真正影响可维护性的往往是状态。输入是什么、已经做过什么、下一步允许做什么、失败次数是多少，这些都需要被结构化记录。

LangGraph 这类框架的价值不只是把节点串起来，而是让流程边界可见。parse、plan、confirm、execute、validate 每个节点的产物都应该能被测试、记录和复盘。

如果状态设计不清楚，后面加入工具调用、人工确认、重试策略时就会变成一堆条件判断。看起来功能更多，实际上更难解释，也更难定位问题。

我不把“全自动”作为 Agent 工作流的默认目标。更实际的目标是：哪些步骤可以自动化，哪些步骤必须确认，哪些步骤失败后应该停止。

这类约束在 Demo 阶段显得保守，但进入真实业务后会变成优势。因为用户需要的是稳定交付，不是一次看起来很聪明但无法复现的运行结果。

能经得起业务约束的 Agent，通常不是最会说的 Agent，而是最清楚自己边界的 Agent。