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
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
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
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
coworker 引擎服务端 · ■ 黄底 = 本地密钥与外部连接器。Project 06
Grok Build:Goal Mode 4 阶段状态机
这张图回答什么grok-build 的 Goal Mode 如何保证长达数小时的多阶段自主任务在跨越多次 LLM 调用时不丢失、不跑偏?
承重墙论点Goal 不是 Prompt,而是持久化的状态机。Grok 是基于 Rust 的单二进制全屏 TUI 编程 Agent。
GoalTracker 显式维护 Plan ➔ Execute ➔ Validate ➔ Strategist 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
Appendix
方法论与勘误记录
这批图经过三轮审阅,每一轮都对着源码树逐条核对、并把全部 Mermaid 丢进渲染器实测。累计闭环 19 处问题。
| 轮次 | 发现的问题 | 结果 |
|---|---|---|
| 第一轮 | 六张图共享同一个「目录树式伪分层」形状;无进程边界、无时间维度、无失败路径;颜色无语义 | 产出绘制规范:六种图型 + 视觉通道纪律 + 事实核对协议 |
| 第二轮 | 一张图语法错误完全不渲染;一个编造的百分比数字;四个源码里查不到的标识符;配色语义未生效(5 个节点漏色) | 产出勘误单;新增「渲染验收前置」与「颜色回渲染器核对」两条硬规则 |
| 第三轮 | 一条边把 spawn 动作归给了数据结构,与该图自己的承重墙论点自相矛盾;两个坏锚点;偏序关系误用多色相 | 产出第三轮审阅;并更正了我自己上一轮的一条错误归因 |
三条最值得记住的规则
规则零
交付前必须真渲染
Mermaid 语法错误不会让流程报错,只会安静地画一个炸弹图标。第二轮就是这样漏掉了一张坏图。断言每张图的 SVG 里确实有节点。
规则十三
颜色要回渲染器核对
class 作用于 subgraph 不会继承给组内节点。第二轮的「控制/数据平面」配色有 5 个节点没生效,其中包括最核心的主循环——论点悄悄失效了。规则十四
问箭头尾巴有没有能力做这件事
数据结构不会 spawn 进程、配置文件不会发起调用。把动作归给数据是最难自查的语义错误——因为它读起来完全通顺。
关于配套海报图(jpg)
这批图另有由图像模型生成的海报版。经逐张检查,它们暂不适合作为技术插图:
- 文字不可靠——每张都有生成式乱码(如
the performant unction、Shore context、continatiue、marhedulms) - 版本滞后——已修正的错误仍被烤进图里(
>90% 缓存命中、6 Sandboxes、3-Process、26 Defs spawning 25 CLIs) - 七张里有四张还是第一版的层叠式设计,与现在的图不是同一套