阅读地图

按角色和问题选择最短阅读路径，并建立贯穿全书的心智模型。

先记住三个不变量

面对几十万行多端代码，最容易迷失在文件名里。先抓住下面三个不变量，后面的模块都能找到位置。

1. Server 是执行边界

Agent 进程、PTY、文件系统、Git、预览端口和大部分密钥都在 Server 所在机器上。客户端不是执行器，而是可替换的控制面。Electron 之所以特殊，只是它能监督一个内嵌 Server，并通过 IPC 增加桌面能力；业务真相仍然在 Server。

2. 事件日志是会话事实，投影是读取产品

用户动作先变成命令，经纯 decider 产生领域事件。事件落入 SQLite 后，projector 才构造线程、消息、活动、会话与回合视图。客户端读取的是投影并订阅增量，不直接把 Provider SDK 的回调当状态。

3. Provider 差异只能越过一条窄缝

Codex 是自定义 JSON-RPC app-server，Claude 是 Agent SDK，Cursor/Grok 走 ACP，OpenCode 走自己的 SDK。差异在 Provider adapter 和 runtime ingestion 被吸收；越过边界后，系统只谈规范化的 session、turn、 message、activity、approval 和 error。

贯穿全书的命令—事件—投影闭环

按目标选择路线

想快速建立全局认识（约 60 分钟）

正在设计实时 Agent 产品

重点读类型化 RPC、事件溯源编排、运行时事件归一化、持久化与投影和连接运行时。这条路线覆盖最难的两件事：服务端如何形成可恢复事实，客户端如何在不稳定网络上维持可信快照。

正在接入新的 Agent Provider

先读Provider 系统，再对比 Codex 与 Claude和ACP 与 OpenCode，最后读运行时事件归一化。新增 Provider 的难点通常不是启动进程，而是把不完整、重复、乱序且粒度不同的回调映射成严格生命周期。

关注桌面、移动或远程能力

章节依赖

建议阅读依赖

如何核对结论

每章的“源码锚点”都链接到上游文件。建议采用三步法：

先看文档中的数据流和不变量，明确要验证的结论；
打开链接，沿类型定义而不是 import 数量阅读；
再看相邻测试，确认失败路径和边界条件是否被显式保护。

T3 Code 的测试命名很有信息量，例如 ProviderRuntimeIngestion.approval.test.ts、 OrchestrationEngine.test.ts 和 GitVcsDriver.test.ts。当实现与直觉冲突时，测试往往比注释更能说明契约。

On this page