怎么才能放心把活交给一个没人盯着的 AI Agent

假设你现在真的有一个 agent，能把一件事从头做到尾——拉数据、写代码、跑测试、发 PR、改文档，一条龙。它不需要你在旁边一句一句喂提示词。你晚上把任务丢给它，去睡觉。

真正的问题不是它能不能做完。这两年我常年把前沿 agent 的生产实践、评测/benchmark 生态、一手信源与论文尽量全量过一遍之后，越来越确信一件事：能力早就不是瓶颈了。真正卡住所有人的问题只有一个——

第二天早上，你敢直接把它的产出拿去用吗？

敢，你就解放了一整个人力。不敢，那它就还只是个更花哨的自动补全，你得逐行审、逐行改，省下的时间又都吐了回去。所以"把活交给一个没人盯着的 AI Agent"这件事，从来不是能力问题，是信任问题。而信任，恰恰是整个 agent 栈里最不成熟的那一层。

一、demo 到生产之间，隔着一条"评测鸿沟"

我见过太多惊艳的 agent demo。录屏里它行云流水，一次做对，观众鼓掌。然后这东西一进生产，就开始漏水。

原因不玄乎。demo 是被精心挑过的一次成功，生产是没人挑的一万次连续运行。 前者只需要"能对一次"，后者需要"错得起、被发现、能回滚"。这中间隔着的东西，我把它叫作评测鸿沟。

很多团队其实已经隐约意识到有条鸿沟，于是拼命上可观测性（observability）：链路追踪、token 计费、每一步工具调用的日志、失败重试的告警。这些都对，但要看清它们到底解决了什么——

可观测性告诉你"发生了什么"，评测（evals）才告诉你"对不对"。

这是两码事。可观测能告诉你 agent 昨晚调了 47 次工具、花了 3 块 2 毛钱、第 31 步重试了两次。它没法告诉你：这 47 次调用里，那份最终交出来的报告，结论是不是错的。 日志再全，也只是把一场事故录得很清楚，不能阻止事故。

据我持续追踪，这个错位在数据上相当明显：上了生产级 agent 的团队里，大致量级上约九成都做了可观测，却只有大约一半真正上了评测。换句话说，大多数人给 agent 装了行车记录仪，却没装刹车。 我们太热衷于"看见它在干什么"，而回避了那个更难、更贵、也更关键的问题——它干得到底对不对。

这正是我在《一个人的智能系统》 里反复强调的：观测性只是入场券，评测才是护城河。

二、无人值守 agent 的信任三件套

那到底怎么才能"放心"？我的答案很朴素，也很工程：信任不是求来的，是搭出来的。具体是三件套。

第一件：执行前授权的护栏（guardrails before action）。

大多数人对护栏的理解还停留在"过滤输出"——等 agent 说完话，再拿个分类器扫一遍有没有脏东西。这太晚了。对一个会动手的 agent，危险从来不在它"说了什么"，而在它"做了什么"。

护栏必须前移到工具执行层。不是拦它的话，是拦它的手。在真正调用 delete、transfer、deploy、send 这些动作之前，先过一道授权：这个动作在不在允许清单里？影响半径多大？可不可逆？金额/范围有没有超过阈值？该由 harness 在执行前决定放不放行，而不是指望模型自己"想清楚了才做"。 这一点我后面还要重申，因为它是整套体系的地基。

至于这道授权具体怎么分级，我在第五节给了一张可以直接照抄的四级表——那是这篇里最能马上用起来的东西。

第二件：可回归的评测（regression evals）。

护栏防的是"别做坏事"，评测答的是"做对了没有"。关键词是可回归——你得有一套固定的、能反复跑的评测集，每次改 prompt、换模型、加工具，都重新跑一遍，看指标是涨了还是掉了。

这里有个反直觉但极其重要的点：benchmark 通过，不代表真能用。 公开榜单刷得再高，也只证明它在别人挑的题上表现好。你的业务、你的数据、你的边界情况，得你自己出题、自己判分。我甚至观察到行业里开始出现新的排名范式——把人类偏好和事实性（factuality）加权结合起来打分，而不是只看单一维度对错。这说明大家终于意识到：“看起来对"和"真的对"是两件必须分开测的事。

