从 Prompt 到 Agentic Workflow 的质变
单次 Prompt 请求大模型一步到位解决难题如同要求一个工程师不加思考一气呵成写完千行代码。
可靠性问题的根源在于：单次生成是一步概率采样，而任务正确性是端到端结果。模式化的工作流设计，本质是在两者之间插入可验证的中间状态——每一步都留下可供检查的产物（计划、工具返回值、反思结论），错误才能被局部发现而不是全局放大。这也是为什么"拆步骤"本身就是最大的可靠性红利，至于怎么拆、拆成什么角色，可参考 ReAct 范式演进之路：从推理-行动循环到 Plan-and-Solve 与自我反思。
四大核心模式协同矩阵
- Reflection（自我反思）：模型主动审查自己刚生成的代码，指出其中的语法隐患与逻辑死角并二次修正；
- Tool Use（工具增强）：借助 MCP 等协议，让模型走出有限知识库，主动调取编译器、搜索引擎与计算器核实事实；
- Planning（规划先行）：先建立任务清单（Checklist），分步攻关并在每一步校验完成状态；
- Multi-Agent Collaboration（多主体协作）：将复杂需求分配给各具角色的虚拟工程师协同完成，形成天然的对抗互审网络。
失效模式与模式的对症映射
| 观察到的失效模式 | 首选模式 | 次选补强 |
|---|---|---|
| 幻觉事实、编造 API 用法 | Tool Use（外部核实） | Reflection（审查引用来源） |
| 代码能跑但埋逻辑漏洞 | Reflection（自审） | Tool Use（静态检查器） |
| 长任务中途跑偏、遗漏需求 | Planning（清单校验） | 状态机约束转移 |
| 单一视角系统性盲区 | Multi-Agent（角色对抗） | Reflection（交叉评审） |
诊断时先定位失效发生在"事实层、代码层、计划层还是视角层"，再选模式，避免四个模式无差别全上。
落地顺序与成本取舍
经验值上建议按 Tool Use → Reflection → Planning → Multi-Agent 的顺序逐级引入：工具增强改动最小、收益最直接；自我反思增加一轮生成开销；规划需要额外的状态管理工程；多主体协作的通信与调度复杂度最高，应留给前三种模式仍压不住的长链路难题。每引入一级之前，先确认上一级的失败确实在增加——全链路可观测性是判断的前提，可参考 智能体可观测性架构：基于 OpenTelemetry 的链路追踪与决策树还原。
验证模式是否真的起作用
- A/B 基线对照：同一批任务分别以单轮 Prompt 与模式化工作流执行，对比完成率与返工次数，量化每个模式的净贡献；
- 中间产物检查：确认计划清单、反思记录确实产生并被后续步骤消费，而不是"写了没人看"的摆设；
- 错误传播测试：故意在早期步骤注入一个小错误，观察工作流能否在下一道检查点拦截；
- 成本记账：为每次模式增强记录 token 与延迟增量，防止可靠性收益被时延劣化吃掉。
常见问题速查
| 现象/疑问 | 原因/背景 | 处理/建议 |
|---|---|---|
| 加了反思反而更不稳 | 反思者与被反思者共享同一盲区 | 换提示词立场或换模型做评审 |
| 计划列了但不执行 | 缺少每步完成校验的强制点 | 用状态机或清单门禁约束推进 |
| 多 Agent 互相推诿死循环 | 角色间无仲裁机制 | 引入编排者或明确升级路径 |
| 模式堆满但任务仍失败 | 失效根因在任务本身不可判定 | 先修需求与评测，再谈模式 |
小结
四个模式不是玄学而是四种"插入检查点"的手段，取舍标准可以完全可执行：对同一批真实任务做开关实验，完成率提升撑不起额外时延与成本的模式就不引入。可靠性工程的第一课是测量，第二课才是模式。