OPEN-SOURCE AGENT PROTOCOL / 开源多智能体协作协议 · MIT License
白蚁协议（Termite Protocol）：让无状态 AI Agent 像白蚁一样协作的开源工程实践
AI 编码 Agent 的会话天然无状态、一次性，而软件工程却需要连续性、协作与记忆——多数多 Agent 框架依赖对话协调，既昂贵又脆弱。LongArena 将支撑自身生产系统的多智能体协作内核完整开源为白蚁协议（Termite Protocol）：Agent 之间不对话，而是通过环境感知彼此的工作；信号持久化于 SQLite、任务原子认领、观察如信息素般跨会话沉积、新会话以 .birth 快照（≤800 Tokens）瞬时接续。该协议已在 6 个生产蚁丘、4 次多模型审计实验与 900+ Commits 中得到验证。
无状态 Agent 与连续性工程之间的结构性矛盾
今天的 AI 编码 Agent 存在一个根本性的错配：Agent 会话是无状态、一次性的，关闭窗口即遗忘一切；而真实的软件项目需要跨越数周数月的持续上下文、多人（多 Agent）协作与知识记忆。业界常见的解法是“多 Agent 对话编排”——让 Agent 互相发消息协调分工。但对话通道既昂贵又脆弱：上下文随对话轮数膨胀、角色 Prompt 层层堆叠，一旦会话中断，协调状态便永久丢失。
白蚁协议（Termite Protocol）给出了相反的答案：不要把协调能力放进 Agent 的对话里，而要放进它们共享的环境里。正如自然界中的白蚁从不开会、不对话，却通过感知环境中的信息素（Stigmergy，痕迹激发协作）建造出结构精密的蚁丘——每个到达的 Agent 读取环境快照、认领任务、留下痕迹，秩序从环境中自发涌现。
这套协议并非演示玩具，而是 LongArena 生产系统的真实协作内核：我们的企业级产品由多智能体流水线持续维护，跨会话的知识沉积、原子任务认领与强制蜕皮交棒，全部运行在白蚁协议之上。目前该协议已在 6 个生产蚁丘、4 次多模型审计实验、累计 900+ Commits 中完成实证，并以 MIT 许可证在 GitHub 完整开源。
第一章：协议内核——10 条语法规则、4 条安全网与种姓权限
白蚁协议把多智能体协作压缩为一组可机械执行的语法规则，而非依赖 Agent 的“自觉”。每个 Agent 的生命周期被严格规约为确定性状态机：
1. 到达即感知（ARRIVE → SENSE → STATE）
Agent 到达时不读冗长文档，先感知环境：读取 BLACKBOARD.md 动态黑板、.pheromone 信息素链与 git status，由 field-arrive.sh 计算当前态势快照，再决定自己的角色与权限边界（STATE → CASTE → PERMISSIONS）。
2. 行动必留痕（DO → DEPOSIT）
协议强制每个行动沉积可追踪痕迹：代码、文档、黑板记录、测试结果或 WIP 交接。低权重信号随时间自然蒸发（EVAPORATE），高权重风险必须强制升级上报（ESCALATE），重复出现的高质量观察沉淀为可复用规则（EMERGE）。
3. 上下文超限必须蜕皮（MOLT）
当上下文接近耗尽（> 80%），Agent 必须写入 WIP.md 与信息素后主动交棒，由下一个全新会话无损接力——彻底根治长会话的推理长尾与幻觉漂移。生成新 Agent 入口时必须注入协议种子（SEED），保证协作基因代代相传。
4. 四条安全网不可让渡
提交信息必须说明改了什么、为什么改；不得删除协议与设计文档；大范围改动必须小步落盘、保持可审计；一旦环境中出现 ALARM.md 警报信号，任何 Agent 必须先停下读取。种姓模型（soldier / worker / scout / nurse）进一步把权限边界写进协议层。
第二章：四大工程机制——环境承载智能
对话式框架假设 Agent 必须始终携带大量上下文；白蚁协议反其道而行，把信号、记忆与模板全部沉淀进环境。其运行时由一组极简 Shell 脚本与一个 SQLite 场数据库构成：
1. .birth 快照：以 ~2% 上下文成本接续现场
新会话不再需要重读约 28K Tokens 的完整协议文档（约占上下文窗口 40%）。field-arrive.sh 在到达时动态计算 .birth 运行快照，将黑板状态、活跃信号、安全提示压缩至 ≤800 Tokens（约 2% 上下文），而重对话编排方案通常要消耗 5~15% 以上的角色 Prompt 与聊天记录。
2. SQLite 原子信号认领
任务以信号（Signal）形式持久化在 WAL 模式的 SQLite 场数据库中，认领通过事务原子完成：无调度器瓶颈、无双重分配、无对话开销；心跳超时后停滞的认领可被自动回收，避免任务被挂死的 Agent 永久占用。
3. 信息素沉积：观察跨会话累积
Agent 的观察、决策与状态以信息素链形式沉积在仓库中，知识不会随单次会话结束而消失。长周期项目的记忆随时间复利增长，这正是白蚁协议相对“每次从零开始”的单会话模式的本质差异。
4. 规则从重复证据中涌现（EMERGE）
当同类观察持续累积到足够证据权重，系统将其晋升为可复用规则并注入后续 .birth——环境随使用越来越聪明，而不是让每个新 Agent 重复踩同一个坑。
第三章：不是口号，是实证——牧羊效应（Shepherd Effect）
白蚁协议最有价值的实证发现是“牧羊效应”：在强弱模型混编的蚁群中，1 个强模型（牧羊人）先在环境中留下高质量范式，后续弱模型（工人）从 .birth 读到模板并通过上下文学习模仿其结构，从而以极低成本逼近强模型的输出质量。touchcli A-005 实验中，1 个 Codex 牧羊人 + 2 个 Haiku 工人即实现了 96.4% 的观察质量：
多模型混编对照实验（观察质量 / 交接质量）
实验对象：touchcli 真实仓库多 Agent 审计任务；观察质量衡量沉积内容的可用性，交接质量衡量跨会话接续的完整度。
如需查看未显示的列，左右滑动表格或使用方向键。
| 实验配置 | 观察质量 | 交接质量 | 关键结论 |
|---|---|---|---|
| 2 × Haiku 独立作业（无牧羊人） | 35.7% | 0% | 纯弱模型执行质量快速退化 |
| 1 × Codex 牧羊人 + 2 × Haiku 工人 | 96.4% | 99% | 牧羊效应成立：强模型范式被弱模型继承 |
| 5 模型混合群（高吞吐配置） | 57% | 100% | 吞吐可扩展，但质量需要门禁控制 |
1. 六个真实蚁丘，900+ Commits
协议已在 6 个真实蚁丘完成验证：从首个审计闭环（A-001，54 commits）到最高吞吐的 5 模型混合群（A-006，562 commits、113 条信号），再到 LongArena 自身的稳定生产参考蚁丘，累计产生 900+ 次提交。
2. 诚实的边界：吞吐可扩展，质量需门禁
实证同样暴露了边界：纯弱模型组合（2×Haiku）观察质量仅 35.7%、交接质量归零；5 模型大混编虽吞吐最高，却暴露出任务饥饿与质量稀释问题。结论清晰——白蚁协议提供协作的物理基础，但质量门禁（如强模型牧羊、独立复核）仍是工程必需品。
3. 与学术研究的互补印证
2026 年论文 SwarmWorld 在受控仿真中独立研究了高度相关的方向：初始同质的 Agent 通过持久化世界协调并积累可执行制品。白蚁协议则是面向真实软件仓库与异质跨会话编码 Agent 的工程协议——二者以不同方法为“环境中介型 Agent 协作”提供了互补证据。
第四章：LongArena 生产工程实践与开源
白蚁协议是 LongArena 无人值守工程体系的底座：本系列 RSI 双工流水线中的 Guardian 强交接门禁触发“会话蜕皮（Molt）”即协议第 9 条规则；BLACKBOARD.md 动态黑板、WIP.md 跨会话交接、信号驱动的工单流转，全部是协议机制在生产中的直接实例。
# 60 秒冒烟测试：在一个全新目录体验协议
mkdir termite-demo && cd termite-demo
curl -fsSL https://raw.githubusercontent.com/billbai-longarena/Termite-Protocol/main/install.sh | bash
./scripts/field-arrive.sh # 计算 .birth 快照并完成创世
./scripts/field-pulse.sh # 项目健康快照：signals=1
sqlite3 .termite.db "select id,status,title from signals;"1. 何时使用：多 Agent 并行、强弱混编、长周期项目
多 Agent 并行开发（原子认领避免重复分配）、强弱模型混编（牧羊效应放大弱模型产能）、长周期项目（跨会话记忆复利）、大规模重构（文件级任务高并行）、审计敏感工作（信号与规则全程可追溯）。
2. 何时不用：一次性小任务不必引入协议开销
很小的一次性任务（协议开销大于收益）、依赖整体判断的开放式研究、几行的小脚本——这些场景直接使用单个编码 Agent 更经济。工程选型的诚实边界，本身就是协议文化的一部分。
3. MIT 完整开源：从冒烟测试到审计材料
协议已在 GitHub 以 MIT 许可证完整开源：一条命令完成安装与创世，60 秒跑通冒烟测试；仓库同时公开全部实验审计包（audit-packages/）、防退化分析（audit-analysis/）与知识库，欢迎复现、质疑与贡献。
技术文档更新日期： · demo@long-arena.com