第三件：早晨的 HITL 复核。

HITL，人在回路（Human-in-the-Loop）。这不是倒退回手动，而是把人的注意力从"全程盯着"精确地挪到"关键点按一下”。

夜里 agent 自己跑，护栏兜住不可逆动作，评测给每个产出打上置信度。早上你端着咖啡坐下，只审两种东西：评测标红的，和动作不可逆的。可回滚的（改个草稿、跑个测试、生成个报告）随它去；一步错满盘输的（打钱、删库、对外发布、生产部署），必须你亲手按下那个按钮。

这三件套的顺序不能乱：护栏在前（别闯祸），评测在中（判对错），HITL 在后（担最终责）。 三者缺一，“无人值守"就是句空话。

三、复合误差：一道你绕不过去的硬数学

为什么我对"无人值守"这么谨慎？因为有一道数学，冷冰冰的，谁也绕不过去。

Agent 干活是多步的。规划、调工具、读结果、再规划……一个像样的任务动辄十几二十步。而每一步都有出错概率，误差会沿着链条累乘，不是累加。

我们来算笔账。假设某一步的准确率是很漂亮的 95%——听着挺可靠了吧？连做 20 步：

0.95^20 ≈ 0.36

只剩 36%。 一个每步 95% 的 agent，跑完一个 20 步的任务，整体做对的概率只有三成多。你以为你雇了个学霸，实际上跑长链条时它是个考试及格线徘徊的学生。这就是复合误差——它是 agent 可靠性问题的数学本质，也是"demo 惊艳、生产拉胯"的根因。我在《一个人的智能系统》 里也算过这笔账，这里再强调一遍，因为它值得所有人背下来。

一个数字容易被当成孤例，摊成一张表你才会真正害怕。横轴是步数，纵轴是单步准确率，格子里是整条链条跑对的概率：

单步准确率 →   90%     95%     98%     99%    99.5%
步数 ↓
   5 步        59%     77%     90%     95%     98%
  10 步        35%     60%     82%     90%     95%
  20 步        12%     36%     67%     82%     90%
  50 步         0.5%    8%     36%     61%     78%
 100 步         0.003%  0.6%   13%     37%     61%

这张表有三个地方值得盯着看久一点。

第一，横着看，右边那几列贵得离谱。 从 95% 挪到 99%，在 20 步那一行是 36% → 82%。但"单步准确率提升 4 个点"这句话轻飘飘，实际含义是把错误率砍掉五分之四——那是换一代模型、重写全部 prompt、把工具接口重做一遍才换得来的东西，而且越往右越难：99% → 99.5% 又要再砍一半错误率。这就是为什么那 1% 的提升如此昂贵又如此值钱。

第二，竖着看，长链条是个绞肉机。 同样是 95% 这个"听起来很不错"的准确率，5 步还有 77%，到 50 步只剩 8%。链条长度对可靠性的伤害，比你直觉里严重一个数量级。 很多人做 agent 的第一反应是"让它多想几步、多调几个工具”，却没意识到每加一步都在往这个乘法里再塞一个小于 1 的因子。

第三，也是最实用的一条——沿着对角线看。 90% 准确率跑 5 步（59%），和 98% 准确率跑 20 步（67%），是一个量级的可靠性。换句话说，缩短链条和提升模型，在数学上是可以互相换算的两种手段。 而其中一种你今天下午就能做，另一种你得等下一代模型。

那怎么办？两条路。

一条是把单步准确率往死里抬。这条路真实存在，也确实有效，但它的价格写在上面那张表的右侧——而且它不在你手里，它在模型厂商手里。

另一条更工程、也更现实：缩短链条、增设检查点、允许回滚。 这一条值得展开算一下，因为很多人以为"加检查点"只是个心理安慰，其实它实打实地改写了那道乘法。

