EP11. "Agents 与 Workflow 设计模式：该照剧本走，还是放手让 Claude 自己想"
🔒 登录后可标记已读- Workflow（工作流） 是为已知问题预先设计好的一连串固定 Claude 调用；Agent（智能体） 是给 Claude 一个目标和一套工具，让它自己判断怎么走——选哪种，看你能不能"想清楚 Claude 该走的确切步骤"：想得清楚用 workflow，想不清楚才用 agent
- 官方课程的立场很明确：优先用 workflow，只有真的需要时才用 agent——workflow 准确度更高、更好测试、表现更稳定可预期；agent 灵活但成功率较低、执行路径难预测、也更难评估
- Workflow 有几种常见设计模式（并行化、链式、路由、evaluator-optimizer），各自适合不同形状的问题，学会辨认能当成一套可重复套用的"配方"
- Agent 要做得好，关键是工具的抽象层级要对——像 Claude Code 用
bash/glob/grep这种通用工具能自由组合，而不是切一堆像「Refactor」这样的超specific 工具 - 本篇课程内容以设计概念和判断准则为主，官方课程页面这几课多数没有展示完整可运行的代码范例，笔记如实呈现——没有的地方不硬造代码
重点内容
Workflow：为已知问题设计固定路径
Workflow 是预先设计好、用来解决已知问题（或已知问题集合）的一连串固定 Claude 调用。
判断该用 workflow 还是 agent，关键看任务的清晰程度：
- 如果你能「想象出 Claude 该走的确切流程/步骤」→ 用 workflow
- 如果连具体该做什么、该用什么参数都不确定 → 用 agent
示范场景：把金属零件的图片转成 CAD 模型（STEP 文件），整个 workflow 是：
- 从图片描述这个物件长什么样
- 用 CadQuery 这个库把它建成模型
- 渲染出 3D 模型
- 评估结果、迭代改进
💡 辨认出不同的 workflow 模式，等于拿到一套可重复套用的"配方"——学会这些既有模式，能帮你在实现新功能时少踩很多坑,不用每次都从零设计。
Evaluator-Optimizer 模式
这是一种 workflow 设计模式，专门处理"需要反复打磨才能达标"的产出：
- Producer（生产者）：先产出初版结果
- Grader（评分者）：照标准评估这个结果
- Feedback loop（反馈循环）：把需要修正的地方回传给 producer
- Acceptance（验收）：一直循环到结果达标为止
📌 这个模式跟 EP02 的评测 pipeline 思路相通——都是靠「产出 → 打分 → 根据分数改进」这个循环把质量做上去，只是这里是把这个循环直接嵌进 workflow 本身，让系统自动迭代,而不是人工手动调 prompt。
并行化（Parallelization）模式
问题：一次请求要求 Claude 同时评估好几个选项，容易让模型顾此失彼。比如一个材料选型任务要求同时分析六种材料，Claude 得同时兼顾好几组复杂分析，容易分身乏术。
解法分三步：
- 拆分（Split）：把复杂任务拆成几个专门的子任务
- 并行执行（Run）：子任务同时跑，不用排队等
- 汇总（Aggregate）：最后一次请求把各子任务结果整合起来
材料选型的例子：不要求一次全面评估，而是把同一张图片分别送给 Claude 好几次，每次用专门针对某一种材料类别的 prompt（一次专门分析金属适不适合、一次专门分析聚合物适不适合……），最后再发一次汇总请求，把这些独立分析综合成最终建议。
📌 四个好处：专注（每次只分析一件事，不用同时兼顾多头）、能各自独立优化（每个子任务的 prompt 可以单独调整）、更好扩展（要加新选项，加一个子任务就好）、总耗时更短（并行跑，不是排队跑）。
适用场景：子问题彼此独立、每个子问题都能从专门设计的 prompt 中受益、整体复杂度容易压垮单次请求的场景。
链式（Chaining）模式
核心思路：把复杂任务拆成一串按顺序执行、每步都专注单一面向的子任务，而不是要求 Claude 一次搞定所有事——这个模式特别适合处理「单一 prompt 里塞了太多限制条件」的场景。
它解决的问题：Prompt 反复迭代优化的过程中，限制条件常常越堆越多。就算写了一堆「不要做 xxx」的指令，Claude 还是可能违反——比如混进 emoji、暴露自己是 AI 的身份、语气跑偏。
两步走的解法：
- 第一次请求用原本的限制条件生成初版输出
- 第二次请求要求 Claude 针对具体、聚焦的指令去修订——例如专门要求找出并删除「AI 自我提及」的句子、去掉 emoji、把口语化措辞换成技术写作该有的规范用语
三个好处：任务拆解（把大任务拆成小的、不能并行的子任务）、灵活性（步骤之间可以选择性插入非 LLM 的处理逻辑）、专注（让 Claude 每一步只专心处理整体任务里的一个面向）。
适用场景：涉及多重限制条件的复杂任务、Claude 对要求的遵循度不稳定、需要中间处理/校验步骤、需要对特定面向持续保持专注的场景。
路由（Routing）模式
它解决的问题：不同类型的内容用同一套 prompt 处理，效果往往平庸。比如同样要生成一段脚本，「编程教学」该走「教育向脚本：清楚的定义、例子、结构化说明」这条路，「冲浪」该走「娱乐向脚本：吸睛的开场、流行用语」这条完全不同的路。
两步流程：
- 分类：Claude 先把用户输入归类到预先定义好的类别（比如 Educational、Entertainment、Comedy、Personal vlog、Reviews、Storytelling）
- 专门处理：根据分类结果，套用对应类别专属的 prompt——教育类 prompt 强调「清楚、吸引人的脚本」「把复杂信息转成好消化的内容」；娱乐类 prompt 强调「高能量、贴近文化潮流的脚本」「用流行用语和吸睛的钩子」
架构模式：用户输入 → 路由器分类 → 对应类别的专门 pipeline（用适配的 prompt/工具）处理 → 输出
📌 好处：分类专属 prompt 让输出质量更好、不同类别甚至能各自调用不同的 API/工具、加新类别时架构方便扩展、只跑真正需要的处理逻辑更省成本。
最适合用在：应用需要处理明显不同类型的请求、且能清楚定义出 3-10 个有意义的类别的场景。
Agents：路不明确时才登场
Agent 跟结构化 workflow 是完全不同的思路——Agent 擅长的场景，正是"前进的路径本来就不清楚"，不是照预先设计好的固定步骤走。
最重要的原则：工具要给得够抽象，不要切得太细。Claude Code 是个好例子，它用的是 bash、glob、grep 这类通用工具，可以自由创意组合,而不是切成「Refactor」「Run Tests」这种超窄的专用工具。
工具串联能力：简单工具组合起来才有力量——EP04/EP05 的日期提醒场景就是例子，get_current_datetime、add_duration_to_datetime、set_reminder 这三个工具，Claude 能依据用户请求的不同需求，自己判断该用什么顺序组合调用，不用你预先写死一条固定路径。
灵活性的好处：以社交媒体短视频制作为例（bash、生图、文字转语音、发布到平台这几个抽象工具），这套工具组合既能支持全自动跑完整个流程，也支持用户在过程中随时插入反馈,做协作式的互动。
⚠️ 代价：Agent 带来部署上的灵活性，但也伴随"可靠性和成本方面的明显缺点"——不是没有代价的自由。
环境检查（Environment Inspection）：Agent 得学会"看结果"
📌 Claude 是"盲目"运作的——它没有天生的能力知道界面对自己的操作有什么反应，得靠主动观察环境才能理解自己刚才那个动作的实际结果。
视觉反馈：Computer Use 工具（见 EP05 内建工具部分）每次操作后会自动返回截图，让 Claude 能判断这次操作到底成不成功、决定接下来该怎么做。
改代码前先看现状：Claude 修改代码之前，应该先读一遍现有文件内容，搞清楚目前的结构，避免改出跟现有代码接不上的整合错误。
实际例子：一个自动生成并发布短视频的 agent，需要检查：输出质量和时长对不对、音画是否对得上、有没有真的成功发布到平台上。
💡 可以透过 system prompt 引导 Claude 的检查行为——比如指示它用 bash 指令或 FFmpeg 这类工具去验证产出的质量。
📌 核心原则：Agent 每做一个动作，后面都该跟着某种形式的验证或检查，确认真的达到了预期结果——这样才能做出更可靠、能自我纠正的 agent 系统，遇到意外结果时也能优雅地应对，而不是一路错下去都不知道。
Workflows vs Agents：怎么选
| Workflow | Agent | |
|---|---|---|
| 本质 | 为已知问题预先设计好的固定一连串 Claude 调用 | 给 Claude 工具和目标，让它自己规划怎么组合工具完成任务 |
| 优点 | 专注单一子任务，准确度更高；更好测试评估；表现稳定可预期 | 用户体验更有弹性；能创意组合工具应对多变任务；能自主追问/生成所需输入 |
| 缺点 | 灵活性有限，只能处理预先设定好的任务类型；需要具体、预先定好的输入 | 成功率通常比 workflow 低；执行路径难预测，难评估表现 |
📌 课程给的建议很直接：能用 workflow 就优先用 workflow，只有真的需要时才用 agent——production 环境里，可靠度和用户体验通常比"用最炫的技术方案"更重要，不要为了用 agent 而用 agent。
常见错误
- ❌ 任务路径其实很清楚，却还是选择用 agent 硬做——workflow 能做到的场景，用 agent 反而牺牲了准确度和可预测性,没有必要的取舍
- ❌ 用一次请求塞进所有选项要求 Claude 同时评估——超过 Claude 单次能兼顾的复杂度时，应该拆成并行的子任务，各自专注一件事
- ❌ Prompt 里限制条件越堆越多、Claude 却还是常常违反——与其继续加「不要做 xxx」的指令，不如改用链式 workflow，第二步专门做检查和修订
- ❌ 给 Agent 切太细、太专用的工具（比如「Refactor」这种窄工具）——好的 agent 工具该是抽象、通用、能自由组合的，像
bash/glob/grep这种 - ❌ Agent 执行完动作就直接假设成功、不做任何验证——每个动作后面都该有检查环节，不然出错了也不会知道
Sources
官方文档：
- Claude with Google Cloud's Vertex AI（Claude Academy 课程）— https://academy.claude.com/courses/claude-with-google-cloud-s-vertex-ai