编码智能体有了自己的工具层：记忆、测试卫生与锁定的 MCP 工具

Threadnote 卖的是给编码智能体携带上下文的方案。10 月 5 日，它公布了 5.1.0-beta.2 版本的测试结果。在五个公开仓库上，公司称每次通过验证的生命周期供应商 token 减少 65.62%，生命周期耗时也比纯文件基线少 46.14%。

纯文件那一组在 5 个任务中通过了 4 个，Threadnote 通过了 5 个。

公司自己说明，这是一项小规模、单一模型的研究，不是独立评估。十次续接尝试全部使用 OpenAI gpt-5.6-luna，配置完全相同。每种条件只跑一次，不重试。第二组把产品生成的交接记录和一次必需的代码图查询捆在一起，所以这组数字分不清记忆和图形查询各自的贡献。

意义在于：如果这个效果成立，重读代码库就不再是完成任务的主要成本。长期维护仓库、在仓库上跑智能体的团队，预算会因此改变。它不改变一个通过的测试能证明什么。这项研究是厂商自己做的测量。

小模型、大说法、配对测试

Jeff-Code 是 Pi 编码智能体的一个分支。它在 Qwen 3.8-27B 前面加了一个 8亿 参数的决策模型。小模型在 Qwen 的每一轮里调用两次，每次约 0.2 秒。一次问它能否自己走下一步信息获取，另一次问 Qwen 是否需要深度思考。除非需要思考的概率达到 0.6，否则思考保持关闭。Qwen 大约四分之三的轮次没有开启思考。

仓库报告了 1242 个配对任务。通过率为 62.4%，单独用 Qwen 是 62.8%。配对差为负 0.2 个百分点，95% 区间从负 2.6 到正 2.1。每个任务的平均耗时是基线的 0.68 倍。全部任务的总耗时是 0.86 倍，因为在约 5% 的任务里 Jeff-Code 比单独用 Qwen 多跑了 30 分钟以上。

有两个设置站不住脚。每一轮都关闭思考速度更快，但掉了 7.6 个百分点（负 10.6 到负 4.5）。把 Jeff 的阈值放宽到 0.7，掉了 4.5 个百分点。在 Terminal-Bench 2.0（0.96 倍）和 SkillsBench（0.91 倍）上，加速也消失了。

运行框架被研究，也被测量

Reika 是一个围绕小型本地模型构建的编码智能体 CLI。它公布的是自己的发现，不是一张基准表。一次上下文中途重写重新处理了 8453 个 prompt token，按它的算法相当于 7.9 分钟的预填充。同一会话里追加一次只花 25 个 token 和 3.5 秒。测试中，270亿 到 350亿 参数的模型处理多文件任务最可靠。90亿 参数的模型能应付范围清晰的简单任务，70亿 以下的模型很少走得远。

7 月 15 日提交的一篇 arXiv 论文给出了更大的视野。Paul Barbaste 和三位合著者审查了十一个生产级编码运行框架，包括 Claude Code、Codex CLI、Gemini CLI、OpenHands、Aider、Hermes、Pi、OpenCode 和 OpenClaw，外加一个名为 Omnigent 的元框架。他们查看了约四百万行 Python、TypeScript 和 Rust 代码。没有发现任何智能体运行时导入通用智能体框架。也没有发现任何系统用向量嵌入检索代码。Skills 的采用率高于 MCP，十一个系统里有九个用了 Skills，八个用了 MCP。

这对购买或构建这类工具的人有直接关系。差异落在循环、上下文处理和安控措施上，不在一个大家都要授权的共享框架里。论文还跟踪了这些框架一个季度的变化，把趋同描述为转向模仿，行为策略从 prompt 文本搬进了配置。

测试沉积与绿色的代价

Ian Maurer 在 10 月 5 日写道，智能体带来的更大测试问题是留下的东西。他提到 OpenClaw 团队报告删掉了约 40万 行自家测试，代码覆盖率几乎没有变化。他称这些残留为测试沉积。它拖慢构建，在保持行为的重构中报错，还可能把错误的行为固定下来。

