Mu

mu：只给任务最需要的东西 μ · Only what's needed. mu 是一套开箱即用的桌面端 Harness，也有命令行版。它让一个小而快的判定模型 Jev 站在中间，替大模型做掉每一轮里几百个和代码无关的小决定：上下文里留什么，几个代理之间传什么，进展怎么讲给人听，哪条经验该记、该用、该退役。这篇介绍讲它为什么存在、怎么工作，以及我在真实使用里修掉的那些问题。 为什么做 mu 做 mu 之前，我一直在用别的编码代理干活。模型一代比一代强，可有四件事，一直让我坐不住。 上下文越塞越满。 我明明只是想写一个方案，每次开口，却要带着一大堆工具说明一起上路。跑一次测试，几千行日志原样灌进去，真正失败的那几行，被同一段报错刷了几十遍。花掉的是钱和速度，还有模型本该留给正事的注意力。 我越来越看不懂它在说什么. 模型干活越来越强，汇报进展的话却越写越像给机器看的，术语一层叠一层。任务跑完，我只知道它说「做完了」，却不知道它到底做了什么。 几个代理一起干活，它们不会说话。要么谁也不告诉谁，几个代理各自走进同一条死路；要么什么都往外倒，每一个的上下文里全是别人的聊天记录。 同一个坑，踩第二遍。今天纠正过的事，明天换个会话它又犯。写进记忆文件的规矩越积越多，重复的、互相矛盾的、早就没人照做的堆在一起，最后自己也成了上下文里的噪音。 后来我看到 Jev 在各个领域大放异彩。Jev 是一个小而快的判定模型：不写代码，也不聊天，只回答有边界的小问题，是非题、选择题、打分题，每个答案都带一个概率。我慢慢意识到，上面这四件事，底下其实是同一个问题：每一轮里都有几百个小决定，没有人认真做。交给大模型，太贵、太慢，还分它的心；交给死规则，又错得太多。 那能不能用 Jev 做一个原生的 Harness，从第一行开始，就让判定站在中间？ 于是有了 mu。它基于开源编码代理 pi，有命令行，也有一个开箱即用的桌面端。 mu 把那几百个小决定，拆成分布在一轮对话各个环节的 35 个判定点。比如： - 你说话时：这是新任务、追问，还是在纠正它？这件事用得上哪些技能和工具？用不到的技能和 MCP 服务器（给模型接外部工具的服务）不进上下文，需要时才打开。代理正在干活时你插了一句，要立刻打断，还是等它做完这一步？ - 工具返回时：一段很长的输出，逐块判断哪块现在有用。有用的进上下文，其余归档，只留一个指针。 - 上下文变长时：哪些旧结果已经过期，直接放下，不写摘要；你会不会在提示缓存过期前回来，值不值得续一次。 - 动手之前：这条命令是不是你要的，有没有越过你定下的约束。 - 一轮结束时：说做完了，有没有东西验证过；中途有没有跑偏；同一个失败一再出现，是不是该退回检查点。 蜂群：让 Jev 站在代理之间 遇到困难的大任务，一个代理不够，就派几个一起查。这件事我试过很多次，最难的从来不是派活，是它们之间怎么交流。 我调研了一圈现有的多代理系统。对「一个代理知道的，要不要告诉另一个」这个问题，它们的回答大致只有四种：什么都不传，只向主代理汇报；什么都传，群聊，或者交接时带上全部历史；让每个代理自己的大模型决定发什么；或者靠固定的角色订阅、共享文件。前两种一个太少、一个太多；第三种让每个干活的模型分心去当邮差；第四种太死板，不看内容。在我看过的这些系统里，没有一个用便宜、快速、专门的判定器来当这道闸门。而这正好是 Jev 最擅长的事。 三道闸门 mu 的蜂群由 2 到 6 只「蜂」组成。每只蜂是一个子代理，各有自己的关注点。它们读代码、跑命令、开浏览器，但**从不改代码**，改动由主模型来做，所以几只蜂可以放心并行，不会互相踩文件。 蜂和蜂之间不直接说话，中间隔着一块只增不删的共享板，和三道 Jev 闸门： | 闸门 | Jev 回答的问题 | 结果 | | --- | --- | --- | | 发布 `hive.publish` | 这只蜂刚说的这段话里，有没有值得共享的发现、死路、决定或阻塞？ | 值得的原文上板，其余留在它自己那里 | | 送达 `hive.deliver` | 板上这条新笔记，和另一只蜂的关注点有关吗？（每只蜂各问一次） | 有关才送过去，并标明「这是发现，不是指令」 | | 关联 `hive.relate` | 这条新发现，推翻、矛盾，还是支持了早先的某一条？ | 推翻的变成纠正，送给拿着旧结论的蜂；矛盾的两条都留着，标成争议 | 第三道闸门是后来加的，来自一次真实运行。一只蜂先报告「测试跑不起来」；过了一会儿，它清掉一个继承下来的环境变量，测试就跑通了。可板是只增不删的，那条「跑不起来」一直留在上面，别的蜂还拿着它做判断。 现在，被推翻的结论会变成一条纠正，送到每一只拿着旧结论的蜂那里；互相矛盾的两条都保留，标成争议，一分钟内没人解决，就派一只核实蜂去查。Jev 从不判断谁对谁错，它只回答「后一条对前一条说了什么」；谁对，由核实蜂去跑、去看。 人话看板：干活和讲话，分给两个模型 人话看板来自开头的第二个问题。 大模型一代代迭代下来，干活越来越强，说话却越来越「黑化」，越来越不说人话：汇报进展的话越写越像给机器看的，术语一层叠一层。这不是某一个模型的问题，更像是一个趋势。好在还有一些模型，说话一直像人。 我试过让干活的模型自己汇报，得到的是另一段需要翻译的话。说实话，那种汇报我自己都读不下去。后来我想明白了：干活和讲话，本来就不该是同一个模型的事。 而 Jev，正好是把两者分开的那把钥匙。 现在 mu 里是这样分工的： 干活的模型照旧用它自己的语言干活，一个字也不用为看板多写。 规则先当场记一笔：代理每做完一步，看板上立刻多一行人话，改了哪个文件、检查过没过、运行了什么命令；连着读了一串文件，就折成一行「看了 6 个文件」。这样的固定句式有 22 种，13 种语言都有，不花一次模型调用。 Jev 在旁边看着：代理中途每说一段话，Jev 用一道选择题判一次，这是要紧的新消息、例行公事，还是说不准。 讲人话的模型只在 Jev 说「这是新消息」时才被叫来，把这段话当场重讲给人听，顺便更新现状：现在在做什么，清单上几件事做完了几件，有什么在等你。它是专门因为说人话而选出来的，比如 Claude Opus 4.6，用 /board model 随时可以换。 讲人话的模型写的字只给人看，从不进干活模型的上下文。开着看板，干活的模型一个 token 也不多花。 从「做完了」到「它做了什么」 看板的第一版不是这样的。那时它更像一块状态牌：每隔 5 次工具调用或者 20 秒刷新一次，结束时再总结一次。结果是，模型那边做完了，看板上就显示一句「做完了」，中间到底发生了什么，一概不知。 这正是我最受不了的地方：看板应该一直跟着更新，而不是等模型做完了，那边才冒出一句「做完了」。所以整块推倒重来，改成一本流水账：每一步当场一行，每一段要紧的话当场重讲；一次运行结束时的总结，只是流水的最后一行，过程全留在上面。 前两行是规则当场写的，最后一行是讲人话的模型写的。 看板也跟着代理的其它动作走：弹出权限请求时，它立刻告诉你代理在等你确认；目标模式自动续跑时，它接着记；派出子代理时，它会说「派了几个助手分头干，在等它们回来」；代理遇到麻烦，比如同一个错一再出现，它也当场说。