别把“Agent 编排”当成万能药：AI 工程化中状态机与确定性路径的回归

在 AI Lab 的交付现场，最常见的一个误区是：试图用一个极其复杂的 Agent 编排框架（比如 LangGraph, CrewAI 或 AutoGPT 的变体）去解决所有业务逻辑。

很多团队在项目初期会陷入一种“智能崇拜”：他们设计一个拥有 10 个 Tool 的 Agent，给它一个宽泛的 System Prompt，然后期待它能通过自我反思（Self-Reflection）和动态规划（Dynamic Planning）自动完成一个复杂的 B 端业务流程。

结果通常是：在 Demo 阶段表现惊艳，但在生产环境（Production）中成了噩梦。

幻觉的代价：不可预测的执行路径

当我们将业务逻辑交给 Agent 的“自主决策”时，我们实际上是在用概率分布替代确定性逻辑。

在一个典型的企业级交付场景中——例如“自动化财务报表审计”——如果 Agent 在第三步决定跳过某个校验环节，或者在第五步因为一次微小的 Token 波动而进入死循环，这种失败是不可接受的。

在 AI Lab 的实际工程实践中，我们发现：越是核心的业务链路，越需要回归到“状态机（State Machine）”而非“纯 Agent”。

从“自主编排”到“受控流转”

真正的 AI 工程化不是让模型决定“怎么走”，而是由工程师定义好“路怎么走”，让模型在每个节点上决定“填什么”。

我们推崇的模式是 Deterministic Workflow + LLM Nodes：

1. 显式状态定义：将业务流程拆解为有限的状态机（FSM）。例如：输入解析 $\rightarrow$ 合规校验 $\rightarrow$ 数据提取 $\rightarrow$ 结果汇总。
2. 强类型接口约束：每个节点之间传递的是结构化数据（JSON Schema），而不是一段随意的对话文本。
3. 局部智能，全局确定：LLM 只负责节点内部的非结构化 $\rightarrow$ 结构化转换。例如，在合规校验节点中，LLM 的任务是判断文本是否违规并输出 {"is_compliant": boolean, "reason": string}，而不是决定下一步该去哪个节点。
4. 异常分支硬编码：如果 LLM 输出不符合 Schema 或判定为失败，直接触发预设的 Error Handler 或人工介入（HITL），而不是让 Agent “尝试重新思考”。

实战教训：为什么不能依赖 Self-Correction？

很多框架宣传的“自我修正”机制在复杂场景下往往会导致“幻觉叠加”。当模型第一次输出错误时，它在第二次尝试修正时可能会为了迎合预期的格式而编造事实。

我们在一次交付中发现，强制要求模型进行三次 Self-Correction 的链路，其最终准确率反而比单次输出 + 硬性规则过滤低了 12%。因为模型在修正过程中丢失了原始上下文中的关键细节。

给 AI 工程团队的建议

如果你正在构建一个面向生产环境的 AI 应用，请尝试以下检查清单：

• [ ] 路径可见性：我能否在不运行程序的情况下，画出所有可能的执行路径图？
• [ ] 状态可追溯：如果系统在第 N 步出错，我能否瞬间定位到是哪个节点的输入/输出导致了偏差？
• [ ] 边界硬约束：关键的业务逻辑是否被写在了 Python 代码里，而不是写在了 System Prompt 里？
• [ ] 降级方案：当 LLM 响应超时或格式崩溃时，系统是否有非 AI 的兜底逻辑？

AI 的价值在于处理模糊性（Ambiguity），而工程化的价值在于消除模糊性。不要试图用一个更强大的模型来掩盖架构上的不确定性。最好的 AI 系统应该是：骨架是刚性的状态机，肌肉是灵活的大模型。