想象一下一个前端项目准备迁移上下文“山”高得不可承受。

一、一次性子任务为何无法覆盖协作场景

传统子 Agent 在完成任务后返回一段并结束生命周期。对代码检索或定位问题足够用，但在需要多轮迭代、持续反馈的团队协作中显得捉襟见肘。说到例如，

• 主 Agent 让队友 A 检查建立配置；
• 队友 A 发现别名规则可能影响测试，需把信息传回主 Agent；
• 主 Agent 接收后再追加新的检查要求。

这里需要的是异步投递与接收消息的通道而不是仅在任务结束时一次性返回文本。

使用者痛点：当子任务累积过多时上下文被塞满导致模型误判；缺乏实时沟通会延迟问题修复。老实说，

二、队友启动后拥有一段独立对话

主 Agent 调用 spawn_teammate 时程序会创建守护线程。并为每个队友准备：

• 新程序提示词
• 单独的消息列表
• 限制工具集
• 上下文保留最近若干条消息，以保持相对独立且长度可控。

messages =
sub_tools =
for _ in range:
inbox = BUS.read_inbox
response = client.messages.create(
model=MODEL,system=system。messages=messages,# 保留最近 N 条
tools=sub_tools,)

User Pain Point: 队友只能看到最初任务，若需要持续共享状态就必须通过额外机制，否则信息孤岛会导致重复工作。

角色与权限限制

角色本质上是程序提示词，例如 “tester” 或 “frontend developer”。所有队友默认拥有同等文件读写权限和 Shell 执行能力；角色帮助聚焦工作内容，却无法替代权限控制。若不加细粒度权限管理，可能出现不经意间修改关键配置文件的风险。

三、队友结果怎样写入收件箱

s15 的消息总线采用极简设计：每个 Agent 对应一个 JSONL 文件。发送时向目标文件追加一行 JSON；读取时读取完整文件并删除，以避免重复消费。

def send:
inbox = MAILBOX_DIR / f"{to_agent}.jsonl"
with open as f:
f.write + "
")
def read_inbox:
inbox = MAILBOX_DIR / f"{agent}.jsonl"
msgs =
inbox.unlink
return msgs

`config-reviewer` 完成检查后将结果写入主 Agent 的收件箱 `.mailboxes/lead.jsonl`。每条记录包含发送者、接收者、文本内容、类型和时间戳。

• User Pain Point:- 长消息被截断，只保留前 N 字符；长报告难以完整呈现给主 Agent。
• - 读取后即删除，若读取失败或网络异常将导致信息丢失。

四、主 Agent 为什么能在没有使用者输入时收到结果

Around main loop we added a polling thread that checks every second wher lead mailbox contains unread messages.

if BUS.peek or has_pending_background:
events.put)

The event queue mixes user input and async notifications. When a “wake” event arrives。we read mailbox contents and inject m as a pseudo‑user message before starting a new agent loop.

inbox = BUS.read_inbox
history.append({
"role"的观点是，"user","content": "
" + inbox_text,})
agent_loop

• User Pain Point:- 主循环被打断后仍需等待下一轮模型调用，否则可能错过紧急通知。
• - 当前实现只保留前 N 字符，对于长结论只能看到开头；未提供补全或重试机制，老实说，
• - 异步唤醒保证了即使使用者停留。也能及时处理队友结果，提高效率。

五、共享工作目录带来的协作风险

• 冲突风险： 两个队友同时修改同一文件。写操作顺序决定最终内容，先写者可能被覆盖而无任何提示。
• 缺乏锁： 教学代码没有为文件写入加锁。也未为每个队友分配独立分支或工作目录，所以共享目录易引发竞争条件。
• 状态跟踪不足： 主 Agent 收到两份“已完成”的报告，却只能看到磁盘上的最终一次写入版本；无法判断哪份更可信或是否需要复核。
• 错误恢复缺失： 如果某个队友执行失败，它仍会尝试发送但未捕获异常导致信息丢失或错误汇报给主 Agent。

说到解决思路。

使用乐观锁或版本号来防止覆盖：在每次写前读取当前版本号并比较，如冲突则重试或报错。
为关键文件设定专属分支。每个队友提交到自己的分支，再由主代理合并。
引入事务式消息程序，保证有序可靠消费。
提供可视化状态面板，让团队成员实时查看谁在做什么还有最新状态。

小结 & 接下来：

目前实现已完成“独立上下文 + 异步消息 + 主代理回收”的主要流程，但仍缺少可靠交付与冲突协调。
下一章节将主要讨论团队协议，包括：
空闲等待机制——让团队成员知道何时可以安全退出；
关闭请求与权限审批——确保只有授权人员才能修改关键文件；
可靠关闭与持久化日志——防止因进程崩溃导致信息丢失；
.

"