返回首页
2026.01.19 14:59 约 10 分钟 全球动态AI 编程革命

仅代码代理

本文信息来源:rijnard

当代码执行确实就是你所需的一切

Code-Only Agent

如果你在构建一个代理,你可能会感到不知所措。工具。 MCP。子代理。技能。生态系统将你推向复杂性, 朝着“正确的做法”前进。你应该知道:像这样的概念 “Skills”和“MCP”实际上是……的结果 人类不断摸索的持续学习过程 。这个领域对探索来说是一片广阔天地 。带着这种心态我… 想尝试一些不同的做法。简化假设。

如果这个代理只有 一个工具呢?不仅仅是任何工具,而是最强大的那个。 图灵完备的那个: 执行代码 

真正的“单一工具”意味着:没有 bash、没有 ls、没有 grep。只有 execute_code。而且你要强制执行它。

当你观察一个代理运行时,你可能会想:“我想知道它会用什么工具来解决这个问题。哦,看看,它运行了 ls。这有道理。接着是 grep。挺好。”

更简洁的“仅代码”范式让这个问题变得无关紧要。问题从“用什么工具?”转变为“它会生成什么代码?”而那时事情就变得有趣了。

execute_code:统领一切的工具

传统提示语的运作方式如下:

> 代理,去做某事
> 代理 响应 以 事物

对比:

> Agent,执行 事物
> 代理 创建并运行代码 去做 事情

它每次都这么做。不是开玩笑, every 次。为我们的仅代码代理选择一个运行时,比如 Python。它需要查找一个文件?它会写出 Python 代码来查找该文件并执行代码。也许它会运行 rglob。也许它会使用 os.walk

它需要创建一个爬取网站的脚本?它不会将脚本写入 你的文件系统(提醒:没有 create_file 工具可以做到这一点!)。它 编写代码以输出一个爬取网站的脚本 1

我们要确保代理绝对不可能 出任何有成效的事情,除非 编写代码 

那又怎样?为什么要这样做?你可能在想,这有何用处?赶快给它一个 bash 工具行不行。

让我们更深入地想想发生了什么。传统的智能体会给出某种回应。让它在 100 个文件中查找某种 DNA 模式。它可能会 ls 然后 grep,也可能以某种非确定的顺序执行这些操作,它会得出一个答案并且 也许你会继续互动,因为它漏掉了一个目录或者你 添加了更多文件。过了一段时间,你就会得到一段对话,内容是 工具调用、响应和一个答案。

在某些时候,代理甚至可能编写一个 Python 脚本来完成这项工作 DNA 模式查找。那将是一个幸运的顺利路径,因为我们 可以重新运行该脚本或稍后更新它……等等,这很方便…… 实际上,不只是方便……难道那不是 理想吗?如果我们一开始就告诉它去写一个脚本,岂不是更好吗? 你看,纯代码代理不需要被告知去写 一个脚本。 has 因为那实际上是它做出任何有实质性动作的唯一方式。 实质内容。

仅代码代理产生的东西比自然语言答案更精确。它生成了代码的证据 。 答案。答案是运行代码后得到的输出。该代理 可以以自然语言(或通过编写代码)解释该输出, 但“工作”在非常字面化的意义上被编码。仅代码 代理不会用某种回应来回答。它生成一个代码证据 产出某些东西。

达阵 ❯❯ Code-Only 插件 for Claude Code

代码见证是语义保证

让我们追随其后果。代码见证必须遵守某些规则:由语言运行时语义施加的规则(例如,Python)。这不是一个“下一个标记”的过程。也不是“LLM 推断一系列工具调用,不,那不是我想要的”。那是一段代码。一段代码!我们这个单工具代理有一个美妙的特性:它通过潜在空间产生出具有明确定义语义、可重复运行且即刻可理解(无论是人类还是代理都能就其进行推理)的东西。这是非确定性的 LLM 标记生成被投射到图灵完备代码空间的结果,是我们所能理解的关于行为的可执行描述。

