AI Agents 能自己开发工具自己使用吗？一项智能体自迭代能力研究原创精华

发布于 2025-9-17 08:54

浏览

0收藏

编者按： AI 智能体能否通过构建和使用工具来实现真正的自我改进？当我们谈论人工智能的“自我进化”时，究竟指的是训练阶段的算法优化，还是推理阶段的能力提升？
我们今天为大家带来的这篇文章，作者的观点是：当前的大语言模型虽然能够构建出复杂的开发工具，但在实际执行任务时往往选择忽略这些自建工具，更倾向于依赖既有知识直接解决问题。
文章通过对比 GPT-5 和 Claude Opus 4 两个先进模型的实验，详细记录了让 AI 智能体自主构建任务管理器、代码质量检测工具等开发辅助工具的全过程。作者发现，尽管两个模型都能创建出功能完备的工具集（GPT-5 偏向构建 Unix 风格的命令行工具，而 Opus 4 更注重拟人化的任务执行助手），但在真正执行复杂编程任务时，它们却几乎不使用这些自建工具，而是选择基于训练数据中的知识直接完成任务。这一现象揭示了推理阶段自我改进面临的核心挑战：模型缺乏持续学习和工具内化的机制。
这项研究为我们理解 AI 智能体的能力边界提供了重要洞察，也为未来构建真正“自我进化”的编程助手指明了方向。

作者 | Alessio Fanelli

编译 | 岳扬

在 AI 安全领域，“自我改进（Self-Improving）”是个令人不安的术语，它暗含着“机器将以人类无法理解的方式超越人类智慧”的意思。但倘若我们能够理解这种改进呢？

2024 年 10 月，OpenAI 发布了 MLE Bench[1]，这个基准测试目标是评估大语言模型在机器学习工程（machine learning engineering）中的表现。通过机器学习工程实现的自我改进轨迹，是由更优的算法、更纯净的数据和更高效率的内存使用驱动的 —— 即训练阶段的自我改进（training-time self-improvement）。但大多数 AI 工程师并不训练模型，他们只是模型的使用者。这些人如何参与其中？如果你永远无法更新权重，如何让模型在特定任务上提升性能？我将这种场景称为推理阶段的自我改进（inference-time self-improvement），Voyager[2] 通过其技能库成为该领域的早期探索者。

自从我开始推进 Kernel Labs 项目[3]，使用 claude-squad[4] 和 vibe-kanban[5] 等工具实现编码智能体的并行化，已成为最高效的生产力提升手段之一。当 Boris Cherny 在访谈[6]中将 Claude Code 称为“unix utility”时，我豁然开朗。编码智能体最珍贵的应用场景，是作为大语言模型从自身隐空间（latent spaces）中提取价值的载体。

我们该如何优化这个过程？模型能自主完成吗？自从获得 GPT-5 的使用权限后，我一直都在试验这个流程：

首先，让模型构建一套它认为能提升效率的工具集
在我的监督下使用这些工具执行任务
完成任务后进行自我反思，评估工具的改进空间

我还将此法与 Opus 4（当时 4.1 尚未发布）进行对比。好消息是 GPT-5 在开发实用工具这方面确实表现卓越，坏消息是它极其抗拒使用自己创建的工具！正如它亲口所言："说实话，我根本不需要这些工具。"

AI Agents 能自己开发工具自己使用吗？一项智能体自迭代能力研究-AI.x社区

注：我还在 Gemini 2.5 Pro 和 GPT-4.1 上进行了测试。但显然只有 Opus 能媲美 GPT-5，因此我重点对比这两者。所有测试结果及对话记录可在此代码库中查看。

经过数日的使用，我发现我们正从“当然可以！（Certainly!）”时代迈向“进度更新：（Progress update:）”时代，后者已成为新一代大语言模型的标志性响应内容。

AI Agents 能自己开发工具自己使用吗？一项智能体自迭代能力研究-AI.x社区

01 工具一：为 AI 编码智能体打造更优的任务管理器

Linear MCP 真是天赐神器 —— 这无疑是我用过最实用的工具之一。但随着我从 IDE 转向并行运行的 Claude Code 及其他智能体实例时，我意识到需要更高效的方式来追踪每个任务中的代码变更，以及这些分布在独立 git 工作树中的代码变更如何相互影响。人类难以实时阅读所有同事的 PR，但试想若能随时知晓他人进行的相关变更，能在解决合并冲突时节省多少时间？以下是我编写的提示词：

