假设你现在真的有一个 agent，能把一件事从头做到尾——拉数据、写代码、跑测试、发 PR、改文档，一条龙。它不需要你在旁边一句一句喂提示词。你晚上把任务丢给它，去睡觉。
真正的问题不只在于它能不能做完。在代码、研究和内容工作流里，模型往往已经能交出一个看起来像样的结果；遇到陌生领域和真正的新问题，能力仍可能是瓶颈。但只要 agent 已经能够动手，另一个问题就会浮上来——
第二天早上，你敢直接把它的产出拿去用吗？
敢，你就真正收回了注意力。不敢，它仍只是更花哨的自动补全：你逐行审、逐行改，又把省下的时间交了回去。这是一个信任问题——不是相信模型“会自觉”，而是拿出证据证明系统没有越权、错误能被发现、状态可以恢复。
demo 到生产之间，隔着一条"评测鸿沟"
我见过太多惊艳的 agent demo。录屏里它行云流水，一次做对，观众鼓掌。然后这东西一进生产，就开始漏水。
原因不玄乎。demo 是被精心挑过的一次成功，生产是没人挑的一万次连续运行。 前者只需要"能对一次"，后者需要"错得起、被发现、能回滚"。这中间隔着的东西，我把它叫作评测鸿沟。
很多团队其实已经隐约意识到有条鸿沟，于是拼命上可观测性（observability）：链路追踪、token 计费、每一步工具调用的日志、失败重试的告警。这些都对，但要看清它们到底解决了什么——
可观测性告诉你"发生了什么"，评测（evals）才告诉你"对不对"。
这是两码事。可观测能告诉你 agent 昨晚调了 47 次工具、花了 3 块 2 毛钱、第 31 步重试了两次。它没法告诉你：这 47 次调用里，那份最终交出来的报告，结论是不是错的。 日志再全，也只是把一场事故录得很清楚，不能阻止事故。
LangChain《State of Agent Engineering》调查 把这种错位量化得很清楚：全部受访者中，89% 使用了某种 agent 可观测能力，52.4% 会在测试集上做离线评测，37.3% 做在线评测；在已经把 agent 投入生产的受访者中，94% 使用了某种可观测能力。这里的分母不同，不能硬拼成“生产团队九成可观测、只有一半评测”的比例。它真正支持的结论更克制：记录 agent 行为，比系统地验证结果更普遍。
换句话说，很多团队先装了行车记录仪，刹车却还没校准。我们擅长看见 agent 做过什么，却不够习惯追问：它做的到底对不对。
这正是我在《一个人的智能系统》 里反复强调的：观测性只是入场券，评测才是护城河。
无人值守 agent 的信任三件套
那到底怎么才能"放心"？我的答案很朴素，也很工程：信任不是求来的，是搭出来的。具体是三件套。
第一件：执行前授权的护栏（guardrails before action）。
大多数人对护栏的理解还停留在"过滤输出"——等 agent 说完话，再拿个分类器扫一遍有没有脏东西。这太晚了。对一个会动手的 agent，危险从来不在它"说了什么"，而在它"做了什么"。
护栏必须前移到工具执行层。不是拦它的话，是拦它的手。在真正调用 delete、transfer、deploy、send 之前，先问：动作是否获准、影响半径多大、是否可逆、金额或范围是否越过阈值。该由 harness 在执行前决定放不放行，而不是指望模型自己“想清楚”。 OWASP 对过度代理权的建议
强调最少功能、最小权限与高影响动作的人类批准；Anthropic 的 Claude 隔离实践
则从沙箱、虚拟机、出站控制和窄工具权限解释如何压低失控后的影响半径。
还要防一种更贴近界面的攻击：伪造审批对话框。模型输出里出现一个“已批准”按钮或一段长得像系统提示的文字，不能改变授权状态。批准信号必须来自受信任的控制面，绑定具体动作、参数、身份、时效与不可重放的请求 ID；下游服务还要独立验权，不能把“上游 agent 说批准了”当凭证。最小权限不是在入口检查一次，而是每一道真正产生副作用的边界都重新检查。
至于这道授权具体怎么分级，我在第五节给了一张可以直接照抄的四级表——那是这篇里最能马上用起来的东西。
第二件：可回归的评测（regression evals）。
护栏防的是未经授权的动作，评测回答工作有没有达到目标。关键词是可回归——你得有一套固定的、能反复跑的评测集，每次改 prompt、换模型、加工具，都重新跑一遍，看指标是涨了还是掉了。Anthropic 的 Agent 评测指南 把一条评测拆成任务、环境和明确的判分逻辑，这比一个模糊的“模型分”更适合落地。
这里有个反直觉但极其重要的点：benchmark 通过，不代表真能用。 公开榜单刷得再高，也只证明它在别人挑的题上表现好。你的业务、你的数据、你的边界情况，得你自己出题、自己判分。我甚至观察到行业里开始出现新的排名范式——把人类偏好和事实性（factuality） 加权结合起来打分，而不是只看单一维度对错。这说明大家终于意识到：“看起来对"和"真的对"是两件必须分开测的事。
第三件：早晨的 HITL 复核。
HITL，人在回路（Human-in-the-Loop）。这不是倒退回手动，而是把人的注意力从"全程盯着"精确地挪到"关键点按一下”。
夜里 agent 自己跑，护栏兜住不可逆动作，评测给每个产出打上置信度。早上你端着咖啡坐下，只审两种东西：评测标红的，和动作不可逆的。可回滚的（改个草稿、跑个测试、生成个报告）随它去；一步错满盘输的（打钱、删库、对外发布、生产部署），必须你亲手按下那个按钮。
这三件套的顺序不能乱：护栏在前（别闯祸），评测在中（判对错），HITL 在后（担最终责）。 三者缺一，“无人值守"就是句空话。
复合误差：一道你绕不过去的硬数学
为什么我对"无人值守"这么谨慎？因为有一道数学，冷冰冰的，谁也绕不过去。
Agent 干活是多步的：规划、调工具、读结果、再规划。先做一个刻意简化的玩具模型：二十步都不可缺，每一步正确率都是 95%，而且各步相互独立。那么整条链路一次无错的概率是：
0.95^20 ≈ 0.36
这里的 36% 是“全程无错率”，不是所有 agent 的实测成功率。现实中的步骤难度不同、错误并不独立，有些偏差无伤大雅，也可能有一次早期错误让后续失败高度相关。这个模型的价值只有一个：提醒我们，漂亮的局部准确率不会自动变成可靠的端到端结果。
把同一个独立且必需步骤的假设摊开：
单步准确率 → 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%
横着读，单步错误率从 5% 降到 1%，二十步全程无错率会从 36% 升到 82%；竖着读，增加必需步骤会迅速拉低结果。它不是“长链必坏”的证明，却足以要求我们测量自己真实的链路。
工程上的回应是：缩短链条，在客观状态上设检查点，并让工作可恢复。 检查点没有让模型变聪明，它只是让可检测的错误别继续污染下游，并允许系统回到已知正确的状态。
下面的第二笔账假设更强：把二十个独立步骤分成四段，每段五步；每段成功率 p = 0.95^5 ≈ 0.77。再假设检查点能召回所有错误、绝不误杀正确结果，回滚能精确还原状态，而且一次重试与前一次独立、成功率不变：
无检查点： [1 → 2 → ... → 20] 全程无错率 = 0.95^20 ≈ 36%
有检查点： [1..5] ✓ [6..10] ✓ [11..15] ✓ [16..20] ✓
每段成功率 p ≈ 77%
两次尝试内成功 = 1-(1-p)² ≈ 95%
四段都恢复成功 ≈ 0.95^4 ≈ 81%
36% 到 81% 不是免费午餐，更不是生产预测。它用更多尝试、延迟、算力、状态存储和运维复杂度换可靠性，而现实会从四个地方击穿假设：
- 检查点召回率。 若检查只能以比例
r抓住坏段，一次重试后的正确率是p + (1-p)rp，不是1-(1-p)²；漏检会继续流向下游。 - 误报率。 把好结果判成坏结果，会制造无意义的重试、成本、延迟，甚至把本来成功的任务判死。
- 重试相关性。 对同一坏上下文重复同一提示，往往只是复刻错误。需要换上下文、策略、工具，或升级给人。
- 可恢复性。 只有能回到已知正确状态时，重试才有意义。外部副作用必须幂等、可补偿或延迟提交；已经汇出的款，不能假装没发生再试一次。
因此不要机械地每五步插一刀。把检查点放在测试是否通过、schema 是否合法、数字能否对账、权限是否越界这些有客观判据的地方，并用真实事故测量召回率与误报率。模型评委可以补主观质量，却也会引入一个需要校准的概率组件。
这也是第三篇里“便宜背后的隐藏成本” 的另一面：便宜 token 让你买到更多尝试，却买不到可靠恢复。恢复依赖状态、证据与边界。
“夜里跑 / 早上审”：一张图说清整条流水线
把上面这些拼起来，一个可以真正放心用的无人值守 agent，长这样：
夜里（无人值守） 早上（HITL）
┌─────────────────────────────┐ ┌──────────────────────┐
│ │ │ │
│ 任务 → 规划 → [工具调用] │ │ ☕ 人来了 │
│ │ │ │ │ │
│ ▼ │ │ ▼ │
│ ┌──────────────┐ │ │ 只看两类： │
│ │ 护栏(执行前) │──超阈值──┼────┼─▶ ① 评测标红的 │
│ │ 可逆? 范围? │ 暂停排队│ │ ② 动作不可逆的 │
│ └──────┬───────┘ │ │ │ │
│ 放行 │ │ │ ┌──┴──┐ │
│ ▼ │ │ │ 批准 │→ 执行 │
│ 执行 → 评测打分 → 落盘 │ │ │ 打回 │→ 回滚重跑 │
│ │(可回滚存档点) │ │ └─────┘ │
│ ▼ │ │ │
│ 下一步 / close the loop │ │ 一步错满盘输的动作， │
│ │ │ 必须人亲手按下。 │
└─────────────────────────────┘ └──────────────────────┘
可回滚的动作 → 交给 agent 自己跑
不可逆的动作 → 排到 HITL 关卡，等人按
看懂这张图，你就看懂了我全部的观点：agent 的自主权应随风险证据分配。 可逆性很重要，却不是唯一维度；还要同时看影响 × 概率、数据敏感度、调用身份已有权限，以及组织自己的风险容忍度。改草稿、跑测试、生成初稿可以在隔离且可恢复的空间里放开；打钱、删库、对外发布则进入人工闸口。自主性不是越高越好，是该高的地方高、该锁的地方锁。
护栏分级：一张可以直接照抄的四级表
落到工具执行层，需要一张能写进策略配置的表。下面四级是我的启发式起点，不是行业标准。部署前仍要结合影响 × 概率、数据敏感度、执行身份的权限和业务风险容忍度校准；一个可逆动作若接触高敏数据，也可能需要升档。
| 级别 | 判据 | 典型动作 | harness 怎么处理 |
|---|---|---|---|
| L0 只读 | 无副作用，纯读 | 读文件、查数据库、跑只读查询、搜索 | 直接放行；仍按审计、取证与隐私要求保留必要记录 |
| L1 留痕 | 可逆，撤回成本≈0 | 写临时文件、跑测试、生成草稿、开分支 | 放行，但必须留可回滚的存档点 |
| L2 限额 | 可逆，但撤回要花钱/花时间 | 写数据库、调收费 API、提交到非主干、发内部通知 | 放行但设阈值：单次上限、总量上限、频率上限；超限→降级到 L3 |
| L3 闸口 | 不可逆，或撤回代价极高 | 打钱、删数据、对外发布、生产部署、发不可撤回的消息、改权限 | 一律排队等人按，无例外 |
用这张表的时候，有四个坑我踩过，直接说给你：
第一，分级的对象是"动作”，不是"工具"。 同一个 db.execute 工具，跑 SELECT 是 L0，跑 UPDATE 是 L2，跑 DROP 是 L3。你要是按工具粒度授权，等于把整个工具的最高危险级别授出去了。授权粒度必须细到参数级。
第二，L2 的阈值要按"总量"设，不只按"单次"设。 单次转账上限 500 元，听起来很安全——直到 agent 在一小时里转了 200 次。任何限额都必须同时有单次上限和窗口内累计上限，否则它就是个可以被循环绕过的假护栏。
第三，不确定的时候，往高了归。 分级错误的代价是极度不对称的：把 L3 误判成 L2，你可能损失一个生产库；把 L2 误判成 L3，你只是早上多按一次按钮。这个不对称性大到没有任何理由去优化"少按几次按钮"。
第四，也是最容易漏的——注意动作的组合与轨迹数据。 单看每一步都是 L1，连起来可能是 L3：agent 读内部数据、写临时文件、传到对象存储，再把桶设为公开，合起来就是数据泄露。提示注入还可能藏在网页、issue 或文档里，诱导 agent 把系统提示、密钥或完整轨迹带出边界。所以除了动作级护栏，还需要轨迹级数据流规则：接触过敏感数据的链条，后续外发一律升到 L3；日志和评测样本也要脱敏、限权和设保留期，不能让“为了可观测”反过来成为泄露通道。
这张表最大的价值不在于它有多精妙——它一点都不精妙——而在于它把"我到底信任这个 agent 到什么程度"这个含糊的心理问题，变成了一份可以被 review、被 diff、被写进 code review 的配置文件。 信任一旦能被版本控制，它就不再是感觉，而是工程。
评测集不是设计出来的，是从事故里长出来的
上护栏的阻力其实不大——大家都怕出事。真正卡住绝大多数团队的是第二件：评测集从哪来。
我见过太多团队卡在这一步，卡的原因高度一致：他们想"设计"一套完整的评测集。开个会，拉个文档，试图穷举所有该测的场景。这个会开完，文档写了三页，然后就没有然后了——因为这件事从正面做是做不完的，你永远想不全。
别设计它。让它长出来。 具体五步：
第一步：先在沙箱或严格限权的低风险范围试跑并测量。 先准备一小组设计用例，再让真实轨迹暴露你没想到的失败模式。不要为了收集样本，把用户或生产数据直接暴露给一个尚未验证的 agent。
第二步：每次出事，立刻固化成一条 case。 agent 把日期解析错，导致整份报告口径歪了——别只是修 prompt 然后翻篇。 保存经过隐私处理的输入、相关中间状态、预期行为与最小复现。事故是一堂昂贵的课；回归用例把它的价值留下来。
第三步：先要"错的样本"，再要"对的样本"。 反直觉但很重要：一个只有正例的评测集几乎没有信息量——模型本来就大概率能做对那些。评测集的价值密度全在负例里。 所以冷启动阶段，优先把每一个失败、每一个人工打回、每一个早晨复核时你皱了眉的产出，全部收进去。
第四步：判分先用客观的，别一上来就上模型评委。 能用精确匹配就精确匹配，能用 schema 校验就 schema 校验，能跑测试就跑测试。只有在实在没有客观判据的地方（比如"这段摘要写得好不好"），才请模型当评委——而且你得意识到，模型评委本身也是个会错的模型，它需要自己的评测。 别用一个没被验证的东西去验证另一个东西。
第五步：接进变更路径。 改 prompt、换模型、加工具，运行相关评测并看差值；过慢或昂贵的全量套件可以定时运行，而不是假装每次提交都跑得起。这与 NIST AI RMF 对部署前及运行中持续进行测试、评估、验证与确认 的要求一致。没有回归保护的评测集，只是一堆躺在仓库里的 JSON。
这套东西的形状大概是这样：
生产里的一次失败
│
▼
┌──────────────────┐
│ 存证：输入 + 中间 │ ← 事故的价值在这一刻被捕获
│ 状态 + 正确输出 │ 而不是在你修完 prompt 之后
└────────┬─────────┘
▼
┌──────────────────┐
│ 固化成 eval case │
│ 标注：为什么错 │
└────────┬─────────┘
▼
┌──────────────────┐ ┌────────────────┐
│ 回归评测集 │◀───────│ 持续红队产出的 │
│ （只增不减） │ │ 新攻击样本 │
└────────┬─────────┘ └────────────────┘
▼
每次改 prompt / 换模型 / 加工具
│
▼
跑一遍 → 指标涨了？跌了？
│
▼
跌了就别上线 ← 这条线才是"回归"两个字的全部意义
注意右边那个入口：持续红队的产出，应该直接回灌进同一个评测集。 这不是两套系统，是一套。红队负责"找出新的错法"，评测集负责"保证这个错法以后不再出现"。这个咬合关系，就是我在第八节要展开的那个预测的技术底座。
在我自己的一个小型工作流里，事故集积累几个月后才显出回报：换模型时，它及时抓到了我最在乎的几条回归。这里没有“第三个月必然见效”的行业规律；价值出现得早晚，取决于运行量、变化频率与事故密度。更普遍的事实是：回报滞后，所以这件事最容易被推迟。
早晨的复核清单，和几个别犯的错
护栏和评测都是给机器写的。这一节是给你自己写的——明天早上你坐下，具体看什么。
早晨复核清单
按这个顺序过，从"最可能出大事"排到"最可能被忽略"：
- 先看闸口队列（L3 排队等你按的）。 这是唯一真正需要你的判断力的地方，注意力最好的时候先给它。逐条问自己：这个动作我认得吗？影响半径是我以为的那个吗？如果它错了我能承受吗？
- 再看评测标红的。 不是看它"红了"，是看它为什么红——是模型退步了，还是这条 case 本身过时了？后者比你想的常见，而且它是评测集腐烂的主要来源。
- 看断在半路的链条。 跑到一半停了的任务，往往比跑完的更有信息量——它停在哪，那里就是你的护栏在起作用，或者是你的护栏定错了阈值。长期不被触发的护栏和天天被触发的护栏，都是配错了。
- 抽查一条"全绿"的链条。 这一条最反直觉，也最重要。全绿不代表全对，只代表没触发你已知的检查。 每天随机挑一条从头到尾人工过一遍，你会周期性地发现新的失败模式——而每一个这样的发现，都是下一条 eval case。这是你唯一的"未知的未知"探测器。
- 最后看账单和时长。 这两个数字的异常波动往往是行为漂移的第一个信号：昨晚突然贵了三倍，通常意味着某个地方在重试打转，而不是它突然变勤奋了。
在我的小型个人工作流里，目标大约是 15–20 分钟，它不是行业基准。合适时长取决于风险、运行量和审阅者经验。真正该持续看的，是审批队列长度与等待时延、单项审阅时间、误批与撤销率、漏检事故、检查点召回率与误报率。队列无限增长，就缩小自主范围或改进分流；长期什么都不浮上来，就验证检查是否真的有召回能力。
反模式清单
这几个是我见过最多、也最贵的错法，按危害排序：
- 只上可观测，不上评测。 这是最普遍的一个，前面说过：给车装了行车记录仪，没装刹车。
- 护栏做在 prompt 里。 “请不要删除生产数据"写进 system prompt，然后就放心了。prompt 是建议，不是约束。 护栏必须在工具执行层用代码写死，模型碰不到、改不了、绕不过。任何一道能被一句话说服的护栏，都不是护栏。
- 拿 benchmark 分数当上线依据。 公开榜单证明它在别人挑的题上表现好，跟你的业务、你的边界情况没有关系。
- 模型评委没有被评测过。 用一个模型判另一个模型的分，然后完全相信这个分。你只是把问题挪了个位置，还挪到了一个更看不见的地方。
- 把审批界面当安全边界。 模型可以伪造“系统已批准”的文字或按钮，网页中的提示注入也可能诱导它请求更大权限。审批必须由受信任控制面生成并绑定具体参数；下游服务独立授权，不能相信 agent 自报的批准状态。
- HITL 变成橡皮图章。 审批提示不会凭空制造注意力。Anthropic 报告 ，Claude Code 用户批准了约 93% 的权限提示，注意力还会随提示累积而下降，这推动了它转向隔离与更安全的自动批准。把审阅量视为可测的容量约束，不要把“有一个批准按钮”当成安全证据。
- 出了事只修 prompt，不留 case。 每一次这样做，你都在把一次免费的教训扔掉，然后确保同样的错误还会再犯一次。
其中前两条决定你会不会出事，后两条决定你出事之后会不会重复出事。
为什么护栏是整个栈里最不成熟的一层
在我自己的项目里，护栏仍是最难标准化的一层。这是个人观察，不是行业测量。 模型有可比较的 benchmark，可观测也逐渐形成通用 trace；一到授权策略，问题就迅速落回具体产品的权限、预算、状态迁移与恢复规则。
这不全是工具不成熟。风险本来就活在语境里：同一个数据库连接上的 SELECT、UPDATE 和 DROP，不可能因为共用工具就共用策略。OWASP AI Agent Security Cheat Sheet
提供了很好的基线，但应用所有者仍要编码自己的影响半径和审批边界。
我在《98.4% 是脚手架，1.6% 是判断》 里故意用了一个尖锐的比例来描述分工；它不是统计测量。真正的意思是：少量模型判断要依靠大量普通系统工程，而你敢不敢放出那点判断力，取决于权限、测试和恢复路径是否扎实。
说到底，“信息不值钱，值钱的是处理信息的能力”；而在 agent 时代我要再续一句——处理信息的能力也在变便宜，真正值钱的是"敢把处理结果直接拿去用"的那份信任，而信任是被脚手架撑起来的。
下半场预测：瓶颈从"造 agent"变成"信 agent”
作为这个专栏，该下判断了。关于 2026 下半场，关于 agent 的信任层，我有两个明确预测。
预测一：评测与可观测赛道，会成为下一个并购战场。
上半场大家的钱和注意力都砸在"造 agent"——更强的模型、更顺的框架、更炫的 demo。下半场，瓶颈会肉眼可见地从**“造 agent"迁移到"信 agent”**。当每家企业都手握一堆能跑的 agent，却谁都不敢真正放手让它无人值守时，市场会疯狂地为"能让我信它"的工具买单。
评测平台、可观测工具、护栏中间件——这三类此前常被当作“运维边角料”的东西，会变成争夺对象。大厂可能用收购补齐这一层，因为从零搭一套可信的评测与护栏体系，往往比整合一个成熟团队更慢。 我的判断是：下半场会有更多钱从“更聪明”流向“更可信”。
这不是无法证伪的气氛判断。我会在 2026 年末复盘两个指标：公开披露的 agent 评测、可观测或护栏公司的收购与重大投资数量，以及主流 agent 平台是否把回归评测与策略执行从可选插件提升为默认产品面。若交易没有明显增加、默认产品仍只强调生成能力，这条预测就算失败。
这一条和第五篇的蓝海判断 是同一枚硬币的两面。那篇讲"红海已满，蓝海在垂直、受监管、端到端"——而一个受监管领域的 agent，凭什么敢端到端替客户负责到底？ 靠的正是这一篇讲的这套东西：护栏证明它不会乱来，评测证明它做得对，HITL 证明关键决策有人担责。信任层不只是一门生意，它是所有蓝海生意的准入条件。 没有这层地基，“端到端负责"就是一句法务不会让你说出口的话。
预测二：持续红队（continuous red teaming）会成为企业标配。
一次性的上线前安全测试会被淘汰。原因很简单：agent 是活的——你换个模型版本、加个新工具、改段 prompt，它的行为边界就悄悄漂移了。上个月安全的东西，这个月未必。
所以红队不能是一锤子买卖，得变成常驻、自动化、持续运行的对抗测试：在隔离环境里诱导越权、试探护栏、测试提示注入与数据外泄，并把新洞回灌进评测集。持续红队之于 agent 安全，就像 CI/CD 之于软件质量——从发布前测一次，走向每次变更都留下证据。
我也给这条预测设一把尺：到 2026 年末，抽样检查公开描述生产级 agent 安全流程的主要平台和企业案例，看其中是否多数明确包含周期性或按变更触发的对抗测试，以及新攻击样本是否进入回归集。若仍以一次性上线审计为主，“成为标配”这个说法就不成立。
一段必须说的 caveat
预测归预测，我得把话说到位，免得你把这篇读成盲目乐观。
安全长在 harness 里，不长在模型自觉里。
这句话我要用最重的语气说。你永远、永远不能把安全托付给"模型应该会想清楚吧”。模型没有自觉，它只有概率分布。它某一次"想清楚了"，不代表下一次不会在一个你没测过的边角上，一本正经地把生产库删了。真正拦住它的，从来不是它的良知，是你写死在工具执行层那道谁也绕不过去的护栏。
所以底线只有一条，粗体、加黑、刻进 SOP：不可逆的动作，必须 HITL。 打钱、删数据、对外发布、生产部署、发不可撤回的消息——这些动作无论 agent 多"成熟"、评测分多高，都必须有一个人类的手指，落在那个最终确认键上。这不是不信任 agent，这是对复合误差和不可逆性这两个客观事实的基本尊重。
这条底线和第二篇里那个"主动 ≠ 自动决策"的边界 ，其实是同一根钉子敲在两个地方。那篇讲的是"谁来发起"和"谁来拍板"是两个独立维度——agent 可以在发起上极度主动，但必须在拍板上极度克制。这篇讲的护栏分级，就是那个"克制"的具体实现：L0 到 L2 是它可以主动的范围，L3 那道闸是它必须克制的地方。 主动式 agent 不是本文这套体系的例外，它是这套体系上面加盖的一层——它不只要你信任 agent 的执行，还要你信任 agent 的判断（判断"这件事值得现在打扰你"），门槛只高不低。先把无人值守的信任搭牢，再谈主动。顺序反了，你得到的只是一个会主动闯祸的 agent。
结尾：我们真正在学的，是怎么"放手"
写到这儿，我发现这篇表面在谈技术，内核其实是在谈一件更难的事——怎么学会放手。
把活交给一个没人盯着的 agent，本质上和把活交给一个新来的下属没有区别。你不会因为他简历漂亮就第一天让他动生产库；你会先给他划清权限（护栏），让他做的每件事都留痕可查、可被复盘（评测），然后在关键决策上仍然要过你这一关（HITL）。等他一次次证明自己，你才一点点松开手。
信任是被工程一点点挣来的，不是被能力一次性给予的。
这两年 agent 的能力曲线陡得吓人，但我越来越不焦虑"它会不会取代我"，而是越来越清楚一件事：在一个人人都能召唤强大 agent 的时代，稀缺的不再是能干活的 agent，而是有本事搭出一套让 agent 值得被信任的 harness 的人。 前者会越来越便宜，后者会越来越值钱。
所以，回到开头那个问题——第二天早上，你敢不敢直接用它的产出？
我的答案是：当你能亲手回答"护栏兜住了什么、评测判过了什么、还有哪几步必须我按下"，你就敢了。 而这套能力，谁也没法替你搭，只能你自己一层一层长出来。这，大概就是 agent 时代留给我们每个人的、最值得干的那份活。
读者回响