导读

2026 年 arXiv 一项研究指出，企业多智能体 LLM 系统的生产部署失败率高达 41%–86.7%，近 79% 的失败根源并非模型能力不足，而是规范定义不清和协调机制缺失；
Gartner 预测到 2027 年底，超过 40% 的 agentic AI 项目将被取消。这些数字的背后，是大量团队在没有搞清楚"自己到底在做一个 Workflow 还是一个 Agent"的情况下，就把系统推向了生产环境。
本文结合 Anthropic 官方框架、多家企业的真实踩坑案例，以及一个多智能体集群的实战复盘，从六个维度给出可落地的选型与验收方法论。

一、问题的根源：为什么很多团队第一步就错了

1.1 名字里的陷阱
"Agent"这个词在 2024–2026 年的 AI 圈子里已经被用滥了。
一个系统只要在某个节点上接了个大模型，就被冠以"智能体"的名号推向市场。
但 Anthropic 在 2024 年 12 月的官方定义中，对这两类系统做了清晰的切分：

概括：Workflow 是人画好路线图，AI 按图索骥；Agent 是人指定目的地，AI 自己开路。
判断一个系统本质上是 Workflow 还是 Agent，核心标准只有一个——控制权在谁手里，而不在于它用了什么模型、名字里有没有"Agent"。

1.2 术语说明：业界用法尚未统一
当前业界对"Agentic Workflow"与"Agent based on Workflow"的用法存在明显分歧，阅读不同资料时容易因术语混用而产生困惑。
部分平台将 Agentic Workflow 理解为"由 Agent 驱动的工作流"——即 Agent 掌控流程，路径由 LLM Planner 实时动态生成，每次执行可能完全不同；将 Agent based on Workflow 理解为"基于固定工作流封装的智能体"——即传统工作流引擎是底座，Agent 只是流程里的一个功能节点，只能处理分配给自己的局部任务。
本文采用的定义基于 Anthropic 2024 年 12 月发布的官方框架，从两个维度进行区分：
一是语法结构："agentic"作为形容词修饰"workflow"，主语仍是 workflow，"agent"作为"based on workflow"的主体，本质仍是 agent；
二是控制权归属：Workflow 的路径由人预设，Agent 的路径由 AI 动态规划。
（读者在阅读其他资料时，建议首先确认作者采用的定义框架，以避免概念混淆。）

1.3 混淆二者的代价
这种混淆是直接关系到项目生死的选型失误。
当前市场上有大量所谓的"Agent 方案"本质上仍是 Workflow——控制权在人手里，流程路径是预设的，AI 只是执行者。如果管理者按照 Agent 的标准去验收这样的系统（期待灵活性和创造性），或者按照 Workflow 的标准去验收真正的 Agent（要求每次输出完全一致），结果都是灾难性的。
澳大利亚联邦银行（CBA）2025 年上线的 AI 客服"Bumblebee"就是一个典型案例。
该系统宣称每周减少 2000 通电话并裁减 45 名客服人员，但实际通话量不降反升，最终因服务质量问题被撤回，被裁员工重新聘回。
复盘发现，银行用"通话量下降"这一确定性指标去验收一个概率性系统，完全忽视了客户满意度和问题解决率等统计性指标：本质上是用验收 Workflow 的逻辑在验收 Agent。

二、六维决策框架：从本质到落地

以下六个维度构成了一套完整的选型与验收方法论。

维度一：系统本质——确定性系统 vs. 概率性系统
这是所有后续判断的逻辑起点。
Workflow 是确定性系统：给定相同输入，输出可预测、可复现。每一个节点都有明确的输入、处理逻辑和输出，分支由人预先定义的条件语句控制。
Agent 是概率性系统：给定相同目标，输出存在不确定性。LLM 在每一步推理中都在概率分布中采样，路径选择、工具调用时机、异常处理策略都是动态的。

从工程实现角度看，这一差异直接决定了系统的可测试性：
Workflow 的可测试性：
输入 A → 节点 1 → 节点 2 → 节点 3 → 输出 B
（每次运行路径固定，可用单元测试覆盖）

Agent 的可测试性：
目标 X → [LLM 自主规划路径] → 输出 Y 或 Z 或 W
（每次运行路径可能不同，需用评估集统计质量分布）

