消息传递有哪些形态？
- 点对点: Agent A 直接调用
send_message_to_agent_b(content)，适用于拓扑固定、Agent 数量少的场景（如电话 + 电脑双 Agent）;
- 点对点的扩展性瓶颈: Agent 数量增多且需异步并行时，连接数随 Agent 数呈平方增长，且要求收发双方同时在线;
- 消息总线: Agent 把消息发布至总线，由总线按订阅关系转发，发送方无需知晓消费者，适合异步并行;
- 消息信封（envelope）: 结构化字段——发送者 ID、目标（指定 Agent 或广播）、消息类型（如
task_assigned/status_update/result/terminate）及 JSON 负载;
- 信封的作用: 保证接收方可靠路由与解析，并使协作链路可追溯，这是多 Agent 系统调试的关键;
用查询接口获取子 Agent 状态为什么不实用？
- 直观做法: 定义
get_subagent_status(agent_id)，返回"运行中/已完成/失败";
- 问题: 子 Agent 一经创建就立即开始执行，直到完成或失败;完成时自然会通知主 Agent，并不需要主 Agent 显式轮询;
- 结论: 状态获取更自然的做法是回到两大通信范式——消息传递或共享文件系统;
- 术语统一: 无论问答还是主动汇报，状态本身宜采用统一的状态机词汇（执行中、需要输入、已完成、失败）;
如何用消息传递获取状态？
- 拉取式: 主 Agent 发一条"进展如何"，子 Agent 在合适时机回复;
- 异步语义: 发出消息不阻塞自己的执行，对方何时回复、是否回复是另一回事——如经理用即时消息询问下属进度，而不要求对方立即停下手头工作;
- 推送式: 子 Agent 在到达关键节点时主动发消息汇报；若已架设消息总线，即往总线上发布一条
status_update;
- 标准化: A2A 协议正是把任务生命周期标准化为这样一组状态，见 跨组织协作的 A2A 协议;
如何用共享文件系统获取状态？
- 最彻底形态: 轨迹持久化（trajectory persistence）——子 Agent 把轨迹实时序列化为 JSON，追加写入日志文件，通常每个会话一个文件、每行一个事件，即 JSONL 格式;
- 主 Agent 得到的: 无需任何状态上报协议，直接读文件就能看到子 Agent 正在调用哪个工具、最近一步在思考什么、是否卡在反复失败的重试上;
- 进程语言类比: 这相当于直接读另一个进程的内存;
- 为什么不宜作为主要方式: 轨迹动辄数万 token，主 Agent 读完还得自行提炼，既费时又费 token;
- 更合理做法: 约定进度文件——启动时约定"把进度写到
progress.md"，子 Agent 每完成一项就更新任务清单，主 Agent 随时读这个轻量文件;
- 共享内存类比: 相当于两个进程在共享内存里划出一小块约定格式的状态区，暴露的是提炼后的进度，而非全部内存;
- 卡住检测: 进度文件或轨迹文件的最后修改时间超过 N 分钟无变化，即可判定子 Agent 无活动并触发超时兜底，避免被阻塞的子 Agent 拖累;
与用户可见的共享空间如何配合？
- 分工: 进度文件属于主 Agent 与子 Agent 之间的轻量控制信息;面向用户的交付物写入共享空间，见 Agent 的虚拟文件系统;
- 一致性: 进度文件不需要并发写保护，但共享空间需要乐观锁或工作副本隔离;