让 AI 驱动研究流程，不等于让 AI 决定系统怎么运行。我在设计 AI 编排系统时做了一个关键分离：AI 只是操作员，执行引擎才是法律。这个决策源于一次失败的经验。

一次失败的启发

在系统早期，我让 AI 有很大的自由度——它可以直接连接数据库查数据，可以在任意目录生成脚本，可以绕过 API 直接实例化内部组件来执行任务。

结果是：AI 确实能更"高效"地完成任务。但代价是——有些任务的执行结果只存在于 AI 启动的那个进程里，脚本退出后数据就丢了。有些临时脚本散落在根目录，没人知道它们还有没有用。有些操作绕过了审计链路，事后无法追溯谁做了什么。

系统"能跑"，但不可信。

这迫使我重新思考一个问题：在一个 AI 驱动的系统里，AI 的权限边界应该画在哪里？

问题的结构

这个问题的本质不是"AI 能力不够"或"AI 不可靠"。而是一个经典的系统设计问题：可变部分和不可变部分的分离。

任何系统都有两类组件：

  • 不可变基础设施：数据访问、执行引擎、审计记录、资源控制。这些是系统的"物理定律"——不因使用者是人还是 AI 而改变。
  • 可变操作层：研究策略、参数选择、迭代决策。这些是"操作员的判断"——可以变，应该灵活。

问题在于：如果不显式划线，AI 会自然地把两层混在一起。它不区分"我在做操作决策"和"我在绕过基础设施"。对它来说，直接连数据库和调 API 一样都是"完成任务的手段"。

这和人类工程师绕过流程走捷径是同一个问题。区别是人类工程师通常知道自己在"违规"，AI 不知道。

我考虑过的方案

方案 A：权限清单模式

给 AI 一份详细的"可以做/不可以做"清单，写在 prompt 或配置文件里。类似于 Claude Code 的 CLAUDE.md 规则文件。

这在哪些场景下有效：规则数量少、AI 使用频率低、出错后果可控的场景。比如让 AI 帮忙写代码但不允许它执行——规则简单，一条就够。

为什么在我的场景下不够：我的系统有几十种任务类型，每种有不同的执行约束。规则清单会膨胀到 AI 无法可靠遵守的程度。上一篇文章已经讨论过——自然语言规则没有强制力，规则越多，被无视的概率越高。

方案 B：沙箱隔离模式

把 AI 放进一个受限沙箱——只能访问特定文件、只能调用特定函数、所有操作都在隔离环境里执行。

这是安全领域的标准做法。Docker 容器、WebAssembly 沙箱、浏览器的同源策略都是这个思路。

为什么没有完全采用：沙箱解决的是安全问题，不是架构问题。即使在沙箱里，AI 仍然可以写出绕过审计的代码、生成不可追溯的结果。沙箱能限制 AI 访问什么资源，但不能限制 AI 如何组织它的输出。

方案 C：三层分离 + API 唯一通道（我的选择）

设计哲学用三句话概括：

Kernel is law.   — 执行引擎定义了系统能做什么，以及怎么做
AI is operator.  — AI 只能通过 API 调用执行引擎，不能直接操作底层
UI is display.   — 展示层只读，不触发执行

核心约束不是"AI 不能做某事"，而是"所有人（包括 AI）只能通过同一条通道做事"。这条通道就是执行引擎的 API。

关键判断点

做出这个设计的关键认识来自操作系统的一个类比。

在操作系统里，用户态程序不能直接操作硬件——必须通过系统调用（syscall）。这不是因为用户程序"不可信"，而是因为直接操作硬件会破坏资源管理的一致性。无论你是 root 用户还是普通用户，操作磁盘都要经过文件系统，操作网络都要经过协议栈。

我的系统采用了同样的模式：执行引擎是"内核"，AI 是"用户态程序"。AI 提交任务必须经过 API（类似 syscall），API 内部负责审计记录、资源控制、结果持久化。AI 不能绕过这层，就像用户程序不能绕过 syscall 直接写磁盘。

这个类比还有一个推论：内核应该独立于使用者存在。 即使把 AI 层完全拆掉，执行引擎仍然可以独立运行——人类可以直接调 API 做同样的事。系统不依赖 AI 才能工作，AI 只是一种更高效的操作方式。

这一点很重要。很多 AI 系统的设计是"AI 在中心，其他组件围绕 AI 服务"。我的设计是反过来的：执行引擎在中心，AI 是接入它的一种方式。这意味着：

  • AI 挂了，系统不挂。人类可以接管。
  • AI 换了（从 GPT 换成 Claude，从 Claude 换成本地模型），执行引擎不需要改。
  • 审计链路不依赖 AI 的"诚实性"——因为所有操作都必须经过 API，API 自动记录。

三条具体约束

从这个哲学出发，落地了三条不可违反的约束：

第一，AI 不直连数据引擎。所有数据访问通过执行引擎的数据 API。AI 不知道数据存在哪里、用什么格式——它只知道"给我这些股票在这个时间段的价格"。

第二，AI 生成的代码在受控沙箱里执行。代码先经过 AST 扫描（禁止直接 import 内部模块），再在资源限制下运行（CPU、内存、超时），最后输出必须符合标准格式。不是让 AI “注意安全”，而是代码层面不可能做出不安全的事。

第三，所有任务必须通过 API 提交。AI 不能在本地实例化执行组件。这确保每个任务都有审计记录、都出现在任务历史里、都可以被界面查询到。没有"影子任务"。

实施效果

这套分离运行了几个月，有一个直观的验证方式：我可以随时关闭 AI 编排层，系统的其他部分完全不受影响。执行引擎继续运行，界面继续展示数据，已有的任务结果不丢失。AI 只是停止了"主动发起新研究"这个功能。

反过来——如果 AI 和执行引擎是耦合的，关掉 AI 意味着整个系统停摆。这就是"operator"和"infrastructure"的本质区别。

另一个效果：当我从一个 LLM 提供商换到另一个时，改动完全局限在编排层——改一下路由配置，API 调用方式换一下。执行引擎、数据层、界面层零改动。这验证了"AI 可替换"这个设计目标。

这个决策教会我什么

我从这次实践中提炼了一条设计原则：

在任何 AI 驱动的系统里，先问一个问题：如果把 AI 拿掉，系统还能运行吗？如果不能，说明你把 AI 和基础设施耦合了。

这是一个比"AI 安全"更底层的问题。不是"AI 会不会做坏事"，而是"系统架构是否允许 AI 做坏事"。

如果架构正确——AI 只是操作员、执行引擎才是法律——那么 AI 的"不可靠性"就不再是系统性风险。AI 的操作空间被约束在确定性的通道里，通道内的行为是可审计的、可回滚的、可追溯的。

这个思维框架来自对传统系统设计的一个延伸：我们不会让任何单个用户拥有绕过操作系统的能力，无论这个用户多么"聪明"。AI 也一样。它的能力不应该成为绕过系统约束的理由。

系列第三篇。上一篇：MCP 的问题不在协议层，在语义层。第一篇：为什么我没有用多智能体架构。