别再只把大模型当API，当系统用的公司已领先

> **企业 AI 化的四层工程体系 · 第 ① 篇**

> 为什么现在必须做 Agent 化，而不是简单接入大模型

---

引言：那个惊艳的 demo，为什么上不了线？

几乎每一家认真投入 AI 的企业，都经历过同样的剧情。

技术团队接入了大模型，花两周时间做出了一个演示版本。会议室里，所有人都为之惊叹：它能解析合同、撰写报价、回复客服工单，回答得有理有据。老板当即拍板：上线，全公司推广。

然而，故事的第二幕接踵而至。真实数据涌入，各种边界情况层出不穷，模型时而胡言乱语、时而调用错工具、时而忘记三步前自己说过什么。**那个在演示中光彩夺目的系统，在生产环境中只有七八成的时间是正确的。**而对一个旨在替代人工流程的系统而言，“八成正确”几乎等同于“不可用”——因为你永远无法预测是哪两成出了纰漏。

于是项目陷入僵局。有人归咎于模型不够强大，有人抱怨 Prompt 调校不到位，还有人开始等待下一代模型的出现。

但真实的答案，与以上三种猜测都无关。**演示与生产之间的那道鸿沟，不是模型能力的鸿沟，而是工程范式的鸿沟。**它将“把大模型当作一个组件来调用”的企业，与“把大模型当作一个系统来构建”的企业分隔开来。前者在原地徘徊，后者已经在拉开差距。

这篇文章要回答的核心问题只有一个：**为什么“接入大模型”和“做 Agent 化”是完全不同的两件事，而后者才是企业 AI 化的真正分水岭。**

---

一、繁荣的假象：90% 的 AI 项目，为什么停在 demo

首先，我们要面对一个不那么令人愉快的判断：今天绝大多数企业的“AI 转型”，本质上是三种认知偏差的叠加。

**第一种偏差：把 AI 当 API。**以为接入大模型就像接入一个支付接口——传入参数，获取结果，调用完毕就结束。然而，大模型并非一个确定性函数。同样的输入，今天和明天可能给出不同的输出；上下文多一句或少一句，结论就可能发生逆转。你把它当作 API 来用，它却是一个有脾气、会走神、需要被管理的“概率组件”。

**第二种偏差：把“聊天助手”当功能。**以为在产品中添加一个对话框、安置一个“AI 助手”按钮，就完成了 AI 化。然而，对话框只是交互界面，并非真正的能力。真正的难点不在于让用户能提问，而在于让系统在用户提问之后，**可靠地、可追溯地、且成本可控地将事情完成**。

**第三种偏差：把 Prompt 当产品。**以为只要 Prompt 写得足够精妙，所有问题都能迎刃而解。于是团队陷入无休止的“咒语调优”，今天加上“请仔细思考”，明天修改一个示例。然而，Prompt 再精巧，它也是无状态、无记忆、无系统性的——它无法处理工具失败，无法管理多步流程的状态，也无法控制成本失控。

这三种偏差的共同结果，就是那道众所周知的墙。

一位资深 AI 工程师、HumanLayer 的创始人 Dex Horthy，在试遍了市面上几乎所有 Agent 框架之后，精准地总结道：**许多团队发现，AI Agent 在惊艳的演示之外，往往会撞上 70%–80% 可靠性的天花板——在系统中打转、发出畸形的工具调用、丢失状态。**他据此提出了著名的「12-Factor Agents」方法论。而这堵墙最残酷的地方在于：从 0 到 80% 很容易，靠模型本身就能达到；但从 80% 到 95%，则完全依赖工程能力。

下面这张图，展示了几乎所有 AI 项目都会经历的轨迹——唯一的区别在于，有的团队停在了墙前，而有的团队成功翻越。


