架构图库 七个项目 · 九张图 全部经渲染验收

每张图都在回答一个问题

这不是「七张架构图」的合集,而是七个不同的问题各自的答案。 每张图上来先写清两件事:它要回答什么承重墙论点是什么—— 图上其余每个框、每条线都只为支撑那一个论点而存在。

判断标准很朴素:把文字全遮住,只留框和线,七张图的形状必须不一样。 因为星形拓扑、时序循环、状态机、继承偏序本来就不该长成同一个竖直层叠。

7
项目,每个一个独立问题
9
张图,无一重复体裁
6
种图型(拓扑/时序/平面/状态/扩展/失败)
3
轮审阅,19 处勘误已闭环
How to read

怎么读这些图

大多数「架构图」其实是带配色的目录树——把源码目录换成方框、竖着摞起来、连一条自上而下的箭头。它的问题不是不好看,而是选错了体裁:六个技术栈完全不同的项目,画出来的图可以互相替换。

一条可靠的自检 把图上所有文字遮住,只留框和线。如果几张图长得一样,那几张图都没画对。 真正的架构差异应该体现在拓扑上,而不是靠框里的文字。

六种图型,各自回答不同的问题

图型回答什么本库示例
A 进程与信任拓扑代码跑在几个地址空间?谁能碰什么?边界怎么穿越?Open Design · OpenCode · OpenWorker
B 一次回合的时序控制权和数据在时间轴上怎么流动?循环怎么退出?Claude Code
C 控制/数据平面哪些组件在决定做什么,哪些在搬运内容Hermes
D 状态归属与生命周期状态存在哪、谁拥有、活多久、崩了丢什么?Hermes 冻结快照
E 扩展点与改动半径加一个新能力要改哪里?会波及谁?Open Design 接第 26 个 CLI
F 状态机与失败恢复出错时会发生什么?怎么恢复?grok-build Goal Mode
为什么每张图都先写「承重墙论点」 架构图的价值在于承载可被质疑的判断。「工具注册表」「Agent 主循环」这类描述没人会反对,也没人能从中学到东西。

好的架构图应该让读者当场产生这类反应:「等等,这里为什么是同步的?」「这条边跨进程了,序列化成本呢?」「这两个框之间没有线,是真的不通信吗?」

如果一张图不可能引发上述任何一句话,它就是装饰品。
Project 01

Hermes Agent (v0.19.0):前缀缓存神圣与闭环学习

