Havenlon｜行业观察：挡不住的 Agent 洪流，那就给它兜底的边界

摘要

知名 AI 研究者 Andrej Karpathy 最近的一番话在业内引起了不少共鸣。他大意是说，当下 AI 领域一个很大的问题，是人们在还没真正掌握底层模型之前，就急着把 Agent 强行推上去干活；他还以自己早年在 OpenAI 的经历、以及自动驾驶行业为例提醒大家——做个 Demo 很容易，但把它做成真正可靠的产品，可能要花上十年，如果跳过了打基础的阶段，最后一切都会崩。他给出的建议很克制：别急着让 Agent 什么都做，先把基础能力打牢，Agent 自然会长出来。

这番话说得很对，也很清醒。但它同时留下了一个现实的空档：道理我们都懂，可 Agent 并不会因为"基础还没打牢"就停下来等我们。它已经在被大量部署，在触碰真实的付款、数据、权限和设备。理想状态是先把模型和基础做扎实，再让 Agent 上场；但现实是，Agent 已经上场了，而且不会退回去。

这篇文章想讨论的，正是这个空档里该怎么办。我们的立场很明确：既然挡不住 AI Agent 发展的历史洪流，那就退而求其次，用一层执行控制，尽可能帮 Agent 少犯、或者说不犯那些代价最高的高风险错误。

需要先说清楚的是，这个立场并不是对 Karpathy 观点的反驳，而是对它的接力。他谈的是"应该怎么把 Agent 做好"，这是研究和产品层面的长期功课；我们谈的是"在它还没做好、却已经在用的当下，如何不让它闯下大祸"，这是安全层面的当下责任。一个向前看十年，一个守住眼前这几年，两者并不冲突，反而缺一不可。

我们没法让今天的 Agent 变得完美，但我们可以让它在还不完美的时候，犯的错不至于变成无法挽回的灾难。

一、Karpathy 提醒的是"该慢"，但现实是"停不下来"

Karpathy 的提醒本质上是一句"慢下来"——先把底层搞懂，别被 Demo 的轻松骗了，产品化的路很长。这是一个技术研究者非常负责任的态度，本系列此前也反复讲过类似的道理：Demo 里顺滑地跑通一次，和在真实业务里稳定可靠地运行，完全是两回事。

但技术研究者能建议"慢下来"，市场却往往不听。资本在推，竞争在推，效率的诱惑在推。当一个公司发现用 Agent 能把过去需要一个团队的活压缩成几天，它很难忍住不用；当竞争对手已经在用 Agent 自动处理客服、财务、运维时，"我们再等等，等基础打牢"这句话在商业上几乎说不出口。于是我们看到的现实是：一边是研究者说"还没准备好"，一边是产业界说"已经在用了"。

这两者之间的落差，不会因为谁更有道理而消失。它就实实在在地存在着，而且随着 Agent 能力越来越强、接入越来越多真实系统，这个落差只会越来越大。承认这一点，不是悲观，而是务实——安全的设计，从来不该建立在"大家都会理性地慢下来"这个不成立的假设上，而应该建立在"Agent 就是会被提前、被大量、被不那么成熟地用起来"这个真实前提上。

历史上几乎每一次重大技术变革，都重复过这个剧本。汽车刚出现时，安全带、交通信号、驾照制度都还不完善，但没有人因此把汽车按住不许上路，人们是一边用、一边补上这些安全机制的。互联网早期，防火墙、加密、身份认证都还很原始，但商业和信息照样涌了上去，安全体系是在使用的过程中被倒逼出来的。技术的采用速度，从来跑在配套安全体系的成熟速度前面——这几乎是一条规律。AI Agent 不会是例外。指望这一次产业界会格外有耐心、会乖乖等到基础完备再动手，是违背历史经验的一厢情愿。既然如此，与其纠结于"该不该现在用"，不如把精力放在"既然一定会现在用，怎么用得更安全"上。

二、洪流挡不住，但可以给它筑堤

面对一股挡不住的洪流，有两种思路。一种是站在上游试图拦住它——要求所有人先把基础打牢再上 Agent，这在道理上对，在现实中几乎不可能实现。另一种是承认水一定会流下来，转而在关键的位置筑起堤坝和河岸，让这股水不至于泛滥成灾，而是被约束在安全的河道里向前流。

执行控制，就是后一种思路。它不试图阻止 Agent 被使用，也不假装能让 Agent 一夜之间变得成熟可靠。它接受一个前提：Agent 会被用起来，而且在相当长一段时间里都不会完美。然后，它在最要命的地方——高风险动作真正落地之前——筑起一道边界，确保即便 Agent 判断错了、被诱导了、或者只是还不够成熟，它造成的破坏也被牢牢限制在河道之内。