有人可能会想：这是否因为团队技术水平不够？恰恰相反，这道墙连最顶尖的公司也必须硬啃。以知识管理平台 Notion 为例——为了将企业级的 Agent 能力真正投入生产，他们花费了数年时间，将整套 Agent 基础设施**彻底重建了四到五次**，最终才打磨出一套包含渐进式工具暴露、类 SQL 数据抽象、为模型消费优化的接口以及完整评估框架的系统。这不是调整几句 Prompt 就能跨越的沟壑，而是需要重建一整套工程底座。

另一个数字同样令人警醒：即便是 Anthropic 这样的团队，在复盘自家 Agent 系统时也发现，**工具调用失败出现在多达 36% 的对话里。**三分之一的交互会在“调用工具”这一环节出现岔子——这恰恰说明，幻觉拦截、工具可靠性、状态管理这些“脏活累活”，才是真正决定成败的关键，而它们没有一个能通过单纯提升模型性能来自动解决。

**结论很简单：模型提供了 80% 的智能，但剩下的 20% 可靠性，是工程问题，而非模型问题。**要解决工程问题，你必须首先承认：你要构建的不是一次调用，而是一个系统。

---

二、真正的范式转移：从 Software 到 System of Agents

如果说“接入大模型”是把 AI 当作软件中的一个新零件，那么“Agent 化”则意味着软件形态本身的一次迁移。这次迁移体现在三个层面。

**第一，从 Software 到 System of Agents。**

传统软件的逻辑是确定的：程序员编写好每一条 if-else 分支，系统就严格按照预设路径执行。而在 Agent 系统中，**每一个关键节点的“下一步该做什么”，由模型在运行时动态决定。**它不再是一条预先铺设好的轨道，而是一个能根据现场情况自主寻路的系统。

**第二，从 workflow 到 loop-based automation。**

工作流（Workflow）是线性的：A 做完做 B，B 做完做 C，路径是固定的。而 Agent 的核心是循环（Loop）：观察现状、做出判断、采取行动、校验结果、更新状态，然后回到下一轮观察——它会循环、会重试、会根据反馈进行调整。**Workflow 处理的是“路径已知的任务”，而 Loop 处理的是“路径未知、需要边走边定的任务”。**

**第三，从 rule-based 到 context-based decisioning。**

规则系统依赖人工将每一种情况写为规则，规则之外它便束手无策。而 Agent 依靠上下文进行决策——它读取当前任务的状态空间（检索到的信息、工具的输出、历史的决策），在规则难以穷尽的灰色地带中做出判断。这正是其能够处理“复杂但可表达”任务的根源所在。

但这里必须立刻踩下刹车，**说一句许多 AI 鼓吹者不愿提及的实话：并非所有场景都适合进行 Agent 化。**

强物理执行的环节（如物流、制造的具体操作）、高确定性的纯计算任务、以及极低频的业务流程，采用传统软件或简单规则反而更稳定、更经济。将这些场景硬塞进 Agent，无异于用一把会走神的瑞士军刀去拧一颗只需要螺丝刀的螺丝。**到底哪些场景值得 Agent 化，本系列第②篇将提供一个可操作的二维判断矩阵。**这一篇我们先把“为什么”这个问题讲透彻。

---

三、到底什么是 Agent？——一个需要“赚到”的定义

讲到这里，我们必须正面回答一个被许多文章含糊其辞地略过的问题：**Agent 到底是什么？**

市面上流行的定义大多是抛售式的，比如“能自主完成任务的智能体”。这种说法听起来正确，但什么也没说清楚——它没有告诉你 Agent 与一个普通的聊天机器人或一个自动化脚本之间，究竟存在何种本质差异。

要“赚到”这个定义，最佳的切入点是 Anthropic 工程团队提出的一组关键区分：**Workflow 与 Agent 的分界。**

- **Workflow（工作流）**：路径由人预先编排。LLM 和工具被串联在固定的流程中，每一步该调用什么、该往哪个方向走，都写在代码里。它可靠、可预测，但不灵活。
- **Agent（智能体）**：路径由模型在运行时自行决定。模型自主选择下一步使用什么工具、走哪条分支、何时终止。它灵活，但也更难控制。

