给AI Agent装上「只读模式」：最被低估的安全设计

2026 年最常见的 Agent 事故不是”模型太笨”，而是”模型太能干”。它能操作数据库、能发邮件、能改配置、能提交代码——于是当它理解错一句话的时候，损失也是真金白银。

大多数团队的应对是加一句提示词：“请谨慎操作，重要修改前确认。“这几乎没用。模型对”重要”的判断和人类不在一个频道。

真正有效的做法，是把只读模式当作上线前的必经阶段，而不是出事之后的补救措施。

一、为什么只读模式是第一道防线

只读模式的价值不在于”让 Agent 少干活”，而在于它能回答三个关键问题：

• 它理解对了吗？ 让它跑一个完整任务，但只输出”我打算做什么”，而不是真的去做。
• 它的边界在哪？ 只读权限会立刻暴露它需要的上下文有多宽——很多 Agent 在只读阶段就要求访问全库，这本身就是警报。
• 它会不会乱调工具？ 观察工具调用日志，你会惊讶于某些 Agent 为了回答”本月销售额”调用了多少次内部接口。

换句话说，只读模式是一台免费的监控仪。它让你在不承担风险的前提下，看清 Agent 的真实行为。

二、五级权限分级清单

在项目启动时就把权限分成五级，比事后翻审计日志强得多：

L0 纯解答：只返回文本，不调用任何工具。适用于知识问答、解释类任务。

L1 只读工具：可调用查询类接口（搜索、读数据库、读文件），结果只返回给模型，不落库、不外发。这是上线前两周的默认形态。

L2 沙箱写入：可在隔离环境内写（临时目录、测试数据库、草稿箱），结果不进生产。

L3 受限写入：可写生产但受配额限制——每月最多发 100 封邮件、每天最多改 10 条记录，超额需人工审批。

L4 自主写入：仅对经过充分验证的窄任务开放，例如”给已关闭的工单打标签”。

关键原则：升级必须有数据依据，例如”在 L1 阶段连续 200 次任务，工具选择正确率 > 98%，无越权调用”，而不是”老板说可以了”。

三、实现方式：三条落地路径

1. 在工具层做，不要在提示层做。 提示词说”你不能删除记录”是建议，代码里不暴露 delete 接口才是约束。把工具注册表按权限级别配置，L1 阶段的 Agent 根本没有写工具可调用。

2. 凭证分级，而不是逻辑分级。 给 Agent 配一个只读数据库账号，比在代码里写 if (isReadOnly) return 可靠得多。数据库层面的约束无法被提示注入绕过。

3. 记录”打算做什么”。 在 L1 阶段强制 Agent 输出结构化的操作意图（intent + 参数 + 预期影响），人工抽检。这批样本是后续设计审批规则的最佳素材。

四、一个真实的时间表

我们内部常用的节奏是：

• 第 1～3 天：L0 调试，确认基础能力
• 第 4～17 天：L1 只读运行，收集 200+ 任务样本
• 第 18～24 天：L2 沙箱写入，对比沙箱结果与人工预期
• 第 25 天起：L3 受限写入，配审批队列，逐步放开配额

整个周期约四周，比”直接上线然后天天救火”快得多。

写在最后

Agent 的能力上限很高，但它的可靠性是渐进的。只读模式就像给新员工的前两周安排”陪跑看流程”——不是不信任他，而是让他在没有成本的地方犯错。

如果你现在正打算把一个能写数据库的 Agent 上线，建议先把它降级到 L1，跑两周，看一眼日志。这个动作的成本几乎为零，但它可能避免一次最昂贵的教训。