安全审批机制：AI 能力与人类控制的平衡

想象一个场景：你让 AI 帮你清理一个项目目录中的临时文件。AI 理解了你的意图，生成了一条命令——但它把删除路径写错了，指向了你的源代码目录。如果这条命令被直接执行，你可能在几秒内丢失数周的工作成果。

这不是假设。当 AI 拥有文件读写和命令执行的能力时，任何一次"幻觉"都可能变成真实的损失。Tokeny 的答案是：赋予 AI 工具能力的同时，把最终决定权留给用户。这就是我们的 HITL 安全审批机制。

HITL：让人类始终在决策回路中

HITL 全称 Human-in-the-Loop，即"人在回路"。这个概念源自航空航天和工业自动化领域——在关键系统中，自动化可以辅助决策，但最终的确认权必须在人类手中。

在 Tokeny 中，HITL 的具体表现是：AI 在执行高风险操作前会自动暂停，弹出一个审批弹窗，展示即将执行的操作内容。你查看后可以批准、拒绝，或者修改后再执行。AI 不会擅自做任何你看不到的危险操作。

这个设计与我们"协同而非委托"的核心理念一脉相承：AI 负责思考和建议，人类负责判断和确认。两者各司其职，协同完成任务。

哪些操作需要审批，哪些不需要

并非所有操作都需要审批——那样会让体验变得极其繁琐。我们的设计原则是：读操作自由执行，写操作按风险分级。

需要审批的操作：

• Shell 命令执行：所有 Shell 命令默认需要你逐条批准。Shell 命令不受工作空间沙箱限制，可以访问系统任意位置、执行任意操作——这正是它必须审批的根本原因
• 文件删除：无论是删除单个文件还是递归删除目录，AI 都必须先征得你的同意

不需要审批的操作：

• 读取文件内容——AI 需要阅读你的文件来理解上下文，这是安全的
• 创建和写入文件——新建文件不会破坏现有内容，且文件工具的操作范围被限制在工作空间沙箱内
• 搜索文件内容（grep）——只读操作，不修改任何文件
• 联网搜索和获取网页信息——信息获取不影响本地数据
• 与你的对话交互——AI 随时可以向你提问确认

一次审批的完整流程

以一个具体场景为例：你让 AI 帮你初始化一个 Node.js 项目。

1. 1AI 分析你的需求，决定执行 npm init -y 来初始化项目
2. 2系统暂停执行，弹出审批弹窗，清晰展示命令内容和工作目录
3. 3你查看后确认这条命令是安全的，点击"批准"
4. 4命令执行完成，AI 获得输出结果，继续下一步工作
5. 5AI 接着想执行 npm install express —— 再次弹出审批弹窗
6. 6你确认后批准，流程继续

整个过程中，你始终清楚 AI 在做什么、为什么做、即将执行什么命令。没有任何"黑箱"环节。

审批弹窗中的三个选择

每次审批弹窗出现时，你有三个选择：

• 批准：确认执行这条命令。注意，这只批准当前这一条命令，下一条命令仍然需要单独审批
• 自动执行：开启自动执行模式，在当前工作空间目录下自动执行后续命令。适合你信任当前任务且需要连续执行多条命令的场景
• 拒绝：取消执行这条命令。AI 不会强行执行，而是会换一种方式——它可能会修改命令、选择另一个方案，或者直接问你希望怎么做

拒绝不是"终止任务"。AI 足够灵活，能根据你的拒绝调整策略。你甚至可以在拒绝时输入原因，比如"不要用 rm，用 mv 移到回收站"——AI 会按你的要求修改方案。

智能风险评估：不只是拦截

Tokeny 的安全机制不是简单的"所有命令都拦截"——那只是一个确认按钮，没有实际帮助。我们在审批之上增加了智能风险评估系统。

系统会对每条 Shell 命令进行自动风险分级：

• 低风险（绿色）：只读或信息查询类命令，如 ls、cat、echo、pwd
• 中风险（黄色）：有副作用但影响可控的命令，如 mkdir、cp、npm install
• 高风险（红色）：可能造成不可逆影响的命令，如 rm -rf、chmod 777、curl | bash、格式化磁盘

当检测到高风险命令时，系统会触发额外的 AI 安全分析——用另一个独立的 AI 模型专门分析这条命令的潜在风险，并在审批弹窗中展示详细的风险报告。这意味着你不需要自己判断 chmod -R 777 / 有多危险，系统会明确告诉你。

工作空间沙箱：文件工具的安全防线

除了 HITL 审批，Tokeny 还在文件系统层面设置了安全边界。AI 的文件工具（读取、写入、创建、删除文件等）被严格限制在工作空间目录内：

• 路径穿越防御：AI 无法通过 ../ 等技巧访问工作空间之外的目录
• 符号链接检测：系统会检测指向工作空间外部的符号链接并阻止操作
• 路径白名单：所有文件工具的操作路径必须在工作空间范围内，否则直接拒绝

即使 AI 因为幻觉生成了一条指向系统目录的文件路径，安全验证器也会在执行前将其拦截。这是 HITL 之外的第二道防线。

但需要明确的是：Shell 命令不受沙箱约束。一条 Shell 命令可以访问文件系统的任意位置、执行任意系统操作——这是 Shell 的本质能力，无法通过沙箱来限制。这也是为什么 Shell 命令必须经过 HITL 审批的根本原因：沙箱保护不了的地方，由你来把关。

自动执行模式：效率与安全的平衡点

逐条审批在某些场景下确实会降低效率——比如让 AI 搭建一个项目脚手架，可能需要连续执行 20 多条命令。如果每条都要手动点确认，体验就不太好了。

因此 Tokeny 提供了"自动执行"模式：开启后，Shell 命令会以当前工作空间目录为工作目录自动运行，跳过逐条审批。但这个模式有几个重要特性：

• 你主动选择开启——不是默认行为，而是在审批弹窗中明确选择的
• 工作目录限定——自动执行以当前工作空间目录为工作目录，但 Shell 命令本身仍可能访问工作空间之外的路径
• 随时关闭——你可以在设置中随时关闭自动执行，恢复逐条审批
• 高风险命令仍会拦截——即使开启自动执行，系统识别到的高危命令仍会触发审批

我们对安全的思考

在设计安全机制时，我们反复思考了一个核心问题：安全和效率是否必须对立？

我们的结论是：不需要。关键在于将安全审批放在正确的位置。读取文件不需要审批——那只会制造噪音。执行 Shell 命令需要审批——因为后果可能不可逆。高危命令需要额外分析——因为即使技术用户也可能忽略某些风险。

这就是"默认安全 + 可选放开"的设计哲学：对大多数用户来说，默认的安全设置已经足够好用。对高级用户，自动执行模式提供了效率空间。不同场景、不同信任级别，用户可以自己选择安全策略。