这条分界线一划定，定义便清晰起来。**区分 Agent 与非 Agent 的标准，不是“是否使用了 LLM”，而是“决策路径由谁掌控”。**路径写死在代码里的，是 Workflow，哪怕它调用了十次大模型；路径由模型边走边定的，才是 Agent。

下面用两张图将两者的本质差异并列呈现。先看 Workflow——路径是预先铺设的直线：


再看 Agent——路径由模型在闭环中自行决定，会循环、会自我修正：


当然，为了保持知识的诚实性，需要指出：**Agent 的定义在学术界和工业界尚未完全统一**，有人按“自主性”来定义，有人按“是否具备闭环”来定义，边界地带永远存在争议。但对于企业落地而言，有一个定义足够好用、也足够有力：

> **Agent = 能在不确定环境中持续完成任务的闭环系统。**

请注意，这个定义中的每一个词都含义深刻：「不确定环境」排除了纯计算和死规则的场景；「持续完成」强调它不是一问一答，而是盯着目标直到任务结束；「闭环系统」——这是最关键的——意味着它不是一次调用，而是一个会循环、会自我修正的运行时。

记住这个定义，因为它将贯穿整个系列。**没有闭环的，不是 Agent，而是聊天机器人。**

---

四、最贵的幻觉：Agent ≠ 多 Agent，多 Agent 的“优越”大半是 compute

一旦企业接受了 Agent 化，许多团队会立刻冲向一个更性感的概念：**多 Agent 系统（Multi-Agent System）。**让一个“项目经理 Agent”指挥一群“专家 Agent”协同作战——这个画面太诱人了。

但这里隐藏着企业 Agent 化过程中最昂贵的一个幻觉，值得用一整节来拆穿。

2025 年，业界出现了两篇标题针锋相对的文章：Cognition 团队的《Don't Build Multi-Agents（别做多 Agent）》，和 Anthropic 团队的《How we built our multi-agent research system（我们如何构建多 Agent 研究系统）》。一篇说别做，另一篇说我们做了并且很成功。

许多人以为这是两派在打架。但深入研读这两篇文章后会发现，它们其实在阐述同一个道理：**任务决定了架构。**

- Cognition 解决的问题，是**共享状态**的任务——多个 Agent 需要协作处理同一份资料，一旦将上下文切开分给不同的 Agent，隐含的关键信息就会在交接过程中丢失，隔离反而会坏事。
- Anthropic 解决的问题，是**独立线程**的任务——比如开放式研究，每个子方向可以并行、互不干扰，隔离恰恰是优势。

两者都是正确的，只是任务类型不同。**多 Agent 并不是更高级的架构，它只是适配某一类任务的特定架构。**

更尖锐的真相还在后面。Anthropic 在复盘时承认：他们的多 Agent 研究系统在内部评估上比单 Agent 强 90.2%，但——**Token 用量解释了其中约 80% 的性能差异。**翻译成大白话：多 Agent 之所以表现更好，很大程度上并非因为“多个脑子更聪明”，而是因为它**消耗了多得多的 Token**，进行了多得多的思考。

2026 年的多项对照实验进一步证实了这一结论：当把“思考 Token 预算”对齐之后，单 Agent 在多跳推理上的表现能追平、甚至超过多 Agent。研究者的结论是——**许多所谓的多 Agent 收益，更应该归因于算力和上下文效应，而非架构本身的优越性。**

这对企业意味着什么？意味着在你兴冲冲地搭建多 Agent 之前，必须先问自己一个扎心的问题：

> **我到底是需要“多个 Agent 协作”，还是仅仅想“多花点 Token 多想一会儿”？**

如果是后者，给单个 Agent 更大的思考预算，往往更简单、更便宜、更可控。


还有两条来自一线的硬经验，企业在采用多 Agent 之前必须知晓：

第一，**避免让子 Agent 再生成子 Agent。**递归式的繁衍会导致成本失控——这个限制必须在编排层用代码强制实施，而不是在 Prompt 中“请求”模型不要这样做。

