子 Agent（Subagent）模式有什么优势和挑战？父 Agent 调用子 Agent 时需要考虑哪些边界问题？
- 标签：AI、大模型、Agent
🏛 业务架构师
子 Agent 模式的优势、挑战与边界问题：
优势：
- 上下文隔离：子任务的海量中间结果（全库搜索、长文档分析）留在子 Agent 的独立上下文里，主 Agent 只接收结论——主上下文保持干净，这是最硬的技术价值；
- 专业分工：子 Agent 各配专属 System Prompt、工具包、模型规格（检索用快模型、写作用强模型）——单环节质量更优；
- 并行提速：可拆分任务并行执行，墙钟时间数倍缩短；
- 权限收窄：子 Agent 权限可以比父更小，风险面收敛。
挑战：编排复杂度上升（结果怎么聚合、冲突怎么裁决）、调试链路变长（跨 Agent 追踪）、成本归属要清晰计量、失败传播要设计（子失败父怎么办）。
父调用子的边界问题：权限边界（子权限≤父，防提权）、上下文边界（传任务摘要不传全量历史，回传结构化结论）、资源边界（子的步数/token/超时独立限额；派发数量与深度设上限，防"子生孙"套娃失控）、审计边界（子的每个动作关联父链路 ID，全程可回放）、失败边界（部分失败时父决定重试/降级/放弃，不能无限重生）。
业务判断：多 Agent 是"组织设计"不是技术炫技——什么时候拆子公司（独立 BU）、什么时候派专项小组（临时子 Agent）、什么时候一个人干（单 Agent），逻辑与企业组织管理同构。能用单 Agent 解决的别拆，拆是为了隔离与并行，不是为了架构图好看。
🏗 系统架构师
Subagent 模式 = 父 Agent 把子任务 spawn 给独立的子 Agent 实例执行，各自有独立上下文、工具集、预算。我按优势、挑战、边界问题讲：
优势：
- 上下文隔离：子任务知识量大时（各读几十篇文档），子 Agent 各自持有上下文，父级只收结论——父级窗口不被打爆（MapReduce 模式）；
- 并行加速：独立子任务并发执行，墙钟时间除以 N；
- 专业分工：子 Agent 可配专用 System Prompt 与工具集（代码 Agent、测试 Agent），行为更精准；
- 权限隔离：不可信操作（跑用户代码）放在最小权限子 Agent 里，爆炸半径受控。
挑战：
- 信息传递有损（子不继承父上下文，交接靠任务契约）；成本倍增（每个子 Agent 独立循环计费）；调试链路变深（跨 Agent 追踪要全链路 trace）；生命周期管理复杂。
父调子必须考虑的边界问题：
- 上下文边界：任务描述自包含（目标/约束/输入/输出格式四要素），输出走结构化契约；
- 权限边界：子 Agent 显式授予最小工具集，禁止继承全部权限（防权限放大）；
- 资源边界：子级预算硬顶（token/步数/时长）、递归深度上限（防子生孙指数爆炸）、并发数限制；
- 生命周期绑定：父取消则子级联取消（防孤儿进程）；子超时父级有接管/放弃策略；
- 错误传播：子失败作为可处理结果返回，父级决定重试/换法/降级，不让整体任务崩。
架构本质：子 Agent 是"受控的分布式子进程"——隔离、配额、级联取消、契约通信四大件齐了才生产可用。
💻 全栈开发专家
子 Agent 模式的优势和挑战，以及父调子时的边界问题：
优势：
- 上下文隔离：子任务的大量中间结果（日志、代码、搜索）留在子 Agent 的独立窗口，父只收结论——这是解决上下文膨胀的架构手段；
- 专业化：每个子 Agent 可以有专属的 system prompt、工具集、甚至不同的模型（代码任务用代码强模型，研究用长上下文模型）；
- 并行加速：独立子任务并发执行（扇出-收集），墙钟时间大幅缩短；
- 权限最小化：子 Agent 权限可以小于父，限定它能碰的范围。
挑战：
- 通信损耗：任务 brief 传递有信息损失，子理解偏差导致返工；
- 协调成本：失败传播、超时、取消、结果质量参差都要处理；
- 成本放大：每个子 Agent 都是完整循环，token 成本翻着涨；
- 调试复杂：树状执行轨迹，定位问题要跨层。
父调子的边界问题（checklist）：
- 上下文边界：传 brief 不传全量对话；子返回摘要不返回轨迹；敏感信息按需传递（子不需要知道用户身份时匿名化）；
- 权限边界：子权限 ⊆ 父权限；子产生的 confirm 请求路由回父/用户，不能自批；
- 资源边界：独立步数/token/时间预算；并发上限 3~5；递归深度 ≤2；
- 生命周期边界：父取消级联取消子；子孤儿检测（父不在了主动自杀）；
- 结果信任边界：子的产出要校验（schema/规则），不能盲信——「子 Agent 幻觉了」是父错误答案的常见来源。