我们检查了每一份依赖清单，并在每棵源码树中检索广泛部署的智能体框架的导入：LangChain、LangGraph、LlamaIndex、AutoGen、CrewAI、Pydantic AI、Genkit、Haystack agents、Semantic Kernel、Google 的 ADK，以及若干更小的库（Smolagents、Swarm、Agno）。 在约 400 万行 Python、TypeScript 与 Rust 中，没有任何生产级智能体代码路径导入其中任何一个——这个结果值得从两个方向品味：Gemini CLI 连 Google 自家的框架（Genkit、ADK）都不用，而 Hermes 中仅有的 “LangChain” 字符串位于捆绑技能的文档里，教智能体用户可能会怎么用向量数据库。 两个边界情形值得精确说明。 Aider 随附一个可选的框架相邻扩展：其 /help 命令可以安装 llama-index，对 aider 自己的文档跑 doc-RAG——这是一个可选的功能依赖，不是智能体循环编排。 而 OpenCode 把内层的 LLM/工具管线委托给 Vercel 的 AI SDK——那是一个供应商抽象层，不是智能体编排框架，但它是语料库中第一个内层循环管线是第三方 SDK 的系统（一个自研替代客户端藏在特性开关之后，暗示该依赖是过渡性的）。

每个循环都用宿主语言的原生原语手写：asyncio（OpenHands、Mistral Vibe、Hermes）、阻塞式同步 Python（Aider、Mini-SWE-Agent）、Promise/异步迭代器（Claude Code、Gemini CLI、Pi、OpenCode、OpenClaw）、Tokio（Codex）。 每个工具注册表都围绕 Pydantic、Zod、TypeBox、Effect Schema 或 Rust 枚举定制构建。 每个提示词模板都是朴素的 Markdown、Jinja2 或字符串拼接。

另一场平行的搜索覆盖向量库依赖（Chroma、Pinecone、Weaviate、Qdrant、Milvus、FAISS、LanceDB、sqlite-vec、向量模式的 Elasticsearch）、嵌入库，以及匹配 embedding、vector_store、vectordb、rag 或 retrieval 的目录或文件。 对代码检索而言，结果不变且如今覆盖 11 个系统：零。 例外都关乎会话记忆，而这里 7 月的图景确实变了：OpenClaw 的默认记忆插件（memory-core）现在跑混合的 sqlite-vec KNN + FTS5/BM25 检索，嵌入默认开启（供应商默认 OpenAI；本地 GGUF 模型可选；4 月时代的 LanceDB 扩展作为可选插件幸存），使 OpenClaw 成为唯一嵌入默认开启的系统——为了聊天召回，从不为了读源码树。 Hermes 在规模上展示了相反的选择：其核心的过往会话检索刻意是词法性的（触发器维护的 SQLite FTS5，BM25 加面向中日韩的三元组分词，“任何地方都没有 LLM 调用”），嵌入只限于可选的记忆插件。

11 个系统在代码检索上用什么取代了 RAG，汇总于表 13。

第一个缺席印证了智能体设计者自己的建议。 Schluntz 与 Zhang 的 Building Effective Agents [16] 警告框架“常常制造额外的抽象层，遮蔽底层的提示词与响应，使它们更难调试”，并建议从原始 SDK 调用出发。 那条建议出现在 2024 年 12 月；我们 2026 年在这里跑的源码审计表明，每一家商业供应商都照做了。 值得指出这一点，因为更广的 Python LLM 应用社区在同一时期一直在框架抽象上持续投资。 生产级 SWE 智能体看起来运行在与通用 LLM 应用不同的复杂度预算上。 一旦智能体开始修改真实源码，手写可调试代码就胜过可复用抽象，因为失败模式（静默的提示词损坏、不透明的缓存、版本不兼容的工具 schema）变得昂贵到无法耸肩带过。

