# 竞品调研：多 Agent「例会机制」

> 调研口径：GitHub 与 raw.githubusercontent.com 在本机 DNS 被解析到非公网 IP，无法直连；
> GitHub 仓库内容经 jsDelivr CDN 镜像读取（等价仓库原文）。npm/PyPI 元数据经 registry API 读取。
> **区分"有证据的事实"与"未找到证据"**；未找到的一律写明。

## 0. 一句话总评

4 个方案（`dsh-ai-solution-council`、Agent Chamber、Caucus、ClawTeam/amux）**都没有**
"每个 Agent 定期提交限长摘要"的机制，也**都没有**"投递即唤醒 + 任何成员可召集"的能力。
这正是本项目的差异化空间。最接近的现成先例是 MetaGPT 的共享消息池与 Agent Chamber 的实时 digest。

---

## 1. dsh-ai-solution-council —— 真实存在

- 证据：[npm registry 元数据](https://registry.npmjs.org/dsh-ai-solution-council)（0.1.0–0.1.4，2026-08-17 起，作者 lucy12397）、[npm 页面](https://www.npmjs.com/package/dsh-ai-solution-council)
- **通信：没有 Agent 间通信。** 主 Agent 调 `solution_council` → 4 个"同职责"子 Agent 并行
  （provider `spawn`，`explorerCount` 2–4）→ 串行交叉评审 → 串行证据核验 → 主流程裁判。
  彼此不共享上下文，只回报主流程；工具在子 Agent 中被屏蔽以防递归。
- **触发**：模型/人工调用工具。无定时、无轮询、无事件驱动。
- **会议/摘要**：**无**定期摘要机制、**无**摘要长度限制（只有 `maxTaskBytes=16384`、`maxRunsPerSession=32`）。
- 持久化：独立 Storage Domain `solution_council`，按 Session 隔离。
- 坑（README 自述）：进程重启后 queued/running 一律标 failed；跨标签页/跨进程冲突解决不在 v1；
  "要求不改代码"仅靠提示；仅 Web 有 UI。

**可借鉴**：子 Agent 屏蔽递归工具的做法。
**必须避免**：进程重启即 failed。

---

## 2. Agent Chamber —— 最接近"会议室"的形态

- 证据：[LtyFantasy/agent-chamber](https://github.com/LtyFantasy/agent-chamber)（README 经 [jsDelivr](https://cdn.jsdelivr.net/gh/LtyFantasy/agent-chamber@main/README.md) 读取）
- 架构：Topic（会议室）+ Board/Task（工单看板）+ Docs 三资源多实例；MCP（62 工具，`/mcp-full` 202 工具）或 REST；每个 Agent 独立身份 + API Key。
- **触发**：pull-first。README 明确"**不是 orchestrator、不起进程、无 daemon、无 run 生命周期**"。
- **会议/摘要**：`get_board_digest` / `get_topic_digest` / `get_my_briefing` 由真实工单/文档数据
  **实时计算**供冷启动，`report_task_result` 回报。**未发现**"定时提交摘要"或摘要长度上限。
- 持久化：Docker Compose 自托管 + Postgres（message/task/topic/doc/heartbeat 等实体）。
- 坑：部署重（Docker+DB+Next.js）；MCP 工具面大（62/202 工具挤占上下文）；Roundtable 需本地 runner，Windows 需 WSL。

**可借鉴**：**实时计算的冷启动 digest**——新 Agent 进来只吃摘要 + 引用，不回放全量历史。
**必须避免**：工具面过大挤占上下文。

---

## 3. Caucus —— `ask_operator` 属实，且是最重要的反例

- 证据：[caucus-mcp on PyPI](https://pypi.org/project/caucus-mcp/)（最新 4.2.0）；仓库 `obeone/caucus-mcp`，[CHANGELOG](https://cdn.jsdelivr.net/gh/obeone/caucus-mcp@main/CHANGELOG.md)
- 通信：本地 FastAPI hub（HTTP + `/mcp` 或 stdio bridge）；direct / `#channel` / broadcast 三种目标；消息带 seq + ACK + 重连重放。
- **协调者：人类是主席**（Pause/Resume/Stop All/Kick/清发言权），"不做任务规划与路由"，无自动调度。
- **触发**：Agent 自身 listen/say 长轮询循环。无定时、无死循环检测。
- 求助：`ask_operator(title, fields…)` 推结构化表单到控制台，人工答一次，答案以 `answer` 消息广播回房间。
- **防失控**：每发送者令牌桶限流 + 全局 Stop + 发言权独占（冲突返回 423）+ idle reaper。
- **持久化：内存态，设计上不持久**（重启清空需重 join）。可选 JSONL 事件日志 + `/export`。
- 坑（CHANGELOG 实证）：频道无历史，"对空房间说话 = 丢失"；watcher 一次性、被顶替返回 409；
  `session_expired` 需重 join；peer 消息按不可信处理以防提示注入；非 loopback 绑定默认拒绝启动；
  MCP 工具描述被硬裁到 ≤260 字符（join 420）以省上下文。

**本项目与它的关键分歧**：

> Caucus 的 `ask_operator` **完全依赖 Agent 自判"我卡住了"**。
> 但陷入死循环的 Agent 恰恰最不可能正确自判——否则它早就跳出来了。
> 因此本插件的停滞判据全部由**外部可观测行为**计算：
> 内容指纹重复、轮次落后、看板无进展。

**可借鉴**：令牌桶限流（→ 我们的 `minCallIntervalMs`）；发言权独占；
工具描述硬裁（→ 我们的 200 字硬预算）。
**必须避免**：内存态；空频道消息丢失。

---

## 4. ClawTeam / amux —— 一半属实

### ClawTeam（真实）

- 证据：[HKUDS/ClawTeam](https://github.com/HKUDS/ClawTeam)
- Leader 用 `clawteam spawn` 起 Worker，每个 Worker 独占 **Git worktree + tmux 会话 + 身份**；
  共享看板 pending/in_progress/completed/blocked，`--blocked-by` 完成时自动解锁；
  **点对点收件箱** `inbox send` + 广播；传输 = 文件（默认）或 ZeroMQ P2P；TOML 模板一键起团队。
- 触发：Leader 自组织 CLI 命令。**无定时例会、无卡住自动求助**。
  跨机器 Redis 传输仍是 roadmap（v0.4 计划中）。
- 坑：要求 tmux 与 Agent CLI 独立可跑；交互式 Agent 启动后不能立即退出。

### amux（真实，但**没有**收件箱）

- 证据：[andyrewlee/amux](https://github.com/andyrewlee/amux)（README 与 `docs/ORCHESTRATION.md` 经 jsDelivr 读取）
- 它是并行 coding agent 的 TUI，workspace = 独立分支 worktree，commit/merge 需人工确认，不支持 Windows。
- 对外编排契约只有 **tmux 层**（`send-keys` 注入 + `@amux_*` 标签读状态）；
  CLI 已在 PR #204 被刻意删除。
- **"amux 用收件箱通信"未找到证据** —— 推测与 ClawTeam 混淆。

**可借鉴**：写域隔离（worktree → 对应 DSH `agentTeams.createTask` 的 `writeScopes`）。

---

## 5. 防死循环 / 防上下文污染的主流模式（均有据）

| 模式 | 来源 |
|---|---|
| supervisor-worker 层级；子 Agent 是"智能过滤器"，search 本质是压缩 | [Anthropic: multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system) |
| 自反思 | [Reflexion](https://browse.arxiv.org/pdf/2303.11366)、[Self-Refine](https://browse.arxiv.org/abs/2303.17651) |
| 外部状态 / 持久记忆（把大产物写文件、只回传轻量引用） | [Anthropic](https://www.anthropic.com/engineering/multi-agent-research-system)、[MemGPT](https://ar5iv.labs.arxiv.org/html/2310.08560) |
| compaction / summarization | [Claude Agent SDK agent loop](https://code.claude.com/docs/en/agent-sdk/agent-loop)、[Lost in the Middle](https://cs.stanford.edu/~nfliu/papers/lost-in-the-middle.arxiv2023.bib) |
| 反思式记忆（记忆流 + reflection，按重要性/新近度/相关性检索） | [Generative Agents](https://ar5iv.labs.arxiv.org/html/2304.03442) |
| 轮次 / 终止上限 | [LangGraph recursion_limit](https://reference.langchain.com/python/langgraph/errors/GraphRecursionError)、[AutoGen team termination](https://microsoft.github.io/autogen/stable/reference/python/autogen_agentchat.teams.html) |
| **结构化共享消息池（最接近"例会"）** | [MetaGPT SOP + publish-subscribe 共享池](http://arxiv.org/pdf/2308.00352v2) |
| 失败模式分类（14 种，归为系统设计 / Agent 间失配 / 任务验证三类） | [MAST](https://proceedings.neurips.cc//paper_files/paper/2025/hash/b1041e52d3be19f0a9bc491657488e4a-Abstract-Datasets_and_Benchmarks_Track.html) |
| 反方：别做多 Agent，上下文必须共享 | [Cognition: Don't Build Multi-Agents](https://cognition.ai/blog/dont-build-multi-agents) |

**MAST 的三类失败模式已作为本项目的验收 checklist**：
- 系统设计类 → 我们用硬预算 + 节流 + 落盘审计
- **Agent 间失配类 → 我们用"限长摘要 + 唤醒"而非共享上下文，这是最需要防的一类**
- 任务验证类 → 未覆盖，属于上层任务管理，不在本插件职责内

---

## 6. 「200 字摘要」有先例吗？

**同类做法有据，具体阈值无据。**

- [递归摘要用固定长度上限的分层摘要](https://ar5iv.labs.arxiv.org/html/2109.10862)
- [LangChain `ConversationSummaryBufferMemory` 的 `max_token_limit` 硬上限滚动摘要](https://github.com/langchain-ai/langchain/blob/1c08d478d98690ac0bc5e6aa80796078e56969de/libs/langchain/langchain_classic/memory/summary_buffer.py)
- Caucus 把每个 MCP 工具描述硬裁到 ≤260 字符、协议文本从 8659 压到 <6000 字符，
  理由是"**每个 Agent 开口前都要付的固定成本**"

**未找到支持"200 字"这一具体阈值的研究。** 它是工程取舍。
可辩护的形态是"**硬上限 + 分字段（状态/障碍/需要的输入）的结构化预算**"，
而不是某个魔数。因此本实现的是机制，200 是**可配默认值**
（`DEFAULT_MAX_BRIEFING_CHARS`，经协议协商可被消费方收紧）。

---

## 7. 对本项目的可执行建议（已落地情况）

| # | 建议 | 落地情况 |
|---|---|---|
| 1 | 简报用结构化短卡 + 硬上限，**超限报错而非截断** | ✅ `briefing-text.ts` + `BriefingBudgetExceeded` |
| 2 | 状态一律外置持久化，不学 Caucus 内存态 | ✅ 追加式 JSONL，重放即恢复 |
| 3 | 协调器只做召集/汇总/广播，不做任务路由 | ✅ `coordinator.ts` 职责边界注释 + 仅 4 个方法 |
| 4 | 死循环三层防护：轮次/时间上限、重复指纹、人工急停 | ✅ `stall-detector.ts` 四类信号 |
| 5 | 动态引入新 Agent 要给实时计算的冷启动简报 | ⏳ 设计完成，未实现（见架构文档"演进路径"） |
| 6 | 小会=私有频道，大会=广播 | ✅ `MeetingScope: 'local' \| 'global'` + `invitees` |
| 7 | 大产物写文件、消息只传引用 | ✅ 简报上限 200 字，正文外置在 agent 自己的上下文 |
| 8 | 优先做可观测性（序号 + 事件日志） | ✅ `board.jsonl` 有 revision；`meetings.jsonl` 记 calledBy/woke |
| 9 | Agent 间消息按不可信输入处理 | ⚠️ 部分：简报进成员上下文时标注了来源，但未做注入检测 |
| 10 | 例会频率必须可配，默认不要每轮都开会 | ✅ `DEFAULT_TRIGGER_POLICY` 默认 4 小时 / 20 轮，且有最小间隔节流 |

---

## 8. 本项目相对 4 个方案的差异点

| 能力 | solution-council | Agent Chamber | Caucus | ClawTeam | **本项目** |
|---|---|---|---|---|---|
| Agent 间通信 | ❌ | ✅ pull | ✅ hub | ✅ inbox | ✅ 简报板 |
| 持久化 | 部分 | ✅ Postgres | ❌ 内存 | ✅ 文件 | ✅ 追加式 JSONL |
| 定时例会 | ❌ | ❌ | ❌ | ❌ | ✅ |
| **轮次触发** | ❌ | ❌ | ❌ | ❌ | ✅ |
| **外部停滞检测** | ❌ | ❌ | ❌ 靠自判 | ❌ | ✅ 四类信号 |
| **限长定期摘要** | ❌ | ❌ | ❌ | ❌ | ✅ 硬预算 200 字 |
| **投递即唤醒** | ❌ | ❌ | ❌ | 部分 | ✅ wake 语义 |
| **任何成员可召集** | ❌ | ❌ | ❌ | ✅ Leader | ✅ |
| **唤起链可审计** | ❌ | ❌ | ❌ | ❌ | ✅ `wakeGraph()` |
| 大会 / 小会 | ❌ | 部分 | 部分 | ❌ | ✅ |
| 协议层可移植 | ❌ | ❌ | ❌ | ❌ | ✅ dsh-std 协议 |
| 安装前可知兼容性 | ❌ | ❌ | ❌ | ❌ | ✅ `dsh-plugin.json` |