Checklist

• 我已经搜索过相关问题，但没有得到预期的帮助。
• 最新版本中该错误尚未修复。
• 请注意，如果您提交的Bug描述缺少相应的环境信息和最小可复现的demo，我们将很难复现和解决该问题，从而降低收到反馈的可能性，甚至该问题将被关闭。

🐞 问题详细描述

现象

database 性能诊断 benchmark 14 个 case 中，database_8（session database_8_1785424359916，team FinanceDB-Perf-Diagnosis）出现并发抢写：5 个角色（leader + agent1/2/3/5）在约 14 秒内对同一个产物文件 team-workspace/diagnosis.json 无锁并发写入，最终落盘是 agent2 的富文档（4677 字节，root_causes 结构），而非 leader 写对的最小 JSON（{"predicted_labels": ["INSERT_LARGE_DATA", "MISSING_INDEXES"]}），评测判错。

根因链（trace 实测）

1. 题目把 Output Requirement 直接发给 leader：Write your diagnosis result to a file named diagnosis.json ... format {"predicted_labels": ["LABEL1","LABEL2"]}。

2. leader 把产物要求原样塞进了 team_desc（build_team 时）：

   team_desc = "Diagnose database performance issues ... Final diagnosis must be written to diagnosis.json."

3. team_desc 被框架原样注入每个成员的 Team Info 段（prompt-attachment type="team_info"），label 为 Team Goal & Directives / 团队目标与指令。该 label 没有"仅供了解、非行动指令"的提示。

4. 成员据此误以为是行动指令。agent2 的 reasoning 原话：

   "Let me take initiative and write the final diagnosis.json based on the evidence, since the team info instructs: 'Final diagnosis must be written to diagnosis.json.'"

5. 全员汇报完成后，5 个角色各自决定"该写 diagnosis.json 了"，用 bash cat > / echo > 抢写（绕过 write_file 的写前读守卫，也无产物 owner 校验）。

6. leader 写对最小 JSON 并 cat 验证读到正确内容后，1 秒内被 agent2 的富文档覆盖。成员全程"写前不查、写后才发现竞争"（agent2: "It looks like multiple agents wrote diagnosis.json simultaneously. Let me verify."）。

参考issue: https://gitcode.com/openJiuwen/jiuwenswarm/issues/2838

详细的环境信息描述

Linux

其他辅助信息

版本信息

感谢您的贡献 🎉!