给编码Agent请个裁判：它把每次会话的几百个决定交给一个小模型

现在用 AI 写代码，工具越做越像同一批人做出来的：会读文件、会跑命令、会改代码，你就盯着它在终端里一路往下干。差别越来越不在”会不会干活”，而在另一个没人聊的问题——它每一轮到底替你做了哪些跟代码没关系的判断？

工具输出一屏接一屏，哪一段该留在上下文里？一条命令看着危险，要不要先停下来问你？任务说到一半它说”做完了”，这个”完了”有东西验证过吗？跟代码没一点点关系，但每次会话要来几百遍。交给大模型，烧的是 token 和等待；交给写死的规则，错得太多。GitHub 上最近有个叫 mu 的项目，把手伸进这个没人管的地带：它专门养了一个小小的”判定模型”，每次只回答一个有边界的是非题，答案还带概率。仓库地址在文末。

下面先把 mu 跟几个同类放一起看，再说它到底是什么、怎么用，最后聊它能落在哪些日常场景里。

先看它跟谁是一类

mu 属于”编码 Agent”这一拨——就是能在命令行里读文件、跑命令、写代码，跟你多轮对话干活的 AI 助手，常见的是 Claude Code、Codex CLI 这类。先给张表看个大概，每个都点一句白话：

工具	主要在哪个终端里用	需不需要装东西	最扎眼的点	简评
Claude Code	命令行	装 Node，登录 Claude 账号	直接对接 Claude 的模型，口碑最响	上手顺，能拿来干正事，但决定权都在大模型手里
Codex CLI	命令行	OpenAI 的 CLI 工具	OpenAI 官方出的，接自家的模型	跟 Claude Code 同类，选人话看板不如 mu 讲究
mu	命令行 + 桌面端	npm 装一个包，或下原生桌面端	每一轮单独用一个”判定模型”管非代码决定	新鲜点就在这个裁判，别的都像在给干活的大模型减负
pi	命令行	装 Node	极简的编码 Agent，mu 就是从它改出来的	它把核心做小，mu 在这上面加了判定内核

这张表不构成谁赢谁输的结论。mu 还是个预发布（0.1.x），作者在 README 里明说”名字、设置和格式都可能变”，说它”早期开发”。对这拨工具，性价比的账要等它出稳定版才算得清楚。

mu 到底是什么

概括起来：mu 是一个带”判定内核”的编码 Agent，跑在 pi 之上，装完就能在你电脑的命令行里帮你干活。 它不重新发明”怎么读写代码”，而是在每次会话里，把成千上万个跟代码无关的小决定——哪段输出进上下文、哪条命令先问你、活干完没有——单独拎出来，交给一个又小又快的模型来答。

看仓库里实际有什么，就懂这个定位了：

• packages/（一堆包）——agent、ai、coding-agent、kyrn-judge，核心代码都在这里；
• desktop/——原生桌面端的源码；
• docs/——README 和文档；
• .pi/——扩展、技能、提示词那套配置层。

mu 不是模板，是能直接跑的东西。命令行版和桌面版都有，桌面版还自带运行时。

它怎么用

两种走法，看你要多省事。

命令行版，装一个 npm 包就能起会话，需要 Node 22.19 或更新：

npm i -g mu-agent
mu          # 在当前目录开一个交互会话
mu doctor   # 检查安装、判定模型和各项连接

桌面版更省事：它是一个原生应用，mu 和运行时都打包在里面——不用装 Node，第一次启动也不下载任何东西。下下来，接一个模型（ChatGPT、Claude、Grok、Google 的订阅，或任意 pi 支持的 API 密钥）就能开始。它比命令行多一块对话旁边的工作面板：看板、判定流水、蜂群、经验、文件、预览、源码、内置浏览器。

它到底在管什么：35 个判定点

mu 把这件事落成了一个具体的数字：每一轮有 35 个判定点。每个判定点都是一道关于一小段状态的短问题，答案只决定”模型接下来做什么”，从不决定”要不要问你”。

举几个仓库里写得很直白的例子：