你拦不住河水，但你可以决定它流向哪里、能漫到多高。执行控制不是那座拦河的坝，而是那道约束泛滥的岸。

这也正好呼应了 Karpathy 的自动驾驶类比，只是换了个角度看。自动驾驶为什么能在技术还远未"完美"的时候，就已经在真实道路上跑起来？靠的不是等到系统零失误的那一天，而是靠一整套兜底机制：安全员的接管、地理围栏的限定、冗余的刹车系统、明确的运行设计域。这些机制的共同点，都是承认系统会出错，然后想办法让出错不至于致命。执行控制之于 AI Agent，扮演的正是这样一个角色。

这个类比还可以再往深里说一层。自动驾驶行业花了十年才慢慢明白一件事：真正决定一套系统能不能上路的，往往不是它在顺利路况下开得有多好，而是它在极端、罕见、意料之外的情况下会不会失控。一个能在 99.9% 的路况下完美驾驶的系统，如果在剩下 0.1% 的极端场景里会酿成致命事故，它依然不能被放心地交给公众。所以自动驾驶的安全，重心从来不在"把常规开得更好"，而在"给异常兜好底"。AI Agent 的执行安全也是同一个道理：Agent 在大多数常规任务里表现得越来越好，这值得高兴，但真正决定它能不能被托付真实业务的，是它在被诱导、被污染、遇到意外状态时，会不会做出无法挽回的高风险动作。执行控制盯的，正是这后一半——那些低概率但高代价的场景。

三、执行控制不假设 Agent 完美，恰恰假设它会犯错

这是执行控制和很多其他安全思路最根本的区别，也是它能在"基础还没打牢"的现实里立刻起作用的原因。

很多安全方案，隐含地建立在"让主体更可靠"这个前提上——把模型训练得更准，把提示词写得更周全，把 Agent 调教得更听话。这些努力都有价值，但它们的方向是"减少犯错的概率"。而执行控制的出发点完全不同：它不去赌 Agent 不犯错，它直接假设 Agent 一定会在某个时刻犯错，然后专注于回答一个问题——当它犯错时，错误能走多远？

本系列前面讲过这句话：真正可靠的系统，不是要求上游永远干净，而是设计好下游的边界。这句话放在今天这个语境里格外贴切。Karpathy 担心的"基础没打牢就上 Agent"，翻译成执行安全的语言，就是"上游还很不干净"。而执行控制恰恰不要求上游干净——它承认上游可能有误解、有噪声、有诱导、有不成熟，然后在下游、在执行真正发生的那一刻，用一道独立的边界把越界的动作拦下来。它不需要 Agent 先变得成熟，才敢让它上场；它让 Agent 可以在还不成熟的时候，就相对安全地上场。

从这个意义上说，执行控制不是要和 Karpathy 的"打好基础"唱反调，而是它的补充。打基础是长期的、正确的方向；执行控制是在基础还没打好的这段漫长过渡期里，让我们能一边用、一边兜底的现实方案。

值得强调的是，这种"假设会犯错"的设计哲学，在成熟的工程领域早就是常识，而非什么保守或悲观的态度。飞机会假设某个引擎可能失效，所以设计了多引擎冗余；建筑会假设可能发生地震，所以留了远超日常需求的结构余量；金融系统会假设交易可能出错，所以设计了对账和回滚机制。这些设计从不指望某个部件永不失效，而是承认失效必然会发生，然后确保单点的失效不会拖垮整体。真正不成熟、也真正危险的思路，反而是那种"只要我们把它做得足够好，它就不会出错"的乐观——这恰恰是 Karpathy 所批评的那种"明天 AI 会自动进化、到时候一切迎刃而解"的心态。执行控制站在的，是工程界那条更古老、也更可靠的传统上：不赌任何单一环节的完美，而是为必然发生的失误，预先准备好一道兜底的防线。

四、为什么这段"过渡期"尤其需要执行控制

如果 Agent 真的能像 Karpathy 建议的那样，等基础扎实了再上场，那这段风险最高的日子或许可以被跳过。但现实是我们必须穿越这段过渡期，而且这段过渡期恰恰是最危险的——因为它同时具备两个特征：Agent 已经拥有了触碰真实世界的执行能力，但它的可靠性还远没到匹配这种能力的程度。

