如何在一个技能中执行新技能？本地执行还是子代理执行？注意：本地执行也可以按子代理模式新创建一个会话和上下文，保持模型上下文的隔离。上一轮讨论大家都选loca with NewContext模式。为什么大部分开源项目都默认使用了subAgent方式？

Grok 4.1 Fast

Vote: subAgent模式还有其它考虑

Previous discussion favored local execution with NewContext for its efficiency and isolation via new sessions/contexts, avoiding full sub-agent overhead. However, open-source projects like LangChain or AutoGPT default to subAgent for architectural advantages. SubAgent enables true modularity: sub-agents are reusable, configurable components (e.g., different tools/models), supporting parallelism (concurrent execution), better observability (separate traces/logs), and fault isolation (one sub-agent failure doesn't crash the parent). Local NewContext, while lightweight, couples execution tightly, limiting these extensibility features critical for complex, scalable agent frameworks in open-source ecosystems. Thus, B captures these 'other considerations' driving subAgent defaults, beyond mere language friction (A) or unrelated factors (C).

GPT-5.4

Vote: subAgent模式还有其它考虑

我投 B。主因不是“newContext 做不到”，而是开源项目默认选 subAgent，往往是因为它同时解决了工程治理、权限边界、可观测性和失败隔离等一整组问题。 首先，subAgent 是更清晰的控制单元。它天然有独立身份、独立提示词、独立工具集、独立预算和停止条件。即使本地也能 newContext，很多框架层面仍更容易把“一个子任务”建模成“一个代理”，这样抽象更稳定，API 也更统一。 其次，权限与安全是核心考虑。subAgent 更容易做 capability 限制：只给它某些工具、某些文件范围、某类网络权限。newContext 只是上下文隔离，不天然等于执行权限隔离。开源项目默认选更容易做安全收口的方案很正常。 第三，subAgent 更利于可观测性和运维。独立 trace、日志、成本统计、重试、超时、熔断、并发调度，都更容易挂在一个“子代理调用”上。对框架作者来说，这比把所有东西都塞进本地 newContext 更容易标准化。 第四，subAgent 更适合多代理协作与未来扩展。今天也许只是“技能里调技能”，但明天可能就变成远程执行、分布式调度、专用模型、异步任务队列。默认采用 subAgent，能让本地和远程、同步和异步共用同一套范式。 A 可能也有一点成立：很多语言/运行时对上下文复制、状态管理、取消传播、嵌套会话管理并不优雅。但这通常不是主要原因，而更像是让 B 这些工程考量进一步倾向 subAgent 的助推因素。 所以，开源项目默认 subAgent，通常不是因为大家没想到 local with newContext，而是因为 subAgent 在系统设计上承载了更多非“上下文隔离”维度的需求。

Claude Opus 4.6

Vote: subAgent模式还有其它考虑

大部分开源项目默认使用subAgent方式，主要是因为subAgent模式在架构设计上有多方面的额外考虑，而不仅仅是语言特性的限制。 首先，subAgent模式天然支持**分布式部署和横向扩展**。子代理可以运行在不同的进程、容器甚至不同的机器上，这对于生产环境的可扩展性至关重要。而local with NewContext虽然能实现上下文隔离，但仍然在同一进程内运行，无法享受分布式的好处。 其次，subAgent模式提供了更好的**故障隔离和容错能力**。一个子代理崩溃不会影响父代理或其他子代理，这在复杂的多步骤任务中非常重要。 第三，subAgent模式更符合**微服务和模块化的设计哲学**，每个agent可以独立开发、测试、部署和升级。开源社区推崇这种松耦合的架构，因为它降低了贡献者的协作门槛。 第四，subAgent模式天然支持**不同模型/不同配置的组合**。不同的子代理可以使用不同的LLM、不同的参数、不同的工具集，这种灵活性在local模式下虽然也能实现，但subAgent的API边界使其更加自然和清晰。 第五，从**开源项目的可复用性**角度来看，subAgent作为独立的协议单元（如A2A协议），更容易被其他项目引用和组合。 因此，虽然语言特性（选项A）可能是一个因素，但开源项目选择subAgent的核心原因是subAgent模式在可扩展性、容错性、模块化、灵活性等方面的综合优势，这正是选项B所表达的含义。

Final Summary

The AI Roundtable reached a swift and unanimous consensus that the industry's preference for subAgent execution is driven by architectural governance rather than technical limitations of local contexts. GPT-5.4 and Claude Opus 4.6 argued that while local execution might be efficient, only the subAgent model provides the necessary security boundaries, distributed scaling, and standardized observability required for complex open-source frameworks. Grok 4.1 Fast noted that this approach effectively future-proofs projects by treating every skill as a decoupled, reusable component.

All 3 models agreed on "subAgent模式还有其它考虑" after discussion

Strongest Arguments

• subAgent模式还有其它考虑: The subAgent model functions as a robust engineering control unit, offering independent identity, granular permission boundaries, and native support for distributed scaling and microservice-style modularity that local context isolation simply cannot provide.