落地原则：91APP 在 2026 年提出的分流原则值得每个团队看看：
能用 deterministic 解的就用 deterministic 解，剩下真的需要弹性判断的模糊部分，才交给概率性的模型。
企业在做技术选型时，首先判断的是任务的属性：规则明确、边界清晰的任务用 Workflow；动态变化、语义复杂的任务才用 Agent。

维度二：验收标准——稳定性优先 vs. 智能性优先
这是团队踩坑最集中的维度。
Workflow 的验收逻辑与传统软件工程一致：给定输入，验证输出是否符合预期。测试用例覆盖每一个节点、每一条分支、每一个边界条件。"通过"或"不通过"是明确的二元判定。

Agent 的验收逻辑传统的二元判定对概率性系统完全失效。Tian Pan 在 2026 年 4 月的研究中系统阐述了这一问题：LLM 驱动的功能没有单一的"正确"输出，而是存在一个输出分布——其中一些可接受，一些不可接受，大部分处于中间地带。

关键误区：把"跑通了"作为 Agent 系统的验收标准。
这在管理层中极为常见：Agent 在某几次运行中输出了看似合理的结果，项目就被判定为"验收通过"。这种做法的危险性在于：单次运行的成功不代表统计意义上的可靠。

CBA Bumblebee 案例复盘：银行用"通话量下降"（确定性指标）验收 AI 客服系统（概率性系统），忽视了服务质量、客户满意度和问题解决率等统计性指标。系统上线后表面数据"达标"，但内在质量隐患在生产环境中全面爆发，最终导致项目撤回、团队重建。

在工程实践中，将"感性判断"推向"结构化评估"的一种尝试是建立多维度质量审核机制。
例如，在构建多智能体集群时，可以设计一套基于"职业怀疑"理念的审计框架，将每次运行结果按 PASS / OBSERVATION / DISPUTED / ISSUE 四态分类审核。
这种模型的价值在于：将 Agent 输出的质量评估从"好或不好"的二元判断，推进到更具结构性和可追溯性的评估体系。

核心结论：对 Agent 系统的验收不是"一次性考试"，而是"持续评估"。
管理者需要建立定期运行的评估机制，监控质量分布的变化趋势。

维度三：故障排查——逐节点审查 vs. 自主诊断修复

Workflow 模式：人逐个节点查
流程路径是预设的，出问题后运维团队沿着路径逐节点排查日志、定位问题节点，开发团队定向修复。排查逻辑清晰：检查每一个环节是否按预设逻辑正确执行。团队不需要理解 AI 的"思维过程"，只需要验证节点执行的正确性。

Agent 模式：让 AI 自己查自己改
Agent 的路径是自主规划的，每次运行路径可能不同，"逐节点排查"失去了意义。故障排查思路需要从"定位问题节点"转变为"诊断目标达成情况"——评估 Agent 距离目标还有多远，然后让它自行调整策略重新尝试。

Amazon Q 案例复盘：2025 年，Amazon 面向企业工程师推出的 AI 助手 Amazon Q，在上线后一周内依据过时的内部 wiki 文档向工程师提供了错误的操作指导，直接导致四起高严重性生产事故，造成 630 万笔订单处理中断和 6 小时服务宕机。
事后调查发现，系统缺乏有效的边界约束和知识 freshness 监控：Agent 在自主调用工具和提供建议时，没有校验信息时效性，也没有在置信度不足时自动降级为人工审核。
这一事件表明：当 Agent 被赋予过高自主性却缺乏配套约束机制时，其概率性本质所带来的风险将直接转化为生产事故。

腾讯云作者”鱼片粥来碗豆腐“在 2026 年 4 月发布的自愈 Agent 实践中，给出了一个系统性的技术实现方案：
自愈 Agent 的核心循环：
Monitor（监视器）实时观测 Agent 行为与输出
↓ 发现偏离预期
Reflection（反射模块）诊断失败原因
↓ 生成修正策略
Agent 调整后续行为
↓ 循环往复

人的角色重构
从组织管理视角，Agent 范式的引入是团队角色与权责分配的重新设计：

