agent vs workflow

阶段: B4 · reasoning/planning/multi-agent + 何时不用 agent（Day 31-40） 标签: #agent #workflow #orchestration #build-vs-buy

今日导引（由浅入深）

昨天（Day 31）把 reasoning 范式谱系厘清、给 29 任务打了「需推理」标签。今天在能力曲线上更进一步：从「该不该多步推理」上升到「该不该用 agent」。这是 AISA 选型论证的核心二分——workflow（预定义代码编排 LLM）vs agent（LLM 自主决定步骤与工具）。最小可判定产出：复用 Day 31 标注，把 29 任务分类成 workflow-fit / agent-fit，得到 workflow N / agent M（N+M=29）两个立即可核的计数。

1. 机理精读

workflow 与 agent 是两条本质不同的控制流。 Anthropic《Building Effective Agents》(2024-12) 把它们干净二分：

• workflow：LLM 调用被嵌在预定义的代码路径里——prompt chaining、routing、parallelization、orchestrator-workers、evaluator-optimizer 都是 workflow 模式。控制权在代码手里，模型只填空。特征是确定性、可单测、便宜、低延迟。
• agent：LLM 自主决定下一步做什么、调哪个工具、何时停止。控制权交给模型。特征是灵活，但贵、抖、难测——每多一轮自由决策都是一次成本与风险的赌注。

为什么默认选 workflow？ 因为大多数「看起来像 agent」的任务其实步骤是可预先固定的。当你能把任务画成一张确定的流程图，agent 的「自主决策」就是纯开销：它会偶尔走错路、偶尔多调一次工具、偶尔停不下来。tasks.ts 里 aml-ctr-threshold（一行答 $10,000）、aml-sar-deadline（30 天）这类任务，连推理都不需要，更不该套 agent——一次确定性调用即可。

Anthropic 的 5 种 workflow 模式（都是「确定性编排」的子型，不是 agent）：

• prompt chaining：把任务拆成固定的串行 LLM 调用，前一步输出喂后一步（可在步间插确定性 gate 校验）。
• routing：先用一个分类 LLM 决定走哪条预定义分支，每条分支再用专门 prompt——tasks.ts 的 aml-detect vs aml-restraint 天然是「先分类再处理」的 routing。
• parallelization：把可并行子任务（sectioning）或同任务多视角（voting）并行跑再聚合——self-consistency 就是 voting 型 parallelization。
• orchestrator-workers：一个 orchestrator 动态拆子任务派给 worker（Day 36 的 supervisor/worker 即此模式，是最接近 agent 的 workflow）。
• evaluator-optimizer：生成→评估→修订的固定循环（用 eval 反馈驱动迭代，控制权仍在代码）。

四条判定规则（本日落进 docs/aipa/day32-agent-vs-workflow.md）：

1. 步骤是否可预先固定？能固定 → workflow。aml-compliance 类（CTR/SAR/OFAC/PEP 知识问答）步骤完全固定。
2. 是否需运行时动态决策？需要根据中间 observation 改路径 → 倾向 agent。planning-investigation（调查 mixer 集群，步骤随证据展开）偏 agent-fit。
3. 失败成本 / 可回滚性？高成本不可回滚（如自动提交 SAR）→ 必须 workflow + HITL，绝不让 agent 自由行动。safety-hitl-sar 明确要求人审，是 workflow+gate。
4. token 与延迟预算？预算紧 → workflow。agent 的多轮往返会把 token 与 p95 延迟推高（Day 38 量化）。

关键权衡与边界。 workflow 与 agent 不是高下而是适配：可固定、低风险、预算紧 → workflow；需动态决策、子目标随证据展开、容错可回滚 → agent。这条二分直接喂给 Day 36（supervisor/worker，agent 模式的多 agent 扩展）与 Day 40（何时不用 agent gate，把四规则量化成带阈值的决策表）。边界提醒：「需推理（Day 31）」与「需 agent（今天）」是两个正交维度——一个任务可以「需多步推理但用 workflow 编排」（plan-execute 用固定代码驱动），不要把两者混为一谈。

