别再什么都 Agent 化了：一张矩阵，分清"金矿"和"烧钱"

> **企业 AI 化的四层工程体系 · 第 ② 篇** > 从"什么都能 AI"到可判断：企业 Agent 化的场景选择框架 --- ## 引言：信了 Agent 化之后，下一个坑更贵 上一篇我们讲清了一件事：把大模型当 API 的企业，正在输给把它当系统的企业。很多读者看完很兴奋，回去就想把公司里的流程一个一个都 Agent 化。 但我必须泼一盆冷水。**"该不该做 Agent 化"被讲透之后，紧接着的问题——"哪些该做、哪些不该做"——如果答错了，代价比前一个坑更贵。** 为什么？因为热情会驱动企业走向另一个极端：FOMO（错失恐惧）之下，什么都想上 Agent。结果钱烧了一大把，做出来的东西不是用确定性脚本三行代码就能搞定，就是复杂到根本跑不可靠。Gartner 甚至预测，**到 2027 年会有 40% 的企业把已上线的自主 Agent 降级或下线**——其中相当一部分，根本就是一开始场景就选错了。 所以这一篇，我们不谈热情，只给框架。本文要解决的核心问题是：**面对一个具体的业务流程，你如何在三十秒内判断出，它到底是 Agent 化的金矿，还是 Agent 化的陷阱？** 答案是一张二维矩阵。但在画出它之前，我们得先拆掉一个更流行、也更有害的东西——清单式思维。 --- ## 一、为什么"5 类适合场景"这种清单，会害了你 打开任何一篇讲"哪些场景适合 AI Agent"的文章，你大概率会看到一份清单：信息密集型决策、高频重复任务、多源信息整合、复杂规则判断、长链路流程……看起来很全，很专业。 但这种清单有一个致命缺陷：**它不是 MECE 的（相互独立、完全穷尽），所以它无法帮你判断一个新场景。** 举个例子。"企业采购"算哪一类？它是信息密集型决策——要分析供应商、比价格；它也是多源信息整合——要汇总市场、合规、历史数据；它还是长链路流程——从需求到下单要走十几步。**一个场景同时落进三个分类，你说它该不该做？清单不会告诉你。** 清单式思维的问题，在于它给的是**标签**，而不是**坐标**。标签是离散的、会重叠的、解释不了边界情况的。而坐标是连续的——任何一个新场景，你都能在坐标系里给它定个位，然后一眼看出它的命运。 所以，我们要做的不是背一份更长的清单，而是找到**几根本质的轴**，把所有场景放进同一个坐标系里去判断。 经过抽象，企业 Agent 化的场景判断，本质上只取决于三个维度，外加一道闸门：  前两个维度（不确定性、链路长度）构成判断的主平面——也就是那张二维矩阵；第三个维度（信息密度）决定"值不值"；最后那道治理闸门决定"敢不敢"。我们一个一个来。 --- ## 二、第一根轴：不确定性——路径能不能被预先编排 第一根轴，纵轴，叫**不确定性**。它问的问题只有一个： > **这个任务的执行路径，能不能被人预先用 if-else 完整编排出来？** 这正是上一篇 workflow 与 agent 之分的延续。如果能——你能把所有的分支、所有的情况都写成确定的规则，那么这个任务的不确定性就低，它属于 **workflow / 规则系统** 的地盘，根本不需要 Agent 的自主决策。硬上 Agent，等于请了一个会走神的高级顾问，去做一件本可以用计算器完成的事。 如果不能——输入太复杂、情况太多、判断散落在难以穷尽的灰色地带，路径必须边走边定，那么它的不确定性就高，这才是 Agent 真正的主场。 给你一个屡试不爽的判据：**拿起笔，试着把这个任务的处理逻辑写成 if-else。** - 如果你能在一张纸上写完，且覆盖了绝大多数情况——不确定性低。 - 如果你写着写着发现"这里要看具体情况""那里得人工判断""例外太多写不完"——不确定性高。 写不完的那部分判断，正是 Agent 要替你扛的东西。合同审查为什么适合？因为每一份合同的措辞、风险点、上下文都不同，你永远写不完所有规则。固定的工资计算为什么不适合？因为它的每一条规则都能写死，没有任何需要"判断"的灰色地带。 还要补一句，免得你把它当成非黑即白的开关：**不确定性是一条连续谱，不是 0 和 1。**很多场景卡在中间，最典型的是"合规检查"——规则是存在的（看似确定），但规则的表述往往模糊、有例外、要结合上下文解读（其实很不确定）。这种"规则复杂但难以穷尽"的场景，纵轴位置偏高，恰恰是 Agent 能补规则系统短板的地方。判断时别只问"有没有规则"，要问"规则能不能被完整地写死"。 **纵轴越往上，路径越无法预编排，Agent 的价值越大。** --- ## 三、第二根轴：链路长度——任务到底有多少步 第二根轴，横轴，叫**链路长度**。它问的是： > **这个任务，是一次输入一次输出就能搞定，还是要走很多步、带着状态、可能要重试？** 这根轴极其重要，因为它决定了你需不需要"闭环"。 **单步任务**——比如把一段文本分类、从一句话里抽取字段、把一段话改写润色——一次结构化的 LLM 调用就够了。它们确实用了大模型，但它们不需要 loop、不需要状态管理、不需要重试编排。**给一个单步任务套上完整的 Agent 框架，是最常见的过度工程。**你不是在做 Agent，你只是在给一次 API 调用穿了一身昂贵的盔甲。 **长链路任务**——比如端到端的采购、从招标文件解析到投标书准备、复杂工单的全流程处理——它们有很多步，每一步的输出是下一步的输入，中间会出错、要重试、要维护状态。这时候，你才真正需要一个闭环 Agent。 但长链路有一个反直觉的陷阱，必须讲清楚：**链路越长，可靠性不是线性下降，而是复利式衰减。** 假设你的 Agent 每一步都有 95% 的可靠性，听起来很高。但请看这笔账（示意计算）： - 走 10 步，整体可靠性 ≈ 0.95¹⁰ ≈ **60%** - 走 20 步，整体可靠性 ≈ 0.95²⁰ ≈ **36%** 每一步看似只丢一点点，但乘起来，二十步之后只剩三成。**这就是为什么链路不能无限长。** 一线工程实践给出了非常具体的经验阈值（来自「12-Factor Agents」社区的共识）：**3 到 10 步是理想区间，20 步是实际上限。**超过这个数，你不该让一个 Agent 硬扛整条链路，而该把它拆成几个可靠的子任务，或者在关键节点引入校验和人工兜底。 那超过 20 步、又确实需要 Agent 的长链路怎么办？不是不做，而是**拆**。常见的三种拆法：一是把长链路切成几个**职责单一的子任务**，每个子任务自己是一个 3–10 步的小闭环，子任务之间用确定性代码串接；二是在关键节点插入**校验关卡**，把可靠性的复利衰减在中途"重置"，错了当场拦截而不是攒到最后；三是在高风险或高不确定的拐点，引入**人工兜底**。换句话说，链路太长时，真正的解法不是"让一个 Agent 更聪明地扛二十步"，而是"用工程把二十步拆成几个能各自做到高可靠的短闭环"。 **横轴越往右，步骤越多，越需要闭环——但也越需要工程把可靠性的复利衰减摁住。** --- ## 四、两轴交叉：四象限判断矩阵（核心） 把两根轴交叉，企业里所有的"认知类任务"，都会落进四个象限之一。这张矩阵，就是本文最该被截图保存的部分。  我们逐个象限拆解，并顺手把那些流行清单里的场景，安放到它们真正该去的地方。 **右上象限：高不确定 × 长链路 —— 理想 Agent 区。** 这是 Agent 真正能创造价值的金矿。路径无法预编排（需要判断），链路又足够长（需要闭环）。合同审查、招投标分析、端到端采购、投标书准备——这些就是上一篇反复提到的场景。流行清单里的"信息密集型决策""多源信息整合""长链路流程"，本质上全都落在这个象限。**它们不是三类不同的场景，它们是同一个象限的不同侧面。** **左上象限：高不确定 × 单步 —— 单点 LLM 调用区。** 需要判断，但只有一步。比如把客服工单分类、判断一段评论的情绪、从简历里抽取关键信息。这些确实需要大模型的语言理解能力，但它们是单步的——**一次精心设计的结构化调用就够了，硬套 Agent 框架纯属增加复杂度和成本。**很多团队的第一个错误，就是把本属于这里的任务，过度工程化成了一个 Agent。 **右下象限：确定 × 长链路 —— 传统 workflow / RPA 区。** 步骤很多，但路径是死的。比如一个固定的多级审批流、一个跨系统的数据搬运流程。它们看起来"复杂"，但复杂在步骤数，不在判断。**这种场景用确定性的工作流引擎或 RPA 来编排，又快又稳又便宜。**用 Agent 去做，等于让大模型在每一步都"想一想"本来不需要想的事——慢、贵、还引入了不必要的不确定性。 **左下象限：确定 × 单步 —— 别碰区。** 路径确定、又只有一步。纯计算、固定换算、字段映射。**写个脚本或一条规则，三行代码搞定。**任何想在这里上 AI 的冲动，都是把简单问题复杂化。流行清单里说的"高确定性纯计算不适合 AI 化"，说的就是这个象限。 至于那些"强物理执行"的场景（物流实操、产线动作），它们根本不在这张认知任务矩阵里——那是执行层的事，不是判断层的事，自然也不在 Agent 的讨论范围内。 **实战定位：把几个常见场景丢进矩阵。** 光看四个象限的定义还不够直观，我们拿几个企业里最常见的场景，现场定位一遍： - **市场情报 / 竞品分析**：信息散落在几十个来源、要持续追踪、要交叉判断——高不确定 × 长链路 × 高信息密度，妥妥的**右上金矿**。 - **供应链分析**：多源数据汇总 + 异常判断 + 多步推演，同样落在**右上**。 - **客服工单分类**：要理解意图、判断情绪，但只有一步——**左上单点调用区**。一次结构化调用就够，别套 Agent。 - **固定规则的报价生成**：如果你的定价完全能写成 pricing rules（确定）、且要走多步审批（长链路）——这是**右下 RPA 区**，用工作流引擎，别用 Agent。 - **数据录入与校验**：规则确定、动作单一——多半落在**左下别碰区**，写校验脚本即可，除非其中夹着大量需要判断的异常。 注意到一个关键现象没有？**同一个"业务"，在不同粒度下会落进不同象限。** 拿"客服"举例：单看"工单分类"，它是左上的单步调用；但如果你要做的是"从接收工单、检索知识库、判断、起草回复到关单"的**全流程闭环**，它立刻变成右上的理想 Agent 区。"报价"也一样：标准化报价是右下的 RPA，非标的、要谈判要判断的复杂报价则是右上的 Agent。 **所以用矩阵判断时，第一步永远是先界定清楚：你要 Agent 化的，到底是这个业务的哪一个粒度的环节？**粒度选错，象限就错，结论自然全错。这也是为什么流行清单会让人困惑——它给的是"业务名词"，而业务名词跨越多个象限；矩阵给的是"环节坐标"，坐标才唯一。 **一句话记住这张矩阵：只有右上象限，才是 Agent 化该全力投入的地方。** --- ## 五、第三个维度：信息密度——决定"值不值" 但落在右上象限，就一定该做吗？**不一定。**还要看第三个维度：信息密度。 信息密度问的是：**这个任务要处理的信息，是不是分散、多源、非结构化、且量大？** 这个维度，决定的不是"能不能做"，而是"值不值得做"——它是矩阵里那个气泡的大小。 为什么信息密度这么关键？因为信息越密集、越分散，**人来做就越痛苦、越低效、越容易出错**，Agent 替代它创造的价值就越大。一个要从二十份文件里交叉比对、汇总判断的任务，人做一天，Agent 做几分钟——这种地方，ROI 才高。 反过来，即使一个任务落在右上象限（高不确定 × 长链路），但如果它信息稀薄、频率极低——比如一年才发生两三次的某种特殊决策——那么投入工程资源去 Agent 化，账可能算不过来。**右上象限是必要条件，高信息密度才让它变成充分条件。** 把两个都在右上象限的任务摆在一起，对照就清楚了。一个是"竞品情报追踪"：信息来自几十个分散、异构、每天更新的来源，人要持续盯、反复比、不停判断，每周耗掉分析师大量工时——信息密度极高、频率极高，Agent 化的 ROI 高得吓人。另一个是"某类一年发生两三次的非标合规裁决"：它确实也需要判断、也有多步，但信息集中、案例稀少、频率极低——花三个月做一个 Agent，可能还不如让专家直接处理来得划算。**两者都"能做"，但只有前者"值得做"。**这就是信息密度这根第三维存在的意义：它把"技术上可行"的一堆场景，进一步筛成"经济上值得"的少数几个。判断时别只盯着象限，一定要追问一句——这件事，人做起来到底有多痛、多频繁？痛点越深、频次越高，价值越大。 这里还藏着一个对后续文章的预告。业界一个被反复验证的发现是：**大多数 Agent 的失败，是 context（上下文）的失败，而不是 model（模型）的失败。**当 Agent 给出离谱的答案时，底层模型通常没坏，坏的是你喂给它的信息。而信息密度高的场景，恰恰是最考验"喂什么信息进去"的地方——它价值最大，工程也最难。如何把高密度、多源的信息正确地组织进模型，正是本系列第④篇《Context 工程》要专门解决的硬骨头。 所以判断一个场景的完整三维是：**不确定性（该不该）× 链路长度（要不要闭环）× 信息密度（值不值）。**三者都高，才是真正的金矿。 --- ## 六、能做 ≠ 该做：矩阵之外的"治理闸门" 走到这里，你可能以为判断结束了。但还差最后、也是最容易被工程师忽略的一道闸：**治理可行性。** 一个场景哪怕完美落在金矿象限、信息密度也高，如果它涉及高风险动作——动钱、改权限、对外发布、签署承诺——那么"技术上能做"不等于"现在就该放手让 Agent 做"。 Gartner 那个 40% 的预测，根因正在于此。他们点出一个尖锐的判断：很多企业把 Agent 治理当成一道二元开关——**要么彻底锁死，要么完全放任**，却从不区分两件根本不同的事： - **Agent 的"行动能力"**（它能做多复杂的判断） - **Agent 被授予的"访问范围"**（它能碰多大权限的资源） 把这两者混为一谈，就会要么因为怕风险而什么都不敢上，要么因为图省事而把过大的权限交给一个还不够可靠的系统——后者，正是那 40% 在生产事故后才追悔莫及的来源。 正确的做法是**分级授权 + 人在环（human-in-the-loop）**：让 Agent 自主处理低风险、高频的常规情况，而把高风险、高影响的动作，作为"一等公民"路由给人来确认。这套人机协作的运营模型，是本系列第⑧篇《人机接力》的主题，这里先埋下伏笔。 举个具体的例子。同样是"采购 Agent"，落在金矿象限，但它的不同动作要走不同的授权级别：检索供应商、汇总比价、起草采购建议——这些是**只读、可逆**的低风险动作，放手让 Agent 自主做；而真正"下单付款""签署合同""对外发出报价"——这些**动钱、不可逆、对外有约束力**的动作，就必须卡一道人工确认，或者设一个金额阈值，超过就强制升级。**同一个 Agent，能力可以很强，但访问范围要按动作的风险分级收放**——这正是 Gartner 说的"区分行动能力与访问范围"。把这条做对，你既享受了 Agent 的自动化，又不会成为那 40% 在事故后追悔的企业。 这道闸门还有一个纯工程层面的提醒：**即使在理想象限，工具也不是越多越好。**一线实测数据显示，当一个 Agent 可用的工具从 3 个增加到 12 个时，它选对工具的准确率会从 95% 暴跌到 70%。所以哪怕场景再合适，落地时也要把工具按子任务拆开、每个环节只暴露必要的那几个——这既是可靠性的要求，也是治理的要求。 **记住：矩阵告诉你"能不能做"，治理闸门告诉你"敢不敢现在就全放开"。两者都过，才真正可以动手。** --- ## 七、一个可操作的判断流程 把前面所有的维度收拢成一个可以照着走的决策流程，你就有了一把随手可用的"场景筛子"。拿到任何一个候选流程，按下面四问走一遍，结论自然浮现。 ​ 四个问题，对应四个维度： 1. **路径能预编排吗？**（不确定性）——不能，才往下走。 2. **要走很多步吗？**（链路长度）——多步且有状态，才需要闭环；记住 3–10 步是理想，超 20 步要拆。 3. **信息密集吗？**（信息密度）——越密集、越多源，价值越大，ROI 越高。 4. **治理过得了吗？**（闸门）——高风险动作能否分级授权、人在环，决定你现在就全放开，还是先建护栏。 四问全部命中右侧，恭喜，你找到了一座 Agent 化的金矿。任何一问掉到左侧，它就该用更简单、更便宜、更可靠的方式去解决。 --- ## 结论：先选对战场，再谈怎么打 回到开头那盆冷水。Agent 化最贵的浪费，从来不是"不敢做"，而是"做错了对象"——把脚本能解决的事做成了 Agent，把 RPA 该干的活交给了大模型，把一个一年发生两次的低频任务包装成了酷炫的智能体。 这篇文章想留给你的，是一句可以反复使用的判断口诀： > **AI Agent 的金矿 = 高不确定性 × 长链路 × 高信息密度，且过得了治理闸门。** 它不是一份要背诵的清单，而是一套可以套用到任何新场景的坐标系。下次再有人兴冲冲地说"我们这个流程也用 Agent 吧"，你不必凭感觉争论，只需把它往矩阵里一放，命运一目了然。 如果你是技术决策者，现在就可以做一个练习：**拿出你手上正在考虑 AI 化的三个流程，逐个用上面的四步判断走一遍，给它们在矩阵里定位。**你大概率会发现，其中至少有一个，本该用脚本或 RPA，而不是 Agent。 最后，留一个问题，也作为下一篇的引子： **假设你已经用这张矩阵，锁定了一个落在"理想 Agent 区"的业务流程——比如招投标分析。那么接下来，你该如何把这个活生生的业务流程，一步步拆解成一个可以工程化实现的 Agent 设计？** 从一个"流程"到一张"Agent 设计图"之间，还隔着一套方法论。如何识别其中的认知节点、决策点、工具点和失败点，把模糊的业务语言翻译成清晰的工程蓝图——正是本系列**第③篇《如何拆解业务场景 → Agent 化设计方法论》**要解决的问题。 我们下一篇见。 --- *本文为「企业 AI 化的四层工程体系」系列第 ② 篇。上一篇我们回答了"为什么必须做 Agent 化"，这一篇回答了"哪些场景值得做"，下一篇起，我们将进入"具体怎么做"。*