第二，**不要用一个独立的 Agent 给自己的作业打分。**Anthropic 的做法是使用一个独立的校验器逐条核对引用，而不是让生成的 Agent 进行自我评判。**自我评价，是 Agent 系统中最容易自欺欺人的地方。**

---

五、成本结构的重写：从人力到 token，从固定到边际

讲完了“是什么”，我们再回到企业最关心的“为什么是现在”。第一个驱动力，是**成本结构的根本性改变。**

过去，一个信息密集型的认知任务——比如审核一份合同、分析一次招投标、生成一份定价报告——其成本结构是“人力主导”的：它由一位有经验人员的工时决定，是固定的、线性的、难以规模化扩展的。想要多处理一倍的量，基本就得再多招一倍的人。

而 Agent 化之后，成本结构被改写为“Token 主导”：同样的认知任务，边际成本变成了模型推理的 Token 费用，**而 Token 的价格仍在以惊人的速度持续下降。**这意味着，那些过去因为“人力成本太高、难以规模化”而被搁置的认知自动化需求，第一次在经济上变得可行。

第二个驱动力，是**信息密度的变化。**

今天企业需要处理的信息量，比十年前增加了数个数量级，而且越来越非结构化——邮件、合同、工单、市场情报、供应链数据。人脑处理这种高密度、多来源、需要整合判断的信息，既机械又低效。Agent 恰好擅长在这种“输入复杂、需要结构化决策”的场景中发挥价值。

第三个驱动力，是**决策自动化的需求。**

企业需要的不再仅仅是“自动化执行”，而是“自动化判断”。前者规则系统就能实现，后者过去只能依赖人工。Agent 将“语言理解 + 上下文判断”这件事，第一次变成了可批量调用的能力。

但是——这里又必须踩下刹车——**成本结构的改善并非没有陷阱。**

Token 便宜，并不代表 Token 不会失控。Agent 在闭环中循环，一旦没有预算约束，一次任务消耗数百次模型调用并不罕见。一个令人警醒的事实是：**即便是 Anthropic 这样的团队，至今也坦言缺少一个好用的“单次任务成本硬上限”方案**，只能依靠禁止递归来消除最可怕的成本乘数。

因此，正确的认知是：Agent 化重写了成本结构，但将“固定的人力成本”替换为了“可能失控的边际 Token 成本”。**省下来的钱，必须依靠工程手段（预算约束、终止条件、成本监控）才能真正落袋为安。**这又一次指向同一个结论——Agent 化的本质是工程，而非简单的调用。

---

六、一个具体的例子：当“接入大模型”撞上合同审查

讲了这么多抽象的内容，不如落到一个具体场景，看看“接入大模型”和“做 Agent 化”在同一个任务上，究竟差在哪里。

就以**合同审查**为例。这是一个典型的“信息密集 + 多步判断”任务：需要阅读条款、比对公司的合规红线、查阅历史上类似条款的处理方式、识别风险点、并给出修改建议。它复杂、容易出错，且高度依赖判断——几乎是为 Agent 化量身定做的场景。然而，一旦做法错误，它也会成为 Agent 化最典型的翻车现场。

**先看“接入大模型”的天真做法。**

工程师将合同全文塞进 Prompt，加上一句“请审查这份合同，指出风险并给出修改建议”，然后等待模型输出。在演示阶段，它的表现令人惊叹，准确挑出了几个漂亮的风险点，赢得了所有人的掌声。

但当真实合同涌来，问题便一个接一个地暴露出来：

- **它读不完整。**一份几十页的合同塞进上下文，模型会“读着读着就丢失了信息”——后面的条款与前面的定义对不上，关键的交叉引用被忽略。（这正是后续文章将讨论的 Context 问题：上下文并非越长越好。）
- **它会产生幻觉。**遇到拿不准的条款，它不会说“我不确定”，而是自信地编造一条根本不存在的法律依据。
- **它不进行查证。**它并没有真的去比对你公司的合规规则库，只是凭借训练数据中的泛泛常识来回答。
- **它不可追溯。**它给你一个结论，但你无从得知这个结论基于哪一条、哪一款——而对合同审查而言，不可追溯就意味着不可使用。

