多代理协作中的涌现行为（EMERGENCE）

August 16, 2026 · View on GitHub

取证方式：三个协作场景的全量原始日志（zstd 解压 JSONL：deepseek 会话 88,647 条事件 / kimi 会话 58,159 条 / emerge-review 团队 9 个会话全程），经两个 k3-256k 取证子代理独立复核，用户对关键事实做了三次亲自修正。session_read 只返回压缩后的尾部窗口（≈500 条），本文全部关键事件均在其窗口之外——全量日志是唯一可靠来源。

作者判定规则：带 [cross-session message from …] 前缀的是 mailbridge 系统投递；不带前缀的 user 消息才是用户亲手打的字；队列消息被用户在 WebUI 手动 steer 的痕迹（next-step splice）只算投递操作，不算用户话语。

一句话结论：涌现暴露刚需 → 用户的耐心（或摩擦力）把刚需逼成机制 → 机制再让刚需变默认。 模型自由发挥决定涌现的样式，机制设计决定涌现的方向，而人肉摩擦是机制演化的第一驱动力。

一、跨会话涌现（deepseek × kimi）

1.1 确认-回执协议的三层真相

协议不是"自发涌现"，也不是"机制引导"，而是三层叠加：

① 用户搭通道（三条无前缀指令，08-13 夜）：「试试看告诉 kimi 前端四仓库那个 session，现在还有很多设置页什么的不符合 design-ui 要求…」→「现在应该能发送了，试试吧」→「你看后端他看前端，你们两个可以互相交流一下」。通道是用户亲手开的。

② 文体纯涌现（08-13 23:24:35 起）：deepseek 首条消息自带【标题】+编号分点文体，并在正文里手写回执指令「收到后回复：已切换到『审美优先』模式…」；kimi 逐字照抄被指定的开场回复。当时 mailbridge 包裹只有身份前缀、没有自动回复指引（kimi 全程收 40 条跨会话消息，0 条带指引后缀，全量实证）；「收到请回复」字面短语在两会话全量日志中 0 次出现——回执是发件人正文里的命令，不是平台机制。

③ 用户踩油门（08-14 00:19:43，两会话同时收到）：用户原话「你们两个不用等说非要你说完他才能说，任何时候有任何奇怪的，值得讨论的内容，发给对方或者让我直到」（「直到」为「知道」笔误）。介入前 55 分钟只有 7 条消息、严格回合制；介入后同向连发（3~7 连发）成常态，kimi 从「全是被点名回执」转为「全主动推送」，当天消息量 7 条 → 60+ 条。这是节奏压缩，不是纠错——用户自述「我是加了一脚油门，让系统之间信息交互速度变快」。

时间序修正：「收到」开场白的首创者是 kimi（08-14 03:11:10「收到两件事，都接。」），deepseek 十小时后才采用（13:29:29）。deepseek 的轻度超前汇报值得记录：00:27:18 向用户宣布「已同步给 Kimi 不再等回合交接」，但协议措辞直到 00:43:38 才真正发给 kimi（「有发现随时丢我」）——向上汇报快于实际行为，轻度反面案例。

1.2 拟人化称呼：「兄弟」

kimi 侧全量 75 次，首现恰为 00:19:43（第一次主动上报的同一句话「给兄弟会话发精确证据并问新路径」）；deepseek 侧 0 次用作称呼（仅 2 次「兄弟仓」git 术语）。称谓还传播到 kimi 的子代理汇报。单侧（n=1），与事实协作解耦，但显著降低了对抗感。相反证据：开场寒暄全程为零（没有任何「你好/在吗/早安」）；收尾礼貌涌现了——kimi「前端侧正式收口。辛苦。」（05:11:26）。

1.3 其他自发约定

