EP12. "Agent 与 Workflow：该按剧本走，还是放手让 Claude 自己想"

• 两个问题决定该用 Workflow 还是 Agent：能不能在动手前就想清楚 Claude 该走哪几步？能就用 Workflow（预先设计好的固定流程）,不能就用 Agent（给目标和工具,让 Claude 自己想办法）
• 官方态度很直接："用户大概不在乎你是不是搭了一个很炫的 Agent——他们要的是一个稳定好用的产品。"生产环境优先选 Workflow,Agent 留给真的需要应付不可预测、多变请求的场景
• 四种常见 Workflow 模式：Evaluator-Optimizer（产出 → 打分 → 修正,循环到及格）、Parallelization（同一任务拆成几个独立子任务并行跑）、Chaining（长任务拆成有先后顺序的几步）、Routing（先分类,再送进对应的专属处理管线）
• Agent 能不能好用，关键在给它通用型工具（bash、读写文件、grep 这种）而不是每个场景各写一个窄工具,还要让 Claude 每做一步动作后都能"看到"结果（截图、文件内容、API 响应）——Claude 本身是"瞎的"，看不到就没法自我修正
• 前置知识：读过 [EP04](./EP04_工具调用基础.md)（工具调用基础）、[EP11](./EP11_claude-code与computer-use入门.md)（Claude Code/Computer Use 当 Agent 的具体范例）；这篇笔记是把前面学的工具调用能力,组织成更高层的架构模式

重点内容

先分清楚：Workflow 还是 Agent

判断标准很简单：

案例：把金属零件照片转成 CAD 模型（STEP 文件），四步 Workflow：

1. 用 Claude 的视觉能力描述这个物体
2. 让 Claude 用 CadQuery 这个库把它建模出来
3. 生成一张渲染图
4. 拿渲染图跟原图比对，评估效果,不够好就重来

Workflow 模式一：Evaluator-Optimizer（产出-评估-修正循环）

结构：

• Producer（生产者）：从输入产出内容
• Grader（评分者）：拿评分标准去评估这份产出
• Feedback loop（反馈回路）：不合格就把修正意见传回去
• Iteration（迭代）：重复直到产出达标

跟前面「零件转 CAD」案例的第 3、4 步就是这个模式的具体应用——渲染出图、跟原图比对、不够像就回头调整模型参数再来一次。

Workflow 模式二：Parallelization（并行拆解）

遇到的问题：假设在做一个「材质设计推荐」应用——用户传零件照片，系统推荐该用什么材质。如果一个 prompt 里塞进好几种材质、让 Claude 一次性比较选出最好的,缺少针对每种材质各自的专属判断标准，可靠度不够。

解法：不要塞进一个巨大的请求,把同一份输入,同时发给 Claude 好几次,每次只专注评估一种材质，各自独立进行,最后再把结果汇总,做出最终决定。

流程四步：

1. 把复杂任务拆成几个专注的子任务
2. 并行执行各自的评估
3. 把结果合并起来
4. 每个子任务可以有各自专属的 prompt 和评判标准

好处：

• 专注：每次只处理一个面向，不用同时权衡好几种互相竞争的考量
• 好优化：改某一个子任务的 prompt，不会牵动其他子任务
• 好扩展：加新材质/新选项，不用改动既有的 prompt
• 更可靠：认知负担降低了，结果自然更一致

适用场景：能拆成几个互相独立的评估、涉及多个判断标准或选项、需要各自分析完再综合判断的复杂决策。

Workflow 模式三：Chaining（顺序拆解）

跟 Parallelization 的区别：Chaining 处理的是有先后顺序、不能并行的子任务——"把一个庞大复杂的任务，拆成一串按顺序执行的小任务"。

好处：

• 把大任务拆成小的、不能并行的子任务
• 步骤之间可以插入非 LLM 的处理逻辑（比如代码里的数据校验）
• 让 Claude 每一步只专注在整体任务的一个面向上

解决的问题："长 prompt 问题"——一个 prompt 里塞太多要求（比如写一篇技术文章，同时要求不用 emoji、语气专业等等好几条），Claude 容易漏掉某些约束。

两步示范：

• 第一步：先生成初稿内容
• 第二步：针对具体要修的点，给出有针对性的修改指令

这样做的原因："Claude 能把全部注意力放在'修改'这个任务上，不用同时兼顾'生成内容'和'遵守各种约束条件'两件事。"

什么时候该用：任务本身有多个复杂要求、Claude 在长 prompt 里持续漏掉某些约束、步骤之间需要额外处理/校验、想让每一次互动都保持专注和可控。

Workflow 模式四：Routing（先分类再分流）

遇到的问题：内容形态差异很大时，一个通用 prompt 顾不过来——比如编程类主题需要写成教育向内容,冲浪类主题需要写成娱乐向脚本,"一个通用 prompt 没办法同时把两者都处理好"。

六种内容分类范例：娱乐、教育、喜剧、个人 vlog、评测、故事叙述——每一类各自配一套专属的 prompt 模板。

两步流程：

1. 分类：Claude 先把用户的主题归到预先定义好的某个类型
2. 专属处理：这个分类结果决定接下来套用哪份 prompt 模板