为什么检查点能改变这道数学？ 关键在于：0.95^20 这个式子成立，有一个隐含前提——错误一旦发生，就会一路带到底。第 3 步偏了，后面 17 步都在这个偏了的基础上往前跑，最后交出来的东西必错。检查点做的事情是把这个前提打掉：在第 5 步末尾插一道校验，错了就在这里被抓住、回滚、重跑这一小段，而不是让它继续往下污染。

于是那条 20 步的链条，不再是一个 20 次的连乘，而是四段各 5 步的短乘法：

无检查点：  [1 → 2 → ... → 20]                整体 0.95^20 ≈ 36%
            一次连乘，任何一步错 = 全盘错

有检查点：  [1..5] ✓ [6..10] ✓ [11..15] ✓ [16..20] ✓
             ↑校验    ↑校验     ↑校验      ↑校验
            每段 0.95^5 ≈ 77%，错了只回滚这一段重跑
            允许每段重跑一次 → 每段约 1-(1-0.77)² ≈ 95%
            四段整体 ≈ 0.95^4 ≈ 81%

36% → 81%，靠的不是更好的模型，是更好的脚手架。 注意这个 81% 和"把单步准确率抬到 99%“拿到的 82% 几乎一样——你用工程手段，白嫖到了一整代模型升级的效果。 这是这篇文章里我最想让你记住的一笔账。

当然这里有两个诚实的前提，不说清楚就是骗人。其一，校验本身得是可靠的、而且要比生成便宜。 这也是为什么检查点最好放在那些"对错有客观标准"的地方——测试跑没跑过、schema 合不合法、数字对不对得上、文件存不存在。让一个模型去判断另一个模型写的东西"好不好”，你只是把不确定性挪了个位置，还挪贵了。其二，重跑要真的是独立的一次尝试，如果失败原因是这个任务本身超出了模型能力（比如它就是不会用那个 API），那重跑十次也是十次同样的错，(1-p)² 那个式子直接失效。

所以真正的操作顺序是：先找到那些校验便宜、判定客观的位置，把检查点钉在那儿，让链条在那里断开。 而不是均匀地每 5 步插一刀。

最后再说一句诚实的 caveat：把每步准确率抬到 99% 谈何容易，很多真实任务连稳定的 95% 都摸不到。所以对绝大多数团队来说，第二条路才是当下能落地的那条——你没法让模型不犯错，但你能让它犯的错在被复合放大之前，就撞上一道关卡停下来。这也正是第三篇里那笔"便宜背后的隐藏成本" 的另一面：token 便宜让你敢跑更长的链条，而链条越长，这张表就越往下、越往左把你拖。便宜买来的是尝试次数，不是可靠性；可靠性得你自己在链条上钉检查点钉出来。

四、“夜里跑 / 早上审”：一张图说清整条流水线

把上面这些拼起来，一个可以真正放心用的无人值守 agent，长这样：

        夜里（无人值守）                    早上（HITL）
  ┌─────────────────────────────┐    ┌──────────────────────┐
  │                             │    │                      │
  │  任务 → 规划 → [工具调用]    │    │   ☕ 人来了            │
  │           │                 │    │      │               │
  │           ▼                 │    │      ▼               │
  │   ┌──────────────┐          │    │  只看两类：            │
  │   │ 护栏(执行前)  │──超阈值──┼────┼─▶ ① 评测标红的         │
  │   │ 可逆? 范围?   │  暂停排队│    │   ② 动作不可逆的        │
  │   └──────┬───────┘          │    │      │               │
  │      放行 │                 │    │   ┌──┴──┐             │
  │          ▼                 │    │   │ 批准 │→ 执行        │
  │    执行 → 评测打分 → 落盘    │    │   │ 打回 │→ 回滚重跑    │
  │          │(可回滚存档点)    │    │   └─────┘             │
  │          ▼                 │    │                      │
  │   下一步 / close the loop   │    │   一步错满盘输的动作，   │
  │                             │    │   必须人亲手按下。      │
  └─────────────────────────────┘    └──────────────────────┘

  可回滚的动作 → 交给 agent 自己跑
  不可逆的动作 → 排到 HITL 关卡，等人按

