"从 Blocklet 到 Chamber：我们的架构如何为 AI 演进"

约束的洞察

每个重要的软件架构，在其核心，都是一个约束系统。容器约束进程。沙箱约束代码。权限模型约束用户。这些系统的价值不在于它们允许什么 — 而在于它们阻止什么。

当我们设计 Blocklet 架构时，我们从这个洞察出发。我们要解决的问题是：如何让不受信任的行为者在共享基础设施上构建和部署软件组件，同时不让他们破坏东西？

在 2018 年，那些不受信任的行为者是人类工程师。

在 2026 年，那些不受信任的行为者是 AI 代理。

行为者变了。架构不需要从头开始 — 它需要演进。

Blocklet 是在 Blocklet Server 内运行的自包含软件组件。从一开始，架构就强制执行：

这些不是偶然的设计选择。它们是刻意的约束，旨在使组织能够安全地在自己的基础设施上运行第三方软件组件。

关键词是安全。不是方便。不是快速。安全。因为当你在自己的服务器上运行别人的代码时，安全是第一要求。

Blocklet Server 是我们现在称为脚手架模式的第一个实现：一个为运行在其中的组件提供结构、约束和服务的平台。

脚手架不告诉组件做什么。它告诉组件什么是不能做的，并提供它需要的服务来完成其他一切。组件在其边界内是自由的，但边界是不可协商的。

这种模式直接映射到我们思考 AI 代理的方式：

结构是相同的。行为者变了。

Chamber 是为 AI 升级的 Blocklet。它继承了 Blocklet 架构的每一个约束和能力，并添加了 AI 代理特别需要的东西：

模型访问控制 — Chamber 声明它需要访问哪些 AI 模型，平台中介该访问。代理不能触达任意外部服务。它通过平台工作。

提示词和工具边界 — Chamber 定义代理可以使用哪些工具和提示词。这是 Blocklet 能力声明的 AI 等价物。一个被授权读取文件但不能写入的代理不能提升自己的权限。

观察和审计 — AI 代理在 Chamber 内采取的每个操作都带有完整的身份上下文被记录。不仅仅是发生了什么，还有谁授权了它、哪个模型生成了决策、以及提供了什么上下文。

资源计量 — AI 工作负载与传统软件有不同的资源特征。Token 消耗、模型 API 调用和计算时间在 Chamber 层面被跟踪和约束。

AIGNE 框架构建在 Chamber 之上。当你部署一个 AIGNE 代理时，它在 Blocklet Server 上的 Chamber 内运行。框架处理代理逻辑；Chamber 处理约束执行。

有一种说法认为 AI 原生工程（AINE）代表了对 ArcBlock Blocklet 传统的背离。这是不正确的。

AINE 不是在否定 Blocklet。AINE 是 Blocklet 的完成。

Blocklet 架构始终关于一件事：使运行来自你无法完全信任的行为者的组件变得安全。在 2018 年，我们无法预测不受信任的行为者会是 AI 模型。但我们建立的架构原则 — 隔离、声明的能力、基于身份的访问、平台管理的生命周期 — 恰恰是 AI 代理所需要的。

我们没有为 AI 设计 Blocklet。我们为约束不可靠行为者这个通用问题设计了 Blocklet。AI 代理只是当今这个问题最重要的实例。

从 Blocklet 到 Chamber 的演进不是一次迁移。现有的 Blocklet 继续完全像今天一样工作。Chamber 是一个扩展 — 一种新模式，当脚手架内的组件是 AI 代理而非传统应用时激活。

这种向后兼容是有意的。已经在 Blocklet Server 上部署了 Blocklet 的组织不需要重建任何东西。他们获得了在现有应用旁边部署 AI 代理的能力，使用相同的基础设施、相同的身份系统和相同的运营模型。

智能体文件系统提供了连接人类时代 Blocklet 和 AI 时代 Chamber 的共享抽象层。两者都通过 AFS 读写。两者都通过 DID 识别。两者都由 Blocklet Server 管理。

平台演进了。原则站住了。

在同一基础设施上部署传统 Blocklet 和 AI 原生 Chamber。