Anthropic 工作流模式:简单胜过复杂

Anthropic 工作流模式:简单胜过复杂

本节摘要:很多团队为一个其实只需要一次函数调用的问题伸手去拿多 Agent 框架,代价是真实的——框架加层遮蔽了提示、藏起控制流、招来过早的复杂度。Schluntz 与 Zhang(Anthropic, 2024 年 12 月)的帖子是业界被引用最多的反弹:从简单开始,只在复杂度挣回它的代价时才加上去。他们把「工作流」(工程师拥有的预定义路径)与「Agent」(模型动态决定自己的工具与步骤)分开,并给出五种覆盖大多数场景的工作流模式:提示链(线性分解)、路由(分类派发)、并行化(扇出聚合,分块或投票)、编排者-工作者(编排 LLM 动态选专家)、评估者-优化者(提议-评判循环直到通过,即第 05 节自我精炼的泛化)。所有模式都建立在「增强 LLM」之上——一个带检索、工具、记忆三能力的 LLM。本节吃透这五种模式、何时选工作流何时选 Agent,并用标准库对照一个脚本化 LLM 把五种模式全部实现一遍,每个模式仅需 10~15 行代码。

对应原课程:Phase 14 · Lesson 12 · anthropic-workflow-patterns(原英文 phases/14-agent-engineering/12-anthropic-workflow-patterns/docs/en.md)。

学习目标

阅读完本节,你应当能够:

1. 说出 Anthropic 的五种工作流模式:提示链、路由、并行化、编排者-工作者、评估者-优化者。
2. 解释工作流与 Agent 的区别,以及各自的工程代价。
3. 识别何时该选工作流、何时该选 Agent(以及反之)。
4. 用标准库对照一个脚本化 LLM 实现全部五种模式。
5. 抵制「为简单问题上多 Agent 框架」的诱惑,坚持从直接 API 调用开始。

一、问题与直觉

团队为「想要一次函数调用」的问题伸手去拿多 Agent 框架。代价是真实的:框架加层遮蔽提示、藏起控制流、招来过早复杂度。Schluntz 与 Zhang 2024 年 12 月的帖子是业界被引用最多的反弹:从简单开始,只在复杂度挣回代价时才加。

工作流 vs Agent

• 工作流(Workflow) —— 通过预定义代码路径编排的 LLM 与工具。工程师拥有图。
• Agent —— LLM 动态指挥自己的工具、走自己的步骤。模型拥有图。

两者各有位置。工作流更便宜、更快、更易调试。Agent 解锁开放性问题,但让失败模式更难推理。

增强 LLM:五种模式的共同地基

五种模式都建立在一个原子上:一个 LLM,接上三种能力——检索(搜索)、工具(动作)、记忆(持久化)。任何一次 API 调用都能用这三样。

五种模式

1. 提示链(Prompt Chaining) —— 调用 1 的输出是调用 2 的输入。任务有干净的线性分解时用。步骤间可加程序化闸门。
2. 路由(Routing) —— 一个分类器 LLM 选下游调哪个 LLM 或工具。输入类别差异大、需不同处理时用(一线支持 vs 退款 vs Bug vs 销售)。
3. 并行化(Parallelization) —— 并发跑 N 个 LLM 调用,聚合结果。两种形态:分块(不同片段)与投票(同一提示跑 N 次,多数或综合)。
4. 编排者-工作者(Orchestrator-Workers) —— 一个编排 LLM 动态决定跑哪些工作者(也是 LLM),并综合它们的输出。类似 Agent 循环,但编排者不会无限循环。
5. 评估者-优化者(Evaluator-Optimizer) —— 一个 LLM 提议答案,另一个 LLM 评估,迭代直到评估通过。这是第 05 节自我精炼的泛化。

工作流胜过 Agent 的场景

• 可预测任务 —— 如果你能枚举步骤,就该枚举。
• 成本受限任务 —— 工作流步数有界,Agent 可能螺旋。
• 合规受限任务 —— 审计员要读图,不要从轨迹里推断。

Agent 胜过工作流的场景

• 开放式研究 —— 下一步取决于上一步返回了什么。
• 变长任务 —— 几分钟到几小时、步数未知。
• 新领域 —— 你还不知道正确的工作流——先探索,日后固化。

💡 设计要点:决策的简化版——「下一步能不能预测?」能预测就用工作流,不能就用 Agent。这条线一划,90% 的「我们需不需要 Agent 框架」之争就消停了。Anthropic 自己的立场是:大多数生产任务,直接 API 调用就够。

上下文工程配套

Anthropic 2025 年的《Effective context engineering for AI agents》把相邻学科形式化:20 万窗口是预算,不是容器。要包括什么、何时压缩、何时让上下文增长——这是本系列上下文工程(第 12 章)讨论的内容。

二、从零实现

原课程 code/main.py 对照一个 ScriptedLLM 实现全部五种模式:

• prompt_chain(input, steps) —— 顺序。
• route(input, classifier, handlers) —— 分类 + 派发。
• parallel_vote(prompt, n, aggregator) —— N 次跑,聚合。
• orchestrator_workers(task, workers) —— 编排者选工作者。
• evaluator_optimizer(task, proposer, evaluator, max_iter) —— 循环到通过。

核心骨架如下,用伪代码展示。

模式 1:提示链

def prompt_chain(input, steps):
    data = input
    for step in steps:
        data = llm(step, data)          # 上一步输出是下一步输入
        if not gate_check(data):        # 程序化闸门
            return None
    return data
​

模式 2:路由

def route(input, classifier, handlers):
    category = llm(classifier, input)   # 分类器决定走哪条
    handler = handlers[category]
    return llm(handler, input)
​

模式 3:并行投票

def parallel_vote(prompt, n, aggregator):
    results = [llm(prompt) for _ in range(n)]   # 同一提示跑 N 次
    return aggregator(results)                  # 多数表决或综合
​

模式 4:编排者-工作者

def orchestrator_workers(task, workers):
    plan = llm("决定该用哪些工作者", task)       # 动态选
    chosen = [workers[name] for name in plan]
    outputs = [llm(w, task) for w in chosen]
    return llm("综合以下输出", outputs)          # 编排者综合
​

模式 5:评估者-优化者

def evaluator_optimizer(task, proposer, evaluator, max_iter=5):
    answer = llm(proposer, task)
    for _ in range(max_iter):
        verdict = llm(evaluator, task + answer)
        if verdict["pass"]:
            return answer
        answer = llm(proposer, task + verdict["feedback"])  # 带反馈重提
    return answer
​

运行 python3 code/main.py 会看到每个模式打印自己的轨迹。每个模式的代码量约 10~15 行;一个框架的代价以千行计。

💡 设计要点:这五个模式的代码量小得惊人——这正是 Anthropic 帖子的核心论点。当你发现「我需要的模式」可以用 15 行写出来时,引入一个几千行的框架就需要非常具体的理由(持久状态、Actor 并发、角色模板)。否则,直接 API 调用永远是第一选择。

三、框架对比

• 直接 API 调用 —— 大多数任务就够。
• 框架 —— 只在模式确实需要持久状态(LangGraph)、Actor 模型并发(AutoGen v0.4)、角色模板(CrewAI)时才上。
• Claude Agent SDK —— 当你想要 Claude Code 那种 harness 形态,又不想自己重建时伸手。

四、可复用产物

本节产出一份可复用技能(原课程 outputs/skill-workflow-picker.md):

• skill-workflow-picker.md:给定一个任务描述,挑出正确的模式,附决策理由与「工作流不够时如何重构为 Agent」的路径。包含一份五模式决策表(线性分解?类别分派?可并行?需动态选专家?需迭代精炼?),以及一份「该不该上框架」检查清单(有没有持久状态?有没有 Actor 并发?有没有角色模板?三个都没有就别上)。

Python 代码(code/main.py)是五种模式的独立可运行骨架,把 ScriptedLLM 换成真实厂商调用即可投入生产——这正是「简单胜过复杂」的活样本。

五、练习

1. (Easy) 给路由加一个置信度阈值。低于阈值 → 升级给人工。一线支持场景下阈值该落在哪里?
2. (Medium) 给 parallel_vote 加超时。一个调用挂了会怎样?缺票时如何聚合?
3. (Medium) 把 evaluator_optimizer 变成赌博机:跨迭代保留 top-2 输出,这样后到的好结果不会被后到的坏结果覆盖。
4. (Hard) 把提示链与路由组合:一个路由器在三条链中选一条。测量与「单个大提示」对比的 token 成本。
5. (Hard) 挑你自己的一个生产功能。画工作流图。数步数。这里 Agent 真的更好吗?

本节要点回顾

1. 工作流 vs Agent:工程师拥有图 vs 模型拥有图;前者便宜快易调试,后者解锁开放性但难推理。
2. 增强 LLM 是原子:一个 LLM + 检索 + 工具 + 记忆,五种模式都建在它上。
3. 五种模式:提示链、路由、并行化(分块/投票)、编排者-工作者、评估者-优化者。
4. 决策简化版:「下一步能不能预测?」能→工作流,不能→Agent。
5. 工作流赢在:可预测、成本受限、合规受限。
6. Agent 赢在:开放式研究、变长任务、新领域。
7. 代码量惊人地小:每模式 10~15 行,框架以千行计。
8. 框架只在三种情况上:持久状态(LangGraph)、Actor 并发(AutoGen)、角色模板(CrewAI)。
9. 默认是直接 API 调用:这是 Anthropic 自己的立场。
10. 上下文工程配套:窗口是预算不是容器,是本模式的相邻学科。

下一节,我们进入「状态图编排」——LangGraph 把本节的工作流模式落到一个显式的、可持久化的有状态图框架里,当你的模式确实需要持久状态与可中断恢复时,它才挣回自己的代价。