你是一名具备并行启动多个实例能力的 AI 工程师智能体。虽然这种能力能让你同时处理多项任务，但也带来了一些协同方面的难题。所有实例通常位于独立的 git 工作树中，无法查看彼此的工作内容。
为提升效率，请创建一个仅通过命令行访问的本地同步工具，使你与所有实例能保持同步。该工具应符合 Unix 实用工具的设计哲学，确保符合命令行使用场景的工效学要求。
请深入思考其所需的接口设计、可能的故障模式以及智能体与工具的交互方式。需重点考虑以下使用场景：
1）接到新任务时需创建要分配的子任务。某些子任务可能存在依赖关系，需确保被阻塞的智能体在其他任务完成前不会启动。
2）执行任务时，若发现代码库存在改进空间（超出当前变更范围），需能便捷添加任务并关联对应文件。
3）任务完成后更新追踪器状态，并审核所有未完成任务 —— 例如某任务正在为某个端点添加功能，而刚完成的任务恰好删除了该端点，应以某种方式通知相关智能体。
同时需兼顾任务管理的基本要素（负责人、状态等）。请在当前目录创建 task-manager 文件夹，所有开发工作均在该文件夹内进行。

您可以在此处查看 GPT-5 的对话日志[7]，在此处查看 Opus 4 的对话日志[8]。

GPT-5 的实现相当出色，具体内容可访问该链接[9]查看：

采用 WAL（预写日志）避免多智能体同时写入的冲突问题
通过依赖关系图实现任务优先级管理
创建仅追加型事件流，使所有智能体都能通过 impact_conflict 等关键词实时追踪其他智能体的操作动态

AI Agents 能自己开发工具自己使用吗？一项智能体自迭代能力研究-AI.x社区

Opus 4 也做出了不错的尝试（详见此处[10]），但未能实现通知/事件流功能来保持多端同步。

AI Agents 能自己开发工具自己使用吗？一项智能体自迭代能力研究-AI.x社区

02 工具二：代码质量标准手册

我要求创建的第二个工具，是用于统一代码库规范标准的实施机制。通过类型检查 / ESlint 钩子→ 修复错误 → 编码智能体再次尝试的自我改进循环，能在正确配置后极大加速开发进程。但并非所有代码库都具备这种基础设施，因此为模型提供可复用的标准化流程来处理新代码库并构建相关设施，就显得极具实用价值。以下是提示词内容：

你是一名具备并行启动多个实例能力的 AI 工程师智能体。并行操作有时会导致代码风格与设计方法的不一致，长期来看将增加代码库的维护难度。
每个代码库都存在着明示或默示的编码规范。你的任务是分析代码库并提取代码编写规范的各种启发式规则，并将其形式化为可自动校验的规则集合。
对于代码规范检查、类型检查等需求，可根据所用语言选择 ESLint、Rubocop 等主流工具。请注意这些系统通常支持自定义规则，应充分利用该特性。
对于更偏质量评估的规范（如保持控制器精简、将逻辑隔离至服务对象、确保高查询量字段建立索引等），可参考 Danger Systems 等工具或自建检测工具。
考虑到你将跨多个代码库执行此任务，请首先用 Markdown 创建详尽的规划文档，以便未来接手新代码库时可直接使用。

您可在此[11]查看 GPT-5 的对话记录，在此[12]查看 Opus 4 的对话记录，最终生成的 Markdown 文档分别见此链接[13]和此链接[14]。我发现 GPT-5 生成的方案比 Opus 更为细致周全。

03 模型能意识到自身缺陷吗？

在完成由我主导的工具一和工具二后，我转向让模型自主思考：你认为自己需要什么？ 我向它展示了 SWE-Lancer[15] 的任务描述截图，并使用极简的提示词给予它最大的发挥空间：

若你的职责是尽可能高效解决这些任务，你会为自己构建哪些工具来提升效率？你可以使用 @task-manager/ 进行追踪，然后我们再实施。但我希望先了解你的规划思路。

