7 结论

本文提出了一套针对 13 个开源编码智能体脚手架的源代码级架构分类法,组织为三个层次 (控制架构、工具与环境接口、资源管理) 和 12 个维度。每一项分类主张都建立在固定提交处克隆仓库的文件路径和行号之上,提供了一个可独立验证的证据基础,并可随生态系统的演进而扩展。

分析得出三项发现。第一,脚手架架构更适合被表征为沿连续频谱的位置,而非离散类型的实例。控制策略的范围从固定流水线到完整的蒙特卡洛树搜索 (Monte Carlo Tree Search);工具数量从 0 到 37;上下文压缩跨越七种不同策略;状态管理从破坏性覆写到事件溯源。此前基于能力的分类法将智能体归类为 "工具使用型" 或 "规划型",无法区分在这些维度上存在根本差异的系统。第二,控制架构底层的循环原语 (ReAct、生成-测试-修复、计划-执行、多次重试、树搜索) 作为可组合的构建块发挥作用:13 个智能体中有 11 个叠加了多种原语,而非依赖单一控制结构。这种可组合性意味着设计空间是组合式的而非类别式的,给一个系统贴上单一架构标签会掩盖区分它们的设计决策。第三,各维度本身呈现出一种模式:在外部约束的选择上趋同 (工具能力类别、编辑格式、执行隔离),在开放设计问题上分化 (上下文压缩、状态管理、多模型路由),这指示了设计空间的哪些部分已经稳定,哪些部分最需要研究投入。

基于该分类法,可以展开以下几个方向的未来工作。最直接的扩展是受控实验:12 个维度识别了可以在保持其他变量不变的情况下单独隔离的具体架构变量。例如,比较工具集相同但循环策略不同的智能体,或循环相同但压缩策略不同的智能体,同时保持模型不变,这将使性能差异能够因果归因于脚手架设计,而非当前基准测试比较无法解开的模型或配置混淆因素 (Section 5.5)。分类法提供了变量;设计实验是下一步。

第二个方向是纵向分析。分类法描述的是 13 个智能体在固定提交处的快照。在后续提交处重复分析,将揭示脚手架架构如何演进:趋同的维度是否继续趋同,分化的维度是否趋于稳定,以及随着生态系统成熟是否出现新的维度。固定提交的方法论使这种纵向比较变得简便。

第三,将语料库扩展到专有智能体 (当架构细节通过文档或逆向工程变得可用时) 以及针对 Python 以外语言的智能体,可以检验所观察频谱的可推广性 (Section 6)。维度框架被设计为语言和平台无关的,但此处观察到的具体位置是否可推广到不同生态系统,仍然是一个开放问题。

最后,分类法使此前工作所呼吁 [^50] 但因缺乏架构文档而无法实现的架构感知评估指标成为可能。将具体的维度位置 (循环策略、压缩方法、工具集设计) 与可观测结果 (任务成功率、Token 成本、轨迹长度) 关联起来,将推动该领域从系统级排行榜迈向对编码智能体有效性的组件级理解。