环模型从何而来¶

ASILO 0.1 现行的说明。这些背景用于指导设计；已接受的要求保持其范围与效力。

本页帮助你选择并解释一种分层模型。在 ASILO 中，环表示由配置声明并检查的职责边界。 环的圆形便于从规则一直读到外部机制。某个部件所处的位置既不授予权限，也不能证明故障已被遏制。

本方法的研究笔记汇集了架构、计算机保护、分隔和监管方面的思想。这次审阅整理了这些参照，并把模型与某个实现的代码作了对照。下列资料记录了各自的传统；我们提出的它们与 ASILO 的关系，是本方法的编辑性综合。这并不意味着这些资料的作者创造或认可了 ASILO。

四个目的各异的背景¶

已记录的参照	它说明什么	它为本指南提供什么
保护环，Schroeder 与 Saltzer，1972；该工作于 1971 年发表。	控制特权以及跨环调用的处理器机制。	追问每一次跨越由什么机制控制。作者在 MIT 的发布页。
端口与适配器，Cockburn，2005。	通过可互换的端口和适配器，把应用内部与外部技术分开。	让规则独立于具体机制。图中的六条边并非本质。原文。
Onion Architecture，Palermo，2008。	依赖指向核心，基础设施位于外围。	解释依赖方向以及基础设施的替换。原文。
Clean Architecture，Martin，2012。	代码依赖指向内部策略，与外部机制分开。其中的圆只是示意。	声明职责与依赖，而不固定统一的层数。原文。

保护环在执行环境中控制访问。架构层把代码归在一起并声明其依赖。 ASILO 采用层的表示方式，并在适用时要求声明模型；配置会指明所需的运行时控制。导入规则、授权与隔离提供的是不同的证据。

纵深防御通过互补的屏障把人员、技术和运营结合起来。它是分配控制措施的另一种参照；一连串的圆圈并不构成这些屏障。NIST 的定义。所查阅的资料不足以把所有这些模型都归于唯一的军事起源。

它们在 ASILO 中如何汇合¶

flowchart TD
  accTitle: ASILO：环模型的互补参照
  accDescr: 三种传统提出不同的问题。编辑性综合最终形成一份已声明的配置和带有自身证据的控制；箭头并不表示已被证明的谱系。
  A["架构：端口、Onion 与 Clean"] -->|组织依赖| S["ASILO：声明边界与职责"]
  P["保护：特权与能力"] -->|控制跨越与效果| S
  D["纵深防御与遏制"] -->|组合控制| S
  S --> M["配置：模型、规则与例外"]
  M --> E["实现：机制与结果"]

SVG 图 · Mermaid 源文件。

前三条箭头表示对这一解释的贡献。最后两条显示了从方法论决策到可观察机制的路径。它们并不主张作者之间存在历史上的承接关系，也不是安全认证。

为什么会出现四层或五层¶

示意性的环视图把规则与类型归入核心，并展示四项职责：核心、契约、适配器和组合。设计笔记中也描述过五项：类型或 kernel、领域逻辑、契约、适配器和应用。这里的 kernel 指类型核心，而不是操作系统内核。

四分组模型	区分五项职责的模型
核心：规则与类型。	类型核心 + 领域逻辑。
契约或端口。	契约或端口。
适配器。	适配器。
应用或组合。	应用或组合。

这是职责的对照，而不是编号的等同。拆分领域可以让大型系统更清晰；对小型系统而言，合并可能就够了。配置会声明自己的名称、依赖方向、例外和工具。 ASILO-R-002 并不要求四个或五个环；它同时保留了针对单模块系统的条件。参见已接受的要求。

一次实现审阅带来的启示¶

2026 年 10 月 14 日的代码审阅确认，层级图、依赖规则和运行时控制必须分别核对。在仓库中找到某个脚本或测试，只能证明它存在；记录它的执行及结果，证明的则是另一回事。相关软件说明指出了这种关系，但并不把它变成符合性。

观察到的要素	应在配置中记录的检查
职责图。	模块存在，其职责与当前的图一致。
不同工具中的规则。	覆盖相同范围，或声明其差异；例外有负责人和有效期。
上下文、权限与输入校验。	上下文不等于经过认证的身份；格式有效不等于获得授权。
测试、CI 流程与审计记录。	标明环境、执行、结果、留存，以及证据的局限。

这些问题同样适用于只有一个能读写文件的助手的情形。依赖控制检查的是导入；授权控制检查的是该助手能否删除那个文件。否定性测试必须检查拒绝，以及删除并未发生。人工智能的适用范围并不取决于是否有多个智能体。

继续阅读跨学科类比、领域与情境或层与环。