能力和可靠性之间的这道剪刀差，是过渡期风险的核心。一个能力弱的系统即便不可靠，也造不成太大破坏，因为它本来就碰不到要害；一个高度可靠的系统即便能力强，风险也可控，因为它极少出错。最危险的组合，恰恰是"能力已经很强、可靠性却还不够"——而这正是当下大量 Agent 的真实状态。它们已经能调用支付、能改配置、能操作云资源、能连续执行几十上百个步骤，但它们对上下文的判断、对边界的把握、对诱导的抵抗，都还处在很不成熟的阶段。

在这样一个能力超前于可靠性的阶段，指望"再等等模型就好了"是危险的，因为等待期间它已经在碰真实的钱和权限了。这段过渡期不能靠拖延来度过，只能靠兜底来度过。执行控制正是那个兜底：它不消除能力和可靠性之间的剪刀差，但它在这道差最可能酿成大祸的地方——不可逆的高风险动作上——加了一道硬约束，让过渡期的不成熟，不至于付出灾难性的代价。

而且要看到，这段过渡期恐怕比很多人想象的要长。Karpathy 用"十年"来形容从 Demo 到成熟产品的距离，这不是随口一说——自动驾驶就是活生生的例子，从惊艳的演示到真正可靠的量产，走了远超预期的时间，而且至今仍在路上。如果 AI Agent 的成熟也需要以年为单位来计，那就意味着，我们要在这个"能力已经很强、可靠性还不够"的危险区间里，停留相当长的一段时间。这更加说明，把安全寄托于"过渡期很快就会过去"是靠不住的。过渡期越长，兜底机制就越不是权宜之计，而越接近于一种必须长期存在的基础设施。执行控制不是用来临时凑合几个月的补丁，而是要陪着 Agent 走完这段可能长达数年的成长期的长期伙伴。

五、执行控制帮 Agent 挡住的，是那几类"输不起"的错

需要说清楚的是，执行控制并不试图让 Agent 一个错都不犯，那既不现实，也没必要。Agent 在低风险场景里犯点小错——总结得不够准、分类分错了、生成的草稿要返工——这些完全可以容忍，也本就是它在成长过程中会经历的。执行控制真正要帮它挡住的，是那几类"输不起"的错。

哪些是输不起的错？就是本系列反复点名的那些高风险、不可逆的动作：把钱转错地址、把敏感数据导出去、把生产数据库删掉、把最高权限开出去、把密钥用在错误的交易上、把危险指令下发给物理设备。这些动作的共同点是，一旦发生就很难甚至无法挽回，一次就可能造成致命后果。对这些动作，"大概率 Agent 不会做错"这个概率承诺是不够的，因为剩下那一小部分的错误，代价太大了。

执行控制的价值，不在于让 Agent 变成一个不犯错的完人，而在于把它可能犯的错，牢牢挡在"可以承受"和"无法承受"之间的那条线之内。

换句话说，它是一种对错误后果的分级管理：低风险的错，放它去犯，快速迭代、快速成长；高风险的错，用一道独立的、不可绕过的边界死死守住。这恰恰让 Agent 可以更大胆地在低风险区域探索和进化，因为最坏的情况已经被兜住了。

这种分级，其实也回应了 Karpathy 担心的那种"跳过基础、一切崩塌"的连锁灾难。为什么跳过基础会让"一切都崩"？很大程度上是因为，在一个没有兜底边界的系统里，一个局部的小错误可以自由地传导、放大，最终演变成整体的崩溃——Agent 误判了一步，这个错误的结果又成了下一步的输入，一路滚下去，直到造成不可逆的破坏。而执行控制的分级管理，恰恰是在这条传导链的关键节点上设了闸：低风险的错误可以继续流动，因为它们无伤大雅；但一旦这条链条即将触碰到某个高风险、不可逆的动作，闸门就会落下。它做的事，本质上是切断"小错误滚成大灾难"的那条路径，让基础不牢所导致的失误，被限制在局部，而不至于蔓延成全局的崩塌。

六、这不是给 Agent 拖后腿，而是给它铺路

有人可能会觉得，给 Agent 加一道执行控制的边界，是在限制它、拖它的后腿，和"让 Agent 大展拳脚"的方向背道而驰。但如果仔细想想，结论恰恰相反。

真正阻碍 Agent 进入核心业务的，从来不是它能力不够，而是人们不敢放手。企业不敢让 Agent 碰钱，不敢让它管权限，不敢让它改生产——不是因为 Agent 做不到，而是因为一旦它做错了，后果没人兜得起。这种"不敢"，才是 Agent 落地最大的障碍。而执行控制做的，正是把"不敢"变成"敢"：当高风险动作有了一道可靠的兜底边界，企业才敢把真正重要的任务交给 Agent，因为他们知道，即便 Agent 出了岔子，最坏的结果也被限制住了。

