优化 MiMo Code 的 Agent 编排性能，关键并不在于“让模型推理更快”，而是让整个运行时系统更智能地分配任务、隔离潜在风险、并有效复用过往经验。它面临的瓶颈并非单次推理速度，而是在数十步之后出现的决策漂移、状态混乱、子任务遗漏——这些问题在高复杂度任务中往往比 token 响应速度更为致命。

先明确一个要点：如果只是在一条 prompt 中堆叠指令，相当于把整个项目的成功寄托于模型一次性“灵光闪现”。真正的工程化思路，应该从以下四个方向着手。

启用 Max Mode 并合理设定阈值

Max Mode 是 MiMo Code 提升单步鲁棒性的核心机制：每轮并行生成 5 个候选方案，由同一模型充当裁判选出最优项执行。实测在 SWE-Bench Pro 上完成率提升 10%–20%，但代价是 token 消耗增加 4–5 倍。这好比每个战斗班组都配备重火力——杀伤效率固然提高，但后勤补给线可能不堪重负。

因此，策略非常清晰：

• 仅在关键决策节点启用它，例如架构选型、错误修复或接口设计时。日常的简单编辑、注释补充，完全没有必要大动干戈。
• 通过 --max-mode=on --max-candidates=3 降低采样数，从 5 个减少到 3 个，质量损失很小，但 token 开销能节省将近一半。
• 禁用自动重试循环。很多情况下，模型选不出好方案是因为问题本身定义不清，而不是采样不够。改用 Goal 验证器兜底，比盲目重试更加高效。

用 Dynamic Workflow 替代 prompt 编排

设想一下，你要搭建一个全栈记账应用，同时处理前端组件、图表逻辑、后端路由、依赖安装、测试配置。如果靠模型在 prompt 里硬性编排，就像让一位厨师在脑海中同时烹饪十道菜——不出错才怪。

Dynamic Workflow 的解法是将流程控制从语言空间转移到代码空间。主 Agent 只负责生成 Ja vaScript 脚本（而非自由文本），脚本在沙箱中确定性执行。这意味着：

• 用 agent("build") 派出构建子 Agent，barrier() 确保所有子任务完成后再继续——如同工程流水线，每个工位完成工作后才放行。
• 脚本可读、可调试、可版本化。如果某步执行出现问题，人工可以直接查看脚本逻辑，而不必翻查几十页的对话历史。
• 这种架构天然支持回滚和局部重做——例如只重新执行“后端路由”这个子模块，而不会影响其他部分。

分离 Writer 子 Agent，保障记忆一致性

长任务中最大的隐性瓶颈并非计算，而是状态污染。MiMo Code 的 Cycle 机制在上下文达到 20%/45%/70% 时触发 checkpoint，由独立的 Writer 子 Agent 提取结构化字段（意图、动作、错误、设计决策等）写入 SQLite FTS5 数据库。

有一个容易被忽视的细节：Writer 和主 Agent 必须进程隔离。主 Agent 对记忆文件只有读权限，这样即使它“发散思维”，也无法污染已经写好的历史记录。就像实验室里，做实验的人与写实验报告的人分开，避免数据篡改。

此外，在关键节点（如首次提交、测试通过）手动触发 /checkpoint force，相当于为项目拍摄一张快照。定期执行 mimo distill 合并冗余会话、压缩历史——既节省存储空间，又能让后续检索更加精准。

优先复用项目级记忆而非重推上下文

MiMo Code 的“越用越懂项目”能力源于四层记忆体系：项目记忆 > 会话检查点 > 任务进度 > 动态简报。这意味着当你在一个仓库中深耕几天后，它已经记住了你的偏好、代码风格以及常见错误模式。

那么，如何充分发挥这个能力？

• 首次进入仓库后执行 /dream load，自动加载该项目的历史决策快照。这比每次从零扫描代码库高效十倍。
• 使用 --context-from=project:auth-service 显式指定复用某模块记忆，例如只加载“认证服务”模块的历史上下文，而非泛泛读取全部代码。
• 禁用默认的 full-repo scan。许多项目动辄几十万行代码，全量扫描不仅慢，还会让模型分心。改用 --file-filter="src/**/*.{ts,tsx}" 聚焦核心路径，只扫描真正需要的文件。

总结一下：这四个优化方向的核心逻辑高度一致——不要让模型在广度上浪费资源，而是通过工程手段确保它把精力集中在最关键的地方。Max Mode 保障质量，Dynamic Workflow 掌控流程，Writer 子 Agent 稳固记忆，项目级记忆提升效率。四个要点配合得当，才能让 MiMo Code 在高复杂度任务中真正高效运行。