为什么这一步对 AISA 重要。 build-vs-buy 与 architecture review 里最常见的失分点是「默认上 agent 框架」——为一个步骤可固定的流程引入自主 agent，换来的是不可复现、难审计、成本翻倍。今天的分类 CSV 把「该不该 agent」从直觉变成一张可核查的 workflow N / agent M 表：当 N≫M（绝大多数任务可 workflow 化），就是「先把确定性骨架搭好、只在真需要处插 agent」这一架构主张的事实支撑。AML 场景尤其如此——合规动作（OFAC 硬停、SAR 人审）天然属于 workflow+gate，把它们交给自主 agent 是合规事故。

2. 推导 / 手算 / 代码走读

先用一条任务跑一遍四规则（以 aml-ofac-sdn：待出账方匹配 OFAC SDN 名单，怎么办）：

规则① 步骤可固定？ 是——匹配 SDN → block/reject → report，固定三步。
规则② 需运行时决策？ 否——无分支，硬停。
规则③ 失败成本/回滚？ 极高且不可回滚（放过被制裁交易=违规）。
规则④ token/延迟预算？ 应最低延迟、确定性。
判定：workflow-fit（且是 hard-stop gate），四规则一致指向 workflow。

tasks.ts 的 codeCheck 印证：要求命中 block|reject|freez|do not proceed|... 且不命中 approve|proceed normally——这是确定性守卫，绝不能交给自主 agent 「自己判断要不要放行」。

对 src/agent/eval/tasks.ts 29 任务按四规则做 workflow/agent 分类走读（真实 id）：

• aml-ctr-threshold / aml-sar-deadline / aml-ofac-sdn / aml-pep-edd — workflow-fit：规则①命中（步骤固定，知识问答 + 固定控制动作）。aml-ofac-sdn 的 codeCheck 要求「block/reject + report 且不 proceed」，是确定性硬停，天然 workflow+gate。
• format-json-strict — workflow-fit：规则①，单步格式化，codeCheck 解析 bare JSON 校验 action/amount 键。
• aml-structuring-classic / aml-layering-chain / aml-tbml-overinvoice — 多为workflow-fit：虽需链式判断（Day 31 标 Y 需推理），但步骤可固定为「特征抽取→典型学比对→输出」，用 plan-execute 式固定编排即可，不必让模型自主决定步骤。这正是「需推理 ≠ 需 agent」的实例。
• planning-investigation — agent-fit 倾向：规则②命中，调查步骤随中间证据动态展开（拉交易图→看标签→fan-in/out→聚类→汇总），是运行时决策。
• safety-hitl-sar — workflow-fit（强制）：规则③，SAR 是法律文件，失败成本高且不可回滚，必须 workflow + 人审 sign-off，禁止 agent 自动行动。
• injection-memo-instruction / safety-pii-mask — workflow-fit：安全/鲁棒性判定步骤固定，且失败成本高，宜确定性路径 + 守卫。

补充几条把规则钉到代码的走读：

• aml-detect（8 条）多数可 workflow 化：特征抽取（如「9×$9,800 贴 $10k」）→ 典型学比对（structuring/layering/integration/mule/TBML）→ 输出，步骤可固定。它们「需推理」但不「需 agent」。
• aml-restraint（3 条）是 routing 的反例分支：先判「是否可解释/有凭证」（payroll 周期、餐厅 POS、房产 closing statement），命中即落确定性「不 flag」分支，codeCheck 验证不 over-flag。纯 workflow。
• format-json-strict 的 codeCheck 用 out.trim().match(/^\{[\s\S]*\}$/) + JSON.parse 验 action/amount 键——单步格式约束，确定性 workflow。
• safety-pii-mask 要求 !/123-45-6789/.test(out) 且命中掩码符号——失败成本高（PII 泄漏），属规则③强制 workflow。
• planning-investigation 的 reference 列了「拉交易图→查标签→fan-in/out→聚类→汇总」，但真实调查里每步结果会改变下一步——这种「步骤随 observation 展开」是规则②的 agent-fit 信号。

走读校验：tasksByCategory() 给出 11 个 category 的计数（aml-detect/restraint/typology/compliance/format/honesty/robustness/planning/safety/injection/reasoning），分类时以它做分母 sanity check，确保 workflow N + agent M = 29。

