多代理协作缺个名字，我管它叫立图

多代理讨论底下最常见的评论，我已经看到快免疫了："你们都说各自跑得欢，但两个 agent 吵起来的时候，到底谁说了算？"Orvix 那条 announcement 下面又有人问：前后端两个专家 agent，一个坚持 API 这么定，另一个说必须那么定，谁裁决？

这问题被人问了小一年，我没见过哪个答案让人满意。设一个 manager agent——那 manager 和一线 agent 吵起来呢？让人类拍板——那等于承认代理协作不成立。再就是把优先级写进 prompt——写的时候是宪法，跑起来是最早被遗忘的注释。

这件事到现在没名字，所以大家没法把它当成一个可以事前设计的东西来讨论，只能当运维事故，出了事再救火。可它不是事故，是多代理协作的默认状态：分歧一定会发生，重要的是分歧发生之前，系统里有没有一张所有人都认的图。

上个月那个开源项目 Orvix，一句话介绍是"自组织的 AI 工程公司"。你只描述任务目标，它自己拆结构、按需创建专家角色，每个专家一个独立 Git 分支，并行干活，互相 review。单看介绍又是个 agent 玩具，但我翻它文档时停了下来。

它把"协调"提到了开工之前：先有一张 Orvix Map，范围、契约、所有权、验收标准全写上去，是整个系统唯一的事实来源；每个专家的 PR 过一遍 Critic Council 的审查，照 Map 审；真还有分歧，才轮到 MasterMind 拿实时上下文拍板。这套顺序——先有图，再有代理，再有审查，裁决在最后。这哪是 agent 系统，分明是个治理结构。

然后我就想：这堆东西社区里早就反复比划过，却连个名字都没有。叫"多代理编排"？编排是调度层的事，不负责契约和裁决。叫"治理机制"？治理这词又搬了太多管理学的权谋味。没有一个词能在 review 时被直接喊出来：你这里没立图。

我把它叫做：立图。定义就一句话——让一群代理在动手之前，先把范围、契约、所有权、验收标准钉在一张可指认的图上；之后所有审查、裁决、冲突解决，都照图说话。

为什么是"图"不是"文档"不是"契约"？因为图是要被指认的。你指着文档说"这里写清了"和指着图说"你走这"，是两种动作——后者是在给一群不认路的人带路。"立"也不是画：画是个人行为，立是公开确立。

你下次跑多代理工作流，开头多花十分钟干这件事：立图。不需要 Orvix 那套完整机制，四行 Markdown 就够——范围、契约、所有权、验收标准。关键是让每个 agent 都能看见它、分歧时引用它，不是"参考一下"，是"这是唯一事实来源"。之后两个 agent 再争 API 形状，你省掉一类烦恼：拉回图上看一眼，谁越界谁改。图没说清，那是立图人失职，不是调停人失职。

写到这儿我得停一下。按我自己定的规矩，样本没攒够就吹号叫抢拍。"立图"这词我现在手里的完整样本其实只有 Orvix 一个。剩下全是半截的样本——开了几个 agent 各自跑、最后在共享对话里互相打架的那些系统，它们无一例外，缺的都是开工前那张图。所以这个词严格说还在半成品。但我还是把它吹出来了：散点已现形，只是没人往回看。哪怕过两个月它被更好的名字顶掉，只要"开工前立图"这件事能在讨论里被一句话指到，这块空地就算盘活了。

所以你该做的动作就一个：下次再跑多代理，开工前立图！立完再放 agent 出来。用的时候不必挂我的名字——造词的特权，止于能不能让得出。附带作废条件：三个月内，除了我自己，没见第二个人在公开场合用"立图"，说明没群唱起来，我回炉。它要是不配那块空地，我换个名字再吹。