仅靠法典代理真的足够,还是太极端?我坦白说:我之所以追求这种极端做法,源于两点:一是受下文延伸阅读中的文章启发;二是因为对代理无法全面而心生厌烦 在我的笔记本上穷尽地分析成千上万的文件。他们会跳过, 走捷径、产生幻觉。我知道如何解决其中一部分。 问题:创建一个 programmatic 循环和 try 有新的实例/提示来完成工作 全面地。我可以依赖用 Python 编写的循环的语义。 将这个想法进一步扩展,你会意识到对于任何事情 长期运行且可计算(例如,bash 或某些工具),实际上你会 想要真正的“真货”:完整的代码证据,说明事情为何发生的痕迹 工作与否。《The Code-Only Agent》 强制执行 那个原则。

仅限代码的代理并不过于极端。我认为它们是唯一的出路 面向可计算事物的前进。如果你在写旅游博客文章, 您接受 LLMs 的回答(并且您无需运行工具来) 那样的话)。但一旦某事是可计算的,Code-Only 则是唯一的选择 通往……的道路 完全可信 在需要保证(受制于)的地方取得进展的方法 你所选语言所保证的语义,当然)。当我说 保证时,我是以较宽松的意义来说的,也包括在一种 形式 的意义上。这引出一个问题:当我们使用像…这样的语言时会发生什么? 精简 与一些.. 最有力的保证?难道我们没有注意到那.. 程序就是证明 ?

这一个视角认为,Code-Only agent 是证据的“制片人”,是证明即程序世界中计算行为的见证者。一个被迫循环生成证明、执行证明并解释证明结果的 LLM。仅此而已。

只用代码

所以你想只用代码。会发生什么?范式很简单,但设计选择却令人惊讶。

首先是胸背带。LLM 的输出是代码,而你执行该代码。应该向后传达什么?退出代码是合情合理的。输出呢?如果输出很大怎么办?既然你在运行代码,你可以指定运行代码应返回的结果类型。

我个人例如会在结果小于某个阈值(1K 字节)时直接将其返回。此结果会进入会话上下文。或者,如果超过阈值,则将结果写入磁盘上的 JSON 文件。这样可以避免上下文膨胀,结果会告诉代理写入磁盘的输出文件路径。如何最好地传递结果、持久化它们并在大小与上下文占用间优化,仍是开放问题。你还需要定义处理 stdout 和 stderr 的方式:是否向代理公开它们?在公开前是否先进行摘要?

接下来是执行。假设你在使用 Claude Code。仅仅说服它始终创建并运行代码还不够。事实证明,要把 Claude Code 强行限定为单一工具出乎意料地曲折(也许对此的支持将来会改进)。我找到的基于插件的最佳解决方案是一个名为 PreHook 的工具,用来拦截被禁止的工具调用。当 Claude Code 试图使用不允许的工具时,这会浪费一些迭代,但它会学会停止尝试对文件系统进行读/写。初始提示有助于引导。

接着是语言运行时。Python、TypeScript、Rust、Bash。还有其他吗? 任何可被执行的语言都可以,但你需要 思考它是否适用于你的领域。动态语言 像 Python 这样的语言很有趣,因为你可以在本地运行代码 代理自身的运行时,而不是通过子进程调用。同样 TypeScript/JS 可以被注入到基于 TypeScript 的代理中(见 进一步阅读 )。

一旦进入“仅代码”思维模式,你就会看到构成与复用的潜力。Claude 技能(Claude Skills)用自然语言定义可复用的流程。那么“仅代码”代理的等价物是什么?我不确定是否已有相当于技能的东西,但我预计它很快会成形:把代码作为特定领域的构建模块,让“仅代码”代理去组合程序化的模式。这与调用 API 有何不同?API 构成了可复用模块的一部分,但真正由“仅代码”代理生成的是这些模块的组合方式(循环、并行、异步等)。

关于 execute_tool 支持异构语言和运行时呢?我觉得我们还没考虑到那么远。

