# 架构确定：从 52 个来源归纳出的系统架构

governed_by：D-014、D-020、D-043、D-055
updated_at：2026-09-05
状态：架构基线。四平面划分（D-043）与边缘部件裁决（D-047，不设第 15、16 个部件）均已由 Alan 于 2026-09-02 确认，架构问题全部关闭。
依据：四轮材料共 57 个来源，同源合并后 52 个独立来源；逐来源抽取"系统由哪些部件组成、部件之间谁给谁什么、哪些被明确说不可省略、失败归因到哪个部件"。统计见[跨来源合并统计](参考资料/13-架构要素抽取/MERGED.md)，逐来源明细见同目录 A～E 五批。
用途：这是理论的**架构基线**。正文按本文的部件划分重组，每个部件一章。

## 1. 方法

不预设部件清单。对每个来源只问四件事：它的系统里有什么部件（先用来源自己的词，再归一化）；部件之间谁给谁什么；它明确说"没有它不行"的是什么；它把失败归因到哪个部件。然后跨来源计数。归一化词表 17 个基础词，抽取中新造 12 个（★），语义相同的已合并。

必须先说明证据的偏向：52 个来源中一手厂商文档只有 8 个，其余是实践报告和二手综述；19 个属于编码 Agent 场景，9 个企业 Agent 平台，6 个个人，3 个对话 Agent，7 个基础设施与综述。二手来源对一手的转引存在系统性升格（第四轮登记约 90 处失真），所以票数不能当作独立证据简单相加；本文在裁决时对一手来源单独加权（§4）。

## 2. 统计结果

**出现频次**（独立来源数 / 52）：工具与执行环境 50、执行者 49、上下文装配 47、模型 42、验证与测试 42、方法库 41、证据与追踪 41、人 40、状态工件 39、拦截与守卫 39、项目知识 38、评估与演进 38、任务拆分与调度 38、意图与验收 34、权限与边界 34、长期记忆 33；随后断崖：知识/记忆治理 16、代码地图 12（其中 9 个来自编码场景，企业平台场景 0）、外部系统交接 9、Agent 运行时框架 8、触发与入口 6、配置分发 6、事实溯源 6、监控与巡检 5。

**明确标为不可省略**（票数）：人 21、验证与测试 16、拦截与守卫 15、证据与追踪 12、状态工件 11、项目知识 10、权限与边界 9、意图与验收 9、评估与演进 9、上下文装配 8、任务拆分与调度 7；方法库只有 3 票，长期记忆 2 票，工具与环境 4 票。

**失败归因**（被归因的来源数）：验证与测试 32、上下文装配 29、拦截与守卫 28、状态工件 27、评估与演进 25、权限与边界 23、证据与追踪 22、项目知识与新鲜度 21、人 19、任务拆分与调度 19、工具与环境 18；长期记忆 10、方法库 11、代码地图 4。

三张表放在一起看，结论很清楚：**被说得最多的部件（工具、执行者、上下文、模型）和被认为最不能缺、最常出事的部件（人、验证、守卫、证据、状态）不是同一批。** 前者是"做事"的部件，任何系统都有；后者是"让做的事可信、可控、可恢复"的部件，恰恰是大型项目后期变慢时失守的地方。

## 3. 候选架构与比较

**候选 A：工具组合式**——agent team/流水线 + codegraph + memory + 上下文管理 + skill。优点是简单、每块都有现成工具。问题是它覆盖的恰好是"做事"那一批：五块里没有验证、证据、守卫与权限、状态工件、意图与验收，而这些在不可省略投票和失败归因里排在前列；代码图谱在 52 个来源里只出现 12 次且集中在编码场景，不是一等部件。

**候选 B：八层模型（原 00 章）**——覆盖完整，但八层并列、没有主次，读者看不出哪几层是骨架、哪几层可以后补，也没有回答"这套东西怎么用工具拼起来"。

**候选 C：范式阶梯（Prompt → Context → Harness → Loop → Graph）**——12 个二手来源采用，是本轮材料里最流行的叙事。但它是演进史不是架构：层与层是时间先后而非职责划分；8 个一手来源无一使用，且 Anthropic 明确反对默认走到多 Agent 那一端。

**候选 D：平面划分 + 一条交付线**——把高频部件按职责归入若干平面，一条交付线从意图穿到验收。与三个独立来源吻合：WX-44/ATT-A 的"可信上下文 / 可恢复流程 / 可执行约束"三件事、DeepSeek Harness 与 WX-30 的 Surface → Control Plane → Harness → Runtime 分离、WX-40（Anthropic playbook）把 Governance 作为横切层。