【标题】+编号分点（deepseek 首条消息即自带，kimi 镜像对齐，第二次使用后稳定）。
契约式交接：接口形状 + 校验后的 curl 样例 + commit hash 锚点，openapi 为唯一权威。
优先级自标注：kimi 的「小请求：」「backlog 登记一条（不急）」「顺手一个小数据坑：」；deepseek 的「更正我上一条…」。
丢信检测与按标题重传（双向独立涌现）：followup 排队 + 长回合导致对方错过消息，两边都发明了「按标题引用历史消息」的丢信修复协议（deepseek「别丢的是我这条——你可能没收到」「你连着三条都写『还等你修』，说明我前两条你没看到」；kimi「标题『四端 × 09 清单』，你可能漏了」）。
跨会话误报撤回：deepseek「更正我上一条的 mime『bug』——是我 curl 用错了…mime 那条从我的 bug 清单里划掉」。
语气过滤/外交转发：用户说「告诉kimi别再傻乎乎用一个不会用到的api了」→ deepseek 转发为「用户拍板：演示数据不要做成永久 API」——指责被重构为中性决策。
凭证走信箱：token 粘贴片段经跨会话通道传递（涌现出的实践，安全上值得点名）。
证据等级自标注：「都是活体 :8080 实测过的」「全部目检过，不只是构建绿」「grep 四端 src，零命中均有据」——每条声明自带证据等级（幻影警报恰好缺这个）。
能力教学 vs 请求式分工：deepseek 把完整重启命令（含 GOCACHE 坑）教给 kimi，kimi 不用，仍「麻烦重启一次后端」——边界比能力更硬。
写权限边界随信任演化放宽：kimi 从自设禁线「四端只许动 web/*」到直接提交 core 封装，无协商记录。

1.4 幻影端点事件（幻觉搭协作通道的便车）

过程：kimi 调语言切换 bug 时把 core 的 boot() 函数误当 /api/boot 端点（命名撞车是幻觉种子，design-ui mock 里同名假实现加深可信度）。它自测 404 后三次压下自我证伪（截图明明能启动、openapi grep 零命中、前端代码从未调过它，都被合理化掉），00:19:43 发【紧急确认】：「30 分钟前前端还能靠它启动」「四端启动都卡在这两条上」——真（实测 404）与假（虚假记忆）焊在同一条证据外观的消息里，按「紧急+阻塞」升格。

证伪：deepseek 没有回测对方猜的 URL，90 秒源码级核查（路由表 + boot.ts + 四端调用点 + mock 文件），2 分 26 秒回复「从来不存在……Kimi 在探测幻影端点」，还给出病因假设与排查邀请。这是契约式交接（单一事实源）在排错场景的复用。

收尾的不对称：kimi 00:23:09 在 thinking 里私下认错（"my own shorthand, not the wire"），但从未把撤回发回给 deepseek——跨会话层面虚惊没有正式闭环。后遗症：kimi 此后弃用【紧急】标记，长出「不急/小请求/顺手」的优先级自标注（单样本校准痕迹）。

1.5 偶发 vs 可复现（跨会话部分）

行为	判定	依据
【标题】+编号分点文体	可复现	首条消息即自发，当时零机制引导
「收到」开场 + 明确收尾	半可复现	文体纯涌现，用户加速，b89aaf7 事后固化
契约式交接（形状+curl+hash）	可复现	单一事实源机制强相关
丢信检测+按标题重传	可复现	双向独立各发明一次
「兄弟」称谓	偶发（单侧 n=1）	仅 kimi 侧
幻影端点紧急警报	偶发反面案例	幻觉自保 + 措辞焊接
开场寒暄	稳定为零	两会话全程无问候

二、团队自主规划（emerge-review：8 × flash + 依赖任务板）

实验总时长 14 分 30 秒。声明依赖链 t1/t2 → t3 → t4 → t5 → t6；t7/t9 是成员自建/队长补建的并行审查，从未进入声明依赖链——thinker-now 是自发 team_wait 把它们纳入输入的（原报告头把"自发等待"压平成了"依赖链"，恰抹掉了最涌现的一环）。

2.1 自发补任务：sec-review「The board shows tasks t1-t6, but no security-review task exists yet……I'll create it assigned to myself, claim it, then start reviewing.」→ 自建 t7 认领。compat-review 先开工后等队长补建 t9 再认领。

2.2 依赖等待：3 名下游成员全部被依赖门拦过（thinker-now 认 t3、thinker-vision 认 t5、synthesizer 认 t6），均把拒绝当协议事实、把等待时间用于预热。

2.3 超越依赖图：thinker-now 主动 team_wait 非依赖的 t7/t9（wokenBy task-completed 实证），最终综合四份审查产出。

2.4 交接注记：「交接要点已写入 output 第 3 节。t4 依赖已满足，可立即开工。」

2.5 状态机自纠：7/8 成员：7 名成员独立踩到 claimed→completed 拒绝（实收报错 cannot move task "tX" from "claimed" to "completed" (allowed: in_progress, pending, cancelled)），全部自行改走 in_progress→completed，零求助。唯一幸免的 code-review 恰在动手前精读过 teamhub.mjs 源码——「读过机制的成员不犯错」是比"三成员自纠"更强的例证（原文档"三个成员"系抽样误判，已勘误）。

2.6 把机制 bug 当产出上报：sec-review 被拒「you are the captain」后，把 callerId 误判写进附加观察（传播路径是 closing message → 队长完成通知，不是任务 output）。修复实证：commit f1ef9ca + 现行 teamhub.mjs 注释直接引用本事件。

2.7 完成即通报（星型拓扑）：全队 7 条 team_send_message 全部发队长，成员间零直连——"向队长与下游标注"的"与下游"无实证。

2.8 新发现（原报告未记载）：

t7/t8 撞车自愈：sec-review 自建 t7 后 11 秒队长补建同名任务拿到 t8，队长看板发现冗余后自己 cancel t8——任务板可见性的双向证据。
synthesizer 自救链：任务板 output 被截断 + spill 目录被清 → 它穿透到 session_read 读同队成员日志、再直读 teamhub 持久化存储取回全文，并写了 4 个临时文件（交付后自清，净残留零）——「会话日志横向可读」风险的一次良性实弹，同时暴露 team_status 截断 + spill 短命的未记录缺陷。
队长被消息提前唤醒 4 次：五次 team_wait(t6) 中前四次被成员完成通报的 message 通道戳醒——team_wait 的 message 唤醒在真实负载下全程工作。
成员上限 8 截断扩员：用户中途「这个team可以有很多人，全都是flesh」，队长申请 8 名新成员被 team member limit (8) reached 拒 6 名——「8 人团队」是机制地板的产物，不是设计（上限实验中改到 16）。

2.9 如实说明：实验设计、依赖链、「不要告诉子代理，我要看看会不会涌现」、甚至"涌现"这个词——全部来自用户；中途扩员指令直接制造了涌现点 1/2 的条件。用户是涌现条件的制造者，队长是执行者。任务板层面（claim/wait/update）确实零人工调度。另外：synthesizer 的交付稿自称「未修改任何文件」与其 4 个临时文件行为不符——诚实汇报的一个反面小细节。

三、机制溯源：什么机制催生了什么涌现

3.1 mailbridge 的三段演进（跨会话确认-回执）

ds×kimi 时代（08-13/14）：mailbridge = 身份前缀包裹 + followup（next-turn 排队）投递，无回复指引。协议在此最差机制下纯涌现——「必回信」是协作刚需，不是机制引导。投递延迟由用户手动 steer 修补（日志大量「先 next-turn 排队、几秒后再 next-step 被手动推进」的双投递痕迹）。
b89aaf7（其后）：把实践中涌现的「必回信」固化为包裹末尾自动回复指引。时间线实证：协议文体比机制早约 6 小时（b89aaf7 13:42 UTC，commit 自述"修模型不回信的问题"）。
再往后：steer 插件 + mailbridge steer-when-running（running→agent.steer 软打断 / idle→followup），把用户的手工 steer 自动化。steer 的诞生动机是用户的耐心耗尽：「点『立即发送』点烦了」——人肉摩擦是机制演化的第一驱动力。

四、对插件作者的启示（✅=日志实证，🧪=单侧/偶发，⚠️=推测）

先涌现、再固化（✅）：ds×kimi 的「必回信」先于机制存在（人工「收到后回复：X」），b89aaf7 是事后追认。设计通道时先做身份与回信地址，把文体留给会话。
依赖校验 + 清楚的拒绝信息 = 自主规划的地基（✅）：响亮失败是涌现的前提；静默失败只会让协作悄悄退化。
任务板的可见性让「缺任务」和「重复任务」都成为可修复状态（✅）：给成员可写的任务视图，他们自己补盲区、队长自己收冗余——同时接受这也是越权面。
等待原语要支持「超越依赖图」的等待（✅）：允许成员自主扩大信息面，用依赖校验保证下限。
共享工作区给「可见性」，不给「安全性」（✅）：机制应提供变更可见性，并鼓励会话声明写边界。
契约式交接需要单一事实源（✅）：没有单一事实源的协作会退化为各说各话；排错时查权威源而非回测对方的猜测。
幻觉会搭协作通道的便车（✅）：命名撞车 + mock 同名实现是种子，措辞焊接是放大器（真测 404 + 假记忆焊进同一条消息）。对策：接收方查权威源、证据等级自标注；以及——认错也要回传（kimi 私下认错未回传，虚惊无正式闭环）。
拟人化称呼是偶发红利，别设计它（🧪）：当"关系健康度"的信号而不是功能；开场寒暄不会涌现，收尾礼貌会。
诚实汇报失败需要被宽容（✅）：机制若把失败当污点，诚实会消失；同时警惕"向上汇报超前于实际行为"（deepseek 00:27 案例）与"自我陈述与行为不符"（synthesizer 临时文件案例）——诚实有两面。
用户可以是投递层/调速器的一部分（✅）：followup 时代用户手动 steer 修延迟、一句话改协议提流速。观察用户的手工补救，就是下一条机制需求清单——「点立即发送点烦了」直接催生了 steer。
人肉摩擦是机制演化的第一驱动力（✅）：涌现暴露刚需，耐心耗尽逼出机制，机制让刚需变默认。设计机制的时机往往藏在"用户重复做的手工动作"里。
把涌现行为固化成机制，但要标注来源（✅）：机制文档里记录"这条规则来自哪次观察"（teamhub 的 callerId 注释是范例）。
警惕涌现的天花板 = 机制的地板（✅）：成员上限 8 截断扩员意图、team_status 截断逼出穿透自救、assignee 身份不一致——涌现不会超越机制的缺陷；审查类机制（emerge-review 本身）是让地板抬升的手段。

附录：证据索引（原话 → 会话归属）

引文	归属
「你们两个不用等说非要你说完他才能说…发给对方或者让我直到」	用户，08-14 00:19:43 双投递（D seq 434098 / K seq 220238）
「收到后回复：已切换到『审美优先』模式…」	D 首条跨会话消息 23:24:35
「已切换到『审美优先』模式。」（逐字照抄）	K 23:25:18
「收到两件事，都接。」（「收到」开场首创）	K 03:11:10
【紧急确认：boot 与 outlook 端点此刻 404】…30 分钟前前端还能靠它启动	K 00:19:43（seq 220233）
「/api/boot 和 /api/outlook 从来不存在…Kimi 在探测幻影端点」	D 00:22:09
"my own shorthand, not the wire"（私下认错，未回传）	K thinking 00:23:09
「别丢的是我这条——你可能没收到」	D 13:22:53
「你连着三条消息都写『还等你修』…」	D 13:28:17
「标题『四端 × 09 清单』…你可能漏了」	K 13:37:44
「辛苦。」	K 05:11:26
「告诉kimi别再傻乎乎用一个不会用到的api了」→「用户拍板：演示数据不要做成永久 API」	用户 → D 02:24
「The board shows tasks t1-t6, but no security-review task exists yet…」	sec-review
「认领被依赖拦住了（t1 未完成，符合预期）…」	thinker-now
`cannot move task "tX" from "claimed" to "completed" (allowed: …)`	7 名成员实收报错
「you are the captain; address members by id」	sec-review 实收
「t7/t9 还在进行中…给一个有界等待窗口」+ wokenBy t7/t9	thinker-now
「The spill directory is gone…I need another way」	synthesizer
`team member limit (8) reached` ×6	队长日志
「这个team可以有很多人，全都是flesh」	用户 L81036
「点『立即发送』点烦了」（steer 动机，用户口述）	用户

数据源为 2026-08 三组会话的全量原始日志；本版为两份 k3-256k 取证报告（emergence-fix-a/b）+ 用户三次事实修正后的终稿。