架构：用户输入 → 路由组件 → 分类步骤 → 对应的专属处理管线。关键点："用户输入只会流进一条专属管线，不会同时跑全部管线。"

什么时候该用 Routing：应用要处理形态差异很大的多种请求、分类边界本身清楚可定义、Claude 能可靠地做出分类判断、路由带来的性能收益值得付出这层额外开销。客服机器人、内容生成工具是典型的适用场景。

Agent：给工具，让 Claude 自己想办法

Agent 跟前面几种结构化 Workflow 有本质区别："当你确切知道完成任务需要哪些步骤时，Workflow 是最好的选择；而当你不确定这些步骤该是什么时，Agent 的优势就显现出来了。"

用简单工具拼出复杂能力：以「提醒事项系统」（[EP04](./EP04_工具调用基础.md)那三个工具：get_current_datetime、add_duration_to_datetime、set_reminder）为例——这几个简单工具本身很朴素,但 Claude 能自己创造性地把它们串起来。比如"11 天后是星期几"这种问题，需要 Claude 自己判断该按什么顺序、串联调用哪几个工具才能算出来，没人替它预先写好这个步骤序列。

设计哲学：给通用工具，不要给窄工具

Claude Code 本身就是这个哲学的范例——它给 Claude 的是几个非常通用的能力，而不是每个场景各配一个专属工具：

• bash
• 读/写文件
• 编辑功能
• glob 和 grep 搜索

另一个范例：社媒短视频 Agent，可以组合：

• bash（借此访问 FFMPEG）
• generate_image
• text_to_speech
• post_media

这套工具箱既能支撑简单的固定流程，也能支持"根据用户反馈动态调整做法"的互动式体验。

⚠️ 灵活性是有代价的："这种灵活性带来了可靠性和成本上的权衡"，落地时要认真评估值不值得。

Environment Inspection：让 Claude 看得见自己做了什么

Claude 每做一个动作（点按钮、改文件），都得收到反馈（截图、文件内容等），才知道这个动作到底成不成功、环境现在变成什么样了。

先读再写：改动之前先看现状。比如"叫 Claude 往一个 Python 文件加一条新路由"，Claude 应该先读现有代码，搞清楚当前结构长什么样，再动手改。

System Prompt 里明确要求检查环境：像视频生成这种复杂任务，system prompt 里可以明确要求：

• 用 bash 工具核实对白位置对不对
• 截图，肉眼检查产出效果
• 拿生成内容跟需求逐条比对

这么做的四个好处：

• 更好地追踪任务完成进度
• 更容易发现并纠正错误
• 任务完成前能先做一轮质量把关
• 能根据观察结果动态调整行为

实际设计时该问自己："Claude 怎么知道这个动作有没有成功？"具体落实：改动前先读文件、UI 操作后截图、检查 API 响应、把生成的内容拿去跟需求对照验证。

Workflow vs Agent：最终怎么选

Workflow 的定义："一系列预先定义好的 Claude 调用，用来解决一个已知的问题或一类问题。"最适合已经想清楚确切步骤序列的场景。

Agent 的运作方式：Claude 拿到工具，自己设计策略去使用——能靠创造性组合工具，适应各种不同的任务。

Workflow 的优势：

• 让 Claude 能专注在单个子任务上，准确度更高
• 步骤固定，评估和测试更简单
• 执行结果可预测、可靠
• 适合解决定义明确、范围具体的问题

Agent 发光的场景：

• 想要更灵活的用户体验
• 任务需要用意想不到的方式组合工具
• 遇到全新的、没预见过的状况
• 过程中需要跟用户确认、澄清

Workflow 的短板：

• 面对多变的问题类型时灵活性有限
• 用户互动被限制在预先定义好的输入范围内
• 前期需要投入大量规划

Agent 的短板：

• 成功率通常比 Workflow 低
• 执行路径不可预测，测试和评估更困难
• 行为一致性较差

战略建议：生产环境优先选 Workflow——"用户大概不在乎你是不是搭了一个很炫的 Agent，他们要的是一个能稳定运作的产品。"把 Agent 留给真的需要处理不可预测、多变请求的场景。

常见错误

• ❌ 明明能想清楚固定步骤的任务，硬要上 Agent 架构——Workflow 更可预测、更好测试、成功率通常更高，没必要为了"炫"牺牲稳定性
• ❌ 给 Agent 配一堆各自针对单一场景的窄工具——应该反过来给通用型工具（bash、读写文件、grep），让 Agent 有能力应付没被预先想到的场景
• ❌ 让 Agent 执行动作后不给任何反馈机制（不截图、不读文件确认结果）——Claude 看不到自己动作的结果，没法判断有没有成功、更没法自我修正
• ❌ 长 prompt 塞进太多互相竞争的要求，指望 Claude 能同时兼顾——用 Chaining 拆成有先后顺序的几步，比硬塞进一个 prompt 更可靠
• ❌ Routing 场景让一份用户输入同时跑好几条处理管线——应该先分类，让它只流进对应的那一条专属管线，不是全部都跑一遍

Sources

官方文档：

1. Building with the Claude API（Claude Academy 课程）— https://academy.claude.com/courses/building-with-the-claude-api