执行终止为什么有两种强度？
- 触发场景: 并行协作中常出现"一个任务成功，其余任务便无需继续"——多个 Agent 分头搜索，一个命中目标后其余应立即停止;
- 优雅终止（首选）: 主 Agent 发出
terminate 信号，子 Agent 在当前步骤的安全点响应，先清理资源（关闭浏览器会话、写入未完成文件、释放锁），返回确认（ack）后退出;
- 强制终止（兜底）: 直接终止进程，仅在子 Agent 对优雅信号无响应时使用，代价是可能遗留悬挂资源与未完成写入;
- 对应关系: 两者正是 Unix 的
SIGTERM 与 SIGKILL 的区别;
主 Agent 终止后，仍在运行的子 Agent 怎么办？
- 级联终止: 借鉴 Go 的 context，终止沿创建关系向下级联——取消一个 Agent，它派生的所有子 Agent 随之取消，从根上杜绝无人认领的孤儿 Agent;
- 实现对应: 子 Agent 在安全点检查终止信号，对应 Go 中对
ctx.Done() 的轮询;
- 例外: 若确实需要脱离主 Agent、长期运行的后台 Agent（类似 Unix 的
nohup），就让它从一棵新的生命周期树起步（对应 context.Background()），显式声明不随父级终止;
异构双 Agent 协作的关键设计是什么？
- 场景: 用户只给出一个网站 URL，要求填写复杂的注册或航班预订表单，其中姓名、证件号、联系方式、地址与偏好等信息不在当前上下文中，需要向用户收集;
- 分工: Computer Agent 负责浏览器操作并充当编排者；Phone Agent 负责 ASR、LLM、TTS 与实时对话;
- 通信: 两者通过点对点工具或消息总线交换结构化消息（发送者、接收者、类型、内容）;
- 架构选择: 不需要额外的 Manager 进程——Computer Agent 可以像调用工具一样调用 Phone Agent;
- 动机: 让用户在聊天框中逐项打字较慢且易漏项或输错格式；电话 Agent 可以连续询问、确认与重问，把自然语言回答转换成结构化字段;
- 两种模式: 固定模式预先启动两个 Agent 以验证独立 ReAct 循环、双向通信与真正并行；自主模式只启动 Computer Agent，由它根据页面、已知信息与任务需要自主决定是否调用
initiate_phone_call_agent(purpose, required_info);
- 反模式: 不要用"字段数量超过阈值"这类 Python 规则代替模型决策;
- 上下文交接: 调用后把任务目的、待收集字段及格式约束作为独立上下文交给 Phone Agent;
- 并行与闭环: 每收到一个有效值就发送
info_collected，Phone Agent 不等待网页填写完成便询问下一项；Computer Agent 反馈 fill_error 或页面状态，Phone Agent 据此调整话术;
- 错误处理: 格式错误发送
format_invalid 并重新询问；超过重试次数或页面异常则安全暂停；信息收集完成后发送 task_completed，Computer Agent 校验通过再提交表单;
- 安全边界: 异常时取消仍在运行的对端并关闭浏览器、音频轨道与通话；真人语音须显式同意，提交须显式授权;
并行同构搜索如何触发级联终止？
- 场景: 给定一所大学的多个学院网站，在各学院教师名录页面中查找指定教师（如"张伟"），找到后返回其所在学院、职位与研究方向;
- 与双 Agent 的区别: 关注多个同构 Agent 的并行搜索，以及如何通过中心协调实现任务完成与资源优化;
- 并行启动: Manager 动态创建 10 个 Computer Use Agent 实例，每个实例独立进程或线程、独立浏览器会话，互不阻塞;启动时传递目标 URL、教师姓名与任务标识符（用于消息路由）;
- 实时监控: 每个 Agent 定期发送状态更新（"正在加载网站""正在解析教师名录""未找到目标，任务完成""找到匹配，详细信息如下"）;Manager 通过消息总线接收并维护任务状态表;
- 级联终止: 找到目标的 Agent 发送
{"type": "target_found", "agent_id": "agent_3", "data": {...}}，Manager 立即向其余仍在运行的 Agent 发送 {"type": "terminate", "reason": "target_found_by_agent_3"}，每个 Agent 优雅停止并发送确认，Manager 等待所有确认（或超时）后汇总;
- 终止要求: Agent 能随时响应终止信号，终止必须优雅——不留悬挂进程或未关闭的资源，同时需处理竞态条件;
- 失败处理: 为每个 Agent 设置超时（如 2 分钟），超时视为失败；错误隔离，不影响其他 Agent 继续执行;
- 汇总策略: 只要有 Agent 成功就返回信息；全部失败则报告"未找到目标教师"及各失败原因的统计;
竞态条件如何治理？
- 定义: 两个 Agent 几乎在同一毫秒内各自找到目标教师并同时向 Manager 报告"我找到了";
- 后果: Manager 收到 A 的报告后开始汇总，紧接着收到 B 的报告又触发第二次汇总，产生重复结果或互相矛盾的状态;
- 通用解法: 用"锁"机制——第一个报告到达后立即锁定状态，后续报告被识别为重复并忽略;
- 实现对应: 与管理者模式中幂等的
settle_once 是同一个问题，见 管理者模式;
- 结论: 并行带来的收益需要用串行执行的时间差来验证，同时用超时、错误隔离、锁与级联终止把并发风险关在系统内;
资源与调度要管住哪些稀缺项？
- 稀缺资源: 进程世界稀缺的是 CPU 时间与内存，Agent 世界稀缺的是 token 与并发额度;
- 职能归属: 这项职能通常落在管理者 Agent 或运行时身上;
- 预算: 启动子 Agent 时设定步数或 token 预算，超限即止，机制细节见 步骤预算与预算感知;
- 模型分级: 困难任务交给强模型，机械任务交给低成本模型;
- 并发上限: 避免几十个 Agent 同时耗尽 API 配额;
- 抢占: 并发数达到上限而更紧急的任务到来时，打断执行中的子 Agent;
管理者 Agent 的调度为什么优于传统调度器？
- 关键差异: 管理者 Agent 具备推理能力，可以启动多个子 Agent 并行探索一个问题;
- 动态调整: 根据它们的进展决定给哪些 Agent 分配更多资源，或终止看起来误入歧途的 Agent——像公司内部赛马一样;
- 成熟度: 资源与调度领域的实践远不如操作系统调度成熟，但它决定了多 Agent 系统的成本上限，应在架构设计阶段就予以考虑;