回顾
全书要点串联：一条消息穿过的各层、值得记住的设计、与站内其他终端 Agent 的对照、文档与代码的出入，以及可迁移的经验和这份源码的短板。
作者 David更新于 第 33 篇（共 33 篇）
读到这里，MiniMax Code 的形状可以归成一句话：把上游的 Agent 循环整体搬进仓库，在外面自建一套运行时。pi-mono 负责“一轮里调模型、跑工具”，MiniMax 自己负责这一轮之外的一切——谁来受理、排在谁后面、能碰哪些文件、用谁的账号、结果存到哪里、界面怎么画。这一篇把前面各部分串起来。
一条消息穿过的各层
对照一条消息的旅程：
- TUI 提交。输入框把文字、
@引用的文件和当前模式交给运行协调器；运行中再按Enter走“引导”，按Alt+Enter走“排队”（TUI 应用）。 - 进程内入口。TUI、
mcode exec与 ACP 共用同一个进程内运行时，CliService的 86 个公开方法几乎都是一行转发，交给背后的几组应用对象（进程内入口）。 - 回合系统。提交先过受理，再入队、派发、执行、收尾；受理后由回合控制器持有租约，错误按策略重试（回合系统）。
- pi 的循环。每个回合在
agent-core里新建一个 pi 的Agent，按 Agent 服务渲染好的系统提示词、按层层过滤后的工具清单跑起来（pi 的 Agent 循环、Agent 服务、工具体系）；模型调用经 pi-ai 统一成一套事件流（pi-ai）。 - 工具执行。每次调用先过权限判定；打开沙箱（默认关闭）后，macOS 上的 Bash 还会被包进沙箱（权限、沙箱）；Agent 模块在循环的扩展点上注入提醒、盯住失控、管理上下文（Agent 模块、上下文管理）。
- 回到屏幕。事件写进会话流，TUI 把它们投影成转录单元再画成终端行（会话系统、TUI 引擎）。
值得记住的设计
地基
- vendor 上游，改动全有账。pi-mono 四个包按 v0.79.1 原样放进
third_party，34 条本地补丁逐条写明原因、影响的包、是否可回馈上游（内置的 pi-mono）。 - 界面另起一份 fork。产品 TUI 没用
third_party里的 pi-tui，而是基于 pi-tui 0.84.2 另建了一份，逐文件记录哈希与本地改动（TUI 引擎）。 - 先测后存的 BYOK。
mcode provider add … --use先用第一个模型做连通性测试，成功才保存并设为默认（模型系统）。
运行时
- 受理与执行分开。回合先被受理、排队，再由派发器交给执行层；运行中的新输入可以“引导”当前响应，也可以排到下一回合（回合系统）。
- 多进程共用一个数据目录。单个 SQLite 库加手写迁移，靠租约判定哪个进程拥有运行时（存储）。
- 旧会话惰性迁移。更早的会话由导入器惰性、单向地转成 pi 会话，第一代运行时只保留只读的读取器（会话系统、第一代运行时）。
工具与安全
- 工具清单层层过滤，输出分层截断。模型能看到什么由模型能力、Agent 配置与宿主类型共同决定，单条输出有预算（工具体系）。
- Bash 分层判定。一条命令要依次过多层规则才决定放行、询问还是拒绝，“始终允许”落进规则文件（权限）。
- 短期令牌给工具子进程。工具子进程不直接拿用户凭据，而是经本地租约代理领短期令牌（账号、OAuth 与云端工具）。
扩展
- 插件带来多种能力。一个插件可以带技能、MCP 服务器与钩子，快照在回合之间发布；钩子兼容 Claude Code 与 Codex 的格式（插件系统）。
- MCP 工具可以延迟披露。按上下文占比决定内联还是改用检索，默认白名单为空（MCP）。
- 遥测默认关闭、逐项同意。三个通道各自开关，导入当天的提交把自动上传改成需要单独同意（遥测、更新与诊断）。
与站内其他终端 Agent 对照
| 维度 | OpenCode | Kimi Code | MiMo Code | MiniMax Code |
|---|---|---|---|---|
| Agent 循环 | 自研 | 自研 | 沿用 OpenCode | 内置 pi-mono，外包回合系统 |
| 终端界面 | OpenTUI + SolidJS | 复制 pi-tui | 沿用 OpenTUI | 另 fork 的 pi-tui 0.84.2 |
| 存储 | SQLite + Drizzle | 追加日志 + 自研索引 | SQLite | SQLite + Drizzle |
| 入口 | TUI、Web、桌面、ACP 等 | TUI、Web、VS Code、ACP 等 | 以 TUI 为主 | TUI、exec、ACP |
| 与上游的关系 | 自身即上游 | 复制一个库 | 分叉后独立演进 | vendor 源码并记补丁台账 |
文档与代码的出入
README 与仓库文档大体可信，但以下几处与代码不一致，正文都按代码写：
- 终端基础设施：
docs/architecture.md说它来自third_party/pi-mono，实际产品界面用的是另 fork 的 pi-tui 0.84.2（内置的 pi-mono）。 - 插件来源：README 与
docs/tui-capabilities.md说支持官方、本地、GitHub 三类插件，CLI 实际只管官方与本地两类，GitHub 导入只挂在桌面端（插件系统）。 - 内置 Matrix MCP：
docs/tui-capabilities.md说已恢复，公开源码组装服务时把它写死为关闭（MCP）。 - 定时任务：命令行版整条链路都没有装配，Cron 是桌面端能力，README 与文档都没提（定时任务）。
- 遥测：中文更新日志 0.2.5 那句“登录后自动上报”已经过时（遥测、更新与诊断）。
- 只解析、不生效的配置：
permission.classifierTimeoutMs与userConfirmationEnabled在公开代码里只被解析，分类器超时固定 60 秒（权限）。
可迁移的经验
要改上游，就把上游搬进来并记账。 与其等上游发版，不如 vendor 源码、每条改动写清原因与是否可回馈；代价是基线会停住，之后的上游修复只能挑着回移。
公开一个内部仓库，要有机器守门。 文件清单、退役路径、内部地址与凭据扫描都写成脚本进了验证门，而不是靠人工逐个审查。
把“插话”和“排队”分成两种语义。 运行中的新输入是修正当前方向还是下一件事，用户心里是清楚的；代码把两者分开，界面才不会猜错。
遥测默认关闭、逐项同意。 把“要不要上传”交给用户逐项决定，比一个总开关更容易解释清楚。
文档要跟代码一起评审。 本书记下的出入里，多数是能力调整后文档没跟上。
这份源码的短板
- 命令行只是其中一种形态：仓库里混着桌面端、云端与 IM 渠道的模块，读 CLI 主线时得先分清哪些根本没被装配。
- 两代运行时与历史包袱：v2 现役，第一代仍提供大量宿主设施，还有旧会话的读取与导入，理解一条调用链要跨两代代码。
- 配置与实现不同步：有些配置只被解析、没接进 v2，有些开关的注释与实际默认值相反，读配置时要回到代码确认。
- 公开时间短、没有版本标签：源码导入不久、修复仍在频繁合入，仓库没有 tag，引用只能固定在提交上。
继续读什么
- 想对照同样借用 pi 的实现：《Kimi Code 源码解读》。
- 想看另一种 TypeScript 架构与它的二次开发：《OpenCode 源码解读》、《MiMo Code 源码解读》。
- 想看 Rust 生产实现：《Grok Build 源码解读》。
- 想从零理解 Agent 该做什么：《从 LLM 到 Coding Agent》。
- 想了解它兼容的两家：《Claude Code 中文手册》、《Codex 中文手册》。