cfdaily
6.9 KiB
name, description
| name | description |
|---|---|
| agent-collaboration-patterns | Agent 协作模式：角色匹配与认领纪律、inform 邮件处理、沟通效率、 跨项目调研落地映射。涉及 Agent 间任务分配、邮件通信、协作流程时触发。 |
Agent 协作模式
来源：从三国团队（庞统/司马懿/诸葛亮）~2GB 对话历史中蒸馏 卡片数：5（合并自批次2卡片10/11/12/13/15 + MEMORY.md 经验）
适用场景
- 黑板广播任务认领时
- 处理 Agent 间邮件（inform/request）时
- 跨项目调研后做落地规划时
- 安排测试和评审分工时
经验清单
1. Agent 认领任务前必须检查角色匹配（severity: medium）
场景：黑板广播任务时所有 Agent 都能看到。审查者（司马懿）认领编码任务会导致角色错配。
正确做法：
- 任务模板中明确角色匹配规则：只认领符合专长的任务
- 评审/审查类角色不应认领编码任务
- 任务描述中包含"只认领符合你专长的任务"的提示
⚠️ 常见错误：
- simayi-challenger（审查者）认领了 coding 类型任务 [pangtong/mail #337]
- 这个问题出现了 20+ 次（大量 E2E 广播任务被司马懿认领），是系统性问题
关键细节：
- 根因是黑板没有角色过滤机制，完全靠 Agent 自律
- 需要在系统层面增加角色匹配过滤（不只是提示语）
反面教训：角色错配导致编码任务被审查者执行，产出质量不符合预期。
来源：批次2卡片11（角色匹配，freq=4+）
2. inform 类型邮件不应触发完整 Agent 执行（severity: high）
场景：Agent 间邮件有两种：需回复的（request）和纯通知的（inform）。inform 触发完整执行会浪费 token 和 counter。
正确做法：
- Mail 类型简化为两种：inform（通知）和 request（需要回复）
- inform 由 ticker 直接标 done，或用轻量 prompt（"读完标 done"）让 Agent 感知但不完整执行
- 默认类型是 request，inform 是显式指定的特殊场景
⚠️ 常见错误：
- daemon 用
openclaw agent --agent simayi-challenger --timeout 300处理 inform 邮件 - Agent 被完整 spawn 执行，310s 超时后重新投递 [simayi-correction]
- inform 触发完整执行 + 超时重投递 = 死循环
关键细节：
- 庞统和用户确认：inform 仍让 Agent 看到内容（可能包含重要信息），但 prompt 告知不需要回复
- 这种设计比 ticker 直接标 done 更合理
- MEMORY.md 记录：inform 类型邮件处理耗时 >310s 导致反复重试投递（#310-314 各重试 5-7 次）
反面教训：inform 死循环消耗大量 API 调用和 token，阻塞邮件队列。
来源：批次2卡片12（inform处理，freq=2）+ MEMORY.md 庞统 2026-05-19
3. 回答问题要直接，不要绕弯子（severity: medium）
场景：用户提出具体问题时，Agent 回避核心问题，用相关信息绕弯子。
正确做法：
- 先直接回答用户的问题（哪怕答案是"不能/不知道"）
- 不确定时说"不能"，然后说明可以做什么
- 庞统最终模式："处理方式就三个问题：超时后怎么处理、重试用什么 session、重试几次后放弃。这就是全部。没有更复杂的了。" [pangtong/experience]
⚠️ 常见错误：
- 庞统反复讨论"compact 发生的概率"和"v1 vs v2 的区别"，用户已明确说"集中讨论 compact 发生后如何处理"
"别绕了，我都说过了" [user] "你说得对，我一直在说废话" [pangtong/experience]
关键细节：
- "不能区分超时原因"本身就是一个有用的答案
- 不需要区分原因也能给出处理方案——区分原因只对监控有意义
- 与"agent-execution-discipline"中"不绕圈子"经验一致，此处侧重协作沟通层面
反面教训：绕弯子浪费多轮对话，用户反复追问同一问题，信任度下降。
来源：批次2卡片13（沟通效率，freq=3）与批次1卡片2有交叉
4. 测试和评审分工——E2E 测试是评审者的职责（severity: medium）
场景：开发完成后，测试和评审应该由独立角色执行，不是开发者自测。
正确做法：
- E2E 测试是司马懿（评审者）的职责——部署后由他跑测试、分析结果、出评审报告
- 测试和开发必须分离——开发者自查只能发现约 50% 的问题 [MEMORY.md L4]
- 司马懿独立跑 E2E 并做根因分析，与庞统的修复做交叉验证
- 跨模块接口契约必须文档化 + 测试验证 [MEMORY.md L2]
⚠️ 常见错误：
- 开发者自查通过就认为没问题
- 前端开发完先评审而非先端到端测试 [MEMORY.md L1]
- 手动改 DB 推进任务——污染数据、掩盖真正 bug [MEMORY.md L6]
关键细节：
- 司马懿的评审标准："不说'建议优化'——必须说'第X行有问题，应该改为Y，因为Z'" [MEMORY.md 司马懿]
- "不顺手改代码——只指出问题让执行者改"
- 每次修复后全量重跑 E2E（不是只跑失败的用例）
反面教训：开发者自测 + 无 E2E = 假死问题在生产环境暴露，排查成本远高于测试阶段。
来源：批次2卡片10（E2E测试）+ MEMORY.md L1-L7
5. 跨项目调研的实践对照要做落地映射（severity: low）
场景：调研多个开源项目的最佳实践后，需要将发现映射到自己的项目架构中。
正确做法：
- 调研产出必须包含"moziplus 可借鉴点"列，明确优先级（M2 直接借鉴 / 够用 / 暂不需要）
- 标注哪些是可直接复用的模式（如 Lifecycle Hooks → on_node_start/end），哪些需要适配
- 司马懿在评审 Pipeline 重构时引用了业界调研，确认"Temporal 模式最接近我们"
⚠️ 常见错误：
- 部分条目只停留在"可借鉴"层面，没有明确"怎么做"
- 没有落地映射的调研变成"资料搬运"
关键细节：
- 庞统的对照表格式（优秀实践 / 来源 / 核心模式 / 可借鉴点）是好的模板
- 调研本身就是 Agent 经验声明的一种形式
- MEMORY.md 庞统记录了 v2.0 调研的 10 条关键发现，每条都有具体项目和可借鉴点
反面教训：没有落地映射的调研无法转化为架构改进，浪费调研投入。
来源：批次2卡片15（调研落地，freq=2）+ MEMORY.md 庞统 v2.0 调研
检查清单（快速参考）
- 认领任务前：这个任务是否匹配我的角色？
- 评审者不应认领编码任务，编码者不应自测自审
- inform 邮件：轻量处理（读完标 done），不触发完整 Agent 执行
- 回答问题时：先直接回答核心问题，再补充背景
- 调研产出：每个条目都要有"可借鉴点"和落地优先级
- E2E 测试由独立角色执行，走真实环境
- 跨模块接口契约是否文档化？
- 评审意见要具体（行号+修改建议+原因），不说"建议优化"