是刚开源的minimax code

回复 群友 1589： 对，是我认错了对象，把桌面端 Agent Team 的介绍套过来了，抱歉。你说的是刚开源的终端版 MiniMax Code。我重新查了仓库当前 README 和架构文档。 最关键的纠正：这份开源代码不是前面那套 Leader／Worker／Verifier 团队引擎。官方明确说，旧的 Team cycle engine 不在此次源码范围内，终端里的任务委派由当前运行时的任务服务负责。 从 Agent 架构看，可以分成四层。 一、交互入口：三种界面，共用执行核心 支持终端交互 TUI、脚本／CI 用的 headless，以及连接编辑器的 ACP。 比如同一个“复现测试失败、修改实现、重跑测试”的任务，可以在终端交互执行，也可以放进自动化脚本。入口不同，不需要另造一套 Agent。 二、运行时：管理会话、轮次和任务 入口经过统一服务，进入本地应用层，再由 Session、Turn、Agent 服务处理。 以修测试为例：会话保存上下文，一轮执行组织模型与工具交互，任务运行期间还能接收用户补充或排队的后续要求。 这里的架构重点是：把聊天界面和任务执行生命周期分开，而不是把所有逻辑塞进一个终端聊天循环。 三、Agent 底座：复用 Pi，叠加产品运行时 架构文档明确写到，项目使用 pi-mono 提供 Agent、模型协议和终端基础设施。 因此，它不是完全从零写的 Agent 框架。更准确的理解是：在 Pi 的基础设施之上，加入自己的会话管理、任务服务、工具集成和交互体验。 不过，仅凭架构文档还不能断言它具体怎样改造了 Pi 的执行循环，需要进一步读实现。 四、执行能力：工具、权限、沙箱和扩展 它提供文件操作、命令与测试执行，同时支持权限控制、沙箱、MCP、插件、Skills 和子 Agent。 例如“修一个失败测试”，模型决定读哪些文件、改哪里；运行时承接工具调用和权限检查；测试结果再回到模型，决定继续修改还是结束。 注意：支持子 Agent 不等于内置了独立验收团队，更不证明每个任务都会自动走 Tester／Reviewer 返工闭环。前一条在这里说过头了。 我的判断： 这次更值得研究的是“基于 Pi 的本地 Coding Agent harness”：如何把模型执行循环包装成可恢复会话、可干预任务、受控工具执行，以及多入口共用的产品运行时，而不是桌面端多 Agent 团队的宣传架构。 另外，README 将当前源码标为 0.4.12 source preview；开源覆盖终端、headless 和 ACP，不包含桌面应用源码。 仓库： https://github.com/MiniMax-AI/minimax-code 架构依据： https://github.com/MiniMax-AI/minimax-code/blob/main/docs/architecture.md