inbox receive 广播消息读取失败 — 非成员身份时静默查找错误目录

[34262315716]

What happened?

clawteam inbox broadcast 广播消息后，团队成员（architect、engineer、ux-designer）运行 clawteam inbox receive <team> 时报告"没有新消息"，但实际上消息文件已经正确写入各成员的 inbox 目录。

根因分析：

主 agent 调用 clawteam inbox receive rp-tavern（不带 --agent 参数）时，流程如下：

1. AgentIdentity.from_env() 返回 agent_name='agent'（主 agent 的 CLI 身份）
2. TeamManager.resolve_inbox('rp-tavern', 'agent', '') 查询团队配置，发现 'agent' 不是团队成员，返回原名 'agent'
3. MailboxManager.receive('agent', ...) 查找 ~/.clawteam/teams/rp-tavern/inboxes/agent/ → 空的

而 clawteam inbox broadcast 发送消息时，会排除发送者自己（主 agent），只发给注册的团队成员（architect、engineer、ux-designer）。消息正确写入了三人的 inbox，但 receive 命令跑去了空的 agent/ 目录查找。

结论： receive 在调用者身份不是团队成员时，静默地查找了错误的 inbox，而不是回退到 leader 的 inbox 或报错。

Steps to reproduce

环境： 已有至少 3 名团队成员（architect、engineer、ux-designer）的 rp-tavern 团队

复现步骤：

1. 主 agent（或任意非团队成员身份的 agent）向团队广播消息：

   clawteam inbox broadcast rp-tavern "测试消息"

2. 确认消息文件已写入（直接查看 inbox 目录有内容）：

   ls ~/.clawteam/teams/rp-tavern/inboxes/architect/
   cat ~/.clawteam/teams/rp-tavern/inboxes/architect/*.json | jq

3. 在某成员终端运行 clawteam inbox receive：

   clawteam inbox receive rp-tavern

4. 输出：没有新消息。（实际消息已存在于 inbox 目录）

变通方法： 使用 --agent 指定收件人可正常读取：

clawteam inbox receive rp-tavern --agent architect

Environment

• OS: Ubuntu 24.04.4 LTS (Noble Numbat)
• Python version: Python 3.12.3
• ClawTeam version: v0.3.0+openclaw1
• OpenClaw version: OpenClaw 2026.4.11 (769908e)
• Spawn backend: tmux (tmux 3.4)

Relevant logs or error output

## Proposed Fix

**方案一（推荐 — 改动最小的修复）：**

在 `commands.py` 的 `inbox_receive` 函数中，当 `resolve_inbox` 返回的名称不是团队成员时，回退到 leader 的 inbox：


# After resolve_inbox, check if it's actually a member
member = TeamManager.get_member(team, agent_name, identity.user)
if member is None:
    leader_inbox = TeamManager.get_leader_inbox(team)
    if leader_inbox:
        agent_name = leader_inbox  # Fall back to leader's inbox


**方案二（团队设置修复）：**

在创建团队时，确保主 agent（spawner）的身份被注册为团队成员，或在 `resolve_inbox` 返回非成员名称时输出明确提示（而不是静默返回原名）。

**方案三（文档补充）：**

在 README 中说明：主 agent 调用 `receive` 时需要使用 `--agent` 参数指定目标成员 inbox。

[AliceLJY]

感谢详细的根因分析和复现步骤，问题真实。

修复方向

方案一（leader fallback）是最小改动路径，但建议略作调整以保持行为透明：

方案一 + 日志提示（推荐）

在 inbox_receive 中，当 resolve_inbox 返回的名称不是团队成员时：

member = TeamManager.get_member(team, agent_name, identity.user)
if member is None:
    leader_inbox = TeamManager.get_leader_inbox(team)
    if leader_inbox:
        click.echo(f"[info] caller '{agent_name}' 非团队成员，回退到 leader '{leader_inbox}' 的 inbox", err=True)
        agent_name = leader_inbox
    else:
        click.echo(f"[warn] caller '{agent_name}' 非团队成员且 team 无 leader 配置，使用 --agent 指定接收方", err=True)

这样保留方案一的"开箱即用"体验，同时不静默切换身份（用户能看到发生了什么）。

几点对比

方案	用户体感	语义清晰度	推荐度
纯方案一（静默 fallback）	好	中（语义漂移）	⚠️ 别静默
方案一 + info 日志	好	高	✅ 推荐
纯方案二（报错要求 --agent）	差（强制加参数）	最高	可选
方案三（仅文档）	一般	中	不够，bug 还在

语义上的思考

广播消息时已经排除了发送者（主 agent），那么主 agent 在"收"消息时，最合理的语义就是"收被广播发给团队的消息"= leader inbox。这正是方案一的思路，只是要告诉用户这件事发生了。

关于 --agent 参数

建议保留（方案一不替代 --agent）。--agent architect 的场景是主 agent 代替某个成员拉它的 inbox，这个用例仍然存在。

欢迎提 PR 实现（方案一 + 日志提示），我 review + merge。测试点：

1. 主 agent（非成员）调用 inbox receive → 收到 leader inbox 内容 + info 日志
2. 成员调用 inbox receive → 收自己 inbox（现有行为不变）
3. 主 agent 调用 inbox receive --agent xxx → 收 xxx 的 inbox（显式覆盖）
4. 团队无 leader 配置 → 打 warn 不 fallback