MiMo Code 虽然本质上是一个单体的长程编程智能体（Agent），但其内部其实实现了巧妙的“职能分离”——它将一个智能体的工作流程拆解为多个逻辑角色（例如主执行者、独立的验证器、子写入智能体），而非简单堆叠多个独立智能体。这种设计思路，为多智能体系统的边界划定提供了非常实用的启发：关键不在于智能体的数量，而在于职责的隔离与权责的明确划分。

职能必须可验证，不能自我裁决

MiMo Code 引入了一个目标（Goal）机制，并配备了一个独立的验证器（verifier）来审查目标是否真正达成——这打破了单个智能体那种“自己定目标、自己执行、自己验收”的封闭循环。在多智能体设计中，这意味着：

• 每个智能体的输出都必须有明确的验收标准。例如，前端专家只输出“改动范围评估报告”，不碰触代码；后端专家只确认“接口契约是否兼容”，不设计数据库表结构。
• 验收方与执行方必须分离，不能既当运动员又当裁判员。
• 验证器类智能体不需要了解实现细节，只需要掌握契约规范（如 OpenAPI Schema、UI 组件 Props 接口）。

记忆与计算必须解耦

MiMo Code 使用子写入智能体（writer subagent）专门负责检查点（checkpoint）和状态持久化，而主模型专注于推理——这是对“能力边界”进行的物理级切割。迁移到多智能体场景下，具体体现为：

• 不要将“记住上下文”和“做出决策”交给同一个智能体；调度智能体负责流转，记忆智能体专门存取历史任务快照。
• 运维类智能体可以读取日志，但无权修改配置；测试智能体可生成用例，但无权触发上线流程。
• 工具调用权限按最小必要原则分配——例如 QA 智能体有权调用 mock 工具和断言库，但没有权限触及生产数据库连接串。

边界要写进系统提示词，而不是靠运行时约束

MiMo Code 自身曾遇到一些稳定性问题（如自动删除包、内存泄漏），部分原因就是行为没有被显式约束。而在实际工程中，更可靠的做法是像 Slock 社区中所示那样，在每个智能体的系统提示词（system prompt）中使用【你不要做什么】段落划出硬性边界：

• 禁止越权操作：不碰未授权仓库、不修改非职责文件、不伪造结果。
• 禁止模糊兜底：“卡住就上报”比“尽力而为”更可靠。
• 禁止功能蔓延：不要为了“完整性”自行添加需求中未提及的功能，即使逻辑上看起来很顺畅。

归根结底，这种边界并不是技术限制，而是一种协作契约。它让智能体之间能够建立可预期的交接关系——前端专家提交的评估报告，后端专家可以放心读取；QA 补充的用例，开发人员无需二次校验输入合法性。真正的协作效率，来自于清晰的“不做”比模糊的“要做”更少的歧义。