介绍下minimax code，从agent架构角度

回复 群友 1589： 我按 MiniMax Code 桌面端的 Agent Team 来讲，不是 MiniMax 模型本身。下面基于官方架构文章，不是源码审计。 它的核心不是“同时开几个 AI 写代码”，而是：模型负责判断和执行，程序负责推进任务、组织验收和失败返工。 先举个例子：你让它“给项目加一个订单导出功能”。 Leader 先明确导出字段、权限和验收标准，再拆任务；Worker 分别负责实现接口、页面等工作；Verifier 检查权限、导出内容和测试结果。发现越权漏洞，就退回修改，而不是 Worker 说“完成了”就交差。 从 Agent 架构看，有五个重点。 一、Leader：面向用户的控制层 负责理解目标、拆分任务、分配角色、跟踪进度，以及判断什么时候需要人介入。 它不必亲自执行所有工作。耗时任务交给后台 Agent，用户仍能继续问进度、补充要求。 这把“及时回复用户”和“长时间执行任务”分开了，避免主对话被一次长任务堵住。 二、Worker：独立上下文的执行层 不同 Worker 可以有不同工具、上下文、记忆、Skills 和输出要求。 比如写接口的 Worker 主要看服务端代码，审查权限的 Agent 重点看鉴权边界，不必都背着完整聊天记录。 重点不是角色名字，而是给每个执行者恰好够用的信息和能力。上下文隔离也不等于文件系统或安全权限天然隔离，这些需要另外的工程机制。 三、Verifier：独立验收，而非自我评价 它把“生成了结果”和“结果能交付”分开。 在编码场景，官方进一步区分： Tester 看测试、构建等实际执行结果。 Reviewer 看设计、兼容性、权限和潜在风险。 比如测试全部通过，但新接口漏了鉴权，仍然不能交付。验证应绑定外部证据，而不是另一个模型简单说“看起来没问题”。 四、Team Engine：真正撑住长任务的状态机 这是我认为最值得关注的部分。 官方明确描述了这条状态链： 生产 → 验证 → 完成 验证失败 → 重新唤醒生产节点修改 → 再验证 推进这条链的是确定性的程序逻辑，不只是提示词里写一句“请不断努力直到完成”。 Leader 持续获取状态，也能给正在运行的执行或验证 Agent 补充要求。因此，它不只是“调用一个子 Agent，等它返回摘要”，而是可持续交互的任务团队。 这里的确定性指状态流转可控，不代表模型判断或最终结果必然正确。 五、通信与沉淀：避免把所有记录塞给所有人 官方介绍了交接文件、共享白板，以及 Agent 之间直接通信等方式。 例如接口 Worker 交付接口约定和修改摘要，页面 Worker 按需读取，不需要接收对方全部探索过程。 记忆用于沉淀经验，Skills 用于复用操作流程。但这不等于模型权重在线学习；Skills 也不是越多越好，需要管理重复、冲突和过时内容。 我的判断： 它的架构亮点是“角色分工＋上下文隔离＋状态机驱动的验收返工”，而不只是多 Agent 并行。 代价也很明确：交接会丢信息，验收会多花时间和 token；验收标准写错，多个 Agent 仍然可能一起做错。因此跨文件、可拆分、验收清晰的任务更适合 Team，改个常量未必值得启动整套流程。 官方架构说明： https://www.minimax.io/blog/minimax-agent-team-long-running-1779893953