看懂这张图，你就看懂了我全部的观点：agent 的自主权，应该严格按"动作的可逆性"来分配。 改草稿、跑测试、生成初稿，让它撒欢；打钱、删库、对外发布，一律排队等人。自主性不是越高越好，是该高的地方高、该锁的地方锁。

五、护栏分级：一张可以直接照抄的四级表

“按可逆性分配自主权"这句话说起来漂亮，落到工具执行层，你需要的是一张能直接写进配置的表。这是我自己在用的分法，四级，判据只有一个问题：这个动作错了，撤回它要付多大代价？

用这张表的时候，有四个坑我踩过，直接说给你：

第一，分级的对象是"动作”，不是"工具"。 同一个 db.execute 工具，跑 SELECT 是 L0，跑 UPDATE 是 L2，跑 DROP 是 L3。你要是按工具粒度授权，等于把整个工具的最高危险级别授出去了。授权粒度必须细到参数级。

第二，L2 的阈值要按"总量"设，不只按"单次"设。 单次转账上限 500 元，听起来很安全——直到 agent 在一小时里转了 200 次。任何限额都必须同时有单次上限和窗口内累计上限，否则它就是个可以被循环绕过的假护栏。

第三，不确定的时候，往高了归。 分级错误的代价是极度不对称的：把 L3 误判成 L2，你可能损失一个生产库；把 L2 误判成 L3，你只是早上多按一次按钮。这个不对称性大到没有任何理由去优化"少按几次按钮"。

第四，也是最容易漏的——注意动作的组合。 单看每一步都是 L1，连起来可能是 L3。agent 把一份内部数据写进临时文件（L1），把临时文件传到一个对象存储（L1），再把那个存储桶设成公开可读（看起来像个配置操作）——三步都不吓人，合起来是一次数据泄露，而且不可逆。所以除了动作级的护栏，你还需要少量"轨迹级"的规则：比如"任何碰过标记为敏感的数据的链条，其后续的一切外发动作一律升到 L3"。这类规则写起来烦，但它拦的正是那种单点审查永远看不见的事故。

这张表最大的价值不在于它有多精妙——它一点都不精妙——而在于它把"我到底信任这个 agent 到什么程度"这个含糊的心理问题，变成了一份可以被 review、被 diff、被写进 code review 的配置文件。 信任一旦能被版本控制，它就不再是感觉，而是工程。

六、评测集不是设计出来的，是从事故里长出来的

上护栏的阻力其实不大——大家都怕出事。真正卡住绝大多数团队的是第二件：评测集从哪来。

我见过太多团队卡在这一步，卡的原因高度一致：他们想"设计"一套完整的评测集。开个会，拉个文档，试图穷举所有该测的场景。这个会开完，文档写了三页，然后就没有然后了——因为这件事从正面做是做不完的，你永远想不全。

别设计它。让它长出来。 具体五步：

第一步：先跑，别测。 让 agent 在一个低风险范围内真跑起来，跑一两周。你现在最缺的不是评测，是样本——你根本还不知道它会怎么错。凭空想象的失败模式，和它真实的失败模式，重合度低得会让你吃惊。

第二步：每次出事，立刻固化成一条 case。 这是整件事的核心动作。agent 昨晚把一个日期解析错了，导致整份报告的口径歪了——别只是修 prompt 然后翻篇。 把那次的输入、那步的中间状态、正确的输出，原样存成一条 eval case。你的每一次事故，都是老天爷免费送你的一道题，而且是一道你的用户真的会考的题。

第三步：先要"错的样本"，再要"对的样本"。 反直觉但很重要：一个只有正例的评测集几乎没有信息量——模型本来就大概率能做对那些。评测集的价值密度全在负例里。 所以冷启动阶段，优先把每一个失败、每一个人工打回、每一个早晨复核时你皱了眉的产出，全部收进去。

