让人工智能安全行动，需要一份审计日志，而不是五份

答错一个问题，浪费的是一分钟。做错一个动作，则会把邮件发出去、把商机挪走、把发票冲掉。生成式人工智能与智能体式人工智能之间的差距，就是「帮不上忙」与「有危险」之间的差距——而要安全地跨过这道差距，大部分工作发生在模型之下。

Cyril 从一开始就是为「智能体代表你采取行动」而设计的。这件事能成立的前提，是每一个动作都经过人类动作同样要经过的三关：一次权限校验、一条审计记录，以及一条撤销它的路径。

动作散落在五个工具里的问题

在一套拼接起来的技术栈里，会行动的智能体只能透过集成去行动。它在一个工具里创建项目，通过另一个工具发送邮件，再到第三个工具里更新商机。每个工具都有自己的权限模型、自己的（或者根本没有的）审计轨迹，而且对「撤销」没有任何共同的定义。

于是当出问题时——而有了智能体，问题一定会出现——你只能从五份互不相通的日志里还原经过，它们不共享 ID，不共享时钟，也不共享词汇。你回答不了唯一重要的那个问题：智能体做了什么，凭谁的授权做的，我该怎么把它撤回来？

这不是模型安全问题，而是架构问题，一段护栏提示词修不好它。

一套权限模型

在 Cyril 里，智能体是一个调用者，而不是上帝模式。它运行在管辖人类的同一套 RBAC 之内：被限定在某个 org_id 之下，受角色约束，只被允许其授权中明确列出的权限——一点不多。当智能体被要求做超出其权限的事，它会被拒绝，方式与用户被拒绝时完全相同，走的也是同一条代码路径。

这一点之所以重要，是因为它让智能体的权限变得可读。「这个智能体能做什么？」与「这个人能做什么？」的答案形状完全一致——而且你在同一个地方设置它们。

一份审计日志

每一个动作——无论出自人类还是智能体——都写入同一份审计轨迹，其中包含操作者、它所依据的授权、变更前后的内容，以及来自同一个时钟的时间戳。智能体的动作会被如实标记，因此「把上周助手对 Phoenix 客户所做的一切都列出来」是一次查询，而不是一场跨系统的取证还原。

当动作与记录同处一张图谱之上，审计日志就不是外挂上去的东西，而是对同一份数据的一次自然读取。

一条回滚路径

因为变更是事务性的，租户数据是软删除而非真正销毁，所以智能体的动作有一个明确定义的逆操作。走错一步是可以恢复的一步。保护你免于人类误点击的那套机制，同样保护你免于智能体的错误步骤——不存在另一条更危险、绕开安全护栏的「人工智能写入」通道。

人工介入是一个设置项，不是一次重写

有些动作直接执行就好；有些应该等人来确认。因为每个动作都走同一条流水线，「需要审批」是你施加在某一类动作上的策略，而不是一项需要为每个集成重新工程的功能。你按动作决定放给智能体多长的绳子，并且可以随时改变主意，而不必去动智能体本身。

这对你意味着什么

• 让智能体跑一条跨模块的多步流程，然后在一份日志里、以一个身份，清楚看到它究竟做了什么。
• 给它真实的权限，但不是无边界的权限——与你的团队同样的角色，同样的范围限定。
• 像撤销任何一步那样撤销走错的一步，因为从来就不存在第二条更弱的写入路径。

值得信任的人工智能行动，关键不在提示词，而在于底下的平台能否为智能体的所作所为负责到底。Cyril 的构建方式，是让它永远都能。

常见问题

一段护栏提示词还不够吗？

提示词塑造的是模型试图做什么，它对平台允许它做什么毫无影响；而当前者出错时，真正兜底的是后者。把提示词当作人体工学设计，把权限模型当作控制手段。

智能体应该拥有自己的服务账号吗？

不应该是一个权限宽泛的服务账号。一个拥有大范围读取权限的服务账号，会把「授权」这个问题从你的角色模型里挪到一个没人复核的地方。让智能体以用户的身份、在该用户的权限之内行事，才能让「这个智能体能做什么」与「这个人能做什么」在同一个地方得到解答。

「一条回滚路径」到底意味着什么？

意味着智能体的写入走的是与人类完全相同的那条事务性、软删除的代码路径——所以逆操作本来就存在。不存在第二条为人工智能准备的、绕开安全护栏的更弱写入通道，而那条通道，正是上线压力之下最容易被加进来的东西。

可以只对部分动作要求审批吗？

可以，而这正是把一切都汇入同一条流水线的意义所在：审批是施加在某一类动作上的策略，而不是为每个集成分别重建的功能。你可以调整放给智能体的绳子有多长，而完全不必去动智能体。

---

如果你希望成为最早使用 Cyril 的用户，加入等候名单。