即使是最自主的 Agent 系统，也不意味着人类完全退出。
业界已形成的 Human-in-the-Loop（HITL）四级框架 提供了分层介入的标准：

在工程实践中，这一分级审核可以与自动化审计系统结合。
例如，构建多智能体集群时，可以设计 CAD（Consensus Audit & Dispute）审计机制：
免疫系统：通过四项红线（事实一致性、逻辑一致性、安全合规性、资源可控性）自动审查每次 Agent 输出
熔断器：系统负载超阈值时自动触发三级降速（观察→限速→熔断）

核心理念：信任 Agent 的智能，但更信机制的设计。

维度四：流程演进——先设计还是先运行

传统 Workflow 范式：流程图先行
流程在上线前就必须定义清晰。业务分析师与架构师梳理全流程，开发团队编码实现，测试团队逐节点验证。优势在于前期规划充分、上线后风险可控。
Agent 驱动范式：流程自涌现
人只定义目标和约束条件，不预设具体路径。Agent 在运行中自主探索，多次运行后可靠路径被沉淀为标准 workflow，不稳定路径自动淘汰。
四种协作模式的技术实现
Anthropic 归纳的五种 workflow pattern 从控制权角度看，构成了一条从"完全控制"到"高度放手"的光谱：

控制权下放光谱：

Prompt Chaining（提示链）
→ Routing（路由）
→ Parallelization（并行化）
→ Orchestrator-Workers（编排器-工作者）
→ Evaluator-Optimizer（评估器-优化器）
→ Agent（完全自主）

控制强度： 100% → 80% → 60% → 40% → 20% → 0%

在更复杂的 Agent 集群场景中，协作模式可归纳为四种基本形态：

这四种模式是一条控制权逐步下放的连续路径。每一步都建立在前一步的能力基础之上，每一步也都引入新的治理挑战。

流程固化的时机

Agent 探索成果何时沉淀为标准 workflow？
需同时满足三个条件：
稳定性：某条路径在多次运行中表现出一致可靠性
效率性：该路径的执行效率显著优于替代路径
可解释性：决策逻辑可被人类理解和审计

企业最佳实践：双轮循环
当前业界最前沿的实践是将"探索"与"固化"整合为持续运转的双轮循环。
火山引擎 2025 年提出的 ArkClaw + HiAgent 架构 是典型代表：
ArkClaw（敏态）：允许一线自由探索，沉淀可复用的 Skills 与工作流
HiAgent（稳态）：将经验证的最佳实践流程化、标准化，纳入企业智能体体系
反哺循环：标准化能力以 Skill/API/插件形式反向赋能探索端，降低创新成本

观测云在 AIOps 领域的实践也遵循类似路径：先鼓励工程师用 Agent 解决问题积累模式，再将验证过的模式抽象为 Skill 交付给全团队。

维度五：成本与回报——可预测支出 vs. 智能溢价

确定性成本 vs. 不确定性成本
Workflow 的成本结构是可预测的：每个节点的调用次数、token 消耗、API 费用都是预定义的，总成本与任务量呈近似线性关系。财务部门可以建立成本模型，与供应商签订用量定价协议。

Agent 的成本结构则高度不可预测。相同输入可能因不同推理路径导致 token 消耗相差数倍。Elementum.ai 在 2026 年的分析中指出，Agent 链式调用中每一次推理、每一次重试、每一次上下文查找都会触发 LLM 调用，成本在价值实现之前就开始累积。更棘手的是长尾风险：极端情况下 Agent 可能陷入循环推理，单次运行成本飙升至预期的数十倍。

决策原则：不可替代性
91APP 的分流原则在经济层面同样适用：每将一个确定性环节替换为概率性环节，都在增加成本的不确定性。这种"不确定性溢价"必须有对应的"智能收益"来对冲。
在工程实践中，这一原则体现为对 Agent 集群的"减法优化"——系统性地审视每个智能体的存在必要性，识别出处理规则明确任务但披着"Agent"外衣的组件，将其替换为确定性方案。只保留那些真正需要跨系统校验、非结构化语义推演或复杂协调能力的智能体。
这种"不可替代性原则"的实践表明，概率性组件的数量应与任务实际复杂度相匹配。

