小米发布MiMo Code v0.1.17，减少根据模型名称推断参数的隐式行为，采样参数改为配置后发送，内置搜索与Codex工具模式转向主动启用。更新还涉及凭据分离、中文记忆检索及失败处理；开发团队升级时应核对实验开关、外部服务和非交互运行权限，不能将配置调整等同于模型能力或安全性的全面提升。
小米MiMo于2026年11月13日发布MiMo Code v0.1.17，把一次编程智能体更新的重点放在了配置规则上：不再根据模型名称推断上下文与输出上限、推理档位，也不再默认向模型发送 temperature、top_p 等采样参数。内置联网搜索则改为显式启用。
这不是新基础模型发布。按照官方仓库的介绍，MiMo Code是以终端为主要入口的AI编程助手，可以读写代码、运行命令和管理Git，并支持接入不同大模型提供方。此次调整的是模型与工具之间的运行层：同一个模型接入后采用什么参数、获得哪些工具，以及怎样执行任务。
对已有用户而言，更新的实际影响可能首先体现为默认行为变化，而不是代码生成成绩提高。维护者公布了功能调整和修复清单，但这些材料没有提供足以证明整体编程效率提升的独立对照测试。
从“看模型名”转向读取明确配置
过去依赖模型名称设置行为，意味着工具会替用户作出一部分假设。v0.1.17将上下文、输出上限和推理档位的依据转向models.dev模型目录与用户配置，减少这类隐式判断。
相关实现说明列出了更具体的变化：移除针对部分模型名称的输出限制策略，以及按名称、日期维护的推理档位列表；没有声明推理档位的模型，不再自动获得一套档位。temperature、topP、topK也只在配置后发送，而不是由工具按模型标识补上默认值。
这不等于模型本身扩大了上下文窗口，或突然具备更强推理能力。改变的是客户端如何确定和传递参数。模型目录里的声明、用户配置与实际接入服务仍需要对应；把一个更大的上限写入配置，并不能证明服务端会接受它。
版本同时允许在配置中按名称启用/variants推理档位，子智能体继承父会话的档位。对于拆成多个子任务的工作流，这有助于减少父会话与子任务采用不同推理设置的意外，但并不构成任务质量或成本下降的保证。
另一项容易影响使用习惯的变化是，GPT模型不再自动切换到Codex风格的提示词和工具集。所有模型默认使用同一套设置，用户仍可通过MIMOCODE_CODEX_MODE=true主动启用相应模式。这里的“Codex模式”指MiMo Code内部的提示词与工具配置，不是宣布获得OpenAI Codex产品的全部功能。
搜索不再默认提供，但旧实验开关仍需留意
联网搜索的调整与接入方式有关。搜索改动的维护者说明指出，原有小米搜索插件按次向按量付费API凭据计费，并不包含在Token Plan中；此前的路由方式会让部分Token Plan会话收到误导性的插件启用提示。
新版本移除了原有小米网关搜索路径，内置搜索改用Exa通道，并要求显式启用。发布说明给出的常规入口是MIMOCODE_ENABLE_EXA=1；用户也可以另行配置搜索MCP服务器。MCP即模型上下文协议，是智能体连接外部工具的一种方式。
不过，“显式启用”不能简化成“只有这一个变量能打开搜索”。v0.1.17标签下的开关定义显示，实验总开关MIMOCODE_EXPERIMENTAL与旧实验开关MIMOCODE_EXPERIMENTAL_EXA同样能够启用Exa路径。已经使用实验配置的部署，不能仅凭没有设置新变量，就判断内置搜索一定关闭。
因此，升级时需要分别确认两件事：工作流是否仍能取得所需搜索工具，以及这些工具实际上连接哪一个外部服务。搜索默认关闭，也不等于整个智能体禁止联网或不再向外部模型服务发送数据。
凭据、中文记忆与失败处理也有调整
除了模型和搜索配置，发布说明还列出小米API凭据与Token Plan凭据分开保存、两者可以同时登录，以及记忆搜索支持中文子串召回等变化。
凭据分开管理有助于区分不同接入渠道，但不代表两类凭据享有相同额度、计费方式或服务权限。中文子串召回则针对记忆检索方式，并不能据此推导出模型中文理解能力获得同等提升。
稳定性修复包括额度耗尽后仍继续重试，以及上下文压缩失败后留下残余边界等问题。前者涉及失败请求如何停止，后者涉及长会话如何从压缩失败中恢复。这些是维护者公布的修复范围，不是对所有运行环境均已消除故障的独立验证结论。
自动化入口的信任边界并未因此消失
与这些行为变化一同进入版本的，还有对非交互运行风险的文档说明。同一标签下的安全文件明确表示：只有交互式终端界面会在加载工作区前询问是否信任；mimo run、mimo serve与mimo acp等入口会跳过这一提示，加载目标目录中的项目配置、指令、插件和MCP服务器。
这是一项既有行为的明确披露，而不是此次新增了工作区隔离。文档将mimo run定位为面向持续集成和脚本的无头运行方式：通常需要询问的权限请求会自动拒绝，但已有允许规则覆盖的动作仍会执行；启用--dangerously-skip-permissions后，没有被明确拒绝的请求会自动获批。
工作区信任与单次工具审批不是同一层保护。即使某次动作没有获得批准，也不能由此认定陌生仓库中的配置不会加载。安全文件还强调，权限系统不是沙箱；处理第三方拉取请求等不可信内容，应使用一次性容器、虚拟机或其他受限环境。
这一问题也出现在其他编程智能体的演进中。此前Qwen Code围绕项目钩子审批与非交互信任例外的更新表明，自动化系统选定一个目录，并不等于其中的可执行配置已经接受审查。不过，两款工具的授权机制不同，不能将一方的修复直接当作另一方已经具备的保护。
MiMo Code此次更新的共同方向，是减少依赖名称和默认值的隐式行为，让模型参数、搜索入口与工具模式更明确。对开发团队来说，升级后的关键仍是核对实际生效的配置、外部服务与执行权限，而不是把版本号变化本身视为能力或安全性的全面提升。