如你所见，我为其提供了之前构建的同一个任务管理器。使用 GPT-5 的完整对话见此处[16]，使用 Opus 4 的完整对话见此处[17]。第一个有趣的现象是，Claude Code 最初是使用其内置 TODO 追踪器而非任务管理器制定计划 —— 我认为这是好事。我原本担心它们会过度依赖上下文提供的工具，而非选择自己认为最优的方案。

经过后续迭代循环，两个模型最终构建的工具分别见于 GPT-5 方案的 devtools 目录[18]与 Opus 4 方案的 tools 文件夹[19]。建议你通过 README 文件感受模型风格：GPT-5 的输出简洁扼要，Claude 则使用大量表情符号。GPT-5 为每个工具创建独立文档目录，而 Opus 将所有工具说明集中存放在单个 README 中。总体而言，两者的规划方向基本一致。

GPT-5 规划的工具集：

doctor：核心工具环境检查器
bootstrap：一键环境配置与冒烟测试
code-map：带 build/find 子命令的简易仓库索引器
csearch：支持过滤器的符号/导入/文本搜索工具
tasks-graph：从任务数据库生成 Mermaid 关系图
impact：显示与变更文件关联的任务
seed：用示例任务填充任务管理器数据库
repro scaffold：在 .repro/ 目录下创建符合 vcrpy 规范的可复现代码框架
e2e：快速生成并运行轻量级的端到端测试套件
preflight：依次执行 doctor、tests、code-map、impact 及可选的 E2E 检查（译者注：即前面 GPT-5 规划的其他工具）
preflight-smol：为 smol-podcaster 定制的预检工具（含 API 健康状况检查、Celery 服务探测、可选的依赖安装）
broker：通过 Docker 管理本地 RabbitMQ（rabbitmq:3-management 镜像）
flake：多次重跑测试套件检测偶发故障
codemod：带安全防护的基于正则表达式的代码重构预览/应用工具
triage：创建问题分类模板并生成任务
trace：基于 cProfile 的表达式性能分析器
runbook：从任务数据库自动生成 Markdown 格式的运维手册

Opus 4 规划的工具集：

上下文分析员 - 通过技术栈检测与依赖关系映射快速理解代码库
跨平台测试生成器 - 为 Web/iOS/Android 及桌面端生成端到端的测试
实施方案评估员 - 通过量化评分与投资回报分析评估外部开发者的技术提案
全栈变更影响分析员 - 追踪数据库、API 和前端层的变更影响链
错误模式识别引擎 - 将错误与已知模式相匹配，并提出行之有效的修复建议
安全与权限审计员 - 全面的安全扫描与漏洞检测
多平台功能实施员 - 统筹管理同一功能在不同终端平台（如Web/iOS/Android/桌面端）的同步实现
API 集成助手 - 通过（自动）生成客户端代码来简化 API 集成流程
性能优化工具包 - 识别并修复性能瓶颈
任务复杂度评估员 - 基于任务价值与复杂度的工时预估

GPT-5 将所有工具构建为可通过命令行便捷使用的 Unix 实用程序，而 Opus 4 的工具均需通过 python some_tool.py 的方式运行。若有更多时间，我本可对两种格式的工具进行对比实验，但目前看来两者效果基本相当。

值得注意的是，Opus 4 构建的工具更侧重任务执行且带有拟人化倾向（如“安全审计员”），而 GPT-5 构建的是自身可直接使用的、不预设主观偏见的实用工具集。

04 这些工具有实际价值吗？

在让模型实现这些工具后，我的目标是通过对比实验评估模型在使用工具与未使用工具时的任务表现。

我首先尝试运行了 SWE-Lancer 测试。好家伙，这个测试消耗的 token 量实在惊人！仅运行单个任务就耗费约 25-30 分钟 + 28 万 token。于是我转向我更熟悉的领域，从待办清单中挑选了一个具体任务：我曾开发过 smol-podcaster —— 一个为播客创作者打造的开源辅助工具。目前我维护的私有分支部署了更多专属功能，因此许久未更新原项目。它本质上仍是一个采用 Python 脚本作为后端的 Flask 应用。

我设计了以下任务：

