把 Agent 装进桌面，还是把桌面装进 Agent？
> 一个反直觉的观察：现在市面上的”桌面 Agent”，装配方式正好相反。
>
> 有的把 Agent 引擎塞进一个巨大的壳里；有的把壳套在一个原生引擎外面。前者开箱即用，后者可脚本化。这篇文章用两款桌面端（外加一台命令行）做样本，拆开它们的安装目录看个究竟——顺便回答一个更实际的问题：为什么有的 Agent 老来烦你要批准，有的几乎不打扰你？
>
> 取证方式：安装布局 + Electron 资源（app.asar）头部解包 + 配置与诊断输出。全是静态事实，不采信宣传口径。诚实起见：本文只做架构层对比，没有做同任务的实测（这点在文末会再强调一次）。
一、先说清楚三样东西
- MiMo Desktop（小米）：一个 Electron 桌面 GUI，闭源分发。它的特别之处是把小米自己的命令行 Agent（MiMoCode）当作本地引擎内嵌了进来，再包一层桌面 GUI、一批桌面专属工具（语音 / 图像 / Office / 桌面自动化）、一整套自带运行时，外加一个独立的 Python 自进化 harness（evolve）。
- MiMoCode（
mimo命令）：终端原生的 TUI Agent，MIT 开源，仓库在XiaomiMiMo/MiMo-Code。它就是上面那个被内嵌的引擎本体——不是从零写的，fork 自 OpenCode，保留了多 Provider、TUI、LSP、MCP、插件等内核，再叠加自己的模块。 - Reasonix Desktop：另一个 Electron 桌面 GUI，但它默认接的是 DeepSeek 系模型（npm 包
reasonix，MIT，自述 “Cache-first DeepSeek coding agent”）。它跟小米其实没有阵营对立——它的 provider 表里可以直接接入小米的 MiMo 模型。所以这不是”两家打架”，更像”同一台机器上两套可以互相调用的工具链”。
先给一句总纲：
> MiMo Desktop 是”把 Agent 装进桌面”——重壳、内嵌引擎、自带环境、押注自进化；Reasonix Desktop 是”把桌面装进 Agent”——薄壳、原生引擎、多套扩展机制、押注能力治理。
二、最直观的差异：重量
拆开安装目录，第一眼就是体量。
MiMo Desktop 是标准 Electron 打包产物，但”料”很足：
- 应用代码
app.asar≈ 96 MiB，摊开有 2000+ 个条目；主进程里还打包了一个 36.6 MB 的 Node bundle——这不是薄壳，是把整个引擎代码打进去了。 - 它自带一整套运行时：Node、完整的 CPython、qpdf、ripgrep，甚至还有一个
github-mcp-server可执行文件。还有onnxruntime-node（本地推理）和ten_vad.wasm（本地语音活动检测）。 - 桌面上还有一套 Windows 桌面自动化脚本（UI Automation + Win32 P/Invoke 的 PowerShell 运行时）。
Reasonix Desktop 的重心正好相反：
app.asar只有 ≈ 0.6 MB，Electron 真的只是个界面。- 真正的 Agent / CLI 逻辑在 两个原生二进制里：
reasonix-cli.exe≈ 69.6 MB、reasonix-desktop.exe≈ 67.7 MB，同目录、同版本号并列发布。npm 上那个reasonix包只是个下载转发器，不是引擎本体。 - 它不带运行时，依赖宿主环境。
一句话：
> MiMo 把引擎装进壳里；Reasonix 把壳套在引擎外。
代价和收益也一目了然：重壳换来的是零外部依赖、开箱即用、离线可跑，代价是安装包巨大、且闭源；薄壳换来的是同一套引擎同时服务命令行和图形界面，代价是依赖你的机器环境。
小米这一手还有个隐藏设计：桌面端和命令行共用同一套插件协议（@mimo-ai/plugin）和同一套项目目录形状——你在命令行里配的东西，桌面端认；反过来也大体成立。所以它俩不是”两个产品”，是”一个引擎的两种界面”。
三、三条根本分歧
1. 扩展哲学：围墙，还是兼容
这是两款产品价值观差异最大的地方。
MiMo Desktop 走的是”封闭治理”：扩展机制基本只有一套（@mimo-ai/plugin 的 Hook API + skills），而且它显式屏蔽其他 Agent 生态的技能目录——在引擎代码里，~/.claude/skills、~/.codex/skills、~/.agents/skills、~/.opencode/skills 这些路径被明确标注为”不被 MiMo Desktop 扫描或加载”。它只认自己的技能根和内置技能。
Reasonix Desktop 走的是”开放兼容”：Skills（四级作用域 + shadow 覆盖规则）、Commands（斜杠模板）、Hooks（11 个事件）、MCP、插件包（三种 manifest 格式）——五套机制。更关键的是，它主动读取 .claude、.agents 这类约定目录，连 Claude、Codex 的插件清单都兼容。
有意思的是，”MiMo 也不扫 ~/.opencode/skills“这件事——它自己的引擎就是从 OpenCode fork 来的。它一边继承血统，一边把血统的生态入口关掉。
2. 变强路径：自主进化，还是能力沉淀
MiMo 押注的是 evolve——一个随桌面端分发的 Python “自进化 harness”，里面有仿生脑区（丘脑、前额叶、杏仁核、神经调质…）、一个叫 micro_llm 的机制（让同一个基础模型在不同调用里扮演注意力 / 情绪 / 记忆 / 反省），还有”进化树”和”超我”元监督。它的 README 开头是一句宣言：“模型越强，越应把决策权交给模型”。
它自己的成长史里有个细节挺狠：早期 Agent 曾连续输出”不动”30 多步，于是团队造了一套防御系统，最后自删了 22000 行防御框架，结论是”加机制 ≠ 变强“。
Reasonix 不做自主进化，它的重点在可解释的能力加载与静态诊断——谁覆盖了谁、为什么某个技能没加载、给出 issue code 和修复建议。它的自省是”诊断式”的，不是”进化式”的。
MiMoCode 在两者之间：/dream（7 天知识沉淀）+ /distill（30 天把重复流程固化成 skill / subagent）——产品化、轻量、可控。
3. 分发：自带环境，还是依赖宿主
上面第二节已经说了，不重复。只补一句：这决定了它们卖给谁——自带环境的重壳，卖的是”不想折腾环境的人”；依赖宿主的薄壳，卖的是”想把它嵌进自己工作流的人”。
四、体感才是读数：治理的摩擦力
架构是骨架，体感是血肉。同一台机器上连用下来的感受很直白：
> MiMo 需要批准的事情少；Reasonix 屁大个事都要批准，还动不动就限制模型预算。
这不是错觉，翻开配置能看到结构性的原因：
- Reasonix 有一套命令级白名单（每条被批准过的命令都精确记在项目配置里）、一个
tool_approval_mode = ask的默认开关、工作区租约（workspace-lease）和任务锁（task.lock），外加一整个[billing]计费 / 预算段。它的 Hooks 里还有两个事件（PreToolUse、UserPromptSubmit）可以用退出码 2 直接阻塞主循环——也就是”我不同意，你就别往下走”。 - MiMo 当然也有工具审批，但没有把”每一步都要契约背书”做成一等公民。
我的解读是：这不是 bug，是哲学的投影。
把两边的宣言并排看就很清楚——
- MiMo 信的是：”模型越强，越应把决策权交给模型” → 所以少打断、少限制。
- Reasonix 信的是：”能力必须可加载、可审计、可解释” → 所以多审批、多约束。
> 一个信模型，一个信契约。
而在模型能力正在快速上涨的当下，这里藏着一笔容易被忽略的账——摩擦税：
> 治理不是免费的。契约化治理的成本 = 打断次数 × 预算约束 × 上下文中断损耗。当模型越来越靠谱，“每步都问一遍”的边际收益在下降，边际成本（打断、丢上下文、预算卡死）却在上升。
换句话说，审批强度如果不随模型能力动态调整，就是一种刻舟求剑。真正该做的不是”要不要治理”，而是”治理的粒度能不能跟着能力一起变“。这条思路在 Agent 工程里有个名字，叫渐进放权（Progressive Trust）——能力没到就收紧，能力到了就松开。固定不变的治理强度，要么把强模型管死，要么在弱模型上形同虚设。
顺便说一句，”动不动限制模型预算”这半句，本质是把成本控制做成了体验约束：省的是厂商的 token 账单，花的是用户的耐心。这在模型还很贵的时候是合理的，但它会在价格战里第一个站不住脚。
五、这件事更大的信号
把视角拉远一点，这组对比至少说明三件事：
1. 桌面 Agent 的竞争，本质是 Harness 的竞争。
现在连评测都证明了：同一套模型，换一个 Agent 壳，结果能差到让排名逆转（我们之前追踪过的多轮横评里，约 27% 的题目结果完全由 Agent 决定）。当模型被拉平，”怎么组织模型干活”就是新的护城河。
2. “围墙 vs 兼容”是一次战略押注。
MiMo 屏蔽外部技能根，是想把用户圈进自己的生态；Reasonix 兼容 Claude / Codex 资产，是想成为”能接住别人东西的那个”。当前更接近行业直觉的是后者——MCP 正在变成软件的新 USB 口，谁先被 Agent 生态接上，谁吃红利。自建围墙在短期能锁定用户，长期却可能被”更好的兼容者”绕过去。
3. “加机制 ≠ 变强”这句自白，值得所有 Agent 团队打印出来。
MiMo 的 evolve 删掉 22000 行防御代码，和”治理应该渐进放权”是同一枚硬币的两面：机制的堆叠有边际递减，而信任的建立需要方向正确的减法。 这跟我们一直说的那条判断——”机制是乐器，模型是乐手”——是通的：机制恒定，真正决定表现的是执行力和临场方法。
六、诚实标注：这次没做的事
把话说全，免得被当成软文：
- 只做了静态架构与配置层对比，没有做三方的功能对等实测。 同一任务在三处的耗时、成功率、返工率，本文一个数字都没给。体验部分（批准摩擦、预算限制）来自实际使用，但是单机、单人的体感，不是统计。
- Reasonix 的
app.asar没有逐行解包，主进程逻辑、前端框架只从产物命名推断。 - 桌面端是否捆绑了完整的命令行引擎，未做确证（只确认了它生成引擎配置、并共用同一套插件协议）。
- 不同任务上的表现可能完全不同——这也正是”实测意义有限”的原因：没有一个数字能代表所有负载。
收尾
如果只用一句话概括这组对比：
> 桌面 Agent 的两条路线，一条向外长能力，一条向内做治理。而它们真正的分歧，不在壳的厚薄，在”你到底信不信模型”——以及，你愿不愿意让这份信任跟着模型一起长大。
壳可以重可以薄，生态可以开可以闭，这些都是选择。但有一件事不该是选择：当模型变强的时候，你的治理得跟着松开。 否则你不是在管理 Agent，你只是在给它上脚镣，还要它跑得快。
本文为独立技术观察。架构事实来自安装目录解包与配置比对；体验判断来自实际使用，属主观读数。欢迎带着你自己的样本反驳。