把 LLM 用作自主编码智能体的概念，随着 SWE-Bench [1] 而兴起——一个要求端到端解决真实 GitHub 议题的基准。 SWE-Agent [2] 提出了智能体-计算机接口（Agent-Computer Interface, ACI），为 LLM 提供专门的文件查看与编辑工具。 CodeAct 范式 [3] 提议把智能体动作统一为可执行代码，论证这可以涵盖离散的工具调用。 ReAct [4] 确立了支撑当今绝大多数智能体架构的推理-行动循环。

此后出现了第二波面向 SWE 的智能体。 AutoCodeRover [44] 用 AST 感知的检索和基于频谱的故障定位取代文本搜索。 MASAI [48] 把议题解决管线分解为模块化的子智能体，并在 SWE-Bench Lite 上报告了成本感知的结果。 MAGIS [47] 与 CodeR [46] 都为议题解决形式化了基于角色的多智能体协作（MAGIS 中的经理/保管员/开发者/测试，CodeR 中的显式任务图）。 Lingma SWE-GPT [49] 把基础模型与软件工程过程循环联合训练，是我们在第 7 节考察的模型-智能体协同设计的一个实例。 SWE-Search [52] 在智能体轨迹上叠加蒙特卡洛树搜索（延续了 Tree of Thoughts [70] 与 LATS [73] 的基于搜索的推理路线，Plan-and-Solve [71] 是其中更简单的先声），Diversity-Empowers-Intelligence [53] 则在元策略下集成异构智能体。 在设计光谱的另一端，Agentless [51] 报告固定的“定位/修复/验证”管线在 SWE-Bench Lite 上足以与智能体循环竞争——在讨论智能体化复杂度是否必要时，这是一个有用的制衡。 OpenHands 平台论文 [45] 为我们在第 6 节审计其源码的系统提供了经同行评审的依据。 与本研究同期，Lin 等人 [85] 提出智能体 Harness 工程（Agentic Harness Engineering, AHE），利用可观测性驱动的反馈自动演化智能体 Harness（工具、中间件、记忆、子智能体配置）。 从与 Mini-SWE-Agent 相当的纯 bash 种子出发，他们的系统在 SWE-Bench Verified 上达到 71.9%，且演化出的 Harness 可跨模型家族迁移。 其组件级消融为我们通过源码分析独立得出的架构侧重提供了定量佐证：工具、中间件与长期记忆承载了改进，而系统提示词本身并不能。

关于智能体架构的既有工作 [5, 6, 66] 识别出了工具使用、记忆管理与规划等共性模式。 多智能体维度由 Guo 等人 [67] 详尽覆盖；面向 SWE 的子集由 Liu 等人 [68] 绘制；AgentBench [69] 提供了标准的跨域评测 Harness。 这些综述在概念层面运作，描述存在哪些组件，而非它们如何实现。 本文以具体实现为地基进行架构分析，与它们互补，并表明“同一种”模式（如工具使用）在实践中容许相当大的变异。

本研究在方法上最近的亲缘，是与我们 4 月版同期开发的 Rombaut《Inside the Scaffold》[34]：对 13 个开源编码智能体脚手架在固定 commit 上的源码分类，组织为三层十二维（控制架构；工具/环境接口；资源管理），并给出一个有用的发现：多数智能体组合多种循环原语（ReAct、生成-测试-修复、计划-执行、重试、树搜索），而非实现单一一种。 两研究互补而非重复。 Rombaut 的语料库仅限开源，偏向面向基准的管线（AutoCodeRover、Agentless、Moatless Tools、DARS、Prometheus、SWE-agent），并因缺乏公开源码而明确排除 Claude Code。 我们的工作则在源码级覆盖全部四个厂商原生 Harness（包括流传的 Claude Code 快照）、网关与元 Harness 对照点，以及最新的大规模采用系统（Hermes、Pi），并把分析延伸到他的分类法未触及的维度：执行隔离之外的权限与安全架构、多智能体编排、可扩展性接口（Hook、技能、插件、MCP）、提示词内容、智能体间协议，以及第 14.5 节与第 14 节的纵向与平台分析。 他的十二个维度映射到我们的七个子系统如下：控制循环策略、循环驱动器与控制流实现细化我们的 D1；工具集设计、编辑/补丁格式与工具发现策略细化 D3；上下文检索范式、状态管理、上下文压缩与持久记忆细化 D4；执行隔离是我们 D5 的隔离那一半；多模型路由是 D2 的一个格子。 凡他的词汇比我们更锋利之处（循环原语组合），我们直接采用。

