你今天使用的每一款软件都是基于一个单一的假设构建的：屏幕前坐着一个有手指的人。按钮意味着意图。向导（Wizards）管理复杂性。表单构建人类的思维。这种架构统治了数十年的产品设计，因为直到最近，只有人类才会点击。

那个假设现在被打破了。AI Agent 不阅读界面。它们无法从实用的工具提示（tooltips）或确认对话框中获益。当一个自主系统需要代表用户采取行动时，UI 界面（chrome）反而成了阻碍。其结果是，产品的构建方式与现代调用者（callers）的实际行为之间出现了日益增长的错位。

点击范式

传统软件依赖于一种视觉契约。人类看到一个按钮，理解其标签，然后决定是否按下它。工作流被刻意增加了摩擦力。存在多步骤向导是因为人类会犯错，需要护栏（guardrails）。下拉菜单和单选按钮限制了输入，因为自由文本会带来混乱。

当操作者是人时，这套逻辑运行良好。但当操作者是 Agent 时，它就失效了。机器不需要通过一个五步向导来取消订阅或修改记录。它需要的是对存在哪些操作的清晰陈述，以及关于它是否被允许执行这些操作的明确回答。当团队忽视这一点时，通常会寻求两种捷径。

第一，他们给 Agent 一个 API key。第二，他们将现有的用户界面封装在聊天机器人（chatbot）中，并称集成已完成。这两种方法都无法解决根本问题。

API key 回答的是“这个请求是否来自受信任的源？”这个问题。它永远无法回答那个真正重要的问题：“这个特定的调用者能否读取这条特定的记录？”Key 就像一把万能钥匙（skeleton key）。一旦发放，它通常会授予跨资源和上下文的广泛访问权限。它对管理你系统内部单个行为的策略一无所知。

将 GUI 封装在聊天机器人中则更加脆弱。Agent 继承了界面中内置的所有以人为中心的假设。它通过专为肉眼而非自主逻辑设计的模态框（modals）和表单来模拟点击。聊天机器人可能成功地在 UI 界面中导航，但它是在不理解的情况下进行的。这只是“自动化表演”（automation theater）。在底层，仍然缺乏关于允许执行什么的机器可读契约。

Agent 需要的不是另一把前门钥匙。它们需要的是“闸门”（gates）。

闸门究竟起什么作用

闸门是一个受控的执行层。系统不再是信任凭证并寄希望于调用者表现良好，而是通过闸门根据声明的规则来评估每一个请求。这些规则独立于任何界面（无论是人类界面还是其他界面）而存在。

一个完善的闸门定义了四件事：它声明产品内部存在哪些操作；它规定谁可以在什么条件下调用这些操作；它指定调用者在产生副作用（side effects）之前，何时必须停止并请求明确的许可；它确保系统以结构化、可查询的轨迹记录每一个决策。

这与传统的访问控制有着本质区别。基于角色的系统通常在门口问：“你是管理员吗？”然后让你在建筑内随意走动。而闸门在每一个关口都会问：“你现在被允许拨动这个特定的开关吗？”身份变得次于行为。策略随操作而行。

为了更具体地说明，想象一个需要为客户办理退款的 Agent。基于 Key 的方法如果端点可达，可能会允许任何持有该 Key 的人处理退款。而基于闸门的方法会检查可用操作清单，针对特定的客户记录验证 Agent 的权限，要求用户对财务副作用进行明确批准，并将整个序列写入审计日志。闸门强制执行的是策略，而不仅仅是身份。

在 Whistler 上进行测试

我们在 Whistler 上应用了这一模型。我们没有为人类和机器构建独立的流水线，而是编写了一个统一的策略层，并针对它运行了两种不同的调用者。

一个调用者是使用嵌入式 Shell 的人类。另一个是我们团队之外开发的第三方 Agent。两者都连接到同一个清单（manifest）。两者在每一步都面临相同的权限检查。当任何一个调用者尝试具有副作用的操作（例如修改数据或触发外部事件）时，系统都会要求明确的批准。每一次请求、批准和拒绝都会生成相同的结构化审计轨迹。

两个调用者都没有使用主 API 密钥。没有后门，也没有绕过策略的提权凭据。人类调用者并没有因为拥有密码和浏览器而获得更宽松的限制。智能体也没有因为缺乏人类特征而面临随机的拦截。网关评估了操作、上下文和规则。这就是整个交易过程。

其结果是，无论添加的是人类还是机器调用者，都无需重构访问逻辑。你只需更新策略，网关就会执行它。

重新思考产品问题

如果你的团队目前正在研究如何将 AI 智能体添加到面向人类构建的产品中，那么你可能从错误的问题开始。团队本能地会问是否应该开放 API。相反，他们应该问的是，是否为每个调用者都建立了一个受控的执行层。

没有网关的 API 只是一个更宽的门。如果你的内部策略仅存在于向导逻辑、表单验证和人类可读的帮助文本中，那么你发布的任何端点对于自主调用者来说都是不安全的。智能体要么通过密钥继承过高的信任，要么通过聊天机器人封装进行脆弱的“傀儡式”操作。

先构建网关意味着将产品中的每一个有意义的操作都列为声明的操作。这意味着将权限检查与用户界面分离，从而使 Shell 用户和外部智能体都面临相同的运行时强制执行。这意味着在需要执行破坏性操作之前就插入授权钩子，而不是在智能体抹除错误的数据集之后才去补救。这还意味着生成审计追踪，以便安全和合规团队进行检查，而无需关心调用者是碳基还是硅基。

这需要真正的架构转变。以人为中心的设计将逻辑包裹在同理心和摩擦力之中。面向智能体的设计则通过明确的、机器可读的契约来暴露逻辑。界面不再是策略本身，清单成为了策略。

这种转型并不是为了取代人类，而是为了意识到你的软件现在拥有不止一种类型的调用者。每一种调用者都值得同样的严谨对待。

真正的启示

停止为“点击”而设计，开始为“规则”而设计。如果你的系统可以通过声明的操作、上下文权限、授权检查和共享审计追踪来管理每个调用者，那么另一端是谁或是什么都无关紧要。无论是人类还是智能体，他们都会面对同一个网关。先构建网关。API 仅仅是一扇门。策略才是让房间保持完整的关键。