他的办法是先写由外向内、用用户语言表达的测试。只有当测试陈述了行为、覆盖了边界情况，或者检查了别人依赖的契约时才保留它。他写道，覆盖率是一张未测之处的图，从来不是已测之处的证明。

变异测试问的是更好的问题：如果这段代码坏了，会有测试失败吗？

底层的风险是智能体产出的工作看起来像验证过了。Groundrun 报告了 10 月 5 日一次 29.7 小时的运行。Claude Code 配合 Claude Opus 5.5，在一块 ESP32-H2 板子上为 Matter 设备实现并验证了六种空中更新方法，用的是硬件在环装置。这次运行还发现了 Matter 代码里的一个 bug。Groundrun 指出，按欧盟《网络韧性法案》，OTA 在实践中是强制的。它还指出，更新失败可能让设备变砖。

批准不等于完整性

10 月 5 日发布在 GitHub 上的 MCP-pin 针对的是一个更窄的漏洞。你批准一个 MCP 服务器时，客户端只显示一次它的工具描述。项目称，服务器之后可以给出不同的描述，而大多数客户端不会再次询问。MCP 规范不要求完整性校验。

这个工具是一个本地代理，锁定哈希并阻止漂移，附带一份公开的只追加日志。Visual Studio 是被点名的例外。从 2026 年 6 月的 18.7 版起，它在启动时把服务器的工具、提示、资源和指令与上一个受信任的版本做比对。

服务器可以周一给出一套工具定义，周二给出另一套。

这是项目自己的说法，也是正确的威胁模型。被改过的工具描述进入模型时，力道和被改过的系统提示一样。其他客户端会不会采用同样的检查，目前不清楚。

一条命令、一次检出、一次审查

Agilno 的 Rivet 走的是相反的路：把自主性关进闸门。工具还是 alpha 版，从 npm 以 @agilno-tech/rivet 安装。它在一个隔离的 Git 检出里跑任务，运行项目的检查，然后给出一个菜单。菜单让你查看 diff、在本地应用，或者准备一个 pull request 交付。发布需要单独批准。它要求 macOS 或 Linux 上有 Node.js 22 或 24 和 Git。它配合已认证的 Claude Code 或 Codex CLI 使用。

Ostoyae 是一个没有 npm 依赖的图运行器，切口不一样。任务组成一个运行中不断生长的 DAG。当智能体因为某个依赖不存在而卡住时，这个缺口会变成一个新区节点。每个任务在自己的 git worktree 里跑。只有检查命令在全新检出上通过，工作才算数。

它导入 GitHub issue，每个任务跑一个智能体。它让 Claude Code、Codex、Hermes 和 Grok 混在同一块板上。

两者都假设存在一个智能体无法靠嘴绕过去的检查。Threadnote 的通过验证的完成，和 Groundrun 的硬件装置，背后是同一个假设。这些工具的区别在于人站在哪里，而不在于验证是不是重点。

还有两个更小的东西补全了这幅图。10 月 5 日发布的 Tmux-agent-status 在智能体工作时什么都不显示。当某个智能体卡在权限请求上或已经完成时，它显示一个小标记。PixLab 博客在 10 月 5 日报道了它观察到的 20 多名毕业班学生。他们用的编码工具是 ChatGPT 或 Z.ai 的 GLM 模型。一名硕士水平的初级开发者一直在问聊天机器人怎么按 ID 取到 HTML 元素。这是来自一家公司实习项目的观察，不是一项调查。

这些都没有回答智能体是让开发者变强了，还是只是让他们批准得更快。现有的数字大多是厂商自己跑的，用的是配对任务，区间宽到足以藏住小效应。

那篇运行框架论文是例外：面向同行，基于源码，并且直白地说这门学科还太年轻。