所以，执行控制不是 Agent 的刹车片在拖慢它，而更像赛车上的安全带和防滚架——正是因为有了这些保护，车手才敢把车开到更快。给 Agent 兜底，不是为了让它少做事，而是为了让它能更放心地去做那些原本没人敢让它做的事。这和 Karpathy 说的"把基础打牢，Agent 自然会长出来"其实是一个意思的两面：基础从模型内部打，执行控制从外部兜——两者合起来，才是让 Agent 既跑得快、又不至于翻车的完整方案。

这里还藏着一个常被忽略的正向循环。当高风险动作有了可靠的兜底，企业就敢把更真实、更有价值的任务交给 Agent；而 Agent 接触到越多真实的高价值场景，就能积累越多真实的反馈，从而更快地成长和成熟。反过来，如果因为不敢放手，就把 Agent 长期困在那些无关痛痒的低风险玩具场景里，它反而失去了在真实世界里磨砺、进化的机会。也就是说，一道好的执行控制边界，不仅在保护当下，也在加速 Agent 走向成熟的进程——它让 Agent 有机会更早、更安全地进入深水区，而这恰恰是 Karpathy 所期待的那种"把基础打牢、让能力长出来"最终得以实现的现实路径之一。

七、把选择权还给现实：既然要用，就用得起

回到最开始那个空档。Karpathy 站在研究者的位置，提醒我们理想的顺序应该是先打基础、再上 Agent。这是对的。但绝大多数企业和开发者并不站在研究者的位置，他们站在现实的位置，面对的是一个此刻就要做的选择：Agent 已经能大幅提升效率了，我到底用不用？

如果没有执行控制，这个选择会很痛苦——用，怕它在高风险动作上闯下大祸；不用，又眼睁睁看着效率红利溜走，被同行甩开。而执行控制，恰恰是把这个二选一，变成了一个可以两全的方案：你可以现在就用上 Agent 的能力，同时又不必把身家性命押在它的成熟度上。低风险的活尽管交给它，让它在真实场景里快速迭代；高风险的活也可以交给它，但有一道独立边界在最后一刻替你把关。

这才是面对一股挡不住的洪流时，最务实的态度。我们不假装自己能拦住它，也不因为它还不完美就拒绝它带来的价值。我们承认它会来、会犯错、会在成熟之前就大规模上场，然后在它最可能造成不可逆伤害的地方，筑起一道确定的、不可绕过的边界。让洪流照样奔流，但让它流在安全的河道里。

这种态度的可贵之处，在于它同时避开了两种极端。一种极端是盲目乐观——把 Agent 当成已经成熟的工具，什么都敢交给它，直到某一天在一次不可逆的高风险动作上栽了大跟头。另一种极端是因噎废食——因为看到了风险，就干脆把 Agent 拒之门外，眼看着它在别处创造价值，自己却守着过时的方式原地踏步。这两种极端，一个赌 Agent 不会犯错，一个赌自己可以不用 Agent，而现实很快会证明这两个赌注都是输的。执行控制提供的是第三条路：既不盲信，也不排斥，而是用一道清晰的边界，把"可以放心交给 Agent 的部分"和"必须被死死守住的部分"划分开来。它让"用 Agent"这件事，从一个要么全信、要么全不信的豪赌，变成了一个有分寸、有底线、可以理性拿捏的选择。

结语

Karpathy 的提醒和我们的主张，其实并不矛盾，甚至是同一件事的两个层面。他从技术演进的角度说：别急，先把底层模型和基础能力搞扎实，这是根治之道。我们从现实落地的角度补一句：可基础还没扎实的这些年里，Agent 已经在真实世界里跑了，所以在根治之前，我们需要一层兜底，让它跑得起、也翻不了大车。

前者是慢功夫，是对的，但需要时间；后者是过渡期里必须立刻做的事，因为风险不会等基础打牢了才发生。执行控制不解决"如何让 Agent 更聪明"这个长期问题，它解决的是"在 Agent 还不够聪明的时候，如何不让它闯下无法收拾的祸"这个眼前问题。

AI Agent 的发展是一股挡不住的历史洪流，这一点我们改变不了。但我们能改变的是：当这股洪流经过那些最脆弱、最输不起的地方时，有没有一道边界替我们守着。这道边界，就是执行控制。

挡不住洪流，就筑好河岸。我们不奢求 Agent 永不犯错，我们只坚持一件事——在它犯下那些无法挽回的错误之前，永远有一道独立的边界，能够说"不"。