企业 Agent 到底应该怎么搭：先选工作流，还是直接做自主 Agent
一手素材：
1. Anthropic Engineering - *Building Effective AI Agents*（https://www.anthropic.com/engineering/building-effective-agents ，2024-12-19 发布；Anthropic 在 2025-2026 年间通过 "Managed Agents" 文章对原观点做了更新）
2. Microsoft Azure Blog - *Agent Factory: The new era of agentic AI—common use cases and design patterns*（https://azure.microsoft.com/en-us/blog/agent-factory-the-new-era-of-agentic-ai-common-use-cases-and-design-patterns/）
本文把这两篇官方一手资料里"工作流 vs 自主 Agent"这条主线拉出来，再用大量一线企业落地经验把它讲透，目标读者是正在评估"是先上工作流还是直接做 Agent"的业务负责人、IT 架构师和产品经理。
一句话结论
绝大多数企业级业务场景，应当从"明确边界的工作流"起步，再在确实需要动态决策的环节里嵌入自主 Agent，而不是一上来就追求"全自动 AI 员工"。 Anthropic 和 Microsoft Azure 在这个问题上的口径完全一致——Anthropic 强调"简单可组合的模式比复杂框架更成功"，Azure 则把企业 Agent 拆成了"入门型 / 流程增强型 / 自主型"三档，并且建议企业按风险等级逐级放量。
如果你正在做 Agent 选型，可以先记住三个判断标准：
1. 这件事的输入是否结构化？——结构化输入往往意味着可以直接走工作流，不需要 LLM 决策。
2. 这件事的失败成本有多高？——失败成本高、影响合规或资金流向，先让人/规则守住边界，Agent 只做辅助。
3. 这件事的路径是否可枚举？——如果成功路径在 20 步以内能枚举完，工作流的可靠性会远高于 Agent 的随机探索。
满足其中两条以上，先写工作流；都不满足，才考虑让 Agent 自主规划。
一、为什么"全自动 Agent"是企业落地的第一道坎
过去一年，"AI Agent" 这个词被用烂了。一边是投资人 PPT 里"Agent 重塑企业"的宏大叙事，另一边是真正在做生产部署的团队在群里抱怨"上线一周就失控"。这种割裂来自一个共同误解：把"自主 Agent"等同于"高级自动化"，把所有流程都丢给它自主规划。
Anthropic 在 2024 年 12 月的工程博客里给出了一个非常克制的定义。他们把"agentic systems"作为大类，里头再分两小类：
- Workflow（工作流）：LLM 和工具由预先写好的代码路径编排，每一步走哪条分支是确定的。
- Agent（自主 Agent）：LLM 动态决定自己的流程和工具调用顺序，自己控制"如何完成任务"。
这个区分看起来只是定义游戏，实际上是判断企业系统可控性的最关键一环。一旦你把流程交给 Agent 自主规划，你必须同时接受三件事：
- 结果不确定：同一段 prompt 在不同时间可能走出完全不同的工具调用序列；
- 失败不可枚举：你无法靠"枚举失败模式"做上线前的回归测试，只能做大量抽样评估；
- Token 成本不可预测：Agent 的步数取决于模型自己的判断，烧 token 的速度比工作流高出 5-50 倍都不奇怪。
Azure 的 Agent Factory 系列文章则从另一个角度补一刀：他们把企业 Agent 分成三档——入门级（FAQ/检索增强）、流程增强型（在已有工作流里嵌入 Agent 决策）、自主型（端到端动态规划）。微软在企业落地项目里观察到的结论是：真正能稳定运行 6 个月以上的，绝大多数停留在第二档。第一档解决 80% 的咨询类问题，第二档解决 15% 的辅助决策类问题，第三档——也就是大家 PPT 里画的"全自动 AI 员工"——只解决剩下那 5% 但价值最高的场景。
所以结论很直接：企业做 Agent，第一件要做的事是"忍住"。
忍住对"全自动"的执念，先把流程梳理清楚，把那些"看起来很 Agent 但实际上写死更稳"的部分用工作流搞定。把宝贵的 Agent 能力留给"模型判断比规则判断更准"的环节——比如非结构化文本理解、跨系统信息汇总、对长尾问题的回应。
二、企业 Agent 落地的 5 种典型模式
把 Anthropic 和 Azure 两边的描述合起来，企业 Agent 落地时其实反复在用以下 5 种模式。理解它们，就理解了"工作流 + Agent"该怎么搭。
#### 1. Prompt Chaining（提示链）
把一个任务拆成多个固定步骤，每一步的输出是下一步的输入。比如"提取发票信息 → 校验字段完整性 → 写入 ERP"，每一步的提示词、输入输出 schema 全部由代码控制，LLM 只在"理解文本"这一步参与。
适用场景：信息抽取、文档解析、字段标准化。
不适用：每一步的输出格式会随输入剧烈变化的复杂场景。
#### 2. Routing（路由）
先用一个轻量分类器（或 LLM）判断用户意图，再把请求分发给不同的处理流程。客服系统最常用：用户问"查订单"走订单接口，问"申请退款"走工单接口，问"闲聊"走兜底回复。
适用场景：意图明确但分支多的场景，比如客服、销售线索分类。
不适用：用户意图本身模糊、需要多轮澄清的复杂咨询。
#### 3. Parallelization（并行化）
同一个任务用多个独立子任务并行处理，最后汇总。最常见的形态是"投票"——让模型同时生成多个候选答案，按某种标准挑最好的；或者"分块"——把大文档切成多块并行摘要再合并。
适用场景：内容审核（多模型投票降低漏检）、长文档分析（分块并行）、代码评审（多个角度独立审视）。
不适用：任务之间有强依赖关系，必须串行。
#### 4. Orchestrator-Workers（编排者-执行者）
一个"编排者" Agent 动态拆解任务，把子任务分派给多个"执行者" Agent。这是 Anthropic 特别强调的一种模式，也是大多数"多 Agent"系统的底层结构。
适用场景：研究类任务（多源信息汇总）、代码迁移（多模块并行处理）、复杂报表生成。
不适用：拆解成本本身很高的简单任务——为了一句话问答拉起 5 个 Agent 是浪费。
#### 5. Autonomous Agent（自主规划）
完全交给模型自己决定步骤、调用工具、反思错误、决定何时结束。Anthropic 在博客里把它描述为"evolving complex problems over many turns"，用词相当克制，强调"复杂问题"+"多轮迭代"两个前提。
适用场景：开放式研究、复杂排错、需要反复试错的工程任务（比如代码调试、SQL 调优）。
不适用：绝大多数业务场景，详见下一节。
一个常见的误区是：以为模式越往后越"高级"，越能体现技术能力。实际上，Anthropic 反复强调的一句话是——"成功实现都使用简单可组合的模式，而不是复杂框架"。他们见过的最失败的案例，几乎都是一上来就堆自主 Agent，结果成本失控、行为不可预测、最后回退到工作流。
三、什么时候必须用自主 Agent
虽然我前面给了大量"先工作流"的建议，但确实存在一些场景，自主 Agent 是合理选择。这些场景有几个共同特征：
1. 路径不可枚举。开放式的代码调试、未知根因的故障排查，这类问题的成功路径不是 20 步以内能写完的，规则系统根本覆盖不过来。
2. 信息分散在多个工具里。比如让 Agent "帮我查一下这周的运营情况"，它需要主动去 BI 系统看数据、去工单系统看用户反馈、去财务系统看收入波动，自己决定看哪些、看多少。流程根本没法预先写死。
3. 错误可以低成本回滚。如果 Agent 的一次错误调用不会引发实际业务损失（最多浪费 token），可以放开让 Agent 自己试。
4. 失败时容易发现。如果 Agent 错了，人类审查者一眼就能看出来（而不是要等三天业务数据跑出来才发现），适合做自主 Agent。
把这四条反过来，就是"不要用自主 Agent"的信号：路径清楚、信息集中、错误代价高、失败隐蔽。这类场景必须用工作流或 Human-in-the-loop，把决策权交给人。
微软在 Agent Factory 里给出了一个非常实用的判断清单：
- 是否涉及客户资金、合规、法律？ → 先工作流 + Human-in-the-loop
- 是否需要调用 5 个以上外部系统？ → 考虑编排者模式
- 是否每天运行超过 1 万次？ → 严格评估成本和稳定性
- 是否有明确的服务等级协议（SLA）？ → 工作流为主，Agent 只做补充
这四条命中两条以上的，几乎都不应该一上来做自主 Agent。
四、企业落地的 4 步走路径
把上面所有讨论收拢成一个可执行的 4 步走路径，企业可以照着推进：
Step 1：盘点流程，标记"模型可决策"环节
把目标业务流程画成流程图，标出每一步是"规则判断"还是"模型判断更准"。规则判断保留为工作流步骤，模型判断进入 Step 2 的候选。
Step 2：把候选环节做成"流程增强型 Agent"
不要直接把整个流程交给 Agent。把 Step 1 标记出的环节单独抽出来，嵌入到已有的工作流里——上游给结构化输入，下游接工作流的固定步骤。Agent 只在"理解/分类/抽取/汇总"这几类窄任务里发挥作用。
Step 3：搭建最小可观测体系
无论用 Anthropic 强调的轨迹追踪，还是 Azure 的 Agent Observability 仪表盘，没有观测就不要上线。要能记录：每次调用的输入输出、用了哪些工具、耗时多少、Token 消耗、成功失败。
Step 4：小范围放量，逐步引入自主决策
前 4-8 周只在受控环境（内部团队、低风险业务）运行。收集真实数据，建立评测集，再逐步开放到生产。每一步放量都要有"回退方案"——一旦 Agent 行为异常，能在 5 分钟内切回工作流。
这 4 步看起来慢，实际是最快的路径。Anthropic 自己在 2025-2026 年的 Managed Agents 文档里明确说："简单组合 + 严格边界 + 持续观测，这是过去一年所有成功部署的共同特征。"
五、常见的 5 个落地误区
最后梳理 5 个一线最常踩的坑，避免重复别人交过的学费。
误区 1：把"自动化"等同于"无人化"。 大量企业一上来要求 Agent 24 小时无人值守，忽视了 Human-in-the-loop 的必要性。实际上，即使是 Anthropic 描述的最自主的 Agent，也保留了大量人类审查节点。
误区 2：忽略评测体系。 Agent 上线后没有评测数据，等于盲人骑瞎马。需要建立至少三类评测：任务完成率、轨迹质量（工具调用是否合理）、成本（Token 和延迟）。三类指标缺一不可。
误区 3：过度追求多 Agent。 "5 个 Agent 协同"听起来很厉害，实际是 5 倍的协调成本和 5 倍的失败面。Anthropic 的建议是：只在任务确实需要不同角色时再拆 Agent。
误区 4：忽视 Token 经济性。 Agent 的每一步决策都是真金白银。Azure 的数据显示，未优化的 Agent 比单次 LLM 调用平均贵 8-30 倍。企业必须把每次任务的总成本算清楚，而不是只看"调用一次 LLM 的价格"。
误区 5：把所有规则交给它学。 业务规则、合规红线、资金边界——这些不能交给 Agent 自己学，必须用代码或护栏（Guardrails）显式写死。Anthropic 在 2025 年的更新里专门强调这一点："Agent 应该能创新，但不应越过你的护栏。"
写在最后
企业做 Agent，最大的认知陷阱是把它当成"更聪明的自动化"，结果用错了场景、放错了节奏、烧错了预算。
正确的姿势是：
- 从盘点业务出发，而不是从"我想做个 Agent"出发；
- 从工作流 + 流程增强 Agent起步，把自主 Agent 留给确实需要的场景；
- 从可观测 + 评测开始，没有这两件事就先别上线；
- 从小范围放量 + Human-in-the-loop开始扩张，不要一上来就追求"无人值守"。
Anthropic 和 Microsoft Azure 在这一点上给出的建议高度一致："Simple, composable patterns. With strong guardrails."
把这个原则记在心里，你就比 80% 的"AI 转型项目"领先了。
*本文基于 Anthropic 与 Microsoft Azure 两份一手工程文档，结合一线企业落地经验整理。所有事实性表述都可追溯到原始素材；案例部分为通用化描述，不指向特定企业。*