## 4. 裁决：采用候选 D，划分为四个平面

理由有三。第一，它同时容纳了两批部件——"做事"的进执行平面，"可信可控"的进控制平面——而候选 A 只有前者，候选 B 没有主次。第二，它给"简单且灵活"一个明确的落点：**控制平面是纪律，可以只用文档和人工流程实现；执行平面是工具，随时可换；知识平面是资产，随项目积累；责任平面是人，不可转移。** 换工具只换执行平面。第三，一手来源的强调点全部落在控制、知识、责任三个平面：工具接口值得与提示同等投入、做减法、日志是运行时不变量（"模型可见即已记录"）、朴素的状态工件、人是稀缺资源——这些是二手来源常常忽略、而后期变慢时最先失守的。

**人单列为第四平面（责任平面）**，2026-09-02 由 Alan 确认。理由与统计一致：人在不可省略投票中以 21 票居首，远高于第二名验证与测试的 16 票；且 ATT-H 的判据——"不会到期的是三类：只有你们知道的信息、只有人能承担的责任、评价者不能是被评价者本人"——把责任明确列为不随模型能力消解的独立维度。把人放在控制平面会让人读成"控制手段之一"，而它实际上是控制平面本身的授权来源与最终收敛点。

对候选 A（Alan 示例）的处置：agent team 与流水线是执行平面里"调度与拆分"部件的团队级形态（L2 以后才需要）；codegraph 是知识平面里"项目知识"的派生缓存；memory 是知识平面的候选入口，经治理才成为知识；上下文装配与方法库保留为执行平面的两个部件。示例里的五块都在，但它们不是全部，也不都是一等部件。

## 5. 架构定稿

<a id="component-stats"></a>

### 5.1 四个平面与 14 个部件

| 平面 | 部件 | 回答的问题 | 频次 / 不可省略票 / 失败归因 | 最小形态（L0，文档级） | 工具形态（L2+） |
|---|---|---|---|---|---|
| **知识平面**<br>资产，随项目积累 | 意图与验收 | 要做什么、做到什么算完成 | 34 / 9 / — | 带稳定 ID 的验收条目清单 | 需求系统、契约文件 |
| | 项目知识 | 项目特有、代码里读不到的事实 | 38 / 10 / 21 | 短入口 + 就近文档 + ADR | 知识库；代码图谱作为派生缓存 |
| | 记忆与知识治理 | 经验怎样变成知识、怎样过期 | 33+16 / 2+6 / 10+11 | 候选区文档 + 人审 | memory 工具 + 置信分级 + 新鲜度检查 |
| **执行平面**<br>工具，随时可换 | 状态工件 | 做到哪了、怎么恢复 | 39 / 11 / 27 | 工作项 + 交接 + 项目状态三份文档 | 任务系统、检查点 |
| | 调度与拆分 | 谁做、按什么顺序、卡住怎么办 | 38 / 7 / 19 | 一个人按流程走 | 流水线 / agent team |
| | 上下文装配 | 每次推理看什么 | 47 / 8 / 29 | 唯一加载清单 + 交接文档 | 检索、压缩、外部化 |
| | 方法库 | 怎么做才对 | 41 / 3 / 11 | 几条踩坑规则 | Skill 机制、Runbook 库 |
| | 工具与执行环境 | 能对世界做什么 | 50 / 4 / 18 | 命令行 + 仓库 | MCP、沙箱、隔离工作区 |
| | 执行者与模型 | 生成与行动 | 49+42 / — / 8 | 单会话 | 子执行者、模型分档 |
| **控制平面**<br>纪律，可只用文档与人工实现 | 验证与测试 | 怎样证明做对了 | 42 / 16 / 32 | 验收条目派生的测试 + 独立复核 | 独立验证者、回读 |
| | 守卫与权限边界 | 什么不许做、能力有多大 | 39+34 / 15+9 / 28+23 | 书面的权限与不可逆动作清单 | 事实门禁、权限配置、拦截层 |
| | 证据与追踪 | 凭什么说做过、花了什么 | 41 / 12 / 22 | 完成主张绑定六项证据 | 轨迹、只追加日志、成本分解 |
| | 评估与演进 | 系统本身在变好还是变坏 | 38 / 9 / 25 | 失败 Case 清单 + 定期减法 | 评估集、消融、到期审计 |
| **责任平面**<br>人，不可转移 | 人的检查点与授权 | 哪些判断只能人做、谁负责 | 40 / **21** / 19 | 五处状态转换处的确认 | 审批流、预批准动作集 |

