MiniMax开源协作工具：开完会，谁来验收？

开源观察 · MiniMax Code · 2026年11月5日

几个AI讨论完，齐刷刷地说“完成了”。你的文件，可能还停在原地。

这不是一句泛泛的担忧。我们把MiniMax Code公开的协作工具跑了一遍：同一项任务，只改变验收者看什么，就能得到两种截然不同的结果。

直接检查实际文件，错误会被判失败；只核对执行者交来的回执，文件明明没改对，系统照样可以记成“验收通过”。

这次最有价值的发现是：把执行和验收分开，是第一步；让验收者真正看见结果，才是第二步。

01｜这张“桌子”，让谁和谁一起工作？

项目叫mcode-agent-table，公开的是“自带机器人”协作协议（BYOB）0.1和一套可运行的参考实现。意思很直白：带上你自己的机器人来开会。

普通的多智能体系统，往往由一个平台安排几个角色：一个写方案，一个挑毛病，一个做总结。这里换了个出发点：每个人都有自己的助手，助手使用各自主人的模型、工作环境和权限，再到同一张桌子上协作。

比如，产品负责人的助手认为应该先修客户问题；研发负责人的助手更关心周五发布。它们可以讨论，但讨论得再热闹，也不等于其中一个就能替另一个主人修改任务看板。

这张桌子主要提供四样东西：共享记录、参与席位、发言规则和任务交接。它不负责让模型变聪明，而是给合作建立可追踪的秩序。

时间线上，MiniMax的官方GitHub仓库创建于11月3日；11月4日的提交加入Rabbit Hole小应用及相关展示，随后补充界面截图。本文查看的是11月4日的固定代码版本。

02｜讨论、批准、执行、验收，分成四件事

它把协作拆得很清楚：先提出行动；需要时，由受影响资源的主人签字批准；再由这个主人的助手去执行；最后，换另一个席位检查结果。

“需要时”很重要。规范允许主人预先签署特定动作的自动批准规则，不是每一件小事都必须弹一次确认。授权范围由主人设定，而不是让讨论中的机器人自行扩大。

另一个关键区别是：执行者交回结果后，任务先进入“已报告”，并不会立刻变成“已验收”。执行者也不能给自己的回执盖章通过。

你可以把它理解成一次普通的工作交接：方案通过，不等于活已经干了；活干了，不等于别人已经确认合格。会议纪要和交付结果，终于不再混成同一个“完成”。

图1｜项目作者提供的示例界面，裁取右侧任务面板，便于阅读签署、回执和验收记录。图中内容是项目演示数据，不是下文的独立实验。

03｜我们给它出了三道很小、但很具体的题

核心任务非常简单：把一个真实任务文件里的“客户问题”，从第二位移到第一位。提出任务、拥有文件和检查结果，由三个不同的主人及其席位分别承担。

先跑项目自带检查，61项测试通过，离线示例也走到了验收通过。接着，我们另写了三组对照，让协作真的经过接口、签字、文件读写和记录恢复，而不是只看界面上的绿灯。

第一组：事情做对了，验收能通过

主人批准前，文件保持原样，提前报告“开始执行”的请求被拒绝。批准后，执行席位把客户问题移到第一位，再交回回执。

此时任务只是“已报告”。执行席位尝试自行验收，同样被拒绝。另一个席位打开实际文件，确认顺序正确，再提交通过，任务才变成“已验收”。

这一组说明，在这套需要主人批准的设置下，批准、执行和验收之间确实存在可观察的关卡，不只是给同一句“完成了”换几个名字。

第二组：回执写对了，事情没做对

我们保留相同的提议和批准流程，但让实际文件维持旧顺序。执行席位提交的回执，仍然声称客户问题已经排到第一位。

验收席位不听它怎么说，直接打开文件。结果不符，提交失败，任务最终被记为“失败”。

这才是验收真正帮上忙的地方：它拿到的是另一条结果证据，而不只是另一段更像评语的话。

第三组：换了验收者，却只让它看回执

实际文件仍然没有改对，回执仍然声称成功。唯一变化是：这次验收席位只比较回执里的顺序，不再读取实际文件。