延伸阅读

代理生态正在快速演变。我对“仅代码”范式如何融入以下具有启发性的文章和趋势的看法,按时间从近到远排列:

  • prose.md (2026年1月)— “仅代码”将提示简化为可执行代码(与 循环和语句序列)。散文将提示扩展为自然语言 带有类程序结构的语言(也包括循环、序列, 并行性)。用于代理的自然语言与代码之间的相互作用 用于代理执行的编排和僵化语义可能会是 极其强大。
  • 欢迎来到毒气城 (2026年1月)——代理编排失控。运行工具是代理堆栈底层的低级 操作。仅代码代理(Code-Only)恰好适合成为该层的 原始:无论你协调多少个智能体,每一个都.. 归结为生成并执行代码。
  • Anthropic 代码执行与 MCP 文章 (2025 年 11 月)—— 将 MCP 服务器作为代码 API 而非工具调用来公开的以 MCP 为中心的观点 代码优先更为简单且更具有通用性。它 不关心 MCP,而将 MCP 接口视为 API 是 承认前行力量的一种机械必需 仅代码。
  • Anthropic Agent Skills article (2025年10月)——技能体现为用自然语言表述的可复用流程。 它们可以生成并运行代码,但这并不是它们的唯一目的。 “仅限代码”范围更窄(但在计算上更为… 全能):可重用单元始终可执行。类比 到技能体现为可插拔的可执行片段:函数, 循环,可组合的基于 API 的例程。
  • Cloudflare Code 模式文章 (2025年9月)— 可能是最早的单一代码工具的具体实例 实现。Code Mode 将 MCP 工具转换为 TypeScript API 并赋予代理一个工具:执行 TypeScript。他们的见解是 务实观点:LLMs 写出比调用工具更好的代码,因为.. 训练数据。在最广义的层面上,采用仅代码方式不再 无需依赖 MCP 或 API,并封装了所有代码执行 关切。
  • 将 Ralph Wiggum 视为“软件工程师” (2025 年 7 月)——一个针对代理的程序化循环(agent 编排)。Huntley 将其描述为“确定性地糟糕”在 一个非确定性世界”。《仅代码》对此略作颠倒: 将非确定性模型投影为确定性模型 执行。以代理的“仅代码”内循环为基础进行代理编排,可能是一种强有力的组合。 内部循环中的代理编排可能是一种强大的组合。
  • 工具:代码就是你所需的一切 (2025年7月)—— 将代码提升为代理的一级关注点。 罗纳赫的观察:让一个 LLM 编写一个脚本来 将 Markdown 转换,使得可以对该过程进行推理并建立信任。 该脚本可审查、可重复、可组合。 《仅代码》更进一步,将每一项动作都变成脚本 你可以进行推理的。
  • 如何构建一个代理 (2025年4月)——目前实现“仅代码”代理最干净的方式 可能是从头开始构建它。对现有的代理进行调整,比如 Claude 将法典用于强制单一工具意味着摩擦。Thorsten 的 这篇文章清晰地阐述了如何构建带工具的代理循环 呼叫。如果你想强制仅限法典调用,这使得实现变得很容易 自己动手。

下一步是什么

有两个方向看起来不可避免。首先是代理编排。像 prose.md 这样的工具让你能够组合 以类程序结构的自然语言构建代理。什么 当这些代理在它们的内部循环中仅由代码驱动时会发生什么?你会得到 用于协调的自然语言,用于执行的严格语义。 两全其美。

其次,混合工具。技能在以自然语言为主的流程中表现良好。只有代码的方法适用于需要保证的流程。我们将看到流畅混合两者的智能体:用于编排和意图的技能,用于计算和精确性的只有代码。 “提示一个智能体”和“编程一个智能体”之间的界限将日益模糊,直至消失。

达阵 ❯❯ Code-Only 插件 for Claude Code

了解 RecodeX 的更多信息

立即订阅以继续阅读并访问完整档案。

继续阅读