**边缘适配**（只在部分场景出现，是否升为一等部件待定，见 §6）：外部系统交接、触发与入口。

### 5.2 平面之间的接口（跨来源 ≥12 个独立来源明确画出的关系）

- 知识 → 执行：短入口按需拉取，不全量推送（24）；验收条目派生工作项与测试（12）；状态工件是每轮的起点，不回放对话（20）。
- 执行 → 控制：执行事实由环境回读，不信模型自述（21）；子执行者只回结构化结果（18）；确定性判断先由程序做，模型只判残余（18）。
- 控制 → 执行：动作或阶段转换前阻断并回显原因（29）；独立验证者给出通过/失败/未定并定位（22）；范围与预算在创建时固化、执行中只能收窄（15）。
- 控制 → 知识：证据与轨迹是评估、删减、到期审计的输入（28）；失败驱动规则与方法库的增删（22）；状态转换处自动提取记忆候选并经治理写回（15）。
- 控制 → 责任：超限、门禁失败、告警升级到人（21）。
- 责任 → 知识：人确认并冻结意图（19）。
- 责任 → 控制：不可逆动作只能由人授权（17）。

<a id="invariants"></a>

### 5.3 架构级不变量（换任何工具都不变）

1. 控制平面独立于执行平面：验证者不是生成者，守卫在模型控制流之外。
2. 状态外置且朴素：一份进度、一份清单、一份交接，编排靠读状态不读对话。
3. 项目知识是唯一记录源，入口短、细节就近；代码图谱和记忆都是它的派生或候选，不是第二权威。
4. 执行事实来自环境回读与只追加日志，模型可见的都被记录；证据喂给演进。
5. 责任不可转移：人是稀缺资源，检查点集中在少数状态转换，不可逆动作只能由人授权。
6. **边界外不由我们控制。**
   **边界是一段关系，不是对象的一个属性。** 每一次跨边界的读、写、依赖或唤醒都有一个**权威侧**（该类主张的记录源归它治理，或其上已发生的事只有它能撤销）与一个**消费侧**。要判定的是这段关系与我方在其中的角色，不是给对象贴一个内 / 外标签；同一对象在不同关系里角色可以不同，同一事实可以在两侧各有一个身份，此时按主张模型对齐（见[11 项目知识](11-项目知识.md) §2 P1）。
   **我方在消费侧时**，四条推论成立：读只引用不复制；写只在声明的阶段窗口内发生、必须幂等、必须留回执，结果未知即记未定、未成功进待补偿；可用性不保证，跨边界依赖分必需与推荐两档，推荐项缺失可跳过但须留带失效期的记录；唤醒不等于授权，外部事件可以启动一次运行，但自动触发的前提是判定器先于触发器就位。
   **我方在权威侧时，同样四条对偶成立**：我方对外暴露的主张带版本与观察时间；改变已被外部消费的口径或契约之前，须登记受影响的消费者与兼容窗口，既往对外输出是否追认、追认到哪一天随该登记一并裁决；我方发出的唤醒不等于对方已受理，须有与回执同构的应答语义；外部内容进入项目内须经晋升，落地的是带来源、观察时间与失效条件的**主张**而不是副本——提炼与复制的判据是"是否声称对同一类主张有权威"（见[11 项目知识](11-项目知识.md) §2 P1、P2），因此晋升不与"不复制"冲突。
   **判定的同时登记这段关系的三项可执行前提**：对象是否可重读、是否有可比对的版本、写入者是否唯一。任一为否，依赖该前提的推论即不成立，须显式声明替代或整体记未定——不可重读者以采集时的完整性证明替代事后对账；无可比对版本者不适用新鲜度比对；写入者不唯一者须声明冲突处置，此时幂等不等价于安全。读侧标注为不可重读的对象，任何会改变它的写动作以"必需观察已采集"为前置。
   由此得默认取向：跨边界多读少写。

第六条的推导、判据的边界情形与四条推论各自收紧的已有规则见 §6。

**不变量与平面接口（§5.2）是架构级内容**，与 14 个部件并列，不是部件的下属内容；D-043 的"新增内容须归属某个部件"针对的是部件级内容，不约束这一类。

### 5.4 与原八层的映射

