Agentic 的边界悖论：为什么企业 Agent 项目大多失败

一、Agentic 的承诺，与它隐含的前提

Agentic 范式承诺两件事：一是处理动态需求，不依赖预先写死的流程，能够面对未预先定义的情况；二是发挥自主性，在一定范围内自行判断、决策、调用工具并完成任务。

但这两点成立有一个被普遍忽略的前提：设计者必须知道“动态”的范围在哪里、“自主”的边界划在哪里。 也就是要回答三个问题：哪些情况 Agent 可以自己决定？哪些情况必须停下来交还给人？判断“该自己做还是该交人”的标准是什么？

如果边界不明确，Agent 面对的是一个它无法真正理解的开放情境。此时的问题往往不是“多走一步还是少走一步”，而是更直接的失败：它持续给出错误结果，始终交不出可用的产出；严重时产生幻觉，编造事实、虚构流程，输出完全脱离现实。 到了这一步，团队既不敢让它自主，也无法靠频繁人审把它拉回正轨——因为人审的成本已经接近重新做一遍，Agent 也就失去了存在的意义。

二、为什么这个边界定义不出来

现实困境在于：连设计者自己也说不清动态需求的边界在哪里。

企业场景的需求不是项目启动时就完整存在的，它是在实施过程中逐渐浮现的。你以为要解决的是问题 A，做着做着发现真正的约束在 B，而 B 又依赖于 C 的组织流程——这些只有在落地时才会暴露。

换句话说，边界不是被“设计”出来的，是被“实施”出来的。 但 Agentic 的运行方式又要求你先把边界给它，它才能自主运行。这构成一个先后矛盾：

• 你需要先知道边界，才能让 Agent 自主；
• 但你只有在运行中才能知道边界；
• 而 Agent 在边界不清时又无法可靠地自主运行。

三、AI 自身无法弥合这个缺口

如果 AI 能在运行中自己搞清楚边界，这个矛盾就能化解。但目前它做不到，原因有二。

1. 缺乏“把握度”：既无现实感知，也无承担后果的经验

企业场景里大量判断关乎分寸：这件事该不该现在做、做到什么程度算够、风险大不大、要不要升级处理。这类判断很难，难点不在信息多少，而在“度”。

需要说明的是，分寸感并不是“人在现实里”就自动具备的东西。 很多程序员同样天天身处现场，照样把度把握不好：该升级的没升级，该收口的过度设计，该停下来的继续加码。可见仅有对现实的感知还不够。资深工程师和新手看到的现实是一样的，差别在于前者为自己的判断承担过后果——做对过、做错了、被反馈过，长期下来沉淀出一种无法被完整写下来的隐性判断。

AI 在这件事上缺了两层。其一，它没有感知现实的通道，接触到的只是被转写成文本的内容，而客户的语气、现场的气氛、团队真实的负载、那些没说出口的轻重缓急，无法被完整、及时地转写进文本。其二，也是更深的一层，它没有“做出判断—承担后果—据此校准”的经验回路：它不会因为一个判断失误而真实受损，也就没有动力和素材去形成属于自己的分寸感。

所以问题不是“上下文给得够不够”，而是分寸感根本无法靠文本堆砌获得。人即使作为媒介把现实转述给它，也必须同时把那个已经被经验校准过的判断一并提供出来——而能做到这一点的人，本身就是团队里最稀缺的角色。AI 能生成答案，但无法独立判断这个答案在真实情境里是否合适、是否越界。

2. 没有真正的自我学习进化能力

人在实施中会根据反馈重构自己对问题的理解：原来这个需求不是我想的那样，下次换个做法。这是一种对问题框架本身的修正。而目前的 Agent 即使具备记忆和反馈循环，也主要是在既定框架内累积经验，难以自主发现“我对问题的理解本身就是错的”并据此重构边界。它不会在实施过程中自己长出新的职责边界。

四、人也在动态学习，边界因此一直在移动

实施过程对人来说同样是一个学习过程。人也是边做边明白：这个场景真正的痛点是什么；哪些环节真能交给 AI，哪些交出去一定出事；组织能接受多大程度的自主。

所以人机边界不是一次性划定的静态线，而是一条在实施中不断移动的线。人在学习、在调整预期，而 AI 跟不上这种移动——它既不感知边界已经变了，也不会自己重新对齐。

五、致命的一环：需求一旦清楚，就不再需要 Agent 了

前面的困境已经足够棘手，但还有一个更深的反讽，它让整个问题从“执行困难”变成“范式层面的自相矛盾”。

当设计者终于把动态需求摸清楚、把人机边界划出来、把流程落地下来之后，会发现这个需求已经足够稳定和结构化，完全可以用普通的程序和工作流来实施。

于是出现了一个时间错配：

• 需求不清楚的时候，正是最需要 Agent 自主应对动态性的时候——但此时没有边界，Agent 无法可靠地自主；
• 等需求被人的实施和学习弄清楚了，Agent 终于有了可以安全运行的边界——但此时这个边界内的事情已是确定性流程，写死的程序和工作流做得比 Agent 更稳定、更便宜、更可控。

