LLM Workflow 设计：控制层、执行层、知识层三层分离

LLM Workflow 设计是构建 AI 应用时最容易忽视、却又决定成败的环节。很多团队把精力花在模型选型和 prompt 优化上，结果上线后 workflow 频繁崩溃，问题往往出在流程设计本身。

一个好的 Workflow 应该按照三层架构来设计。控制层负责整体的流程编排和决策路由，决定当前应该调用哪个工具、是否需要用户确认、遇到异常怎么处理。执行层负责具体的工具调用和数据处理，每个步骤只做一件事，输入输出接口清晰。知识层负责文档检索和上下文管理，确保模型在每一步都有足够的信息来做出判断。

这三层的核心设计原则是解耦。控制层不直接调用 API，而是通过抽象接口下发指令；执行层不关心业务逻辑，只执行具体任务；知识层不参与决策，只提供信息。每层独立演化，互不影响。

容错设计是另一个容易踩坑的地方。LLM 调用可能超时、可能返回格式错误的输出、可能在关键步骤上产生幻觉。好的 workflow 不是在假设一切正常的前提下设计的，而是在每一步都预设了降级策略。比如模型调用失败时应该重试几次、换成更小的模型还是直接通知用户手动处理，这些应该在设计阶段就明确。

另一个容易被忽略的细节是上下文传递。在多步骤 workflow 中，每一步的执行结果如何传递给下一步、中间状态如何维护、错误信息如何回溯，这些看似琐碎的问题在实际开发中占用的调试时间往往超过模型调优本身。

从实践角度来看，建议先从最简单的线性流程起步：用户输入、检索上下文、调用模型、输出结果。等这个流程稳定运行后，再逐步加入条件分支、并行处理、人工审核节点。一步到位设计复杂的 workflow 通常意味着一步到不了位。

LangChain 和 LlamaIndex 等框架提供了 Workflow 的基础组件，可以加速搭建过程，但不要被框架限制住。框架提供的是工具箱，不是设计蓝图。真正决定 Workflow 质量的，是你对业务场景的理解和容错策略的设计。

一个常见的最佳实践是在关键节点加入人工确认环节。当模型要执行一个不可逆的操作（比如删除数据、发送邮件、提交订单）时，先暂停 workflow，让用户确认后再继续。这个简单的设计能避免绝大多数由模型幻觉引发的生产事故。

最后，Workflow 的可观测性同样重要。每一步的执行时间、token 消耗、调用结果都要记录日志。当问题发生时，没有日志就很难定位是哪个环节出了故障。从第一天就把日志和监控做进去，而不是事后补。

实践中的 Workflow 设计还需要考虑状态管理和持久化。AI Agent 在执行多步骤任务时，中间状态需要被妥善保存，以便在系统崩溃或重启后能恢复执行。常见的做法是将状态存储在 Redis 或数据库中，每个步骤执行完成后更新状态。这样可以做到断点续传，避免从头开始重新执行。错误处理策略也需要明确。不同的错误类型需要不同的处理方式。模型调用超时通常可以重试，API 返回格式错误可以尝试修正后重试，业务逻辑错误则需要人工介入。将错误分类并制定对应的处理策略，能有效提高 Workflow 的健壮性。

Workflow 设计还有一个容易被忽视的方面：人机协作的边界。不是所有的决策都应该交给 AI。对于高风险的操作，比如涉及资金、法律、用户隐私的决策，应该设置人工审核节点。Workflow 在执行到这些节点时，自动暂停并通知人工审核。审核通过后继续执行，不通过则中止或回退。这种设计在保证效率的同时，也控制了风险。随着时间推移和信任积累，人工审核的范围可以逐步缩小。资源消耗的管理也是 Workflow 设计的一部分。大模型的 API 调用成本不低，不合理的 Workflow 设计会导致重复调用和浪费。比如同一个上下文被多次加载到模型输入中，或者一个简单的查询被路由到了大模型而不是小模型。好的 Workflow 设计应该在每个决策点都考虑成本和收益，选择最经济的执行路径。缓存和复用机制也可以大幅降低成本。