第二个缺席与 Rajasekaran 等人 [19]（2025 年 9 月）的近期建议一致，他们偏好“即时”（JIT）检索并推荐混合方案：“我们不记忆整个信息语料库，而是引入文件系统、收件箱和书签之类的外部组织与索引系统，按需取回相关信息。” 那篇博文没有断然拒绝预索引检索，但它的实操建议全都指向 JIT 方法。 语料库中每个系统都遵循这一路径，即便面向仓库的代码检索是一个被充分研究过的领域：RepoCoder [60]、RepoBench [61] 与 CrossCodeEval [62] 都为代码构建检索管线，Long Code Arena [64] 提供匹配的长上下文评测。 Wang 等人的 CodeRAG-Bench [63] 恰好提出本节的问题——“检索能否增强代码生成？”——并发现增益跨任务高度可变：对文档查询与库使用场景可观，而对模型已有足够参数知识的任务则边际或为零。这些增益的不一致性，或许有助于解释为什么生产级 SWE 智能体干脆跳过 RAG 层，而不投资于任务依赖的检索路由。 原因是领域特有的。 代码携带稠密的确定性结构元数据——文件路径、语言服务器、tree-sitter 解析、类型信息——语义相似度检索无法复制它们（而 RepoAgent [65] 与 Aider 的 RepoMap 之类的结构感知工具直接利用它们）。 代码每分钟都在变，预索引的嵌入几乎从构造上就是陈旧的。 每个编码环境都已经内置了一个近乎最优的检索系统：ripgrep、find 与 glob。 在典型的 SWE 智能体任务上，RAG 增加运维成本（嵌入计算、向量库维护、漂移管理）却不提供边际价值。

观察 9。更广的 LLM 应用文献视为核心的两项技术，在全部 11 个系统中缺席——这一发现挺过了语料库三倍扩容和为期三个月的复审。没有任何系统在智能体运行时使用通用智能体框架（检查了 LangChain、LangGraph、AutoGen、CrewAI 等十余个；Gemini CLI 连 Google 自家的都不用）；每个循环都用宿主语言的异步原语手写，OpenCode 把供应商抽象 SDK 用于内层管线是最接近的边界情形。没有任何系统用向量嵌入 RAG 做代码检索；全部依赖 ripgrep、tree-sitter、glob 与自动发现的 Markdown 上下文文件，而在需要会话规模召回的地方，生产级的答案是词法检索（Hermes 的 SQLite FTS5），或者——恰有一个默认配置（OpenClaw）——对聊天历史的混合嵌入，从不对源码树。生产级 Harness 运行在与通用 LLM 应用不同的复杂度预算上：当失败模式是修改真实代码时，可调试性与提示词透明度压过框架复用。第 14.2 节给这个缺席以历史解答。

观察 10。Anthropic《Effective Agents》工程系列（2024 年 12 月至 2025 年 9 月）描述的架构模式，与四个厂商原生系统（它们独立构建）中观察到的架构高度吻合。这反映的是共享的经验现实、公开指南的影响，还是两者皆有，是一个开放问题。

Mini-SWE-Agent 的极简脚手架据报道在 SWE-Bench Verified 上达到 74%+，而 Codex 大得多的代码库报告 69.1%。 这些数字不可直接比较（底层模型不同、评测运行不同、部署配置不同：Mini-SWE-Agent 无沙箱而 Codex 有沙箱），我们不从中得出正面对比的结论。 但这一差距在性质上说明：Codex 的额外代码并未投在原始的任务完成逻辑上；相当大的份额进了安全（跨平台沙箱）、用户体验（TUI、流式）、可扩展性（MCP、插件）与稳健性。 在生产级脚手架是否能在同等条件下的同一基准上产生可测量的改进，是本研究不回答的开放问题（效度威胁见第 15 节）。

安全基础设施更多的系统（Codex、Claude Code）给智能体动作施加更多摩擦。 安全更少的系统（Mini-SWE-Agent、Aider）执行更快，但若无额外保障则不适合企业部署。

Claude Code 与 Codex 利用供应商专属特性（提示词缓存、扩展思考、模型专属提示词），代价是厂商锁定。 基于 LiteLLM 的系统以供应商灵活性换掉这些优化。

Codex 的 126-crate、百万行 Rust 工作区为类型安全与性能优化。 Mini-SWE-Agent 的单文件智能体最大化可理解性。 Pi 把整条轴搬进运行时组合：极简内核加扩展事件总线。 OpenClaw 的插件 SDK 与 OpenCode 的客户端/服务器拆分分别服务于可扩展性与可嵌入性。 光谱上的每个点服务不同的用户群体。

这是哲学上最有意思的一条轴。 Mini-SWE-Agent 有竞争力的基准表现证明，当前模型已足够强大，可以用极简脚手架成功。 生产级系统投资脚手架，不是因为模型完成任务需要它，而是因为用户需要它带来的安全、可靠性与工作流集成。