六、完整的失败链条

把所有环节串起来，失败是结构性的，而非执行不到位：

Agentic 需要清晰的人机边界才能自主
        ↓
边界无法在设计阶段确定，只能在实施中浮现
        ↓
实施中边界随人的学习而移动
        ↓
AI 无现实感知、无后果校准的分寸感，也不重构问题框架
        ↓
等边界终于被人和实施过程确定下来
        ↓
需求已足够结构化 → 确定性程序/工作流即可实现
        ↓
Agentic 的自主性在这个场景里已无存在必要
        ↓
真正需要自主的（不确定）阶段它做不了；
它能安全做的（确定）阶段不需要它
        ↓
项目失败，或退化成“套着 Agent 外壳的工作流”

七、这解释了一个普遍现象

很多号称 Agentic 的企业项目，做到最后实际上变成了：

• 用大模型做几个固定节点的信息抽取或分类；
• 用确定性工作流引擎串起这些节点；
• 关键分支全部用规则和人审兜底；
• 所谓“自主规划”要么被关掉，要么只在无关紧要处展示。

这不是团队能力不足，而是边界悖论的必然结果——当一个需求真的被跑通并落地，它的结构就稳定到了不需要自主性的程度。

八、由此得到的定位启示

如果边界不是设计出来的、而是在实施中浮现的，那么企业 Agent 项目真正的关键就不是选型、框架或模型能力，而是谁在实施过程中持续地界定人机边界。

这个界定工作贯穿项目始终，而不是一次性的前期设计或末期交接。它要在实施中不断回答两类问题：

• 哪些环节必须由人做反馈和抉择——分寸的拿捏、后果的承担、对现实情境的判断；
• 哪些工作可以交给 AI 实施——边界已经相对清晰、错了代价可控、结果可被验证的部分。

而且这条线会随着人对需求理解的深入而移动：今天需要人抉择的环节，明天可能因为规律被摸清而下放给 AI；今天交给 AI 的环节，也可能因为踩到新的现实情况而被收回。界定边界本身就是实施的核心内容，而不是实施开始前的一道手续。

这里有一个常被忽略的前提：这件事必须由一个具备逻辑抽象能力、能在实施中快速自主学习的人来完成。 他要能从零散的试错和反馈中提炼出稳定的判断规则，判断哪些是偶发情况、哪些会反复出现；要能识别“度”的位置，知道哪一步再往前交出去就会失控。没有这样一个角色，边界要么迟迟定不下来，要么被错误地固化，项目自然失败。这不是补上更多工程师或更大模型能替代的。

因此，对企业 Agent 的现实定位应当是：

• 不追求一上来就部署一个自主 Agent 去跑业务。 边界未定时，完全自主必然越界；能被完全写死的流程，又不值得用 Agent。
• 把“在实施中界定人机边界”作为项目的主线工作，由具备抽象和学习能力的人主导，Agent 作为其在边界内探索、试错、归纳的执行工具。
• 边界随认知迭代而调整，稳定一部分就沉淀为工作流，新暴露的部分再回到人与 Agent 的协作中处理。工作流不是项目结束时的一次性产物，而是边界界定过程中持续生成的沉淀。

九、顺带一提：哪些任务才适合 Agent 自由探索

这并不意味着 Agent 的自主性毫无用处，而是要用对地方。适合它自由探索的任务，基本都落在第七节那两个条件的交集里——答案无法预先结构化，且试错成本可承受。具体来说有几类：

• 资料归纳与方案对比。 围绕一个相对明确的主题搜集已有资料、对比多种现成方案、梳理成结构化结论。信息空间是已知的，重点在归纳整理，漏掉一点或方向偏了，人一眼就能纠正。
• 创意与内容生成。 文案、命名、故事、设计发散。产出本就是“多给几个版本供人挑”，错了不伤筋骨，越发散反而越有价值。
• 探索性研究。 在结果本身就未知的领域里铺开搜索——陌生技术方向的调研、大量线索的初步筛查、多个假设的并行试探。这类工作靠人力做又慢又繁重，人真正的瓶颈是遍历和筛选的速度；Agent 可以在短时间内大范围发散、试错、归纳，把人从繁重的遍历中解放出来，由人来判断哪些线索值得深入。
• 动态校验与流程试探。 Agent 不断自主生成测试输入去跑通和施压一个流程，根据返回结果再调整下一轮试探。以 RAG 问答系统为例：AI 可持续生成不同角度、不同难度、甚至带陷阱的问题，去检验检索是否命中、回答是否准确、哪里会产生幻觉，并针对暴露的薄弱点追问。这类校验靠人力既单调又难以覆盖全面，而 Agent 能持续、大批量、多维度地把一个流程的边界和缺陷主动探出来。

这类任务的共同点是：人始终是结果的验收者，而不是把决策权让渡给 Agent；Agent 负责发散和试探，人负责收敛和拍板。 反过来，一旦任务要求每个决策都正确、错误会产生实际业务后果、且答案应当被结构化固定下来——那它就该走工作流，而不是寄希望于 Agent 的自由探索。