父 Agent spawn 子 Agent 时，有哪些边界问题需要考虑？OpenClaw 做了哪些限制和保护？

🏛 业务架构师

父 Agent spawn 子 Agent 的边界问题，我归为五类，并对应 OpenClaw 的保护机制：

1. 权限边界：子 Agent 的工具权限应小于等于父 Agent（防提权）——子 Agent 配置独立声明，默认继承时做交集收紧；高危工具父子都禁。

2. 上下文边界：传给子 Agent 什么、回传什么要明确——OpenClaw 的做法是父 Agent 只传"任务描述+必要背景"，子 Agent 回传结构化结果，两边上下文不串味；子 Agent 的中间过程不自动进入父上下文。

3. 资源边界：子 Agent 也烧 token——要有独立的步数上限、token 预算、超时控制；父 Agent 的派发数量设上限（防"生孩子大军"把系统打爆），派发深度限制（禁止孙 Agent 层层套娃）。

4. 并发与稳定性边界：并行子 Agent 的失败不能拖垮整体——部分失败时父 Agent 拿到失败摘要自行决定重试或降级；子 Agent 卡死有超时熔断。

5. 审计与责任边界：子 Agent 的每个动作独立留痕，且关联到"父 Agent 链路 ID"——出了问题能回放完整链路，这是企业可审计的底线。

业务视角：这套边界设计本质是"授权管理"——像企业里经理给下属派活：讲清任务、给对权限、限定预算、要求汇报格式、出了问题可追责。没有边界的子 Agent 是失控的代理成本，有边界的子 Agent 才是真正的组织杠杆。

父 Agent spawn 子 Agent 的边界问题，我按五类风险 + 对应防护讲：

上下文边界（信息传递有损）：子 Agent 不自动继承父级上下文——任务描述必须自包含（目标、约束、输入、期望输出格式），否则子 Agent 缺背景乱干。防护：任务契约模板化，父级组装时强制 checklist；输出也要定契约（结构化结果对象），父级拿到的是结论不是流水账；
权限边界（权限放大攻击）：子 Agent 若继承全部工具权限，被诱导的子任务可能越权。防护：子 Agent 声明最小工具集与数据范围（OpenClaw 的做法：spawn 时显式指定工具子集与资源配额），敏感操作一律不授予子级；
资源边界（失控放大）：子 Agent 死循环、递归 spawn（子生孙、孙生曾孙）会指数级烧钱。防护：深度上限（如只允许一层）、子级预算硬顶（token/时长/步数独立核算）、并发数上限，超限强杀并回报错误；
生命周期边界：父级崩溃时子 Agent 成孤儿继续跑。防护：父子生命周期绑定（结构化并发思想——父取消则子级级联取消），子级超时父级要有接管/放弃策略；
错误传播：子 Agent 失败不能让父级整个任务崩——错误作为可处理的结果返回，父级决定重试、换方案或降级。

架构总结：子 Agent 的本质是"受控的分布式进程"——进程隔离、配额、级联取消、契约通信，四大件缺一不可。

父 Agent spawn 子 Agent 的边界问题，我按六项 checklist 处理（每一项都对应 OpenClaw 做的限制）：

上下文边界：传什么不传什么——只传任务 brief + 必要背景事实，不传父对话全量（污染+泄密）；子返回摘要而非全轨迹。防「上下文泄漏」和「摘要丢失关键信息」是一对矛盾，brief 要结构化（目标/输入/约束/期望输出格式）。
权限边界：子 Agent 权限 ⊆ 父权限（不能自我提权）；更严格的做法是子 Agent 用独立策略管道，默认只读，写操作显式声明。子 Agent 产生的 confirm 请求要路由回父或原用户，不能自己批自己。
资源边界：步数上限（子任务 max_steps 独立计算）、token/金额预算、超时时钟；并发 spawn 数量限制；递归深度限制（子派孙最多 2 层，防指数爆炸）。
失败传播：子失败≠父失败——错误分类处理（可重试的自动重派、参数错的改写 brief、彻底失败则父降级方案）；子超时要有部分结果回收机制。
生命周期：父结束/取消时子必须级联取消（孤儿 Agent 是资源黑洞）；子完成任务但父已超时，结果走死信队列。
可观测与审计：父子链路共用 trace_id，树状展示派生关系；子 Agent 的所有工具调用同样过审计——权限越小越容易被忽略，但恰恰是审计盲区高发地。

血泪教训：早期没做级联取消，CI 场景父任务超时后子 Agent 还在跑了两小时烧 token——从此取消传播写进了框架测试用例。