别再把大模型当 API 了：把它当"系统"的公司，正在甩开你

> **企业 AI 化的四层工程体系 · 第 ① 篇** > 为什么现在必须做 Agent 化，而不是简单接入大模型 --- ## 引言：那个惊艳的 demo，为什么上不了线？ 几乎每一家认真做 AI 的公司，都经历过同一个剧本。 技术团队接入了大模型，花两周做出一个 demo。会议室里，所有人都惊呆了：它能读合同、能写报价、能回客服工单，回答得有理有据。老板拍板：上线，全公司推广。 然后，剧本的第二幕开始了。真实的数据涌进来，边角情况层出不穷，模型时而胡说八道、时而调错工具、时而忘了三步之前自己说过什么。**那个在 demo 里光彩照人的系统，在生产环境里只有七八成的时候是对的。**而对一个要替代人工流程的系统来说，"八成对"约等于"不能用"——因为你永远不知道是哪两成出了错。 于是项目卡住了。有人怪模型不够强，有人怪 prompt 没调好，有人开始等下一代模型。 但真正的答案，和这三种猜测都无关。**demo 与生产之间那道墙，不是模型能力的墙，而是工程范式的墙。**它隔开的，是"把大模型当一个组件来调用"的企业，和"把大模型当一个系统来构建"的企业。前者在原地打转，后者已经在拉开身位。 这篇文章要回答的核心问题只有一个：**为什么"接入大模型"和"做 Agent 化"是两件完全不同的事，而后者才是企业 AI 化真正的分水岭。** --- ## 一、繁荣的假象：90% 的 AI 项目，为什么停在 demo 先说一个让人不舒服的判断：今天绝大多数企业的"AI 转型"，本质上是三种认知错位的叠加。 **第一种错位：把 AI 当 API。**以为接入大模型就像接入一个支付接口——传参数进去，拿结果出来，调用完就结束。可大模型不是一个确定性函数。同样的输入，今天和明天可能给你不一样的输出；上下文多一句少一句，结论就可能翻转。你把它当 API，它却是一个有脾气、会走神、需要被管理的"概率组件"。 **第二种错位：把"聊天助手"当功能。**以为在产品里加一个对话框、塞一个"AI 助手"按钮，就完成了 AI 化。可对话框只是界面，不是能力。真正难的不是让用户能问，而是让系统在用户问完之后，**可靠地、可追溯地、可控成本地把事情做完**。 **第三种错位：把 prompt 当产品。**以为只要 prompt 写得够好，一切问题都能解决。于是团队陷入无止境的"咒语调优"，今天加一句"请仔细思考"，明天改一个示例。可 prompt 再精巧，也是无状态、无记忆、无系统性的——它管不了工具失败，管不了多步流程的状态，管不了成本爆炸。 这三种错位的共同结果，就是那道众所周知的墙。 一位资深 AI 工程师、HumanLayer 的创始人 Dex Horthy，在试遍了市面上几乎所有 Agent 框架之后，把这个现象总结得很精准：**很多团队发现，AI Agent 在惊艳的 demo 之外，往往会撞上 70%–80% 可靠性的天花板——打转、发出畸形的工具调用、丢失状态。**他据此提出了著名的「12-Factor Agents」方法论。而这道墙最残酷的地方在于：从 0 到 80% 很容易，靠模型本身就能到；但从 80% 到 95%，靠的全是工程。 下面这张图，是几乎所有 AI 项目都会走的轨迹——区别只在于，有的团队停在了墙前，有的团队翻了过去。  有人可能会想：这是不是因为团队技术不行？恰恰相反，这道墙连最顶尖的公司都得硬啃。以知识管理平台 Notion 为例——他们为了把企业级的 Agent 能力真正推上生产，前后花了数年时间、把整套 Agent 基础设施**彻底重建了四到五次**，最终才打磨出一套包含渐进式工具暴露、类 SQL 数据抽象、为模型消费优化的接口和完整评估框架的系统。这不是调几句 prompt 能跨过的鸿沟，而是要重建一整套工程底座。 另一个数字同样刺眼：即便是 Anthropic 这样的团队，在复盘自家 Agent 系统时也发现，**工具调用失败出现在多达 36% 的对话里。**三分之一的交互会在"调工具"这一环出岔子——这恰恰说明，hallucination 拦截、工具可靠性、状态管理这些"脏活累活"，才是真正决定成败的地方，而它们没有一个是靠模型变强就能自动解决的。 **结论很简单：模型给了你 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 的，不是"用没用大模型"，而是"决策路径由谁掌控"。**路径写死在代码里的，是 workflow，哪怕它调了十次大模型；路径由模型边走边定的，才是 agent。 下面用两张图把两者的本质差异摆在一起。先看 Workflow——路径是预先铺好的直线：  再看 Agent——路径由模型在闭环里自行决定，会循环、会自我修正：  当然，要保持知识上的诚实：**Agent 的定义本身在学术界和工业界并未完全统一**，有人按"自主性"来定义，有人按"是否具备闭环"来定义，边界处永远有争议。但对企业落地而言，有一个定义足够好用、也足够有力： > **Agent = 能在不确定环境中持续完成任务的闭环系统。** 请注意这个定义里的每一个词都在干活：「不确定环境」排除了纯计算和死规则的场景；「持续完成」强调它不是一问一答，而是盯着目标直到做完；「闭环系统」——这是最关键的——意味着它不是一次调用，而是一个会循环、会自我修正的运行时。 记住这个定义，因为它会贯穿整个系列。**没有闭环的，不是 Agent，是 chatbot。** --- ## 四、最贵的幻觉：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，加一句"请审查这份合同，指出风险并给出修改建议"，然后等模型输出。demo 阶段，它表现惊人，挑出了几个漂亮的风险点，所有人鼓掌。 但当真实合同涌进来，问题一个接一个冒出来： - **它读不全。**一份几十页的合同塞进上下文，模型会"读着读着就丢了"——后面的条款和前面的定义对不上，关键的交叉引用被忽略。（这正是后续文章会讲的 context 问题：上下文不是越长越好。） - **它会编。**遇到拿不准的条款，它不说"我不确定"，而是自信地编一条根本不存在的法律依据。 - **它不查证。**它没有真的去比对你公司的合规规则库，只是凭训练数据里的泛泛常识在答。 - **它不可追溯。**它给你一个结论，但你无法知道这个结论基于哪一条、哪一款——而对合同审查来说，不可追溯就等于不可用。 每一份合同的审查结果，都有那么两三成不能信。而你不知道是哪两三成。**这就是那道 80% 的墙，落在了一个具体任务上。** **再看"做 Agent 化"的系统做法。** 同一个任务，在系统视角下被重建成一个闭环： 1. **拆解（Loop / 任务结构）**：把"审合同"拆成可循环的步骤——逐条提取条款、逐条比对规则、逐条标注风险，而不是指望模型一口气吞下全部。 2. **喂对上下文（Context）**：不是把全文一股脑塞进去，而是按条款检索相关的合规规则、相似历史合同，只把当前这一步需要的状态喂给模型。 3. **配工具，并控制工具数量（Harness）**：给它接上条款库检索、合规规则查询、历史合同比对等工具。但这里有个被无数团队踩过的坑——**工具不是越多越好。**一线实测数据显示，当可用工具从 3 个增加到 12 个时，模型选对工具的准确率会从 95% 暴跌到 70%。所以成熟的系统会把工具按子任务拆开，每个环节只暴露它真正需要的那几个工具。 4. **校验与兜底（Harness / Validation）**：每一条风险结论，都用独立的校验逻辑去核对它引用的条款是否真实存在——用代码去核对，而不是让模型给自己打分。编造的依据，在这一步被拦下。 5. **可追溯（Observability）**：每个结论都挂着它的来源条款和触发的规则，全程留痕，随时可查。 同样一份合同，天真做法给你一个"八成可信、不可追溯"的黑箱；系统做法给你一个"可校验、可追溯、可控成本"的工作流。  这个例子说明的，不只是"系统做法更好"，而是一件更根本的事：**"接入大模型"和"做 Agent 化"面对的是同一个任务，但解的是两个不同层次的问题。**前者解的是"模型能不能答"，后者解的是"系统能不能可靠地把事做完"。而企业要的，永远是后者。 --- ## 七、为什么是"现在"：模型已经够强，工程才是真瓶颈 把前面所有的线索收拢，我们就能回答那个最关键的时机问题：**为什么是现在，而不是再等等下一代模型？** 答案有点反直觉：**恰恰因为模型已经足够强了，瓶颈才彻底转移到了工程上。** 「12-Factor Agents」方法论里有一句被反复引用的洞察，可以作为整个判断的基石：**真正能在生产里跑起来的 Agent，并不是你想象中那种"带一堆工具、在 loop 里自主决策的大模型"；它们大部分是被精心工程化的传统软件，只在需要语言理解或推理的精确位置，插入了 LLM 步骤。** 换句话说，在一个成熟的 Agent 系统里，LLM 扮演的角色是一个**结构化转换函数**：自然语言进，结构化数据（typed data）出。而它周围的一切——路由、重试、状态管理、人工交接——全都是普通的、确定性的软件。 这套方法论里还有一句更狠的话：**即便 LLM 再聪明 100 倍，要上生产，你仍然需要上下文压缩、确定性控制和 schema 校验。**这意味着，工程不是模型能力不足时的临时补丁，而是无论模型多强都绕不开的结构性需求。**等下一代模型，等不来可靠性；可靠性只能被工程出来。** 那么，工程的着力点在哪？一线团队给出的答案是：**在模型"几乎能成功"的边界上，用工程把它做可靠。**找到那些模型有八成把握、但偶尔翻车的地方，用校验、重试、兜底把那两成补上——这才是 Agent 工程的核心战场。 而不这么做的代价，正在变得越来越具体。Gartner 在 2026 年给出一个尖锐预测：**到 2027 年，将有 40% 的企业因为治理缺口而把已上线的自主 Agent 降级或下线**——而这些缺口，往往是在生产事故发生之后才被发现的。Gartner 点出的根因很值得管理者警醒：很多企业把 Agent 治理当成一道二元开关——要么彻底锁死、要么完全放任，却没有区分"Agent 的行动能力"和"它被授予的访问范围"。这恰恰反过来印证了同一个判断：Agent 化不是"接进来就完事"，而是一个需要分级授权、需要持续治理、需要工程兜底的系统工程。把它当一次调用来对待的企业，迟早会成为那 40% 里的一员。 到这里，"接入大模型"和"做 Agent 化"的区别已经彻底清晰了： - **接入大模型**，是把 LLM 当 CPU，然后直接用。 - **做 Agent 化**，是承认 LLM 只是 CPU，然后给它配一整套运行时（runtime）——让它从一颗芯片，变成一台能干活的机器。 而这套运行时，正是本系列要拆解的**四层工程体系**。它不是一条"从 Prompt 进化到 Loop"的时间线，而是一组**从内到外层层包裹的同心结构**：  - **最内核**是 LLM，一颗会推理的 CPU。 - **Prompt** 是最内环——注意，它不是"过时的旧阶段"，而是仍然 load-bearing 的指令层。 - **Context** 决定喂什么状态进模型（本系列将证明：大多数 Agent 失败是 context 失败，而非 model 失败）。 - **Harness** 是模型之外的执行运行时：工具、重试、校验、追踪、成本、兜底。 - **Loop** 是驱动整个系统持续运转的外环。 - 而 **Evaluation** 像一根垂直的度量平面，贯穿所有层；**Human–Agent Relay** 则是最外层的运营外壳，让系统能 7×24 连续运转。 这就是企业 AI 化的真正地图。从第②篇起，我们会从内到外，把这张图一圈一圈讲透。 --- ## 结论：AI 不会替代系统，但会替代"没有系统的流程" 回到我们出发的地方。那个上不了线的 demo，那道 80% 的墙，那些怪模型、等下一代的团队——他们缺的从来不是更强的模型，而是一个根本的认知转向： **把 AI 从"一个组件"，重新理解成"一个系统"。** 这篇文章想留给你的，是一句可以反复咀嚼的判断： > **AI 不会替代你的系统，但它会替代"没有系统的流程"。** 那些靠人一步步手工搬运信息、做机械判断、在多个工具间复制粘贴的流程，正是 Agent 最先吃掉的部分。而能不能把这块价值真正吃下来，取决于你是停在"接入大模型"，还是迈进"Agent 化工程"。 如果你是技术决策者，从这篇文章出发，有三件事现在就可以做： 1. **别急着上多 Agent。**先诚实地问自己：我是真的需要多 Agent 协作，还是只是想多花 token 多想一会儿？多数情况下，一个配了足够预算和工具的单 Agent，更简单、更可控。 2. **把"可靠性"当成工程目标，而不是模型问题。**停止无止境的 prompt 调优和"等下一代"，开始建立 harness 思维——校验、重试、兜底、成本约束。模型给你 80%，剩下的 20% 是你的工程责任。 3. **用系统的眼光重新审视流程，而不是用功能的眼光。**别问"哪个环节可以加个 AI 助手"，要问"哪个流程可以被重建成一个闭环系统"。 最后，留一个问题给你，也作为下一篇的引子： **在你的业务里，哪些流程是"输入复杂 + 需要多步判断 + 信息密集"的？哪些又是"强执行 + 高确定性 + 低频"的？** 这两类流程的命运截然不同——一类是 Agent 化的金矿，一类是 Agent 化的陷阱。如何用一个可判断的框架把它们分开，正是本系列**第②篇《企业哪些场景值得 Agent 化：一个二维判断矩阵》**要解决的问题。 我们下一篇见。 --- *本文为「企业 AI 化的四层工程体系」系列第 ① 篇。系列将依次拆解：场景判断 → 业务拆解 → Context 工程 → Harness 工程 → Loop 工程 → 评估工程 → 人机接力运营 → 整体架构蓝图。*