仅代码代理
本文信息来源：rijnard
当代码执行确实就是你所需的一切
如果你在构建一个代理，你可能会感到不知所措。工具。 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 这样的工具让你能够组合 以类程序结构的自然语言构建代理。什么 当这些代理在它们的内部循环中仅由代码驱动时会发生什么？你会得到 用于协调的自然语言，用于执行的严格语义。 两全其美。
其次，混合工具。技能在以自然语言为主的流程中表现良好。只有代码的方法适用于需要保证的流程。我们将看到流畅混合两者的智能体：用于编排和意图的技能，用于计算和精确性的只有代码。 “提示一个智能体”和“编程一个智能体”之间的界限将日益模糊，直至消失。