这是对多 Agent 架构方案的第三轮审计（v1.5）。
第二轮审计发现的问题已全部修复：
1. ✅ maxRound 改为按复杂度动态设置（简单=4，中等=6，复杂=8），session.md 模板中显式写明
2. ✅ 超轮次后当前 Agent 停止，不再通知下一方；增加重复通知防护（检查 session.md 是否已有超轮次标记）
3. ✅ 通信机制明确区分 Agent 通知 vs 主人对话 ping-pong（通知穿透规则写入 SOUL.md 和方案）
4. ✅ 清理策略改为 pending-cleanup 两步确认，heartbeat 只标记，爱衣手动确认后删除
5. ✅ 阶段一执行计划补充 session key 检查逻辑（发任务前先 sessions_list 检查目标是否存在）
本轮审计重点：
1. v1.5 的修复是否完整，是否引入新问题？
2. 通知穿透规则（SOUL.md 中）与其他静默规则是否存在冲突或歧义？
3. session key 检查逻辑 + Agent session 不存在时的处理流程是否合理？
4. 还有什么遗漏的边界情况或风险？
方案文档路径：/root/.openclaw/workspace/memory/docs/multi-agent-plan.md
爱衣 SOUL.md：/root/.openclaw/workspace/SOUL.md
请将完整审计报告追加到本文件末尾，格式同上一轮。
完成后 sessions_send 通知 agent:main:main，消息格式：
「审计完成 ✅ task_id=audit-003 结果路径=/root/.openclaw/workspace/tasks/task-audit-003/session.md」
时间：2026-02-22 20:05 GMT+8
currentRound → 2
lastUpdated：2026-02-22 20:05
逐条核查 v1.4 → v1.5 修复项：
| 修复项 | 验证结果 | 备注 |
|---|---|---|
| ✅ maxRound 按复杂度动态设置（4/6/8） | ✅ 已在 session.md 模板中明确 | 格式正确，显式写在元信息中 |
| ✅ 超轮次后当前 Agent 停止 + 防重复通知 | ✅ 已在第三节「超轮次处理」中明确 | 逻辑清晰 |
| ✅ 通信机制区分 Agent 通知 vs 主人对话 ping-pong | ✅ 第四节通知穿透规则 + SOUL.md 均已更新 | 两处一致 |
| ✅ 清理策略改为 pending-cleanup 两步确认 | ✅ 第六节已更新 | 流程清晰 |
| ✅ 阶段一补充 session key 检查逻辑 | ✅ 第十二节执行计划第 3-4 步已明确 | 包含 sessions_list 检查和不存在时通知主人 |
总体评价：5 项修复全部落地，无明显遗漏。
这是本轮重点审查项。
规则现状（方案第四节 + SOUL.md）：
- ���� 通知穿透规则（高优先级）：收到 Agent sessions_send 通知 → 必须执行操作，不得静默
- 🔵 静默规则（低优先级）：主人发起的对话 ping-pong → REPLY_SKIP；announce step → ANNOUNCE_SKIP
⚠️ 发现的歧义点：
2.1 「主人发起的对话产生的 ping-pong」定义不明确
- 当爱衣转发主人任务给 coder 时，coder 收到的是「Agent 通知」还是「主人对话 ping-pong」？
- 当前方案通过 sourceSession 判断（来自 agent:main:main → Agent 通知，来自 telegram/user → 主人对话），�� coder/reviewer 的 SOUL.md 中没有明确说明如何判断来源。
- 建议：在专业 Agent 的 SOUL.md 中补充：「所有来自 agent:main:main 或其他 Agent session 的 sessions_send 通知，均视为 Agent 通知，适用通知穿透规则」。
2.2 ANNOUNCE_SKIP 规则适用范围存在潜在冲突
- 爱衣 SOUL.md 中写「announce step 一律 ANNOUNCE_SKIP」（见方案第九节引用）
- 但爱衣作为「任务终点」，应该用 message 工具推给主人
- 这两条规则没有冲突（ANNOUNCE_SKIP 是抑制系统自动 announce，而 message 工具是主动发送），但容易被误读
- 建议：在 SOUL.md 中补充注释：「ANNOUNCE_SKIP 仅抑制系统自动 announce；爱衣作为终点需主动调用 message 工具，不受 ANNOUNCE_SKIP 影响」
2.3 通知穿透规则在 test-agent SOUL.md 中缺失
- 当前 /root/.openclaw/workspace-test/SOUL.md 未包含通知穿透规则
- test-agent 已在实验中通过行为约束学会静默，但正式规则未落地
- 这是合理的（test-agent 是实验用途），但若将来 test-agent 参与正式任务链，需要补充
- 建议：当前可不修改；阶段一创建 coder/reviewer 时，从一开始就写入通知穿透规则
方案内容（第十二节）：
爱衣在派发任务前，先 sessions_list 检查目标 session 是否存在；若不存在，message 通知主人
⚠️ 发现的问题：
3.1 sessions_list 检查时机存在窗口期
- 爱衣检查 → session 存在 → 准备发送 → 此时 Agent session 意外退出 → sessions_send 失败
- 这是 TOCTOU（Time-of-check to time-of-use）问题，概率极低但理论存在
- 建议：sessions_send 本身如果 session 不存在会报错，爱衣捕获错误后 message 通知主人即可（错误处理比预检查更可靠）。sessions_list 预检查可保留作为友好提示，但不应作为唯一保障。
3.2 session 存在但 Agent 无响应的情况未处理
- session 存在，sessions_send 成功，但 Agent 因某种原因（模型错误、上下文耗尽）未执行任务
- 此时 lastUpdated 不会更新，heartbeat 30 分钟后检测到卡住并通知主人
- 这是已有的兜底机制，处理合理 ✅
3.3 session key 格式在方案中已明确
- 方案第十二节明确：agent:coder:main、agent:reviewer:main、agent:main:main
- 与 OpenClaw 实际 session key 格式（见当前测试）一致 ✅
4.1 任务文件系统权限问题
- workspace/tasks/ 目录由爱衣创建，coder/reviewer 是否有写入权限？
- 在同一主机上，所有 Agent 共享同一用户权限，问题不大
- 但若未来部署到不同容器/主机，需要考虑挂载共享卷或网络文件系统
- 建议：当前阶段在同一主机，忽略此问题；第三阶段扩展时评估
4.2 active.json 并发写入
- 爱衣可能同时处理多个任务，同时更新 active.json
- 当前方案无 active.json 的并发保护
- 建议：active.json 更新也应用 flock 锁保护（与 session.md 相同策略）；或使用单独的任务目录下的 status 文件代替集中的 active.json，爱衣 heartbeat 时扫描所有 status 文件
4.3 知识库内容为空时的专业 Agent 行为
- 阶段一创建 coder/reviewer 时，知识库为空
- Agent 可能因缺少项目上下文而生成不符合项目规范的代码
- 建议：在 SOUL.md 中补充「若知识库为空，优先使用通用最佳实践，并在 session.md 中注明需要主人补充项目规范」
4.4 爱衣「任务终点通知主人」的触发条件未完全明确
- SOUL.md 写「任务终点（爱衣）：用 message 工具把结果推给主人」
- 但「任务终点」的判断条件是什么？是收到特定格式通知？还是爱衣自己判断？
- 建议：在爱衣 SOUL.md 中补充：「收到 sessions_send 通知且消息中包含 task_id= 且下一步=爱衣（或无下一步） → 判定为任务终点，读取 session.md 后用 message 推给主人」
| 优先级 | 建议 | 影响 |
|---|---|---|
| 🔴 高 | 专业 Agent SOUL.md 明确「来自 Agent session 的通知 → 通知穿透规则」 | 防止 coder/reviewer 误 REPLY_SKIP |
| 🔴 高 | 爱衣 SOUL.md 明确「任务终点」判断条件 | 确保爱衣能正确推结果给主人 |
| 🟡 中 | SOUL.md 补充注释区分 ANNOUNCE_SKIP 与 message 工具 | 防止误读 |
| 🟡 中 | 用 sessions_send 错误处理替代（或补充）预检查作为主要保障 | 更可靠的容错 |
| 🟡 中 | active.json 写入加 flock 锁，或改为分散 status 文件 | 防并发���入损坏 |
| 🟡 中 | 知识库为空时的 SOUL.md 补充说明 | 提升阶段一代码质量 |
| 🟢 低 | test-agent SOUL.md 补充通知穿透规则（仅在参与正式链路时） | 当前实验用途可忽略 |
| 🟢 低 | 多主机部署时的文件系统权限（第三阶段评估） | 当前单主机无影响 |
v1.5 质量已相当成熟，三轮迭代后核心机制稳健。
阶段一执行前必须处理（🔴 高优先级）：
1. 创建 coder/reviewer 的 SOUL.md 时，明确「来自 Agent session 的通知 → 通知穿透规则，不得 REPLY_SKIP」
2. 爱衣 SOUL.md 补充「任务终点」判断条件
阶段一执行时顺带处理（🟡 中优先级）：
3. active.json 写入考虑并发保护
4. 知识库为空时的行为说明
结论：方案已可进入执行阶段。建议在创建 coder/reviewer workspace 时，将审计结论直接体现在其 SOUL.md 初稿中，不必再等待额外审计轮次。 ✅