8.0
热点
AI SCORE
技术实践2026-10-15 01:47
编程 Agent 源码研究：架构比功能清单耐用
dev.to · AI#编程智能体#源码分析#工具评测
Editor brief · 编辑速览
文章围绕一份覆盖 11 款编程 Agent 的 83 页源码研究，讨论系统结构与功能清单的时效差异。作者称亲自复核了两项结论，并发现一项版本相关声明在研究指定版本中已失效。
AI 披露：本文由 AI 生成，由我的 Agent 工具链在我的指导下撰写。我设定问题，执行实测，并核实每一项主张；文中的判断由我本人作出。
Wavestone AI Lab 发布了一份长达 83 页的源码研究，分析了 11 款已投入生产使用的 coding Agent：Claude Code、Codex CLI、Gemini CLI、Mistral Vibe、OpenHands、Aider、Mini-SWE-Agent、Hermes、Pi、OpenCode 和 OpenClaw，另外还加入了一个 meta-harness 对照组 Omnigent。研究涉及约 400 万行 Python、TypeScript 和 Rust 代码，逐个子系统展开分析，并叠加了跨度为 90 天的纵向 diff。（论文编号：arXiv:2609.00006。下文涉及的规模数据均来自论文本身，我没有重新统计。）
其中一句话让我印象很深：“清单类结论（工具数量、功能表格中的条目、锁定的版本）会在几周内过时，而结构类结论（循环分类、子系统剖析，以及那些缺失的机制）迄今仍然经得起时间检验。”
于是，我亲自核查了一项清单类结论。结果，在论文点名的那个二进制版本里，它就已经消失了。
本文不是论文摘要。我想谈三件多数解读文章会略过的事：亲手复核论文中的两项主张，追问一家咨询公司为什么愿意投入资源发表这样的研究，以及为引用这篇论文的人写下使用边界。
双重缺席。 这 11 个系统都没有使用通用 Agent 框架，也没有把代码检索作为核心机制嵌入上下文循环。真正交付上线的系统走的是朴素路线：自己实现调度器，自己管理上下文。（这是论文的发现，我没有重新核实。）
Skills 正在胜出。 11 个系统中，有 9 个采用了 skills/plugin 系统，超过了采用 MCP 的 8 个。其中一个系统还随附了由 Agent 自己编写的 skill。供应链治理正在成为一个需要认真对待的问题。（数据来自论文。）
模仿带来趋同。 从跨度为 90 天的 diff 来看，各系统的架构正在趋同：后来者会模仿领先者的模式。（这是论文的发现。）
完整论文还包含对七个子系统的剖析、29 种设计模式，以及 13 项跨领域观察。信息密度很高，这里不再概述。
读到这样的论文时，我通常会在自己的设备上独立验证至少几项主张。这次的两项核查都很有意思。
论文引用了 2026 年 3 月源码快照中的两个 Claude Code 常量：AUTOCOMPACT_BUFFER_TOKENS = 13,000 和 POST_COMPACT_TOKEN_BUDGET = 50,000。论文自己的表格也提醒过：实际发布的二进制版本（“2.1.206，2026 年 7 月”）可能有所不同。
于是，我把两个版本都查了一遍。我从 npm 拉取了 2.1.206 的二进制文件，使用按单词边界匹配的 grep 搜索；随后，又对当前安装的版本（2.1.296，2026 年 10 月）执行了相同检查：
grep -aow 'AUTOCOMPACT_BUFFER_TOKENS' <2.1.206 binary> # 0 hits
grep -aow 'AUTOCOMPACT_BUFFER_TOKENS' <2.1.296 binary> # 0 hits
grep -aow 'POST_COMPACT_TOKEN_BUDGET' <each binary> # 0 hits
全部都是零命中。两个二进制文件中都能找到的，是一组换过名字的相关标识：autoCompactWindow、compact_boundary，以及 PreCompact/PostCompact hooks。过时的是旧名称，它们所描述的压缩机制依然存在，只是换了新名字。真正让我记住的是：论文早就写出了这个教训。我的核查，不过是让那句话在现场重演了一遍。
NousResearch 的 Hermes 也在研究范围之内。在停用它之前，我曾长期使用它，本地旧安装（v0.21.3）现在还留着。论文提到的两项 Hermes 特有机制——谱系压缩（通过 parent_session_id 轮换 session）和验证保护机制（verify-on-stop）——都能在我的旧安装中通过 grep 找到。
亲手使用过其中一个研究对象，也让我有了衡量其他章节可信度的参照：Hermes 那一章写到的一些细节，恰好是我实际运行这个系统才知道的。这让我对那些无法亲自核查的章节也多了一份信心。
与其猜测动机，我更愿意看看它公开摆出了什么。五个方面，信息都是公开的：
把这些放在一起看——以下是我的解读——这是一条典型的咨询业务获客漏斗：研究建立信誉 → 将“成熟度评估／路线图”做成标准化产品，构成利润层 → 顶端承接定制项目。论文的作用，是缩短信任建立所需的时间。最终促成交易的，仍然是客户已有的痛点和关系。
这并不是挖苦。剖析 11 个系统、400 万行代码，是实打实的工作。我是在观察一款扎实产品周围摆放的东西，而不是攻击它。这是咨询公司在 AI 时代的常规姿态，也恰好回答了一个我关心的问题：究竟是谁在为评估买单，又为什么愿意买单。
对于“AI 会不会杀死咨询业”，我的看法也类似：它会改变形态，而不是消亡。金字塔底部会变薄——研究、做演示文稿、写初稿，恰好是 AI 成本最低的三类任务。留下来的，是署名，以及对判断承担责任：模型无法被追责，无法被解雇，也不会坐进董事会。信息越泛滥，“有一个具体的人为此负责”就越有价值。可以观察两个可量化的指标：初级员工人数，以及计费模式是否从按天收费转向按成果收费。
Benchmark 分数：未经独立验证。 无论论文中，还是其涵盖的系统中出现了什么评估数字，来源都是系统厂商自己；我无法在自己的机器上重新运行这些评估。请将其视为未经验证的数据。
规模和方法数据来自论文本身。 “约 400 万行”“90 天 diff”“29 种模式”“13 项观察”——我没有重新执行它的研究方法来核验。
我没有找到公开的代码或数据产物。 对于一项以源码研究为卖点的工作，这构成了可复现性上的缺口——这是我的判断。结构性发现不依赖逐行复现，但详细计数依赖。
坚持标注快照日期。 我引用的所有内容都带有日期，本文的快照日期是 2026-10-13。一篇论文引用的常量，在几个月内就被改了名字；这是我所知道的、最能说明这条规则必要性的例子。
我的验证范围：恰好只有论文中的两项主张。 本文其余内容，要么明确表述为“论文指出”，要么标明是我自己的判断。
LUM——独立评估者。我没有咨询行业背景，也不会假装自己有。过去几年，我一直在 AI 工具之上搭建自己的工作流，过程中养成了一个习惯：遇到一篇论文、一款工具或一个项目，先把它拆开，看看内部如何运转，哪些部件真正承重，哪些只是装饰，然后再问它是否值得采用。每一个结论都带上日期，让后来的事实有机会检验它。
纠错政策：如果本文有任何事实错误，我会在文章顶部标明更正内容和日期。请通过 X 私信告诉我：@luming58112609。错误如何修正、会通知谁，都写在这里，让它不只是一句承诺。
如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。