Workflows 解决的不是“能不能”，而是“好不好”
Claude Opus 4.8 发布时附带的 Workflows 功能，说实话我一开始没当回事。毕竟 LangGraph 和 AutoGen 早就把“多 agent 编排”的概念炒上天了。但真上手试了两周，发现这个东西的定位很微妙——它不是让你做以前做不到的事，而是让你能把以前凑合着跑的东西，理得稍微像样点。
问题在这：单 agent + 工具调用其实能解决 80% 的需求。你要做的是把 prompt 写稳、工具定义写对、重试策略写健壮。但剩下那 20% 的场景，比如“先检索再总结、再写报告、再翻译、再格式化”，每一步的状态要往下一步传，出错要能局部重跑——这时候单 agent 的线性对话就开始漏风了。
Workflows 做的是把这种多步流程写成声明式 YAML/JSON，不用写 agent 循环，不用手写状态机。它比较像前端的 pipeline 思路，每个 step 是一个任务，可以串行、并行、条件分支、循环。听起来像啥？像 GitHub Actions 加了个 LLM 调用块。
我试了三种编排框架的体感
最近刚好在做一个内部工单流转 agent：收到需求 → 分类 → 查知识库 → 生成方案 → 审核 → 发送。人工一次要 15 分钟，想自动化到 5 分钟以内。
试试 LangGraph？概念太重。节点、边、状态 reducers、条件边、记忆持久化……文档写得像论文。我花了两天把图搭出来，但改分支逻辑就得重新编译图结构，调试还得靠 LangSmith 看轨迹。对于一个小项目，这属于过度工程。
AutoGen 呢？0.4 版本改成了事件驱动架构，概念又变了。它的多 agent 聊天循环很有意思，但你得定义 agent 之间怎么聊、谁先发言、怎么终止。一旦 agent 数量超过三个，对话树就乱了。
Claude Workflows 是另一个极端——它把“多 agent”藏起来了，你只定义一个 step 列表，每个 step 指定用哪个模型、哪个工具、输入模板。模型调用被工作流调度器管理，你不用担心 agent 之间怎么对话。代码量少了很多。
# workflows 片段示意（实际语法简化了）
workflow:
steps:
- id: classify
model: claude-3-opus-4.8
prompt: "根据需求内容分类：bug/feature/其他"
output: classification
- id: retrieve
model: claude-3-haiku-4.8
tools: [search_kb]
input: "分类: {{steps.classify.output}}"
output: kb_results
- id: draft
model: claude-3-sonnet-4.8
prompt: "基于 {{kb_results}} 生成方案"
output: proposal
就三层，每个 step 的输入是前面 step 的输出变量。状态传递是隐式的，你不用自己维护 dict。如果 retrieve 失败，可以只重跑那个 step，保持 classify 的结果。这在单 agent 长对话里很难做到。
但别急着把 LangGraph 扔了
Workflows 的坑也是明显的。
状态回溯能力弱
你在 step 3 发现 step 1 的判断错了，想改分类再重新跑后续步骤。Workflows 目前没有“人工介入修改中间状态再继续”的能力。要么全部重跑，要么你手动改输入变量。而 LangGraph 的状态 reducers 可以让你任意时间点注入修改。
调试成谜
Workflows 的 step 日志是按执行批次聚类的。如果 step 失败，你能看到错误消息，但要追踪到 prompt 内部哪个条件触发的问题，还得去 Anthropic Console 翻请求轨迹。相比之下，LangSmith 的 trace 视图更直观，虽然它也有自己的繁琐。
条件分支不够灵活
Workflows 支持 if/else、switch，但不能在运行时根据模型输出动态添加步骤。比如你要做“根据第一步的分类决定是否调用外部 API”，可以写 if。但你要做“根据分类从 10 个 API 中选 2 个，再对结果合并”，就得在 step 内用工具调用自己处理——这又回到了 tool calling 模式。所以 Workflows 擅长的是固定拓扑的流水线，对于图结构还在玩变形的场景，还是 LangGraph 更对路。
一个实际例子：用 Workflows 做代码审查
我们 team 每天有几十个 PR 需要走一遍自动化代码审查。传统方式是写个脚本调模型，每次把 diff 塞进一个 prompt，模型输出意见。问题是 diff 太长的话 token 超限，而且模型经常会漏掉某些文件。
用 Workflows 可以拆成：
- 列出变更文件（GitHub API）
- 对每个文件单独审查（并行 step，每个文件一个调用）
- 聚合所有文件意见（merge step）
- 按严重等级排序（sort step）
- 生成总结并评论 PR（final step）
这里关键在第二步的并行：Workflows 的 foreach 可以让每个文件审查独立调用，互不影响。如果审到第三个文件时超时，只重跑那一个。如果用单 agent 循环做，要么全重来，要么得自己写错误隔离。
实际跑下来，审查质量没有明显提升，但鲁棒性好多了。某个文件分析挂掉不影响其他。之前单 agent 经常因为一个文件的分析出错而丢失整个对话上下文——现在好很多。
什么场景值得用
我自己画了条线：
- 少于 3 步，无分支 → 单 agent + 工具调用，别折腾
- 3-8 步，有少量分支，流程固定 → Workflows，性价比最高
- 超过 8 步，状态复杂，需要回退和人工干预 → LangGraph 或自己写状态机，别图省事
- 纯聊天式交互，用户自由对话 → 啥框架都别上，单 agent 搭配 memory 足够
- 需要多个 agent 辩论或协同 → AutoGen 的 agent 聊天循环有独特优势，但警惕 overthinking
老实说，大部分团队根本到不了多 agent 编排的复杂场景。我在社区看了一圈，很多人把“文件处理多步”和“多 agent 协同”搞混了。你只是把同一个模型调了三遍，每次给不同的 prompt，这不算多 agent，只是多 step 工作流。Workflows 正好覆盖这个盲区。
未来可能的方向
Workflows 目前还是 beta，我猜 Anthropic 下一步会加：
- 人工审核 step（暂停执行等待人工确认，类似 Slack 通知）
- 子工作流嵌套（把一段流程抽象成模块复用）
- 更好的错误恢复策略（指定失败后重试次数、降级方案）
另外，社区已经开始有人把 Workflows 和 LangGraph 混合用了——外层用 LangGraph 做主流程，某些步骤里用 Workflows 句柄串行任务。这听起来像套娃，但实际工程里还挺合理：用 Workflows 管理 LLM 调用细节，用 LangGraph 管理全局状态流。
嗯，这个判断我自己也犹豫过。也许 6 个月后回头看会被打脸——可能 Workflows 直接进化成全功能编排，或者 Anthropic 放弃这个方向专攻模型能力。但至少现在，它给了我一个不用写状态机的选择，这就够了。