每一份合同的审查结果，都有那么两三成不能令人信任。而你却不知道是哪两三成。**这就是那道 80% 的墙，在一个具体任务上的真实写照。**

**再看“做 Agent 化”的系统做法。**

同一个任务，在系统视角下被重构为一个闭环：

1. **拆解（Loop / 任务结构）**：将“审查合同”拆解为可循环的步骤——逐条提取条款、逐条比对规则、逐条标注风险，而不是指望模型一口气处理全部内容。
2. **喂对上下文（Context）**：不是将全文一股脑地塞入，而是按条款检索相关的合规规则、相似历史合同，只将当前这一步所需的状态传递给模型。
3. **配备工具，并控制工具数量（Harness）**：为它接上条款库检索、合规规则查询、历史合同比对等工具。但这里有一个被无数团队踩过的坑——**工具并非越多越好。**一线实测数据显示，当可用工具从 3 个增加到 12 个时，模型选对工具的准确率会从 95% 暴跌至 70%。因此，成熟的系统会将工具按子任务拆分开，每个环节只暴露它真正需要的几个工具。
4. **校验与兜底（Harness / Validation）**：每一条风险结论，都使用独立的校验逻辑去核对它所引用的条款是否真实存在——用代码去核对，而不是让模型为自己打分。编造的依据，在这一步被拦截下来。
5. **可追溯（Observability）**：每个结论都附带其来源条款和触发的规则，全程留有痕迹，随时可供核查。

同样一份合同，天真做法给你一个“八成可信、不可追溯”的黑箱；系统做法则给你一个“可校验、可追溯、成本可控”的工作流。


这个例子所说明的，不仅仅是“系统做法更好”，而是一件更根本的事情：**“接入大模型”和“做 Agent 化”面对的是同一个任务，但解决的是两个不同层次的问题。**前者解决的是“模型能不能回答问题”，后者解决的是“系统能不能可靠地把事情做完”。而企业所需要的，永远是后者。

---

七、为什么是“现在”：模型已经够强，工程才是真瓶颈

将前面所有的线索收拢起来，我们就能回答那个最关键的时机问题：**为什么是现在，而不是再等等下一代模型？**

答案有点反直觉：**恰恰因为模型已经足够强大，瓶颈才彻底转移到了工程层面。**

「12-Factor Agents」方法论中有一句被反复引用的洞察，可以作为整个判断的基石：**真正能够在生产环境中运行的 Agent，并非你想象中那种“带着一堆工具、在循环中自主决策的 LLM”；它们大部分是被精心工程化的传统软件，只是在需要语言理解或推理的精确位置，插入了 LLM 步骤。**

换句话说，在一个成熟的 Agent 系统中，LLM 扮演的角色是一个**结构化转换函数**：输入自然语言，输出结构化数据。而它周围的一切——路由、重试、状态管理、人工交接——全都是普通的、确定性的软件。

这套方法论中还有一句更直白的话：**即便 LLM 再聪明 100 倍，要投入生产，你仍然需要上下文压缩、确定性控制和 Schema 校验。**这意味着，工程并非 LLM 能力不足时的临时补丁，而是无论模型多强都无法绕开的结构性需求。**等待下一代模型，等不来可靠性；可靠性只能通过工程手段被创造出来。**

那么，工程的核心着力点在哪里？一线团队给出的答案是：**在模型“几乎能成功”的边界上，用工程手段将其做可靠。**找到那些模型有八成把握、但偶尔会出错的地方，利用校验、重试、兜底方法将那两成补上——这才是 Agent 工程的核心战场。

而不这样做的代价，正变得越来越具体。Gartner 在 2026 年给出了一个尖锐预测：**到 2027 年，将有 40% 的企业因治理缺口而将已上线的自主 Agent 降级或下线**——而这些缺口，往往是在生产事故发生之后才被发现的。Gartner 点出的根本原因值得管理者深思：许多企业将 Agent 治理视为一道二元开关——要么彻底锁死，要么完全放任——却没有区分“Agent 的行动能力”和“它被授予的访问范围”。这恰恰反过来印证了同一个判断：Agent 化不是“接入就完事”，而是一个需要分级授权、需要持续治理、需要工程兜底的系统工程。将其视为一次简单调用的企业，迟早会成为那 40% 中的一员。