• input.preflight——这条消息是什么类型，需要多深的思考？给模型一行提示，顺带定这轮的思考级别。
• tool.admission——一段很长的工具输出，一块一块地判：这一块现在重要吗？重要的进上下文，不重要的归档，只留一个指针。
• tool.risk——一条被规则标记出来的命令：你这是真要跑吗？拿不准就问你。
• turn.completion——模型说”做完了”：到底有什么东西验证过？没有就提醒一次。
• context.compact——上下文变长了，这一段留还是删？按判定压缩，不写摘要。
• memory.capture——这条消息是在纠正你，还是在立一条规矩？后者就变成一条经验。
• swarm.routing——这个派出去的活，用哪个角色、哪一档模型、多深的思考？判给合适的子代理。

规则是底线。README 原文写着：“看起来危险的命令先由规则拦下，判定器只负责确认这是你要的。“也就是说，安全这道闸门是硬规则在守，判定模型只负责在规则没拦的地方帮你拿主意。

每个判定点有两种工作方式之外的选择：

• active —— 生效，真的改变行为；
• shadow —— 照常提问并记录，但不改变任何行为，专门用来在切换前对比两个判定器哪个靠谱；
• off —— 干脆关掉。

每个判定点还能指定自己的”裁判”：jev（云端）、laya（本地）、llm:<提供商>/<模型>（任意一个大模型），或 laya,jev 这种级联。你可以让”危险命令确认”用本地模型、让”上下文精简”用云端 Jev。

那个”裁判”：Jev 和 Laya

mu 默认带的判定器叫 Jev，跑在云端。README 描述它是”有边界的问题，答案带概率”。作者自己会话里实测：HTTP/2 上一个热连接的问题大约 0.3 秒；16 块工具输出并成一个请求一起判完 0.44 秒，状态只计费一次。整个研究里 282 次真实 Jev 请求，按标价大约 $0.017；用默认问法，单次请求中位耗时 345 毫秒。每一次判定、概率和耗时都进流水，mu ledger 能看到。

还有个本地选项 Laya：一个 3.22 亿参数的判定器，跑在你自己的机器上，不走网络。README 强调，未经你同意不下载任何东西。它”在简单谓词上可靠，元判断上偏弱”——所以作者建议先让它以影子模式和 Jev 并行跑，看过流水再把判定点交给它。

判定的成本意识也写着：大模型很贵，小模型便宜、快，适合含几十上百个点的每一轮。把”要不要""哪一段""做完没”这种高频低难度的决定交出去，大模型的注意力就省下来干正事。

一个具体的账：测试日志能被砍掉一半多

对干测试的人，mu 最扎眼的一个数字在”测试日志精简”上。失败的测试跑一次，常常给每个失败的测试各打印一遍同样的 diff、DOM dump 或堆栈。mu 的做法是：保留第一份，之后的每一份换成一行，写明它重复的是哪几行，不调用任何模型，标记展开后逐字节等于原文。

仓库自带的真实数据（来自作者会话里 7 份 Vitest 失败日志，共 139,820 字符）：折叠完全重复后，最大的 5 份分别少了 86%、44%、44%、47%、16%，最小的 2 份原样保留，合计 51%。一次 338 行的失败运行，滚动过去后模型读到的只有 135 行，7,686 字符变成 4,262 字符，没调一次模型。

更讲究的是”按目标挑选”。用详细 reporter 时，该留什么取决于你问的是什么：调试失败时，通过的测试是噪音；问哪些测试跑过时，它们就是证据。Jev 在一个请求里对每一块通过记录、每一块测试输出各问一次：目标还需要它吗？只有 Jev 给”不需要”的概率到 0.9 或以上，这一块才会省掉。研究数据：调整用的 29 个目标上，Jev 省 40.2%，72 条必要证据一条没丢；只留失败的过滤器省了 61.9%，却丢了 9 条——省得多，但伤了证据。

