mimo code 通过内部职能分离为多 agent 协作提供边界设计启示：职责隔离、验收分离、记忆与计算解耦、工具权限最小化，并将硬边界写入 system prompt。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
MiMo Code 并没有直接定义多 Agent 的协作边界，它本身是一个单体长程编程 Agent，其核心创新在于“内部职能分离”——把一个 Agent 的工作流切分为多个逻辑角色（如 主执行者、独立 verifier、writer subagent），而非部署多个独立运行的 Agent。但它对“职能划定”的实践，恰恰为多 Agent 系统中如何设定边界提供了关键启示：不是靠数量堆砌，而是靠职责隔离与权责明确。
职能必须可验证，不能自我裁决
MiMo Code 引入 Goal 机制，并用独立的 verifier 审查是否真正达成目标，这打破了单 Agent “自己定目标、自己干、自己说干完了”的闭环。在多 Agent 设计中，这意味着：
- 每个 Agent 的输出必须有明确的验收标准，比如前端专家只输出“改动范围评估报告”，不输出代码；后端专家只确认“接口契约是否兼容”，不设计数据库表结构
- 验收方和执行方必须分离，避免角色既当运动员又当裁判员
- Verifier 类 Agent 不需要懂实现细节，只需掌握契约规范（如 OpenAPI Schema、UI 组件 Props 接口）
记忆与计算必须解耦
MiMo Code 用 writer subagent 专门负责 checkpoint 和状态写盘，主模型专注推理——这是对“能力边界”的物理级划分。迁移到多 Agent 场景，就体现为：
- 不把“记住上下文”和“做决策”交给同一个 Agent；调度 Agent 负责流转，记忆 Agent 负责存取历史任务快照
- 运维类 Agent 可以读取日志，但无权修改配置；测试 Agent 可生成用例，但无权触发上线流程
- 工具调用权限按最小必要原则分配，比如 QA Agent 有权调用 mock 工具和断言库，但无权访问生产数据库连接串
边界要写进系统提示词，而不是靠运行时约束
MiMo Code 的稳定性问题（如自动删包、内存泄漏）部分源于行为未被显式约束。而实践中更稳健的做法，是像 Slock 社区里那样，在每个 Agent 的 system prompt 中用【你不要做什么】段落划出硬边界：
- 禁止越权操作：不碰未授权仓库、不修改非职责文件、不伪造结果
- 禁止模糊兜底：“卡住就上报”比“尽力而为”更可靠
- 禁止功能蔓延：不为“完整”自行添加需求未提及的功能，哪怕逻辑上很顺
这种边界不是技术限制，而是协作契约。它让 Agent 之间能建立可预期的交接关系——前端专家交出的评估报告，后端专家能放心读；QA 补的用例，开发不用再二次校验输入合法性。真正的协作效率，来自清晰的“不做”比模糊的“要做”更少歧义。