第四步：判分先用客观的，别一上来就上模型评委。 能用精确匹配就精确匹配，能用 schema 校验就 schema 校验，能跑测试就跑测试。只有在实在没有客观判据的地方（比如"这段摘要写得好不好"），才请模型当评委——而且你得意识到，模型评委本身也是个会错的模型，它需要自己的评测。 别用一个没被验证的东西去验证另一个东西。

第五步：接进 CI，改一行就跑。 评测集不接进流程，三周之内必然腐烂。改 prompt、换模型、加工具——每一次都跑一遍，看指标。没有回归保护的评测集，只是一堆躺在仓库里的 JSON。

这套东西的形状大概是这样：

   生产里的一次失败
        │
        ▼
   ┌──────────────────┐
   │ 存证：输入 + 中间 │   ← 事故的价值在这一刻被捕获
   │ 状态 + 正确输出   │      而不是在你修完 prompt 之后
   └────────┬─────────┘
            ▼
   ┌──────────────────┐
   │  固化成 eval case │
   │  标注：为什么错    │
   └────────┬─────────┘
            ▼
   ┌──────────────────┐        ┌────────────────┐
   │   回归评测集      │◀───────│  持续红队产出的 │
   │  （只增不减）      │        │  新攻击样本     │
   └────────┬─────────┘        └────────────────┘
            ▼
   每次改 prompt / 换模型 / 加工具
            │
            ▼
   跑一遍 → 指标涨了？跌了？
            │
            ▼
   跌了就别上线 ← 这条线才是"回归"两个字的全部意义

注意右边那个入口：持续红队的产出，应该直接回灌进同一个评测集。 这不是两套系统，是一套。红队负责"找出新的错法"，评测集负责"保证这个错法以后不再出现"。这个咬合关系，就是我在第八节要展开的那个预测的技术底座。

一个我自己的经验：这个评测集的价值，会在第三个月左右突然显形。 前两个月你会觉得它是负担——每次出事还要多花二十分钟存证。到第三个月，当你换了个新模型，跑一遍评测集，它直接告诉你"这个新模型在你最在乎的七个 case 上退步了"——那一刻你会庆幸得想哭。它是那种回报极度延迟、但一旦兑现就再也回不去的投资。 也正因为回报延迟，它是绝大多数团队一直拖着没做的那件事，而这恰恰是为什么它在下半场会变得那么值钱。

七、早晨的复核清单，和几个别犯的错

护栏和评测都是给机器写的。这一节是给你自己写的——明天早上你坐下，具体看什么。

早晨复核清单

按这个顺序过，从"最可能出大事"排到"最可能被忽略"：

• 先看闸口队列（L3 排队等你按的）。 这是唯一真正需要你的判断力的地方，注意力最好的时候先给它。逐条问自己：这个动作我认得吗？影响半径是我以为的那个吗？如果它错了我能承受吗？
• 再看评测标红的。 不是看它"红了"，是看它为什么红——是模型退步了，还是这条 case 本身过时了？后者比你想的常见，而且它是评测集腐烂的主要来源。
• 看断在半路的链条。 跑到一半停了的任务，往往比跑完的更有信息量——它停在哪，那里就是你的护栏在起作用，或者是你的护栏定错了阈值。长期不被触发的护栏和天天被触发的护栏，都是配错了。
• 抽查一条"全绿"的链条。 这一条最反直觉，也最重要。全绿不代表全对，只代表没触发你已知的检查。 每天随机挑一条从头到尾人工过一遍，你会周期性地发现新的失败模式——而每一个这样的发现，都是下一条 eval case。这是你唯一的"未知的未知"探测器。
• 最后看账单和时长。 这两个数字的异常波动往往是行为漂移的第一个信号：昨晚突然贵了三倍，通常意味着某个地方在重试打转，而不是它突然变勤奋了。

这份清单该花多久？据我观察，一个健康的系统，早晨复核应该稳定在十几二十分钟。 如果每天都要花两小时，说明护栏定太松、太多东西漏到了你面前；如果每天只需要两分钟、什么都不用看，恐怕不是它很可靠，是你的评测根本没在测有意义的东西。这两个方向的偏离，都是要修的。

反模式清单