Agentic ROI 三阶段模型
CrewAI 创始人 Joao Moura 提出的三阶段模型，为评估 Agent 投资回报提供了实用框架：

Agentic Workflow 更适合第一阶段的"成本节省"：确定性特征使降本效果可量化；
Agent based on Workflow 更适合第二、三阶段：概率性特征虽增加不确定性，但打开了更大的价值空间。

维度六：落地指南——选型决策表与验收清单
六维决策对照表

Agentic Workflow 验收 Checklist(例）
[ ] 所有节点均有预设的输入、处理逻辑和输出定义
[ ] 测试用例覆盖所有分支路径和边界条件
[ ] 回归测试通过率 > 95%
[ ] 相同输入下输出可复现
[ ] 故障排查文档完备，每一步可追溯
[ ] 成本模型已建立，单位任务成本可预测
[ ] 上线后监控体系已部署

Agent based on Workflow 验收 Checklist（例）
[ ] 目标定义清晰，约束条件明确
[ ] 评估集（eval set）已建立，覆盖代表性输入分布
[ ] 三层质量线（最低/目标/理想）已定义并量化
[ ] 多轮运行统计数据已收集，质量分布可观测
[ ] 自愈机制已部署（Monitor + Reflection）
[ ] 成本监控与熔断机制已配置
[ ] HITL 分级审核机制已落地
[ ] 审计机制已部署，Agent 行为可审计、可追溯

三种最常见的选型与验收误区
误区一：用验收 Workflow 的方式验收 Agent
要求 Agent 系统每次输出完全一致，用单一测试用例判定"通过"。纠正：Agent 应基于统计评估，关注质量分布而非单次输出。
误区二：用 Agent 的灵活性要求苛责 Workflow
期待 Workflow 处理未预设的边界情况，抱怨其"不够智能"。纠正：Workflow 的核心价值是稳定性，不应以灵活性标准评估。
误区三：混淆名字和本质
因方案名称带"Agent"就按 Agent 标准验收，或因系统用了 LLM 就认为具备 Agent 自主性。纠正：判断标准是控制权归属，而非产品名称或技术栈。

三、总结：从软件工程到智能体工程的范式转移

Agentic Workflow 与 Agent based on Workflow 的辨析，表面上是技术选型问题，深层上是管理思维范式的转移。
软件工程建立在确定性假设之上：相同输入产生相同输出，验收是一次性判定。
智能体工程必须接纳概率性：输出是分布而非点，验收是持续过程，团队角色从"修理工"变为"审核员"和"环境设计师"。

最高效的 AI 战略不是二选一，而是在清晰边界内让二者协同运转：用 Workflow 保障底线，用 Agent 探索上限，在"探索"与"固化"的持续循环中，逐步构建企业级的智能体能力资产。

参考

Anthropic. Building Effective Agents. 2024-12. https://www.anthropic.com/engineering/building-effective-agents
Tian Pan. Writing Acceptance Criteria for Non-Deterministic AI Features. 2026-04. https://tianpan.co/blog/2026-04-17-acceptance-criteria-non-deterministic-ai
Joao Moura (CrewAI). Agentic ROI: The Three-Stage Model. 2025-04.
91APP. 确定性/概率性分流原则. 2026-06.
腾讯云. 自愈 Agent 实践：Monitor + Reflection 机制. 2026-04.
火山引擎. ArkClaw + HiAgent 双轮架构. 2025-10.
观测云. AIOps 两步走建设路径. 2025.
Elementum.ai. Agent Cost Structure Analysis. 2026-03.
Human-in-the-Loop Framework. Four-Level Review Mechanism.
arXiv. Semantic Consensus in Multi-Agent LLM Systems. 2026-03.
Gartner. Agentic AI Project Cancellation Prediction. 2026.
TechRadar / AP News. CBA Bumblebee AI Chatbot Withdrawal. 2025.
awesome-agent-failures. Amazon Q Production Incident Case Study. 2025.

【看山 Agent 架构】

工信部 AI 技术应用（高级）认证

30次集群崩溃复盘 | 20+智能体实战

深耕 Agent 集群架构，用商科思维重构复杂系统效率

注：本文内容由 AI 辅助创作，作者对内容结果负责