拿到小米 MiMo 桌面版内测资格后，我把它拆开接了 27 个用例

我没把它当聊天窗口用，而是直接拆它的本地接口、接进自己的 Agent 体系，跑了一整天硬测试。结论：安全做得比预期扎实，产物能力是真的补位，但有 5 个坑必须提前知道。

先说结论

维度	结论
本地 API 安全	13 条用例全过（Host 校验、路径穿越防护、令牌校验都在）
引擎性能	TTFT 661ms；37.5k tokens 上下文 2.11s
4 小时长稳	可用率 97.9%，延迟 p50 2.28s / p95 22.7s
真正值钱的	Office 产物（Word/PPT/Excel/PDF）+ 图像 + 语音，一条链路全出
最大的坑	bash 工具会挂死不返回，整个会话被锁死，只能人工中断

内测版本：26.912.121036。以下结论只对这一个版本负责。

一、先搞清楚能测什么

它其实是两个通道叠在一起：

通道	地址	能力
Desktop API	127.0.0.1:59634/v1	health / sessions / messages / events(SSE) / turns / files
引擎（LLM）	127.0.0.1:4096/v1	OpenAI 兼容，models + chat/completions（含流式）

两个端口同属一个进程 —— 这点很重要，后面第 5 个坑就是它。

二、安全与契约：13/13 全过

这是最超出预期的一块。我把能想到的坏心思都试了一遍：

用例	结果
错误令牌 / 无令牌	401
伪造 Host 头	403 forbidden-host
会话 ID 路径穿越（..%2F..%2Fetc）	404（白名单拦截）
文件读取穿越（?u=../../../密钥文件）	403
未知路由 / 不存在的会话	404

令牌用常量时间比较、Host + 端口绑定、sessionId 白名单、文件读取走 realpath 前缀校验 —— 四道防线都在。本地 API 能被浏览器里的任意脚本盲打，它把这个前提考虑进去了，值得表扬。

三、引擎性能：比预期快，但有个隐藏排队

• 基础问答：819ms（prompt 15 / completion 26 tokens）
• 流式首字节：661ms
• 长上下文：7.5k tokens → 1.57s；37.5k tokens → 2.11s（线性良好，没衰减）
• function calling：可用，一次命中正确参数

但并发 3 路时，墙钟 ≈ 最慢那一路（2974ms） —— 说明请求实际是串行排队的。单机自用没感觉，多 Agent 同时打就会有排队延迟。

四、真正值钱的是”产物能力”

我们自己的工具链缺一块：生成能直接打开的 Office 文件。它正好补上，而且补得很整。

我给它一条指令 —— “把我们这一周的日志整理成周报” —— 它自己读素材、写生成脚本、产出四件：

产物	实测
Word 周报	37.5KB，样式 Title/Heading1/ListBullet 齐全，页脚含 PAGE 域
PPT	7 页（要求 ≤8），封面 + 四段 + 数据页
封面图	1536×1024 PNG，提示词要素全中，无水印外的瑕疵
语音摘要	PCM 24kHz / 16bit / 单声道，3 分钟出，无需转码直接可用

全流程 7 分 55 秒，而且内容带出处引用（每条标了来自哪份日志）——这说明它真读了素材，不是编的。

它还支持 MCP（配置文件里 mcp 段声明 local/remote 服务），意味着你可以把自建工具挂给它当原生工具用。

五、5 个坑（按恶心程度排序）

① bash 工具会挂死不返回 —— 最致命
让 agent 执行一句 New-Item -ItemType Directory（创建目录），工具状态永远停在 running，回合再也不推进。我这边两个会话分别挂了 11.5 小时和 12.7 小时，只能人工中断。
更糟的是：依赖目录创建的后续写入会静默换位置——产物被写进项目根目录而不是指定子目录，你根本不知道。

② 标题生成走云端，返回 401
所有会话标题都退化成”截取你第一句话”。查日志发现：标题子代理直连云端 api.xiaomimimo.com 拿 401 Invalid API Key，而本地引擎是好的 —— 说明内部小任务绕过了带鉴权的本地代理。

③ max_tokens 给小了，会返回”成功但空回复”
max_tokens=16 时 HTTP 200、content 为空、finish_reason=length —— 推理内容把预算吃光了。
这个坑不止它一家：我拿 DeepSeek 的 API 复现了同样现象（reasoning_tokens 把 completion 额度吃满，正文返回空）。接任何推理型模型，预算都要给足。

④ /v1 兼容层缺常用参数
response_format、n、logprobs、verbosity 一律 400 —— 意味着没有 JSON 模式，结构化输出只能靠提示词硬凑。

⑤ 引擎绑死客户端生命周期
关掉客户端 = 两个端口直接消失 = 依赖它的上游立刻断。要接进生产链路，必须做熔断和降级。

六、方法论：把”测试”做成能复现的东西

这次我没写一堆结论了事，而是留了一套可复现的测试台：

• 27 条用例脚本（安全/契约、引擎边界、集成），一条命令全跑
• 4 小时长稳压测脚本：每 5 分钟一拍，记录延迟、断连、错误类型
• 音频结构分析器：不靠听感，用能量包络 + 音节速率就能判定”是 TTS 漏播还是 ASR 漏听”

最后这条挺有用：当时 ASR 转出来少了一句，看着像漏听。用包络一算，音频里只有 9 个音节爆发，而 17 个音节的原文塞进 3 秒需要 5.6 音节/秒 —— 超出正常语速。结论是原文压根没念那一句，ASR 是对的。

测试的价值不在于”我测过了”，而在于结论能被别人拿同样的命令推翻或复现。

收束

内测产品的正确用法，不是当第二个聊天窗口，而是当能力供给：它的 Office 产物、图像、语音是我们缺的，那就接过来做流水线；它的引擎绑客户端生命周期、没有 JSON 模式，那就别把它放进生产主链路。

一句话：能用，但要按它的形状用它。

---

测试环境：Windows 10.0.26200 / 客户端 26.912.121036（内测版）/ 纯 CPU 32GB。文中数据均为实测，含 27 条用例、4 小时长稳与多模态验收。