最后一公里不是模型

每隔几周就有人给我发一个演示：一个 agent 读取发票，做出判断，再把结果写回 ERP。演示总是跑得通。我的工作时间大半花在这句话的后半截，也就是「写回」那部分上，而演示从来不是让我担心的地方。

2026 年的几组数字给出的是同一个判断，只是不带个人色彩。Gartner 的统计是，2026 年第一季度发布或更新的企业应用中，80% 至少嵌入了一个 AI agent，而 2024 年这个比例是 33%。同一时间段内，尝试过 agent 的公司里，把其中一个规模化到能拿出可度量价值的不到 10%。这两个数字描述的是同一道落差，而在我看来，多数团队找错了它的位置。

工作量实际落在哪里

在被问到是什么卡住了项目时，46% 的团队给出的首要答案是与既有系统的集成，排在模型能力、成本和幻觉之前。对这些团队而言，真正停住项目的，是让一个 agent 安全且可靠地访问那些已经在支撑业务运转的系统。

按我的经验，这一点会让人意外，原因是演示把它藏起来了。在演示里，ERP 是一个 mock：它在 40 毫秒内返回，不会抛出锁超时，库里只有一条数据干净的客户记录。生产环境在这三点上全部相反，而任何一个对接过两套企业系统的工程师都会告诉你，表结构是简单的那一半。难的那一半是第四次重试时会发生什么，以及同一天落进来的数以万计的记录会发生什么。

举个例子，设想一个 agent 去过一笔分录。模型判断正确，API 调用超时，此时 agent 无从知道这笔分录到底落没落库。它于是重试，同一张发票在一个本就承载数以万计记录的日子里被记了两次。在对接过两套系统的工程师当中，这是早已解决的地面：解法有自己的名字，幂等键，但它是枯燥的活，任何演示里都不包含。得有人替 agent 被允许执行的每一个动作，把这件事一个个建出来。

生产环境的那道闸门

但演示还藏着第二件事，而这件事是我反复回到的。

一个能写的 agent，就是一个能写生产库的 agent。我自己这一周遇到的是它的缩小版。我修好了七个加载不了环境变量的一次性脚本，修复本身是成功的，但那七个脚本已经连不上数据库好几个月，而那次连接失败，正是一条随手敲下的命令与生产数据库之间唯一的阻隔。修好 bug 等于拆掉了一直在保护我的那次意外。于是下一个改动加上了守卫，那七个脚本现在拒绝碰生产库，除非运行它的工程师显式传入 --apply。

在七个脚本这个量级上，这是个小案例，而我认为它会朝一个不受欢迎的方向放大。你交给 agent 的每一项能力，都需要被问到同样的三个问题：这个动作碰到了什么，它能不能被撤销，以及这一次具体的执行是谁批准的。一个团队如果连一个脚本都答不出这三问，面对四十个 agent 工具时同样答不出来。

项目为什么会被砍掉

Gartner 预计，超过 40% 的 agentic AI 项目会在 2027 年底之前被取消，而我不把这 40% 读作对模型的判决。我的猜测是，其中多数死在「一个能跑的演示」与「一套可审计的生产集成」之间的那道缝里，因为这道缝是按工程师月计算的，而几乎没有人为它编过预算。我没有见过按成因拆分取消原因的数据，所以这条按假设处理。

按行业拆开的数据对此有一点支持。银行与保险业让 agent 跑在生产环境的比例是 47%，医疗是 18%，政府是 14%。这三个数字对应的并不是模型最好的行业，而是在任何人说出 agent 这个词之前，就已经把变更控制、审计轨迹和对账放在那里的行业。麦肯锡给出的数字是，88% 的机构至少在一项业务职能中使用了 AI，而在任何环节把 agentic AI 规模化的只有 23%，这两个数字之间的 65 个百分点，就是我在描述的那道距离。

如果让我先做一件事

如果有团队问我从哪里开始，我不会从模型开始，因为那 46% 说集成的人，讲的不是一个模型问题。

在第一个月里，我会挑一个动作而不是一条工作流，让它可撤销，写下它碰到的东西，并在不可撤销的那一版前面放一个人。随后我会让这一个动作跑满 30 天，分开记两件事：集成失败了多少次，模型判断错了多少次。我的预期是集成失败会以很大的差距领先，而这两个计数之间的比值，才是真正的项目计划。

模型是公司可以买来的那一部分。对那还没有规模化的 90% 来说，最后一公里是他们必须自己建的那一部分，而它看起来，与 agent 出现之前就已经存在的集成工作没有多大差别。

资料来源

• Gartner 关于 agent 嵌入率与项目取消率的数字 —— 转引自 kore.ai
• 采用率、集成障碍与规模化数字 —— digitalapplied.com、prefactor.tech
• 分行业生产部署率 —— paul-okhrem.com
• 麦肯锡 State of AI 规模化数字 —— 转引自 writer.com