作者对这批数字很克制。README 明说这些数字”不代表什么”：它们度量的是什么进了模型、丢了什么，不是模型之后能不能把任务做完；重复段只来自一位开发者两天的 15 份测试日志，全是 Vitest，其他运行器没测过；也还没有在同一批任务上和 pi、Claude Code、Codex 做端到端对比。这个”不吹”挺难得——它把自己的局限一条条摆出来，而不是只晒省了多少。

那个”人话看板”：别让干活的模型自己汇报

mu 还留意到一个越来越普遍的现象：大模型干活越来越强，汇报却越来越黑，术语堆叠，越来越不说人话。mu 的选择是——不让干活的模型自己汇报。打开看板后（命令行 /board，或桌面端看板页开关），代理每做完一步，看板上立刻多一行人话：改了哪个文件、检查过没过、运行了什么命令，连着读文件就折成一行”看了 N 个文件”。

关键在这：代理干活中途每说一段话，board.read 判定器判一次这是不是新消息；是，就由一个只因为说人话而选出来的模型（/board model 可换）当场重讲给人听。干活的模型照旧用它自己的语言干活，看板上的字始终是人一眼读得懂的。

蜂群：多代理之间，判定器当闸门

多代理系统绕不开同一个问题：一个代理知道的，要不要告诉另一个？常见答案要么什么都不传、要么全传、要么靠每个代理自己的大模型拿主意。mu 的答案是把判定器当闸门。

一个蜂群是 2 到 6 只 bee，各有各的关注点。bee 读代码、跑命令、开浏览器，从不改代码，改动由主模型来做。每只 bee 说完一段，hive.publish 问一次：这里有值得共享的发现、死路、决定或阻塞吗？值得的上到一块只增不删的共享板。板上每来一条新笔记，hive.deliver 对每只别的 bee 各问一次：这和你的关注点有关吗？有关就投递过去，标着”这是发现，不是指令”。

因为板只增不删，后来的结论会推翻早先的。hive.relate 读两条笔记之间的关系：推翻、矛盾、还是支持。被推翻的结论变成纠错，送给每只拿着旧结论的 bee；互相矛盾的两条都留着，标成争议，一分钟内没人解决就派一只核查 bee 去查。README 记了一次真实的运行：3 只 bee，9 分钟，评了 117 条候选，27 条上板，16 条投递到需要它的 bee 那里。

会怎么用上它

mu 的”判定内核”思路，放到几个日常场景里其实是同一件事：把高频、低难度、却容易烧钱烧时间的小决定，从大模型手里分出去，交给又快又便宜的小模型，并让这些决定可回查。

对干测试的人，最有看头的是测试日志那套。CI 一跑失败，几千行的失败日志能吞掉大半个上下文，调试时最烦的就是在重复的 diff 里翻找。“完全重复只留一份、按目标挑选证据”这两招，直接对着测试场景最痛的噪声下手。把”目标还需要这一段吗”变成每次判定点，等于给测试日志的上报装了道过滤器——省的字符是实打实的，记号展开还逐字节等于原文，证据没丢。

对日常用 AI 写代码的人，那个”记录每一次判定、都能翻到”的设计值回票价。现在多数编码 Agent 是结果导向的：bad，只有”做完了”和”没做完”。mu 把”活干完没""这一步在不在目标上”这种判断都留了账，事后想知道它为什么这么走、走了哪条路，有据可查。

对把 AI 放进团队流程的人，“人话看板 + 讲人话的汇报模型”是个该搭的场景。让干活的和汇报的分开，一个干、一个讲，项目进展不用人从一堆技术输出里猜。蜂群那套”发现 vs 指令”的投递，也能迁到团队协作的设计里：共享的信息标清楚这是发现不是结论，争议先留出来查清楚再定，而不是谁嗓门大听谁的。

mu 值不值得你上手，取决于你认不认那个起点：每次会话里那几百个跟代码无关的决定，值得单独找一个又快又小、带概率的模型来管，并让它们都可以回看。 认，这个预发布项目值得你装一个跑两天看看；不认，它的取舍也算摆在明面上，省了你的时间。

仓库地址：https://github.com/qybaihe/mu

#AI编程 #编码Agent #开源项目 #mu #pi #上下文管理 #测试开发