这张图回答什么Hermes 如何在跨约 20 个消息平台运行时,既做到「每轮复用缓存前缀」(省钱),又实现跨会话的自我进化?
承重墙论点系统提示词在会话生命周期内逐字节稳定 (AGENTS.md:90-91 "byte-stable for the life of a conversation")。记忆写入采用「冻结快照」模式([tools/memory_tool.py:9-12](file:///Users/mikayiyanglin/Documents/Github%20claude-code/claude%20code源码分析/项目分析/hermes-agent-源码分析.md#第-8-章-上下文压缩与记忆短记忆靠压缩长记忆靠文件):落盘更新文件但不改当前会话系统提示词);技能由 skill_manage 自动写盘,由 curator.py 在空闲时后台无感策展。
C · 控制/数据平面控制平面 vs 数据平面流程图 (Control/Data Plane Split)
flowchart LR
    subgraph UI_PLATFORMS["多端接入平面"]
        CLI["CLI REPL
cli.py"] TUI["TUI 界面
ui-tui/"] GW["20+ 消息网关
plugins/platforms/"] ACP["ACP 适配器
acp_adapter/entry.py"] end subgraph CTRL["控制平面 (Control Plane)"] AIA["AIAgent 实例
run_agent.py:400"] LOOP["ReAct 主循环
agent/conversation_loop.py:669"] COMP["上下文压缩器
agent/context_compressor.py"] CURATOR["Curator 后台策展
agent/curator.py"] end subgraph DATA["数据平面与存储 (Data & Storage)"] PROMPT["字节级稳定提示词三明治
agent/system_prompt.py"] SKILLS[("skills/ 技能库
SKILL.md 快照")] MEM[("MEMORY.md & USER.md
冻结快照 (memory_tool.py:9)")] FTS[("SQLite FTS5
session_search")] end subgraph EXEC["执行与 6 种后端 (5 种隔离 + local 裸跑)"] REGISTRY["工具注册表
tools/registry.py"] SANDBOX["6 种执行后端
local / docker / modal ..."] end CLI & TUI & GW & ACP -->|"输入分流"| AIA AIA --> LOOP LOOP -->|"1. 组装逐字节稳定 Prompt"| PROMPT PROMPT --- SKILLS PROMPT --- MEM LOOP -->|"2. 触发工具调用"| REGISTRY --> SANDBOX SANDBOX -->|"3. 结果追加 (Role=Tool)"| LOOP LOOP -.->|"4. 达到 50% 阈值触发压缩"| COMP CURATOR -.->|"5. 空闲时评审归档技能"| SKILLS classDef ctrlBox fill:#eef4ff,stroke:#4a6fa5,stroke-width:1.5px classDef ctrl fill:#d0e1fd,stroke:#1e88e5,stroke-width:2px classDef data fill:#f4fff0,stroke:#4a8f3c,stroke-width:2px classDef exec fill:#fff4ec,stroke:#4f46e5,stroke-width:2px class CTRL ctrlBox class AIA,LOOP,COMP,CURATOR ctrl class PROMPT data class REGISTRY,SANDBOX exec style SKILLS fill:#f4fff0,stroke:#4a8f3c,stroke-width:2px style MEM fill:#f4fff0,stroke:#4a8f3c,stroke-width:2px style FTS fill:#f4fff0,stroke:#4a8f3c,stroke-width:2px
蓝底 = 控制平面核心逻辑 · 绿底 = 数据与存储快照 · 橙底 = 74 个工具与 6 种执行后端。
D · 状态归属与生命周期图型 D · 状态归属与双时间线生命周期图 (State Ownership & Lifecycle)
flowchart LR
    W["Agent 调用 memory 工具写入"] --> DISK[("MEMORY.md / USER.md
磁盘持久化文件")] DISK -.->|"❌ 本会话刻意切断/不生效
修改提示词会破坏前缀缓存"| CUR["当前会话的系统提示词
(只读已冻结快照)"] DISK ==>|"✅ 下一个会话启动时
作为全新冻结快照注入"| NEXT["下一个会话的系统提示词"] classDef now fill:#ffebee,stroke:#c62828,stroke-width:2px classDef next fill:#e8f5e9,stroke:#2e7d32,stroke-width:2.5px classDef store fill:#fff8e1,stroke:#f57f17,stroke-width:2px class CUR now class NEXT next class DISK store
红框 = 本会话内不会改变的冻结上下文 · 绿框 = 下个会话启动时生效 · 黄框 = 持久化文件。虚线 ❌ 表示被架构刻意切断的即时回流路径。
Project 02

Claude Code:一次回合的时序与横切权限控制

这张图回答什么用户敲回车后,控制权在组件间如何传递?权限检查发生在何处?
承重墙论点权限系统是贯穿全栈的横切关注点 (Cross-Cutting Gate),在工具执行前通过 checkPermissions (src/Tool.ts:500) 实施裁决。主循环心脏分布在 src/query.ts (queryLoop)、src/QueryEngine.ts (1295 行) 及 src/query/;上下文每回合刷新;无工具调用(纯文本)或孤儿结果补充为收敛退出信号。
B · 一次回合的时序一次回合的完整时序图 (Turn Sequence Diagram)
sequenceDiagram
    autonumber
    actor U as 用户 (Terminal User)
    participant R as src/screens/REPL.tsx
    participant H as src/utils/handlePromptSubmit.ts
    participant Q as src/query.ts & QueryEngine.ts
    participant C as src/constants/prompts.ts
    participant A as src/services/api/claude.ts
    participant P as src/utils/permissions/
    participant T as src/tools/ (43 个工具)

    U->>R: 敲击回车
    R->>H: 传递输入文本
    H->>H: 判定: 斜杠命令 / !shell / 普通消息
    H->>Q: 启动 queryLoop 主循环

    loop 每回合循环 (Per-Turn Loop)
        Q->>C: 重新组装上下文 (Prompts + CLAUDE.md + Git状态)
        C-->>Q: 交付全新 messages[] 数组
        Q->>A: SSE 流式请求 Anthropic API
        A-->>Q: 实时返回 Token 流及 tool_use 块
        
        alt 模型申请调用工具
            Q->>P: 提权裁决 (checkPermissions in Tool.ts:500)
            alt mode ∈ {bypassPermissions, dontAsk} 或命中已授权规则
                P-->>Q: 允许执行
            else 属于高危命令/未授权
                P->>R: 触发终端交互弹窗
                R->>U: 显示权限确认选项
                U-->>R: 选择 允许 / 拒绝 / 本次允许
                R-->>P: 返回用户判定结果
                P-->>Q: 交付最终许可状态
            end

            alt 许可通过
                Q->>T: 执行对应工具逻辑 (Bash / Edit / Read...)
                T-->>Q: 返回工具执行结果 (tool_result)
            else 许可拒绝
                P-->>Q: 返回拒绝提示信息
            end
            Note over Q: 将结果回流 append 进 messages[],开启下一轮
        else 模型仅回复纯文本 (无 tool_use)
            Q-->>R: 输出回复文本,收敛并退出循环
        end
    end
    
Project 03

Open Design:多进程信任拓扑与两端收口架构

这张图回答什么Open Design 自己不写 Agent 主循环,凭什么保证 25 个第三方 CLI 产出的设计质量一致?
承重墙论点两端收口,中间放手;适配器是纯数据描述而非执行类。Daemon 是唯一拥有 Express Server (apps/daemon/AGENTS.md:96)、better-sqlite3、凭证与 Spawn 权的特权进程(绑 loopback)。RuntimeAgentDef 只是数据字面量,不持有 spawn 权;第三方 CLI 作为独立子进程运行并直接写盘;Open Design 的控制力全集中在入口的 20 层提示词组装 (prompts/system.ts)出口的事后质量闸门 (lint-artifact 与 Design Jury)
A · 进程与信任拓扑进程与信任拓扑图 (Process & Trust Topology)
flowchart LR
    subgraph BROWSER["① 渲染进程 (Web / Electron Renderer) · 无特权"]
        UI["Next.js 16 App Router + React 18
apps/web/src/"] VIEWER["FileViewer.tsx (660 KB)
沙箱 iframe 预览"] end subgraph SIDECAR["② SSR 侧车 · 低特权"] SSR["Next.js Server Sidecar
apps/web/"] end subgraph DAEMON["③ Daemon 主进程 · 唯一特权方"] SERVER["Express Server (绑 loopback)
apps/daemon/AGENTS.md:96"] DB[("better-sqlite3
projects · runs · conversations")] SYS_PROMPT["prompts/system.ts (2075 行)
20 层提示词组装入口"] DEFS["RuntimeAgentDef ×26
runtimes/defs/ (纯数据规格)"] GATE["出口质量闸门
lint-artifact & Design Jury"] end subgraph CLI_CHILD["④ 被 Spawn 的第三方 CLI · 独立子进程"] CLIS["claude / codex / cursor-agent / opencode ...
(共 26 条定义描述 25 个 CLI 二进制)"] end subgraph DISK["⑤ 项目 cwd 文件系统"] FS[("真实产物文件
HTML / PDF / PPTX / MP4")] end UI -->|"HTTP 请求"| SSR UI -->|"HTTP / SSE (Loopback)"| SERVER SERVER --- DB SERVER --> SYS_PROMPT SERVER -.->|"读取参数定义 (纯数据)"| DEFS DEFS -.->|"buildArgs() 纯函数
仅产出 argv 数组"| SERVER SERVER -->|"spawn(binary, argv)
唯一持有 spawn 权"| CLIS CLIS -->|"直接写盘 (产物不回传 Daemon)"| FS FS -.->|"事后读取进行校验"| GATE GATE -.->|"校验不合格重新触发"| SYS_PROMPT classDef privileged fill:#fff3e0,stroke:#e65100,stroke-width:2.5px classDef unprivileged fill:#e8eaf6,stroke:#283593,stroke-width:1.5px classDef third fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,stroke-dasharray:4 3 classDef storage fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px class DAEMON privileged class SERVER,SYS_PROMPT,GATE privileged class BROWSER,SIDECAR,UI,VIEWER,SSR unprivileged class CLI_CHILD,CLIS third class DISK storage class DEFS third style DB fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px style FS fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
橘底 = 唯一特权 Daemon 节点 · 蓝底 = 低特权/无特权 UI 渲染节点 · 紫虚线 = 外部 CLI 独立进程或纯数据结构 · 绿底 = 本地文件/数据库。
E · 扩展点与改动半径扩展点图 (Diagram Type E: Extension Surface)
flowchart LR
    NEED["需求:接入第 26 个 CLI 运行引擎"] --> ASK{"要改什么?"}
    ASK -->|"❶ 数据扩展 (数据即适配器)"| D1["runtimes/registry.ts
往数组加一条 RuntimeAgentDef 字面量
改动半径 = 1 个文件 · 0 行新逻辑代码"] ASK -.->|"❷ 接口扩展 (本项目不需要)"| D2["编写 JavaScript 类 / 实现 Adapter 接口"] ASK -.->|"❸ 核心改造 (本项目不需要)"| D3["修改 Daemon 主循环调度器"] D1 --> OK["✅ 接入完成"] classDef good fill:#e8f5e9,stroke:#2e7d32,stroke-width:2.5px classDef na fill:#fafafa,stroke:#bdbdbd,stroke-dasharray:4 3,color:#9e9e9e class D1,OK good class D2,D3 na
绿色 = 实际需要做的扩展步骤 · 灰色虚线 = 架构优秀导致**完全不需要改动*
Project 04

OpenCode:服务器即本体的星形拓扑

这张图回答什么为什么 OpenCode 能让 TUI、桌面 App、Web 界面与 Zed 编辑器无缝共享同一个会话状态?
承重墙论点服务器即 Agent 本体。OpenCode 在 Bun 运行时 Worker 线程中运行 HTTP/SSE 服务器 (packages/opencode/src/server/),基于 Effect TS 函数式框架管理会话。TUI 与 Zed ACP(位于服务端包内部 packages/opencode/src/acp/)全都是纯粹的 HTTP 客户端
A · 进程与信任拓扑
flowchart LR
    subgraph CLIENTS["客户端接入层 (全是 HTTP/SSE 客户端)"]
        TUI["packages/tui
OpenTUI + SolidJS 终端 UI"] DESK["packages/desktop / web / app
桌面与 Web 前端"] ZED["Zed 编辑器
(ACP 客户端)"] end subgraph SERVER_WORKER["Bun 进程 / Worker 线程 (Agent 本体 - 星形核心)"] HTTP_API["server/routes/instance/httpapi
REST + SSE 实时事件接口"] EFFECT_GEN["Effect TS 框架
(Effect.gen 依赖注入 & 结构化并发)"] SESSION_LOOP["session/prompt.ts
Agent 主循环心脏"] INTERNAL_ACP["packages/opencode/src/acp/
内嵌 ACP 协议转换层"] TOOLS["tool/registry.ts
内置工具注册表"] SQLITE[("SQLite + Drizzle ORM
会话持久化存储")] end subgraph LLM_TIER["外部模型厂商"] LLM_PROVIDERS["Multi-Provider LLM SDK
(OpenAI / Anthropic / DeepSeek / Kimi 等 30+ 厂商)"] end TUI & DESK -->|"HTTP 请求"| HTTP_API ZED <-->|"ACP JSON-RPC"| INTERNAL_ACP --> HTTP_API HTTP_API --> EFFECT_GEN --> SESSION_LOOP SESSION_LOOP -->|"读写 CRUD"| SQLITE SESSION_LOOP -->|"dispatch"| TOOLS TOOLS -->|"result"| SESSION_LOOP SESSION_LOOP -->|"llm.stream"| LLM_PROVIDERS classDef client fill:#e1f5fe,stroke:#0288d1,stroke-width:2px classDef server fill:#efebe9,stroke:#4e342e,stroke-width:2.5px classDef ext fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px class CLIENTS,TUI,DESK,ZED client class SERVER_WORKER,HTTP_API,EFFECT_GEN,SESSION_LOOP,INTERNAL_ACP,TOOLS server class LLM_TIER,LLM_PROVIDERS ext style SQLITE fill:#efebe9,stroke:#4e342e,stroke-width:2.5px
蓝底 = 外部多客户端平级节点 · 棕底 = 居中的 Agent 服务端核心节点 · 紫底 = 外部 LLM API。
Project 05

OpenWorker:事件流与带外审批治理

这张图回答什么OpenWorker 作为「AI 数字同事」,如何在执行跨应用无人值守任务时,做到「不中断主循环、又能进行人类安全治理」?
承重墙论点带外审批与统一事件流。Python 包名为 coworker(对应仓库 openworker,命令 openworker);与 Rust/Tauri 桌面壳通过事件通信;密钥绝对不进 LLM 上下文 ([coworker/secrets.py:3](file:///Users/mikayiyanglin/Documents/Github%20claude-code/claude%20code源码分析/项目分析/openworker-源码分析.md#第-7-章-工具系统与权限aisuite-工具--五档模式--标准规则));TurnEngine (engine.py) 产生统一 EventStream (events.py)。高危权限请求不阻塞会话,而是落入 Attention Inbox (收件箱) 待人类处理,调度器位于 coworker/automation/scheduler.py
A · 进程与信任拓扑
flowchart LR
    subgraph TAURI_SHELL["① 桌面壳 & 界面进程 (Rust / Tauri)"]
        GUI["React 界面 (surfaces/gui/src)
会话视图 / 工具卡 / 审批卡"] STT["Rust STT 侧车 (stt/)
语音输入处理"] end subgraph PYTHON_SERVER["② Python Agent 引擎服务进程 (coworker/)"] FASTAPI["FastAPI / uvicorn 服务
coworker/server/run.py"] MGR["SessionManager 会话编排
coworker/server/manager.py"] ENGINE["TurnEngine 循环心脏
coworker/engine.py"] EVENTS["TurnEngine EventStream
(events.py: TURN_START / TOOL_PROPOSED)"] INBOX["Attention Inbox 收件箱
(带外人类注意力队列)"] SCHED["Cron 调度器
coworker/automation/scheduler.py"] end subgraph STORAGE_EXT["③ 密钥库与基础设施"] KEYRING[("本地 OS 密钥库
secrets.py:3 Secrets Never Enter Context")] CONNECTORS["25+ 应用连接器
Slack / Jira / GitHub / Calendar"] AISUITE["aisuite 统一 LLM SDK
(OpenAI / Anthropic / Ollama)"] end GUI -->|"HTTP 请求"| FASTAPI FASTAPI -->|"WebSocket 事件推送"| GUI STT --> GUI FASTAPI --> MGR --> ENGINE ENGINE --> EVENTS EVENTS -->|"1. 提权请求不阻塞,丢入队列"| INBOX INBOX -.->|"2. 人类有空时审批放行"| ENGINE SCHED --> MGR ENGINE --- KEYRING ENGINE --> CONNECTORS ENGINE --> AISUITE classDef rust fill:#ffebee,stroke:#c62828,stroke-width:2px classDef python fill:#e8f5e9,stroke:#2e7d32,stroke-width:2.5px classDef ext fill:#fff8e1,stroke:#f57f17,stroke-width:2px class TAURI_SHELL,GUI,STT rust class PYTHON_SERVER,FASTAPI,MGR,ENGINE,EVENTS,INBOX,SCHED python class STORAGE_EXT,CONNECTORS,AISUITE ext style KEYRING fill:#fff8e1,stroke:#f57f17,stroke-width:2px
红底 = Rust/Tauri 桌面界面 · 绿底 = Python coworker 引擎服务端 · 黄底 = 本地密钥与外部连接器。
Project 06

Grok Build:Goal Mode 4 阶段状态机

这张图回答什么grok-build 的 Goal Mode 如何保证长达数小时的多阶段自主任务在跨越多次 LLM 调用时不丢失、不跑偏?
承重墙论点Goal 不是 Prompt,而是持久化的状态机。Grok 是基于 Rust 的单二进制全屏 TUI 编程 Agent。GoalTracker 显式维护 PlanExecuteValidateStrategist Recover 四态,状态独占持久化,即便 LLM 上下文被截断或模型报错,控制平面状态机依然能驱动战略恢复。
F · 状态机与失败恢复
stateDiagram-v2
    [*] --> Plan: 用户输入 Goal 任务目标
    
    state Plan {
        [*] --> AnalyzingCodebase: xai-codebase-graph 索引分析
        AnalyzingCodebase --> DecomposingSubtasks: 拆解为可验证的子目标数组
        DecomposingSubtasks --> PlanLocked: 锁定任务规划线索
    }

    PlanLocked --> Execute: 状态机推向执行

    state Execute {
        [*] --> ToolExecution: ToolBridge 调用 (~25 Rust 工具)
        ToolExecution --> FileMutation: 修改代码与操作 Shell
        FileMutation --> InspectOutput: 捕获运行日志与 Diff
    }

    Execute --> Validate: 状态机推向验证

    state Validate {
        [*] --> RunTests: 自动运行编译与单元测试
        RunTests --> CheckCriteria: 检查目标断言条件
    }

    Validate --> [*]: 验证通过,目标完成 (Goal Completed)
    
    Validate --> StrategistRecover: 验证失败 / 遇到编译错误
    
    state StrategistRecover {
        [*] --> AnalyzeFailure: 战略师 Agent 分析失败根因
        AnalyzeFailure --> AdjustPlan: 修正后续子任务规划
    }

    StrategistRecover --> Execute: 带着修正案重新执行
    
Project 07

OpenManus:继承链作为能力偏序与双重终止防线

这张图回答什么OpenManus 如何通过极简的面向对象继承链组织不同 Agent 的能力,并防止长任务死循环?
承重墙论点继承链即能力偏序,止损靠双重防线。从 BaseAgent(基础循环 + is_stuck() / handle_stuck_state() 判定 + max_steps 默认限制为 10 步)➔ ReActAgent (think/act) ➔ ToolCallAgent (工具解析) ➔ Manus / BrowserAgent / DataAnalysis / SandboxManus 逐级拓展能力。
E · 类型拓扑与能力偏序
flowchart TB
    subgraph ENTRANCE["入口层 (Entrance Scripts)"]
        MAIN["main.py ➔ Manus.create()"]
        FLOW["run_flow.py ➔ PlanningFlow (多 Agent 编排)"]
        SANDBOX_MAIN["sandbox_main.py ➔ Daytona 云沙箱版"]
        MCP_SERVER["run_mcp_server.py ➔ FastMCP 服务端"]
    end

    subgraph HIERARCHY["Agent 继承链 (单色相多明度能力偏序图)"]
        BASE["BaseAgent (app/agent/base.py)
• 基础 step() 循环框架
• 🛡️ 止损防线 1: is_stuck() / handle_stuck_state()
• 🛡️ 止损防线 2: max_steps 默认限制 = 10 步 (base.py:40)"] REACT["ReActAgent (app/agent/react.py)
• 新增 think() 与 act() 抽象方法"] TOOL_CALL["ToolCallAgent (app/agent/toolcall.py)
• 新增 LLM 工具调用 Block 解析与挂载"] MANUS["Manus / BrowserAgent / DataAnalysis / SandboxManus
• 注入特定工具箱 (browser-use / search / python / chart)"] BASE -->|"继承并扩展"| REACT REACT -->|"继承并扩展"| TOOL_CALL TOOL_CALL -->|"继承并实例化"| MANUS end subgraph DELIVERABLES["调研与交付物工具集 (app/tool/)"] BROWSER["browser_use_tool.py (Playwright 浏览器)"] SEARCH["web_search.py (Google/Baidu 级联搜索)"] PYTHON["python_execute.py (代码执行)"] CHART["chart_visualization/ (图表绘制)"] end ENTRANCE --> HIERARCHY MANUS --> DELIVERABLES DELIVERABLES -->|"交付成果"| HANDBOOK[("HTML 旅游手册 / 调研报告 / 数据图表")] classDef lv1 fill:#fce4ec,stroke:#ad1457,stroke-width:2px classDef lv2 fill:#f8bbd0,stroke:#ad1457,stroke-width:2px classDef lv3 fill:#f48fb1,stroke:#ad1457,stroke-width:2px classDef lv4 fill:#f06292,stroke:#ad1457,stroke-width:2.5px,color:#fff class BASE lv1 class REACT lv2 class TOOL_CALL lv3 class MANUS lv4
粉色由浅到深 ( Level 1 ➔ Level 4) = 继承链上的能力累积。颜色越深,代表获得的工具与抽象能力越多(偏序渐进关系)。
Appendix

方法论与勘误记录

这批图经过三轮审阅,每一轮都对着源码树逐条核对、并把全部 Mermaid 丢进渲染器实测。累计闭环 19 处问题。

轮次发现的问题结果
第一轮六张图共享同一个「目录树式伪分层」形状;无进程边界、无时间维度、无失败路径;颜色无语义产出绘制规范:六种图型 + 视觉通道纪律 + 事实核对协议
第二轮一张图语法错误完全不渲染;一个编造的百分比数字;四个源码里查不到的标识符;配色语义未生效(5 个节点漏色)产出勘误单;新增「渲染验收前置」与「颜色回渲染器核对」两条硬规则
第三轮一条边把 spawn 动作归给了数据结构,与该图自己的承重墙论点自相矛盾;两个坏锚点;偏序关系误用多色相产出第三轮审阅;并更正了我自己上一轮的一条错误归因

三条最值得记住的规则

规则零
交付前必须真渲染
Mermaid 语法错误不会让流程报错,只会安静地画一个炸弹图标。第二轮就是这样漏掉了一张坏图。断言每张图的 SVG 里确实有节点
规则十三
颜色要回渲染器核对
class 作用于 subgraph 不会继承给组内节点。第二轮的「控制/数据平面」配色有 5 个节点没生效,其中包括最核心的主循环——论点悄悄失效了
规则十四
问箭头尾巴有没有能力做这件事
数据结构不会 spawn 进程、配置文件不会发起调用。把动作归给数据是最难自查的语义错误——因为它读起来完全通顺
关于配套海报图(jpg) 这批图另有由图像模型生成的海报版。经逐张检查,它们暂不适合作为技术插图
  • 文字不可靠——每张都有生成式乱码(如 the performant unctionShore contextcontinatiuemarhedulms
  • 版本滞后——已修正的错误仍被烤进图里(>90% 缓存命中6 Sandboxes3-Process26 Defs spawning 25 CLIs
  • 七张里有四张还是第一版的层叠式设计,与现在的图不是同一套
本页因此以 Mermaid 图为准——它们是经过三轮核对与渲染验收的版本。海报重制后可作为章首视觉补入。