| 原八层 | 归入 |
|---|---|
| 1 意图与权威 | 知识·意图与验收 + 责任·人的检查点与授权 |
| 2 事实与知识 | 知识·项目知识 |
| 3 上下文 | 执行·上下文装配 |
| 4 长期记忆 | 知识·记忆与知识治理 |
| 5 状态与工作流 | 执行·状态工件 + 调度与拆分 |
| 6 工具与执行 | 执行·工具与执行环境 + 执行者与模型 |
| 7 验证与证据 | 控制·验证与测试 + 证据与追踪 + 守卫与权限边界 |
| 8 评估与演进 | 控制·评估与演进 |

四个闭环不变：交付闭环是交付线；上下文闭环在执行平面内；记忆闭环是执行 → 控制 → 知识；改进闭环在控制平面内。

<a id="edge-components"></a>

## 6. 两个边缘部件：裁决为选项 D（2026-09-02 Alan 接受，D-047）

**结论：不设部件。** 外部系统交接与触发入口的全部纪律收敛为一条"外部"判据加第六条不变量（§5.3），落到 [11 项目知识](11-项目知识.md)、[21 调度与拆分](21-调度与拆分.md)、[24 工具与执行环境](24-工具与执行环境.md) 三处一行标注，不新增部件与章节。推导见 §6.4，与另三个选项的对比见 §6.5。

以下 §6.1～§6.3 保留裁决前的材料与备选，供追溯。

这两个部件在统计上都处于断崖之下（9/52 与 6/52），但它们不是"弱证据的普通部件"，而是**场景相关**：在需要它们的场景里，来源把它们列为不可省略；在不需要的场景里，它们根本不出现。所以问题不是"要不要"，而是"要不要写进所有项目都必须回答的清单"。

### 6.1 外部系统交接（9/52，其中编码场景 6、企业平台 2、个人 1；一手厂商文档 0 票）

**它是什么。** AI 的产出与组织已有系统之间的读写通道：从需求系统读原文、往工单回写状态、开 PR、发通知、把验收结果回写回来。

**材料里的具体样子。**

- WX-05/WX-03 把它叫 Connectors，是 Loop 六要素之一，明确绑定失败："去掉 Connectors → Isolation"。跑完一轮后开 PR、更新 Ticket、发通知，否则产出留在本地无人知道。
- WX-07 接了 5 个 MCP（需求系统、Wiki、代码平台、构建平台、IM），并给出一套纪律：**读多写少；写只允许在流程的初始化与收尾两处；写必须幂等；写失败软降级不阻断**。
- WX-08 把外部依赖分成两档：需求系统缺失即阻塞（必需），设计稿与 IM 通知可跳过并记 `mark-skipped` 带 7 天有效期（推荐）。
- WX-04 要求需求原文只引用不复述（避免第二事实来源），发布记录回写。
- WX-11 走得最远：外部事件（邮件、IM、Hook、文档）可以直接进入工作流，验收结果由外部系统 Callback 回写。
- WX-34 让工单状态由代码事件自动推进，而不是人手工汇报。

**它防御的失败（3 个来源报告）。** 双通道写导致审计不一致、重跑灌入重复关联（WX-07）；接入方不支持某类配置导致链路断裂（WX-06）；只读接入只能建议不能交付，价值大打折扣（WX-03）。

**为什么一手厂商文档 0 票。** 它们的场景是人发起任务、产出留在仓库与 PR 里，组织流程系统不在回路上。这不是它们否定这个部件，而是它们的边界不含它。

### 6.2 触发与入口（6/52，其中编码场景 4、企业平台 2；个人与一手 0 票）

**它是什么。** 一次运行由什么发起：人手工、定时心跳、外部事件、告警。

**材料里的具体样子。**

- WX-03/WX-05 叫 Automations，同样是 Loop 六要素之一，绑定失败："去掉 Automation → Inactivity（永不启动）"。典型形态是每天定时唤醒，读昨日进度，扫描 CI 与 Issue，生成待办。
- WX-04 的运营轨道：四类告警源 → 分流 Agent → 多源检索 → 根因 → 修复 → 回归 → 经验回流。触发器是告警而不是人。
- WX-06 用定时扫描做知识库新鲜度检查；WX-10 有周期性的"文档园丁"；WX-38 有跨会话巡检。这三例的共同点是：**被触发的不是交付任务，而是控制平面自己的维护任务。**
- WX-11 允许外部事件进入工作流。

**它防御的失败（2 个来源报告）。** 无触发则永不启动（WX-03）；全靠人触发形成瓶颈、任务积压（WX-05）。