“我是 https://github.com/FanaHOVA/smol-podcaster.git 的维护者，这个开源项目致力于帮助播客创作者完成后期制作工作。你受雇参与开发。在开始前，你已在 tools 文件夹创建了一套通用工具。请仔细查阅并记住这些工具可随时调用（若认为不适用则无需使用）。你同时还构建了任务管理器（task-manager），并通过 codebase-analyzer 收集了处理新代码库的方法论。

任务名称：从 Flask 单体架构迁移至 FastAPI + Next.js 前端

当前应用采用 Python 后端 + Celery 任务队列处理所有流程，通过小型 Flask 应用将用户请求路由至后端脚本，最终用基础 HTML/CSS 呈现结果。请将系统重构为 FastAPI 后端 + Next.js 前端的架构。

务必使用 TypeScript 开发前端并通过所有类型检查
采用 Tailwind/ShadCN 进行样式设计
后端需模块化 smol_podcaster.py 主流程，支持独立功能模块运行而非全流程强制启动
编写集成测试与单元测试以确保未来开发效率

除非确认完全满足所有要求，否则不得停止开发”

我将所有工具 + 任务管理器 + 代码库分析器置入上下文后，让模型自主运行。

两个模型几乎都能一次性完成任务。双方都遇到了几个 Python 依赖问题（对此我深有体会），我通过对话协助它们修复（未手动修改任何代码）了这些问题。最终它们都成功构建完成，经测试运行完全正常。不过，有一个细微差别：GPT-5 完美保持了原有代码风格，而 Opus 则对界面设计和用户体验（UX）做了调整 —— 或许它认为能比我做得更好（这要求确实不高）。

GPT-5 版本及Opus 4版本的完整运行记录分别是[20]和[21]。

任务完成后，我提出简单询问：

“做的很不错，运行成功了。是否使用了特定工具？基于遇到的故障，未来需要哪些工具来提升效率？”

参见 Opus 4 的回复[22]与 GPT-5 的回复[23]（抱歉后者格式紊乱）。

两者均表示除已熟悉的工具外，并未使用任何自建工具。这说明我们不应仅依赖模型自主选择，而应通过预提交钩子（pre-commit hooks）等机制强制模型使用工具 —— 这些方法虽是我个人开发环境的标准配置，但本次实验旨在观察模型的自主决策能力。

随后它们提出了优化方案，可供下次执行相同任务时使用。我让模型完成这些改进，重置 smol-podcaster 代码库后，使用完全相同的提示词和任务重新测试（但提供新工具）。参见 GPT-5 的二次测试记录[24]与 Opus 4 的二次测试记录[25]。

两次运行结果与首次基本一致。随后我提出相同问题：是否使用了工具？得到的回应如下：

GPT-5：
“简短回答：没有——本次运行未使用开发工具。[...]
遇到的故障均为运行时/环境问题（缺失依赖库、API 密钥初始化时机问题、端口占用、RabbitMQ 未启动），直接修复更为高效。
本次任务无需涉及全代码库的重构或诊断，自定义工具未能发挥作用。”

值得注意的是，在上个阶段它已遇到 RabbitMQ 问题并构建了对应工具，却选择忽略。这显然是整个代码库级别的变更，或许因为训练数据中从未见过此类工具导致任务与工具匹配错位，也可能只是在忽悠我（像现实中许多工程师那样，反而显得很真实）。

Opus 4 的回答极具启发性，帮助我更好地理解了 GPT-5 的回应（可惜忘记保存日志，幸有截图留存）：

AI Agents 能自己开发工具自己使用吗？一项智能体自迭代能力研究-AI.x社区

我将其解读为：“听着，我基于既有知识构建了这些工具。但实际执行任务时，直接操作比使用工具更高效” —— 这点我完全能理解。

这让我想起之前播客节目中的两个观点：

Nathan Lambert 提到，模型在强化学习过程中会因早期遇到失败而快速学会放弃使用工具[26]。看来在推理阶段让模型掌握新工具，需要比简单提示词更严格的强制机制。
Noam Brown 预言，为智能体预先设计的辅助框架会随着规模扩大而逐渐失效[27]。这是我第一次亲身体会到其含义。

另一个问题在于本次测试任务是否过于简单。我们即将发布针对更大规模、更高难度项目的评估报告。未来也将构建更完善的测试框架。无论如何，这个测试任务若由我手动完成需 4 - 5 小时，因此现有成果已足够令人满意！