近期工作探索了面向软件工程的多智能体协作。 MetaGPT [7] 为不同智能体分配专门角色（产品经理、架构师、工程师）。 ChatDev [50] 独立发展，围绕聊天链通信组织角色扮演式的开发管线。 AutoGen [8] 提供多智能体对话框架。 Magentic-One [9] 实现了带专门子智能体的编排器模式。 具体到编码，MAGIS [47] 与 CodeR [46] 把角色分解与任务图配对，Chain-of-Agents [72] 让子智能体在长输入上级联。 本研究的若干系统纳入了多智能体模式，使这些方案能在单一领域内直接比较。

Toolformer [10] 证明 LLM 能够学会使用外部工具。 Gorilla [11] 表明，在提供文档时 LLM 能生成准确的 API 调用。 ToolLLM [58] 把工具使用评测扩展到 16,000+ 个真实 API，AnyTool [59] 则为大型 API 表面演示了分层工具路由。 Model Context Protocol（MCP）[12] 提出了把 LLM 连接到外部工具与数据源的标准接口。 本文分析发现，MCP 已成为跨系统的可扩展性标准，被所研究的 11 个系统中的 8 个采用（全部四个厂商原生智能体，外加 OpenHands、Hermes、OpenCode 与 OpenClaw）。

与学术综述互补的一条线索，是主流 LLM 供应商直接发布的工程指南。 2024 年 12 月至 2025 年 9 月间，Anthropic 发布了四篇文章，共同阐述了一套连贯的智能体设计哲学： (i) Building Effective Agents [16]，对比“工作流”（预定义代码路径）与“智能体”（LLM 主导的动态过程），列举五种可组合模式（提示词链、路由、并行化、编排者-工作者、评估者-优化者），并明确警告不要使用通用智能体框架； (ii) Effective Context Engineering for AI Agents [19]，把“提示词工程”重构为“上下文工程”，记录长窗口中的上下文腐坏（context rot），推荐偏向经由 grep/tail/文件系统的即时（JIT）检索的混合方案，同时承认对特定用例预索引检索可作为 JIT 方法的补充； (iii) Writing Effective Tools for AI Agents [18]，建立在 Building Effective Agents [16] 引入的智能体-计算机接口（ACI）概念之上，建议把工具合并为“少数经过深思”的高信号操作，并报告了经提示词工程打磨的工具描述带来的 SWE-Bench 提升； (iv) How We Built Our Multi-Agent Research System [17]，一篇案例研究，报告编排者-工作者架构加并行子智能体在内部评测中超过单智能体基线 90.2%，但消耗的 token 约为单次聊天交互的 $\sim$15$\times$ 倍（该对比的基线是简单聊天，而非优化过的单智能体管线）。

把四篇文章作为一个整体来读，它们勾勒出一个预言性框架，预演了我们后来在各厂商间观察到的许多模式。 我们将其作为参考基线，用来评估所研究系统的源码级决策（尤其见第 15.1 节）。

本文研究的语料库，是从一个增长远快于追踪它的文献的领域中刻意抽出的样本。 为本修订版（2026 年 7 月）做的一次市场普查，识别出 20 多个本文未分析、但活跃维护的编码智能体 Harness；表 2 列出其中最重要的。 自本研究初版（2026 年 4 月）以来的三个进展，重塑了语料库所处的背景。³³3本小节的格局事件取自截至 2026-07-10 的厂商公告、发布说明与仓库元数据；与语料库论断不同，它们未经源码验证。