6 效度威胁
本节按照实证软件工程研究的标准框架 [^44] 组织效度威胁:构造效度 (研究是否测量了其声称测量的内容)、内部效度 (研究发现是否源自数据)、外部效度 (研究发现是否可推广到本研究之外) 和可靠性 (研究是否可以被复现)。
6.1 构造效度
主要的构造效度威胁是单作者偏差。全部 13 个智能体的分析均由单一作者完成 (辅以 LLM 协助的代码导航,如 Section 3.4 所述),这意味着维度分类、证据选择和跨智能体比较反映的是一个人对源代码的解读。两项缓解措施部分解决了这一威胁。第一,Section 4 中的每一项分类主张都建立在固定提交哈希处的具体文件路径和行号之上 (Appendix B),使每项主张都可以独立地对照源代码进行验证。一次事后验证检查了从克隆仓库中提取的 296 项主张,确认了 267 项,修正了 19 项 (主要是由于分析日期和验证日期之间代码演进导致的行号偏移),接受了 10 项作为轻微简化 (例如,用比代码实际实现更少的步骤描述一个多步过程,或将跨越两个函数的行为归因于单个函数)。验证由进行原始分析的同一研究者完成;虽然自我验证弱于独立审核,但固定提交的证据链使独立验证变得简便。第二,分析模板将观察 (代码做了什么)、分类 (如何映射到维度) 和证据 (文件路径和行号) 分离,遵循了案例研究报告指南 [^44]。这种分离使读者可以独立于观察来评估分类。尽管如此,本研究仍将受益于第二位分析者的独立复现,尤其是在需要判断取舍的维度上 (例如,Prometheus 的图作用域状态管理是否构成一种结构性压缩的形式,还是一种独立的架构模式)。
第二个构造效度威胁涉及维度框架本身。虽然九个分析维度是在对两个架构对比鲜明的智能体进行试点分析 (Section 3.2) 时通过开放编码 [^51] 迭代得出的,但试点智能体 (Aider 和 OpenHands) 可能未能呈现所有相关维度。分析模板的开放式第十节旨在捕获预定义维度之外的观察,它产生了 47 项跨维度发现,为最终分类法提供了信息 (Section 4.4)。然而,两个试点智能体都不具备且后续智能体也未使其显著的维度仍可能被遗漏。例如,分类法不包含提示工程策略维度 (系统提示如何构建和变化)。虽然提示模板在源代码中可见,但该维度因范围原因被排除:分析 13 个智能体的提示结构、长度、少样本示例和角色指令本身就构成一项独立研究,而且在没有运行时实验的情况下,无法评估提示差异 (相对于脚手架差异) 的架构影响。这一排除是有意为之,但意味着脚手架设计的一个重要方面未被捕获。
6.2 内部效度
内部效度关注的是,观察到的模式是否真正反映了架构关系而非混淆因素。两个威胁与此相关。
第一,分类法描述的是固定提交处的源代码,但若干智能体在分析期间正处于活跃开发状态 (Section 3.4)。架构特性可能在被分析的提交与当前版本之间被添加、移除或大幅重构。固定到特定提交确保了所报告发现的可重现性,但意味着分类法是一个快照,而非实时描述。提交哈希列于 Appendix B 中,以便读者评估每个智能体自分析以来发生了多大变化。
第二,某些维度之间的独立性可能不如分类法所暗示的那样强。Section 5.3 指出,循环驱动者与检索策略存在相关性:脚手架驱动的智能体倾向于投资检索基础设施,而 LLM 驱动的智能体则依赖通用工具。其他维度之间可能存在类似的相关性 (例如,工具发现策略与工具数量之间,或状态管理与上下文压缩之间)。分类法将各维度呈现为独立的轴,但实际上它们构成一个相互依赖的设计空间,在一个维度上的选择会约束其他维度的选项。Section 4.4 的跨维度主题捕获了其中一些相互依赖性,但对维度交互的完整分析超出了本研究的范围。
6.3 外部效度
三个威胁限制了研究发现的可推广性。
第一,语料库仅限于具有可读源代码的开源智能体 (Section 3.1)。专有编码智能体 (GitHub Copilot Workspace、Cursor 的 AI 后端、Windsurf) 以及源代码经过编译或混淆的智能体 (Claude Code) 被排除在外,因为其脚手架代码不可公开检视。这引入了幸存者偏差:开源智能体可能在业务约束、专有模型访问或不同的优化目标 (用户体验与基准测试分数) 驱动的设计选择上,与专有智能体存在系统性差异。因此,分类法应被理解为描述开源设计空间,而非编码智能体的完整设计空间。
第二,13 个智能体的语料库虽然涵盖了一系列架构策略,但并非穷尽性的。分析期后发布的智能体或不符合纳入标准的智能体可能展现出分类法中未涵盖的架构模式。本研究追求的是分析性可推广性 [^59] (维度和频谱应当可用于表征新智能体),而非统计性可推广性 (智能体在维度位置上的分布并未声称代表任何总体)。随着生态系统的演进,新的维度和现有维度上的新位置都可能出现。
第三,语料库以针对 Python 语言代码仓库的智能体为主,这主要是因为 SWE-bench (主导性的评估基准测试) 仅使用 Python 项目。为多语言或非 Python 生态系统设计的智能体可能面临不同的架构约束 (例如,不同的 AST 解析需求、不同的构建和测试工具链,或不同的依赖解析模式),这可能产生此处未观察到的架构差异 [^27] [^55]。Prometheus 的 20 种语言 tree-sitter 支持和 SWE-agent 的语言无关的基于 shell 的方法表明,一些智能体已经在应对这一局限,但本分析并未系统评估架构选择如何随目标语言而变化。
6.4 可靠性
主要的可靠性威胁是可重现性。完整的分析模板 (Section 3.4) 和固定的提交哈希 (Appendix B) 使第二位分析者能够得出大体相似的观察结果,尽管分类判断 (将智能体置于连续频谱上的何处) 可能存在差异。完整的分析文档支持独立审查。
次要关切是,静态源代码分析会遗漏运行时行为。某些架构特性 (实践中的 MCP 工具发现、Moatless Tools 的可插拔选择器等可配置特性是否在典型部署中被使用) 可能只在运行时才可见。分类法描述的是架构能力,而非观察到的运行时行为。
语料库也高度集中于 Python 实现的智能体 (13 个中有 10 个);三个 TypeScript 智能体 (Cline、Gemini CLI、OpenCode) 可能使用了以 Python 为导向的分析框架不太敏感的语言习惯用法 (事件驱动架构、模块系统)。分析模板被设计为语言无关的,但分析者在注意力上的细微偏差无法排除。
最后,贯穿全文使用的 CLI/SWE-bench 类别划分 (Table 1) 是一种简化。有些智能体跨越类别:OpenHands 被归类为 SWE-bench,但也被广泛用作交互式开发工具,若干 SWE-bench 智能体也可以交互式运行。这一划分是描述性的 (用于对设计选择提供背景说明) 而非分析性的 (不作为分类法的一个维度),但读者不应将其解读为一个刚性边界。