这几个是我见过最多、也最贵的错法，按危害排序：

• 只上可观测，不上评测。 这是最普遍的一个，前面说过：给车装了行车记录仪，没装刹车。
• 护栏做在 prompt 里。 “请不要删除生产数据"写进 system prompt，然后就放心了。prompt 是建议，不是约束。 护栏必须在工具执行层用代码写死，模型碰不到、改不了、绕不过。任何一道能被一句话说服的护栏，都不是护栏。
• 拿 benchmark 分数当上线依据。 公开榜单证明它在别人挑的题上表现好，跟你的业务、你的边界情况没有关系。
• 模型评委没有被评测过。 用一个模型判另一个模型的分，然后完全相信这个分。你只是把问题挪了个位置，还挪到了一个更看不见的地方。
• HITL 变成橡皮图章。 这个最隐蔽，也最危险。一个每天要点 80 次"批准"的人，在第 30 次的时候就已经不是在审查了，他只是在点。 需要人审的东西一多，人的审查质量就归零——这时候你拥有的不是 HITL，是一个 HITL 的表演。所以护栏的阈值要调到让 L3 队列每天只有个位数，HITL 的价值和它的数量成反比。
• 出了事只修 prompt，不留 case。 每一次这样做，你都在把一次免费的教训扔掉，然后确保同样的错误还会再犯一次。

其中前两条决定你会不会出事，后两条决定你出事之后会不会重复出事。

八、为什么护栏是整个栈里最不成熟的一层

前面反复提护栏，这里得摊开说个不太好听的事实：护栏是当下整个 agent 栈里最不成熟的一层。

模型有一堆 SOTA 可比，推理框架有 LangGraph 们打得火热，可观测有一票成熟工具，向量库、RAG、工具调用协议都在快速收敛。唯独护栏——没有主导框架，没有成熟范式，没有大家默认照抄的最佳实践。 每个团队都在用各自的 if-else、各自的正则、各自拍脑袋定的阈值，重复造着漏风的轮子。

这恰恰是最讽刺的地方：无人值守 agent 最依赖的那一层，偏偏是最不成熟的那一层。 我在《98.4% 是脚手架，1.6% 是判断》 里讲过 harness engineering 的分工——一个 agent 系统里，98.4% 是脚手架，1.6% 是判断。护栏、评测、HITL 关卡，全属于那 98.4% 的脚手架。模型贡献那关键的 1.6% 判断力，但那 1.6% 能不能被你放心地放出去用，完全取决于那 98.4% 的脚手架搭得牢不牢。

说到底，“信息不值钱，值钱的是处理信息的能力”；而在 agent 时代我要再续一句——处理信息的能力也在变便宜，真正值钱的是"敢把处理结果直接拿去用"的那份信任，而信任是被脚手架撑起来的。

九、下半场预测：瓶颈从"造 agent"变成"信 agent”

作为这个专栏，该下判断了。关于 2026 下半场，关于 agent 的信任层，我有两个明确预测。

预测一：评测与可观测赛道，会成为下一个并购战场。

上半场大家的钱和注意力都砸在"造 agent"——更强的模型、更顺的框架、更炫的 demo。下半场，瓶颈会肉眼可见地从**“造 agent"迁移到"信 agent”**。当每家企业都手握一堆能跑的 agent，却谁都不敢真正放手让它无人值守时，市场会疯狂地为"能让我信它"的工具买单。

评测平台、可观测工具、护栏中间件——这三类此前被当作"运维边角料"的东西，会突然变成兵家必争之地。大厂会用收购补齐这一层，因为自己从零搭一套可信的评测/护栏体系，比收购一个成熟团队慢太多。 谁掌握了"让 agent 变得可信"的能力，谁就掌握了 agent 商业化真正的闸门。记住这个判断：下半场的钱，会从"更聪明"流向"更可信"。

