Agent Composition Boundary：Provider、Child Agent 还是 ACP Proxy？

[627150795]

这是 #314 Capability Shape and Harness Value 的运行时互操作专题。

OpenPI 如果以后要让一个 Agent 调用 Codex、Claude Code 或其他独立 Agent，需要先回答一个容易被忽略的问题：下游对象到底是什么？它是提供模型生成的 Provider、拥有独立上下文和生命周期的 Child Agent，还是只负责转发协议和事件的 Proxy？

如果把这三种对象都放在同一个 Provider 接口后面，父 Agent 就可能需要替下游 Agent 翻译 context、tool event、streaming、权限、steering、取消、重试和 Session 恢复。发生失败或迟到结果时，系统也很难判断那是一次模型 attempt、一个独立 child run，还是一次协议转发。

Goose #11384 讨论了类似问题。Goose 描述的 AcpProvider 会把外部 Agent 放在普通 model-provider 的位置，于是出现两个 Agent loop 嵌套运行的情况。维护者在回复中区分了 Provider wrapper 和真正的 Agent-to-Agent orchestration。讨论也显示，不同外部 Agent 往往有不同的 Skill、Connector、订阅方式和知识边界，扁平化成一个模型名称会丢掉重要信息。

ACP #690 提出了一个较小的 Subagent runtime surface。它把可用 Subagent 做成 Session-scoped catalog，用 capability gating 控制 delegation policy，在父 Session 的 tool call 中关联 childSessionId，并让 child 继续使用普通 Session 的恢复、取消和关闭语义。这个 RFD 仍然是设计信号，没有要求所有产品统一 manifest 文件、目录结构或 prompt syntax。

问题场景

至少要覆盖以下情况：

1. 父 Agent 调用一个只提供模型生成的 Provider；
2. 父 Agent 委派一个拥有独立 Session、权限和预算的 Child Agent；
3. Host 只转发下游 Agent 的协议、事件和结果，不接管下游语义；
4. child 失败、取消、重试、恢复或产生迟到结果；
5. 下游能力目录未知，或目录已知但为空。

先区分三种组合形态

model_provider

它只提供模型生成，使用当前 Agent loop 的 context 和 lifecycle，不拥有第二套 Agent Session。

child_agent

它拥有独立的 context、权限交集、预算、事件或 Session、取消边界和结构化结果。父子关系必须有稳定 identity，父 Agent 不能把 child 的真实执行成本压缩成一条普通模型调用。

agent_proxy

它负责把下游 Agent 的协议或事件暴露给调用方。Proxy 不应偷偷替下游做 prompt、permission 或 retry 决策，也不应把下游的独立 Session 伪装成当前 Agent loop 的内部状态。

建议的最小 Runtime contract

• dispatch 前声明组合模式，并通过 capability negotiation 确认对方支持的模式；
• child_agent 使用 Session-scoped catalog，明确区分 catalog unknown 和 empty catalog；
• delegation policy 至少能表达 auto、disable、prefer 和 require。require 不满足时应 typed-fail，不能静默 fallback；
• 父事件先关联 child identity，再允许 child 的事件流出，避免 observer 先看到没有归属的执行事件；
• child 的权限交集、预算、取消传播、恢复、retry 和 result receipt 都要有明确 owner；
• Proxy 必须声明谁拥有下游 Session、谁负责恢复、谁能看到 transcript，以及哪些事件只是转发事实。

最小可证伪实验

选一个能够通过 ACP 调用的外部编码 Agent，分别以 model_provider wrapper、child_agent Session 和 agent_proxy pass-through 接入。使用同一个任务、同一个模型和同一组工具，比较：

• 总 token、实际费用和上下文重复量；
• 取消、重试和迟到结果的处理；
• 父子 trace lineage 是否完整；
• 权限是否在 child boundary 被扩大；
• 用户是否能理解当前到底是谁在执行。

与现有工作的关系

#314 已经讨论 Child Session/Subagent 何时值得存在；其他相关工作已经覆盖委托身份与执行拓扑。这里新增的是：当下游本身是一个完整 Agent 时，Provider、Child Agent、Proxy 三种拓扑如何分类，以及最小互操作面应由谁拥有 lifecycle。

非目标

• 现在就统一所有 Agent 的 manifest 或目录格式；
• 为 Agent-to-Agent 调用建立一套与 Session 平行的完整 RPC 家族；
• 预设所有 child 都必须递归创建更多 child；
• 让 Provider adapter 代替 Runtime 拥有权限、预算和生命周期。

希望讨论的问题

1. 什么条件下，一个拥有独立 context 和 lifecycle 的下游对象必须被建模为 Child Agent，而不能继续放在 Model Provider 接口后面？
2. Subagent catalog、prefer/require、foreground/background 和 parent-child identity 是否足以构成第一版最小互操作面？
3. Child 的权限、预算、取消、恢复和成本由父 Agent、Host 还是 Runtime 拥有？
4. Proxy 应保留哪些下游事实，哪些转换会改变语义并必须被显式记录？

希望讨论最终回答：

当 OpenPI 调用一个可独立运行的 Agent 时，最小的角色分类、权限边界、生命周期归属和可验证 receipt 合同应该是什么？