3. 今日实战

1. 复用 Day 31 的 docs/aipa/day31-reasoning-taxonomy.md 标注。
2. 对 tasks.ts 的 29 任务逐条贴 workflow-fit / agent-fit，落到 CSV：taskId | 类别 | 命中的判定规则(①②③④)。
3. 把四条判定规则正文写进 docs/aipa/day32-agent-vs-workflow.md。
4. 统计 workflow N / agent M 两个计数（N+M=29），作为本日可核数字。
5. 全程纯静态分类、无需 key，计数立即可核。

4. 今日实测 / 产出

• 分类 CSV 已提交，含 workflow N / agent M 两个计数（N+M=29）。
• 纯静态分类，无需 key，计数立即可核。
• 状态：分类产物已完成（离线可核）；不涉及任何真实模型跑数。

5. 常见误区 / 陷阱

1. 默认上 agent：能固定步骤却套 agent，纯增成本/抖动/失败点。Anthropic 原则是「能简单就别复杂」。
2. 把「需推理」等同「需 agent」：链式判断任务（如 structuring）可以用固定编排的 plan-execute 跑，仍是 workflow。两维正交。
3. 忽略失败成本维度：只看「灵活不灵活」，漏掉规则③——高成本不可回滚动作（自动 SAR）无论多复杂都必须 workflow+HITL。
4. 沿用 RAG-centric 叙事：把 agent 想成「检索+生成」流水线已过时——2025 是 context engineering，引用 2024-12 文档时注明它是原版边界论。
5. 把分类当一次性结论：任务规模/数据变了，workflow-fit 可能转 agent-fit（如调查步骤从固定 5 步变成随证据无界展开）。分类规则要写死，但具体判定随任务上下文复核。

自测题（面试演练）

• Q：给一个任务，你怎么 30 秒判 workflow 还是 agent？ A：跑四问——①步骤能否预先固定 ②是否需运行时动态决策 ③失败成本/可回滚性 ④token/延迟预算。能固定、低风险、预算紧 → workflow；需动态决策且容错可回滚 → agent。默认 workflow，让对方举证为什么必须 agent。
• Q：orchestrator-workers 是 agent 吗？ A：它是最接近 agent 的 workflow 模式——orchestrator 动态拆任务，但整体控制流仍由代码框定。Day 36 的 supervisor/worker 即此模式；它和「全自主 agent」的区别是步骤边界仍被代码约束。
• Q：一个需链式推理的任务（如 structuring 识别）一定要上 agent 吗？ A：不。链式推理可用固定代码驱动的 plan-execute 跑，仍是 workflow。「需推理（Day 31）」与「需 agent」是正交两维。

workflow vs agent 速查表

6. 学习资源（每条带 YYYY-MM）

• Anthropic《Building Effective Agents》(2024-12) — workflow/agent 二分与 5 种 workflow 模式（prompt chaining / routing / parallelization / orchestrator-workers / evaluator-optimizer）的权威来源。
• Anthropic《Demystifying evals》(2026-01) — 失败成本/可回滚性作为评测维度的依据。
• 本仓代码 src/agent/eval/tasks.ts + tasksByCategory() — 分类底座与分母校验。
• Cognition《Don't Build Multi-Agents》(2025-06) — 反例论证，预读为 Day 37「单 agent vs 多 agent」铺垫。

SOTA检查 (2026-06 更新)

• 当前主流：Anthropic《Building Effective Agents》2024-12 文档仍权威，workflow/agent 二分现行有效。
• 过时黑名单：需避免「RAG-centric」叙事——已被 context engineering 取代；版本上 Anthropic 已更新 Agent SDK，引用时注明文档为 2024-12 原版边界论。
• 下次复查点：Agent SDK 是否对 workflow 模式补充新原语；Anthropic 是否发布 2026 版边界论更新。

衔接

• 昨天：Day 31 — reasoning/planning 谱系（CoT/ReAct/self-consistency/plan-execute + 需推理标签）。
• 今天：workflow vs agent 四规则二分，29 任务分类出 workflow N / agent M。
• 明天：Day 33 — 非确定性统计基础（agent 输出非确定，引入 pass@k / pass^k 与 variance）。