到这里，“接入大模型”和“做 Agent 化”的区别已经彻底清晰了：

- **接入大模型**，是将 LLM 视为 CPU，然后直接使用它。
- **做 Agent 化**，是承认 LLM 只是 CPU，并为其配备一整套运行时环境——让它从一颗芯片，变成一台能真正干活的机器。

而这套运行时环境，正是本系列将要拆解的**四层工程体系**。它不是一条“从 Prompt 进化到 Loop”的时间线，而是一组**从内到外层层包裹的同心结构**：


- **最内核**是 LLM，一颗会推理的 CPU。
- **Prompt** 是最内环——注意，它不是“过时的旧阶段”，而是仍然承担重要负载的指令层。
- **Context** 决定将何种状态输入模型（本系列将证明：大多数 Agent 的失败是 Context 失败，而非 Model 失败）。
- **Harness** 是模型之外的执行运行时：包括工具、重试、校验、追踪、成本控制、兜底策略。
- **Loop** 是驱动整个系统持续运转的外环。
- 而 **Evaluation** 像一根垂直的度量平面，贯穿所有层；**Human–Agent Relay** 则是最外层的运营外壳，让系统能够 7×24 小时连续运转。

这就是企业 AI 化的真正地图。从第②篇开始，我们将由内到外，把这幅图的每一圈都逐一讲透彻。

---

结论：AI 不会替代系统，但会替代“没有系统的流程”

回到我们出发的地方。那个无法上线的演示版本，那道 80% 的墙，那些归咎于模型、等待下一代的团队——他们缺少的从来不是更强的模型，而是一个根本的认知转变：

**将 AI 从“一个组件”重新理解为“一个系统”。**

这篇文章希望留给你的，是一句可以反复咀嚼的判断：

> **AI 不会替代你的系统，但它会替代那些“没有系统的流程”。**

那些依靠人工一步步手工搬运信息、进行机械判断、在多个工具间复制粘贴的流程，正是 Agent 会率先吃掉的部分。而能否真正获取这份价值，取决于你是停留在“接入大模型”的阶段，还是迈进“Agent 化工程”的层次。

如果你是技术决策者，从这篇文章出发，有三件事现在就可以着手进行：

1. **不要急于上多 Agent。**先诚实地问自己：我是否真的需要多 Agent 协作，还是仅仅想多花些 Token 多思考一会儿？在多数情况下，一个配备了足够预算和工具的单 Agent，更简单、更可控。

2. **将“可靠性”视为工程目标，而非模型问题。**停止无休止的 Prompt 调优和“等待下一代”，开始建立 Harness 思维——包括校验、重试、兜底、成本约束。模型给你 80%，剩下的 20% 是你的工程责任。

3. **用系统的眼光重新审视流程，而不是功能的眼光。**不要问“哪个环节可以加个 AI 助手”，而要问“哪个流程可以被重构为一个闭环系统”。

最后，留一个问题给你，也作为下一篇的引子：

**在你的业务中，哪些流程是“输入复杂 + 需要多步判断 + 信息密集”的？哪些又是“强执行 + 高确定性 + 低频”的？**

这两类流程的命运截然不同——一类是 Agent 化的金矿，另一类是 Agent 化的陷阱。如何用一个可判断的框架将两者区分开来，正是本系列**第②篇《企业哪些场景值得 Agent 化：一个二维判断矩阵》**要解决的问题。

我们下一篇见。

---

*本文为「企业 AI 化的四层工程体系」系列第 ① 篇。系列将依次拆解：场景判断 → 业务拆解 → Context 工程 → Harness 工程 → Loop 工程 → 评估工程 → 人机接力运营 → 整体架构蓝图。*