[!info] related notes

• 所属 MOC: Agent MOC, AI MOC
• 相关概念: Agent, Agentic Systems, Prompt Chaining, LLM Task Routing, LLM Parallelization, Orchestrator-Workers, Evaluator-Optimizer
• 易混淆概念: AI Agent 创建实践, Orchestration
• 相关资源: Claude AI

Agentic Workflow Patterns

范围

这篇关系笔记讨论的不是“agent 要不要接工具”，而是当你已经决定做 multi-step system 后，应该选哪种工作流模式。

为什么要放在一起理解

这些模式长得都像“多次调用 LLM”，但它们解决的问题完全不同：

• 有的重点是把任务拆小
• 有的重点是分类路由
• 有的重点是并行提高速度或置信度
• 有的重点是动态拆任务
• 有的重点是迭代打磨结果
• agent 则是把决策权进一步交给模型

如果不放在一起比较，很容易为了“看起来高级”过度上复杂结构。

依赖路径 / 调用链 / 演进链

可以按复杂度和灵活性大致看成一条升级链：

1. Prompt Chaining
2. LLM Task Routing
3. LLM Parallelization
4. Orchestrator-Workers
5. Evaluator-Optimizer
6. Agent

越往后，灵活性越高，但成本、延迟和调试难度通常也越高。

对比与易混淆点

模式	核心问题	适合场景	主要代价
Prompt chaining	任务能否拆成固定步骤	大纲 -> 正文、抽取 -> 整理	延迟上升
Routing	输入是否该走不同路径	客服分类、模型分流	分类错误会放大
Parallelization	是否能并行提速或提置信度	多维评审、guardrails、voting	成本上升
Orchestrator-workers	子任务是否事先难写死	coding、复杂 research	编排更复杂
Evaluator-optimizer	是否值得反复打磨	翻译、复杂写作、深度搜索	loop 成本
Agent	是否需要模型持续决定下一步	open-ended coding、computer use	成本高、错误可叠加

几个经验判断：

• 如果单次调用加检索就够，不要急着升级成 workflow
• 如果步骤清晰，用 workflow 往往比 agent 更可控
• 如果路径不可预测、工具反馈很多，agent 才真正有优势

Appendix 里的落地例子为什么典型

• Customer Support Agents 同时具备会话、工具调用、明确完成标准和人工审批点
• Coding Agents 则因为测试可验证、环境反馈强、任务结构清楚而特别适合 agent 化

学习检查

不看正文回答：

1. Prompt Chaining、Routing、Parallelization 分别适合怎样的任务结构？
2. Orchestrator-Workers 与固定并行最大的差异是什么？
3. Evaluator-Optimizer 为什么需要可判断的质量标准？
4. 什么时候应该升级到 autonomous agent，而不是继续增加 workflow 节点？
5. 为什么模式选择的关键是“任务的不确定性与可验证性”，而不是哪个模式更高级？
6. 给一个代码重构任务，设计 chaining / parallel workers / evaluator 三种方案并说明取舍。

Related notes

• Agent MOC
• Agentic Systems
• Agent 执行闭环