结果，任务被记成了“已验收”。

这不是绕过了签字，也不是执行者给自己放行。角色分离照常存在，只是验收者检查的对象错了。桌子能确认“另一个席位提交了通过”，却不会自动知道业务世界里到底发生了什么。

三组结果：
文件正确＋读取文件验收：通过。
文件错误＋读取文件验收：失败。
文件错误＋只看回执验收：通过。

三组记录重新加载后，也分别保持这些状态。它忠实保存了验收者给出的判断；这个判断是否可靠，仍取决于验收者掌握什么证据。

这三组使用确定性脚本驱动的席位和任务文件，回答的是协作流程如何运行，不是不同模型谁更聪明。主人签署也由实验脚本完成，不能据此推断真人操作界面的体验。

04｜对真正用智能体干活的人，有什么用？

第一，别把“多叫一个AI评审”当作验收方案。改文件，就让验收者读文件；生成报表，就让它核对数据和产物；调整任务顺序，就让它重新打开任务列表。

第二，把“讨论结束”和“工作完成”拆开。本次对照里，桌子在形成决定后就结束了讨论，但批准、执行、验收仍能继续。现实团队也一样：会可以先散，任务不能跟着自动结案。

第三，先明确谁拥有资源，再考虑怎么让助手合作。不同人的助手，不必为了协作就把所有账号和权限塞进一个共同的大机器人。这个工具展示的是另一条组织方式：共享讨论，保留各自的执行责任。

如果你只是想让一个助手润色文字，多搭一张桌子未必划算。如果你已经在协调多个负责人、多个助手和需要确认的外部动作，这种把责任写进流程的设计，才更值得研究。

05｜现在拿得到什么，接下来该看什么？

当前仓库提供协议、参考服务、客户端、命令行工具和供智能体接入的工具桥，也有Rabbit Hole小应用。项目采用MIT许可证，离线脚本示例可以不调用模型运行。

按官方路线图，跨主机的桌子互联、多主人共同批准一项提议，以及投票和法定人数机制仍是后续工作。稳定的上下文前缀是它的设计之一，作者也明确说，提示缓存的命中收益尚未测量。

因此，下一步最值得看的是实际应用：验收席位能否稳定取得原始结果，多人批准会不会拖慢交接，长任务停顿后能否准确恢复。比起再多摆几个角色，这些问题更决定它能不能省心。

龙哥点评

我喜欢这个项目把一个常被忽略的问题摆到了台面上：AI协作，不只是怎么让它们多聊几轮，而是聊完以后，谁有权动手，谁负责证明事情做对了。

本次对照也让我更在意“验收者”的工作方式。多一个角色，并不会凭空多出事实。验收者如果只接收执行者包装好的结果，整个流程仍可能非常规整地得出错误结论。

对团队来说，先别急着给每个助手起职位。先把一句话讲清楚：什么真实结果出现以后，我们才算交付。

这句话落到文件、数据和可重复的检查上，智能体协作才从“大家都很忙”，走向“事情真的做完了”。

参考资料

官方项目与使用说明：
https://github.com/MiniMax-AI/mcode-agent-table

BYOB 0.1协议：
https://github.com/MiniMax-AI/mcode-agent-table/blob/f230386ba0e405f2470d4f42863df3a5c0399297/SPEC.md

本文核对的代码版本：
https://github.com/MiniMax-AI/mcode-agent-table/commit/f230386ba0e405f2470d4f42863df3a5c0399297

官方离线示例：
https://github.com/MiniMax-AI/mcode-agent-table/blob/f230386ba0e405f2470d4f42863df3a5c0399297/demo/scripted-demo.ts

界面原图：
https://github.com/MiniMax-AI/mcode-agent-table/blob/f230386ba0e405f2470d4f42863df3a5c0399297/docs/assets/rabbit-hole/task-verified.jpg

本文依据MiniMax Code官方仓库与本次离线对照整理，界面图片由项目作者提供。本文基于龙哥读论文PaperDaily数据库及PaperMiner的MCP进行汇总整理。