**注意一个次序约束**（本项目已采纳，见 D-024 与架构不变量）：**判定器必须先于自动触发器就位**——没有一个不需要人在场就能拒绝坏输出的判定器，就不该给它自动触发的能力。所以触发与入口天然是后期部件。

### 6.3 三个选项与代价（初评）

| 选项 | 做法 | 代价 | 适合 |
|---|---|---|---|
| **A（建议）保持边缘适配** | 不进 14 个部件清单，在执行平面章节里各占一节，标注"L2 团队场景才出现"；两者防御的失败仍登记进 Case 注册表 | 企业场景的读者要多翻一层才找到它 | 规范同时面向个人与团队，且希望 L0/L1 保持轻 |
| **B 升为一等部件** | 变成 15、16 号部件，各一章 | 每个项目都要回答"谁触发、回写到哪"，个人项目要写两次"不适用"；与"简单且灵活"的目标相悖 | 规范主要面向企业团队 |
| **C 并入现有部件** | 触发与入口并入"调度与拆分"（作为一次运行的起点）；外部系统交接并入"工具与执行环境"（作为一类有副作用的工具） | 会丢掉它们各自的纪律（读多写少、写限两处、幂等、软降级、必需/推荐分档、判定器先于触发器），这些纪律在被并入的章节里显得突兀 | 追求最少章节数 |

**初评倾向 A**，理由是它们的纪律足够具体、足够独立，并入会稀释，而提为一等部件又让个人项目背上不必要的清单。但 A/B/C 的代价有一个共同来源，见下节。

### 6.4 选项 D（已采纳）：不设部件，改设一条边界判据与一条不变量

A/B/C 都在回答同一个问题——"这两块内容放进哪个盒子"。它们共同的代价来自一个没被质疑的前提：**它们是两个部件**。回到材料看，两者是同一个事实的两个方向：

> 有些东西不是我们的：它的权威记录源不由本项目治理，或者它上面已经发生的事我们不能单方面撤销。

外部系统交接是**往外写**，触发与入口是**从外进来**。而 §6.1 与 §6.2 列举的全部纪律——读多写少、写限窗口、幂等、软降级、必需与推荐分档、判定器先于触发器——没有一条在讲"这个部件自己要做什么"，全部在讲"跨过这条边界时什么不许变"。这是**约束**的形状，不是**部件**的形状。部件回答"谁做"，约束回答"做的时候什么不许变"；架构里已有专门安放后者的位置，即 §5.3 的不变量。

**D 的做法是三件事，不新增章节。**

**(1) 一条可判定的"外部"判据。** 满足任一条即为外部：

- 它的**权威记录源不由本项目治理**——改它要走别人的流程、别人的审批、别人的发布节奏；
- 它上面**已经发生的事我们不能单方面撤销**——撤销要么需要对方动作，要么留下不可消除的痕迹。

按这条判据：本项目的仓库、构建与测试是内部（记录源归我们、可重置）；部署之后的生产数据、工单系统、通知渠道、需求系统是外部。判据让"这算不算外部"不再靠感觉。第二条尤其关键：它把"不可逆"从动作属性升格为边界属性，而不可逆动作的授权规则本项目已有（见[40 人的检查点与授权](40-人的检查点与授权.md)）。

**(2) 第六条不变量「边界外不由我们控制」。** 四条推论，每条都是已有规则在跨边界处的收紧，不引入新语义：

| 推论 | 它收紧的是哪条已有规则 |
|---|---|
| **读只引用不复制。** 外部记录源不在项目内建第二份副本；引用带版本与观察时间。 | [11 项目知识](11-项目知识.md) P1 权威按主张指定、P4 派生只能作为缓存 |
| **写只在声明的阶段窗口内发生，必须幂等，必须留回执；结果未知即记未定，未成功进待补偿。** | [30 验证与测试](30-验证与测试.md) 三态裁定 + [32 证据与追踪](32-证据与追踪.md) 证据字段 |
| **可用性不保证。** 跨边界依赖分必需与推荐两档：必需缺失即阻塞，推荐缺失可跳过但须留带失效期的记录。 | [31 守卫与权限边界](31-守卫与权限边界.md) 豁免必须带失效期 |
| **唤醒不等于授权。** 外部事件可以启动一次运行，但自动触发的前提是判定器先于触发器就位。 | [21 调度与拆分](21-调度与拆分.md) P3 + [40 人的检查点与授权](40-人的检查点与授权.md) |

四条推论直接给出一条默认取向：**跨边界默认多读少写**——读错了可以重读，写错了不一定撤得回。材料里那条"读多写少"因此不再是抄来的条款，而是推出来的结论。

