# 回顾

> 全书要点串联：一条消息穿过的各层、值得记住的设计、与站内其他终端 Agent 的对照、文档与代码的出入，以及可迁移的经验和这份源码的短板。

- 作者：David（道雾轩）
- 专栏：MiniMax Code 源码解读（https://daiw.org/manual/minimax-code.md）
- 最后更新：2026-09-19
- 原文：https://daiw.org/manual/minimax-code/recap
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

读到这里，MiniMax Code 的形状可以归成一句话：**把上游的 Agent 循环整体搬进仓库，在外面自建一套运行时**。pi-mono 负责“一轮里调模型、跑工具”，MiniMax 自己负责这一轮之外的一切——谁来受理、排在谁后面、能碰哪些文件、用谁的账号、结果存到哪里、界面怎么画。这一篇把前面各部分串起来。

## 一条消息穿过的各层

对照[一条消息的旅程](https://daiw.org/manual/minimax-code/message-lifecycle)：

1. **TUI 提交**。输入框把文字、`@` 引用的文件和当前模式交给运行协调器；运行中再按 `Enter` 走“引导”，按 `Alt+Enter` 走“排队”（[TUI 应用](https://daiw.org/manual/minimax-code/tui-app)）。
2. **进程内入口**。TUI、`mcode exec` 与 ACP 共用同一个进程内运行时，`CliService` 的 86 个公开方法几乎都是一行转发，交给背后的几组应用对象（[进程内入口](https://daiw.org/manual/minimax-code/runtime-entry)）。
3. **回合系统**。提交先过受理，再入队、派发、执行、收尾；受理后由回合控制器持有租约，错误按策略重试（[回合系统](https://daiw.org/manual/minimax-code/turn-system)）。
4. **pi 的循环**。每个回合在 `agent-core` 里新建一个 pi 的 `Agent`，按 Agent 服务渲染好的系统提示词、按层层过滤后的工具清单跑起来（[pi 的 Agent 循环](https://daiw.org/manual/minimax-code/pi-agent)、[Agent 服务](https://daiw.org/manual/minimax-code/agent-service)、[工具体系](https://daiw.org/manual/minimax-code/tool-system)）；模型调用经 pi-ai 统一成一套事件流（[pi-ai](https://daiw.org/manual/minimax-code/pi-ai)）。
5. **工具执行**。每次调用先过权限判定；打开沙箱（默认关闭）后，macOS 上的 Bash 还会被包进沙箱（[权限](https://daiw.org/manual/minimax-code/permission)、[沙箱](https://daiw.org/manual/minimax-code/sandbox)）；Agent 模块在循环的扩展点上注入提醒、盯住失控、管理上下文（[Agent 模块](https://daiw.org/manual/minimax-code/agent-modules)、[上下文管理](https://daiw.org/manual/minimax-code/context-management)）。
6. **回到屏幕**。事件写进会话流，TUI 把它们投影成转录单元再画成终端行（[会话系统](https://daiw.org/manual/minimax-code/session-system)、[TUI 引擎](https://daiw.org/manual/minimax-code/tui-engine)）。

## 值得记住的设计

**地基**

1. **vendor 上游，改动全有账**。pi-mono 四个包按 v0.79.1 原样放进 `third_party`，34 条本地补丁逐条写明原因、影响的包、是否可回馈上游（[内置的 pi-mono](https://daiw.org/manual/minimax-code/pi-mono)）。
2. **界面另起一份 fork**。产品 TUI 没用 `third_party` 里的 pi-tui，而是基于 pi-tui 0.84.2 另建了一份，逐文件记录哈希与本地改动（[TUI 引擎](https://daiw.org/manual/minimax-code/tui-engine)）。
3. **先测后存的 BYOK**。`mcode provider add … --use` 先用第一个模型做连通性测试，成功才保存并设为默认（[模型系统](https://daiw.org/manual/minimax-code/model-system)）。

**运行时**

4. **受理与执行分开**。回合先被受理、排队，再由派发器交给执行层；运行中的新输入可以“引导”当前响应，也可以排到下一回合（[回合系统](https://daiw.org/manual/minimax-code/turn-system)）。
5. **多进程共用一个数据目录**。单个 SQLite 库加手写迁移，靠租约判定哪个进程拥有运行时（[存储](https://daiw.org/manual/minimax-code/storage)）。
6. **旧会话惰性迁移**。更早的会话由导入器惰性、单向地转成 pi 会话，第一代运行时只保留只读的读取器（[会话系统](https://daiw.org/manual/minimax-code/session-system)、[第一代运行时](https://daiw.org/manual/minimax-code/runtime-v1)）。

**工具与安全**

7. **工具清单层层过滤，输出分层截断**。模型能看到什么由模型能力、Agent 配置与宿主类型共同决定，单条输出有预算（[工具体系](https://daiw.org/manual/minimax-code/tool-system)）。
8. **Bash 分层判定**。一条命令要依次过多层规则才决定放行、询问还是拒绝，“始终允许”落进规则文件（[权限](https://daiw.org/manual/minimax-code/permission)）。
9. **短期令牌给工具子进程**。工具子进程不直接拿用户凭据，而是经本地租约代理领短期令牌（[账号、OAuth 与云端工具](https://daiw.org/manual/minimax-code/accounts-and-tools)）。

**扩展**

10. **插件带来多种能力**。一个插件可以带技能、MCP 服务器与钩子，快照在回合之间发布；钩子兼容 Claude Code 与 Codex 的格式（[插件系统](https://daiw.org/manual/minimax-code/plugins)）。
11. **MCP 工具可以延迟披露**。按上下文占比决定内联还是改用检索，默认白名单为空（[MCP](https://daiw.org/manual/minimax-code/mcp)）。
12. **遥测默认关闭、逐项同意**。三个通道各自开关，导入当天的提交把自动上传改成需要单独同意（[遥测、更新与诊断](https://daiw.org/manual/minimax-code/telemetry-and-update)）。

## 与站内其他终端 Agent 对照

| 维度 | [OpenCode](https://daiw.org/manual/opencode) | [Kimi Code](https://daiw.org/manual/kimi-code) | [MiMo Code](https://daiw.org/manual/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](https://daiw.org/manual/minimax-code/pi-mono)）。
- **插件来源**：README 与 `docs/tui-capabilities.md` 说支持官方、本地、GitHub 三类插件，CLI 实际只管官方与本地两类，GitHub 导入只挂在桌面端（[插件系统](https://daiw.org/manual/minimax-code/plugins)）。
- **内置 Matrix MCP**：`docs/tui-capabilities.md` 说已恢复，公开源码组装服务时把它写死为关闭（[MCP](https://daiw.org/manual/minimax-code/mcp)）。
- **定时任务**：命令行版整条链路都没有装配，Cron 是桌面端能力，README 与文档都没提（[定时任务](https://daiw.org/manual/minimax-code/cron)）。
- **遥测**：中文更新日志 0.2.5 那句“登录后自动上报”已经过时（[遥测、更新与诊断](https://daiw.org/manual/minimax-code/telemetry-and-update)）。
- **只解析、不生效的配置**：`permission.classifierTimeoutMs` 与 `userConfirmationEnabled` 在公开代码里只被解析，分类器超时固定 60 秒（[权限](https://daiw.org/manual/minimax-code/permission)）。

## 可迁移的经验

**要改上游，就把上游搬进来并记账。** 与其等上游发版，不如 vendor 源码、每条改动写清原因与是否可回馈；代价是基线会停住，之后的上游修复只能挑着回移。

**公开一个内部仓库，要有机器守门。** 文件清单、退役路径、内部地址与凭据扫描都写成脚本进了验证门，而不是靠人工逐个审查。

**把“插话”和“排队”分成两种语义。** 运行中的新输入是修正当前方向还是下一件事，用户心里是清楚的；代码把两者分开，界面才不会猜错。

**遥测默认关闭、逐项同意。** 把“要不要上传”交给用户逐项决定，比一个总开关更容易解释清楚。

**文档要跟代码一起评审。** 本书记下的出入里，多数是能力调整后文档没跟上。

## 这份源码的短板

- **命令行只是其中一种形态**：仓库里混着桌面端、云端与 IM 渠道的模块，读 CLI 主线时得先分清哪些根本没被装配。
- **两代运行时与历史包袱**：v2 现役，第一代仍提供大量宿主设施，还有旧会话的读取与导入，理解一条调用链要跨两代代码。
- **配置与实现不同步**：有些配置只被解析、没接进 v2，有些开关的注释与实际默认值相反，读配置时要回到代码确认。
- **公开时间短、没有版本标签**：源码导入不久、修复仍在频繁合入，仓库没有 tag，引用只能固定在提交上。

## 继续读什么

- **想对照同样借用 pi 的实现**：[《Kimi Code 源码解读》](https://daiw.org/manual/kimi-code)。
- **想看另一种 TypeScript 架构与它的二次开发**：[《OpenCode 源码解读》](https://daiw.org/manual/opencode)、[《MiMo Code 源码解读》](https://daiw.org/manual/mimo-code)。
- **想看 Rust 生产实现**：[《Grok Build 源码解读》](https://daiw.org/manual/grok-build)。
- **想从零理解 Agent 该做什么**：[《从 LLM 到 Coding Agent》](https://daiw.org/manual/llm-to-agent)。
- **想了解它兼容的两家**：[《Claude Code 中文手册》](https://daiw.org/manual/claude-code)、[《Codex 中文手册》](https://daiw.org/manual/codex)。