给 Agent 立规矩：安全审计 Skill

前几篇把 Agent 越讲越能干：一个 Skill 能到处复用，几个 Agent 能并行干活，Super-agent 还有 Router 派活收活。能力上去了，风险也跟着上去了：一个能干的 Agent，一次就能改掉一堆文件、发出去一条消息、花掉一笔钱，或者把不该发的东西发出去了。

所以能力越大，规矩越要先立好。这一篇讲安全审计 Skill：安全不是干完活再检查一遍，而是在动手之前先过一道关，通不过就不动手。 这道关也写成一个 Skill，让 Agent 每次动手前自动先翻它。

一、哪些事碰都不能碰

先把两条红线写死，写进 Skill 里，而不是只记在脑子里：

  • 不可逆的事，必须你点头。 花钱、对外发消息、删数据、改设置、发布文章，这些事一旦做了就收不回来。Skill 里对这类事只能写“停下来等用户确认”，不能写“顺手帮你办了”。Agent 可以把材料准备好、把要发的内容列出来，但按下发送键、确认付款键的那一下，必须是你。
  • 秘密信息，绝不能发出去。 密码、密钥、验证码、证件和银行卡信息、别人的隐私，这些东西不要写进 Skill，不要贴进对话里让 Agent 转发，也不要让 Agent 为了“方便”把它存进一个能对外发的文件里。发出去之前先问一句：这条信息一旦发出去了，还收得回来吗？收不回来，就不发。

这两条还有一个共同点：不要靠 Agent 自己判断。 “这笔钱不大，应该没事”“这条消息看着没问题”——这种判断一旦交给 Agent，出事只是早晚。红线的好处就是不用判断：碰到就停，停下来问你。

二、安全审计 Skill 长什么样

安全审计本身也是一个 Skill，写法和第二篇讲的最小结构一样：一个文件夹、一个 SKILL.md。不同的是，它的触发条件要写得宽一点，正文要写得严一点。

---
name: safety-audit
description: 动手前的安全审计，在 Agent 要花钱、对外发送、删除或修改文件、改设置、发布之前使用。
---

触发条件宽，是因为审计不能漏：只要任务里沾到上面任何一件，就要先翻它。正文严，是因为审计的每一条都要有明确的通过标准，含糊的审计等于没有审计。一个能直接用的正文，可以写成这样：

  1. 核对要做的事是不是不可逆的：是，就停下来等用户确认，不要继续往下做。
  2. 核对要发出去的内容里有没有秘密信息：有，就先去掉，再问用户要不要发。
  3. 核对收件人、版本、数字和日期：这三样有一项对不上，就先停下来，不要猜着发。
  4. 核对要改的文件和范围：只改约定的那一份，改之前先确认备份或回退办法。

注意第 4 条。审计不只管“发不发”，也管“改哪里”：第五篇的三条规矩里，各写各的地盘就是安全的一部分，改错了地方，事后补救比事前多问一句贵得多。

审计 Skill 还有一条纪律：它自己只读不写。 审计是检查，不是动手，它不改文件、不发消息、不跑会改变状态的命令。审计一旦自己下场动手，它就没法再替你把关了。

三、审计放在哪三个位置

一道关不够，审计要放在三个位置，缺一个都可能漏：

  • 动手前，先审一遍。 任务一到，先翻安全审计 Skill，把上面四条过一遍再动手。这是成本最低的一次审计，多问一句，少返工一轮。
  • 动手中间，变了就重审。 做到一半发现任务变了：本来只改文字，现在要顺手改链接；本来只在本地看，现在要发出去。范围一变，之前的审计就作废了，停下来重审一遍，再决定要不要继续。
  • 动手之后，再验一遍。 做完不要直接说“搞定了”，先回头看一遍实际改了什么：改的是不是约定的那一份，有没有多改、改错，发出去的内容是不是核对过的那一份。对不上就先停下来，再核对、再补救，不要接着往下做。

在 Super-agent 里，这三道关由 Router 来守。Worker 只管自己那一份，审计的结论由 Router 执行：通不过的活，Router 不派；做到一半变了的活，Router 叫停。审计的规矩不能由干活的人自己说了算，守关的和干活的必须是两个人，这道关才立得住。

四、动手：给发文章前检查加一道安全审计

拿第二篇那个发文章前检查练一次，目标是：检查还是那五步，但动手之前先过一遍安全审计，通不过就不发。

  1. 先翻安全审计 Skill，把四条过一遍：这篇文章要发布，是不可逆的事，先停下来；文里有没有密钥、验证码这类秘密信息，有就先去掉；收件人和发布位置对不对，标题、数字和日期有没有改过没核对的地方。
  2. 审计通过了，再按第二篇的五步做检查：标题、描述、分类和标签、链接和图片，逐条给出通过或不通过的结果。
  3. 检查里发现问题就改，改完之后范围变了就重审一次：改的是不是约定的那篇文章，有没有顺手改了别的文件。
  4. 最后把结果汇总成一张表交给用户：哪条通过、哪条不通过、审计过了哪几条。发不发，由用户决定，不要直接发布。

练完这一次，对照一下：你多花了一分钟过审计，换来的是发出去的东西和核对过的是同一份。如果哪一步还得你亲自盯着补，问题一般出在审计写得太含糊：把那一条的通过标准再写具体一点，下次就不用你盯了。

练一次：给你的一个 Skill 写一条审计规则

挑一个你已经写好的 Skill，不用重写整个文件，只给它加一条审计规则：

  1. 写下这个 Skill 动手时会碰到的最危险的一件事：是对外发消息，还是删改文件，还是花钱。
  2. 给这件事写一条通过标准：做到什么样才算通过，通不过时停下来问谁。
  3. 把这条规则写进 SKILL.md 的正文开头，触发条件里加上“动手前先读这一条”。
  4. 下次用这个 Skill 时，先看审计有没有被触发：没触发，说明触发条件写窄了，把它放宽一点。

加完之后问自己一句：如果今天换一个人照着这个 Skill 干活，他会不会在同一个地方停下来问你？如果会，这条规矩就立住了；如果不会，说明规则还写在你的脑子里，没写进文件里。

下一篇，我们讲从一个 Skill 到一套工作流：几个 Skill 怎么拼成一套每天都能跑的流程，收个尾。