**(3) 三处一行标注。**

- [11 项目知识](11-项目知识.md)：权威记录源的指派增加"内部 / 外部"标注，按上面的判据判定。
- [24 工具与执行环境](24-工具与执行环境.md)：工具登记增加同一标注；标为外部的工具适用第六条不变量。
- [21 调度与拆分](21-调度与拆分.md)：最小职责补一句"一次运行的起点"，取值含人、计划、外部事件；自动起点受第六不变量第四条约束。

**D 的代价，诚实列出。**

- 不变量比章节更容易被跳过。缓解：受影响的三章各加一句交叉引用，[00 总览](00-总览.md)诊断表加一行，成长路径在 L2 处点名。
- D-043 的 blocks 条款写的是"阻止新增内容不归属于四平面 14 个部件之一"，需要一句澄清：不变量与平面接口是**架构级内容**，本来就是第三类（§5.3 已有五条），不受该条款约束。这是澄清，不是修正。
- 判据第二条依赖"能否单方面撤销"的判断，边界情形（例如可回滚的灰度发布）需个案裁定。缓解：判不清时按我方处于消费侧处理，并把三项可执行前提（可重读 / 有可比对版本 / 写入者唯一）全部登记为"否"——这样保守的代价是显式的，而不是一句"更保守"。

### 6.5 四个选项的落地量对比

| | A 边缘适配 | B 一等部件 | C 并入现有部件 | D 判据加不变量 |
|---|---|---|---|---|
| 新增章节 | 0（两节待定） | 2 | 0 | 0 |
| 每个项目必答的问题 | 不变 | 增 2 | 不变 | 不变 |
| 纪律是否完整保留 | 是，但散在两节 | 是 | 否，会被稀释 | 是，且各自挂回一条已有规则 |
| 正文净增行数（估） | 0 | 约 +110 | 约 +25 | 约 +10，并删去两节"待定" |
| 个人项目的负担 | 低 | 高 | 低 | 无 |
| 那些纪律的地位 | 并列条款 | 并列条款 | 并列条款 | 由一条判据推出 |

D 满足"更少的实现达到同样目的"：没有新部件，没有新章节，七条并列纪律缩成一条判据加四条推论，而每条推论都指回一条已有规则。它不是再打一个补丁，是把已有规则用到本来就该用到的地方。

**落地情况（2026-09-02 完成）。** 第六条不变量已写入 §5.3；D-043 的澄清已附在同处（不变量与平面接口是架构级内容，不受"须归属某个部件"约束）；[11](11-项目知识.md)、[24](24-工具与执行环境.md) 增加"内部 / 外部"标注，[21](21-调度与拆分.md) 增加"一次运行的起点"；[21](21-调度与拆分.md) 与 [24](24-工具与执行环境.md) 原有的两节"待定"已删除（当时的节号为 §6，现已不存在，两章均为四节）。

**证伪信号。** 出现下列任一情况即说明 D 不成立、应回到 B：跨边界纪律在实际使用中反复被绕过，说明不变量的约束力不足以替代章节；或出现一条既不属于四条推论、也无法由"外部"判据推出的跨边界纪律，说明这里确有部件级内容。


## 7. 本次裁决刻意没有采纳的

- 范式阶梯作为架构：它是历史叙事，一手来源不用。
- 把代码图谱、记忆、agent team 提为一等部件：频次与场景分布不支持。
- 多阶段流水线（P0–P6、13 棒接力）作为默认形态：一手来源全部使用朴素状态工件，Anthropic 明确主张先用最简单方案。
- 二手来源特有的"用 Hook 治理模型三类失败"叙事：守卫进控制平面，但以"事实门禁 + 权限边界"的语义表达，不绑定具体机制。

## 8. 决策记录

| 日期 | 决定 | 决定人 |
|---|---|---|
| 2026-09-02 | 采用四平面划分（知识 / 执行 / 控制 / 责任）+ 一条交付线 | Alan |
| 2026-09-02 | 人的检查点与授权单列为责任平面，不放在控制平面 | Alan |
| 2026-09-02 | 正文按 14 个部件重组，每部件一章；边缘部件待定后再补 | Alan |
| 2026-09-02 | 边缘部件按选项 D 处理：不设部件，改为一条"外部"判据加第六条不变量，三处一行标注（D-047） | Alan |
| 2026-09-02 | 澄清 D-043：不变量与平面接口是架构级内容，与 14 部件并列，不受"须归属某个部件"约束 | Alan |