这一条和第五篇的蓝海判断 是同一枚硬币的两面。那篇讲"红海已满，蓝海在垂直、受监管、端到端"——而一个受监管领域的 agent，凭什么敢端到端替客户负责到底？ 靠的正是这一篇讲的这套东西：护栏证明它不会乱来，评测证明它做得对，HITL 证明关键决策有人担责。信任层不只是一门生意，它是所有蓝海生意的准入条件。 没有这层地基，“端到端负责"就是一句法务不会让你说出口的话。

预测二：持续红队（continuous red teaming）会成为企业标配。

一次性的上线前安全测试会被淘汰。原因很简单：agent 是活的——你换个模型版本、加个新工具、改段 prompt，它的行为边界就悄悄漂移了。上个月安全的东西，这个月未必。

所以红队不能是一锤子买卖，得变成常驻的、自动化的、持续运行的对抗测试：一支（很可能本身也是 agent 组成的）红队，7×24 地对你的生产 agent 发起攻击、诱导越权、试探护栏边界，一旦发现新漏洞立刻回灌进评测集。持续红队之于 agent 安全，就像 CI/CD 之于软件质量——从"发布前测一次"进化成"永远在测”。到今年底，我预计这会从头部公司的奢侈品，变成严肃部署 agent 的团队的标配。

十、一段必须说的 caveat

预测归预测，我得把话说到位，免得你把这篇读成盲目乐观。

安全长在 harness 里，不长在模型自觉里。

这句话我要用最重的语气说。你永远、永远不能把安全托付给"模型应该会想清楚吧"。模型没有自觉，它只有概率分布。它某一次"想清楚了"，不代表下一次不会在一个你没测过的边角上，一本正经地把生产库删了。真正拦住它的，从来不是它的良知，是你写死在工具执行层那道谁也绕不过去的护栏。

所以底线只有一条，粗体、加黑、刻进 SOP：不可逆的动作，必须 HITL。 打钱、删数据、对外发布、生产部署、发不可撤回的消息——这些动作无论 agent 多"成熟"、评测分多高，都必须有一个人类的手指，落在那个最终确认键上。这不是不信任 agent，这是对复合误差和不可逆性这两个客观事实的基本尊重。

这条底线和第二篇里那个"主动 ≠ 自动决策"的边界 ，其实是同一根钉子敲在两个地方。那篇讲的是"谁来发起"和"谁来拍板"是两个独立维度——agent 可以在发起上极度主动，但必须在拍板上极度克制。这篇讲的护栏分级，就是那个"克制"的具体实现：L0 到 L2 是它可以主动的范围，L3 那道闸是它必须克制的地方。 主动式 agent 不是本文这套体系的例外，它是这套体系上面加盖的一层——它不只要你信任 agent 的执行，还要你信任 agent 的判断（判断"这件事值得现在打扰你"），门槛只高不低。先把无人值守的信任搭牢，再谈主动。顺序反了，你得到的只是一个会主动闯祸的 agent。

十一、结尾：我们真正在学的，是怎么"放手"

写到这儿，我发现这篇表面在谈技术，内核其实是在谈一件更难的事——怎么学会放手。

把活交给一个没人盯着的 agent，本质上和把活交给一个新来的下属没有区别。你不会因为他简历漂亮就第一天让他动生产库；你会先给他划清权限（护栏），让他做的每件事都留痕可查、可被复盘（评测），然后在关键决策上仍然要过你这一关（HITL）。等他一次次证明自己，你才一点点松开手。

信任是被工程一点点挣来的，不是被能力一次性给予的。

这两年 agent 的能力曲线陡得吓人，但我越来越不焦虑"它会不会取代我"，而是越来越清楚一件事：在一个人人都能召唤强大 agent 的时代，稀缺的不再是能干活的 agent，而是有本事搭出一套让 agent 值得被信任的 harness 的人。 前者会越来越便宜，后者会越来越值钱。

所以，回到开头那个问题——第二天早上，你敢不敢直接用它的产出？

我的答案是：当你能亲手回答"护栏兜住了什么、评测判过了什么、还有哪几步必须我按下"，你就敢了。 而这套能力，谁也没法替你搭，只能你自己一层一层长出来。这，大概就是 agent 时代留给我们每个人的、最值得干的那份活。