大模型通识 / 大模型技术演进

14. 2025：从修改代码到执行和验证，编程智能体发展起来

本篇目录 · 9 节

来源：大模型技术演进

2025 年 2 月 24 日，Anthropic 在发布 Claude 3.7 Sonnet 的同时，拿出了一个外观并不华丽的新产品：Claude Code。

它最初以有限研究预览的形式进入终端。官方展示的工作范围已经跨过单纯回答问题：搜索和阅读项目代码，编辑文件，编写并运行测试，调用命令行工具，参与代码提交等开发操作。Claude 3.7 Sonnet 与 Claude Code 发布公告

对习惯了把报错复制进聊天框的开发者，这是一种很直接的变化。过去，人要在聊天、编辑器和终端之间搬运信息；现在，AI 有机会自己找到相关文件、执行检查、读取失败结果，再继续修改。屏幕上滚动的内容，从一段准备让人复制的答案，变成了正在发生的开发过程。

这一转折的分量，可以从 2025 年春季前后一连串产品变化中看出来：Cursor 把 Agent 设为默认模式；OpenAI 推出终端里的 Codex CLI，又推出云端 Codex；GitHub 让 Copilot 接收任务并提交代码供人审阅。AI 编程产品开始围绕“完成一项工作”重新组织体验。

这里说的 Coding Agent，可以理解为能够围绕编程任务，连续选择并调用工具的智能体。它仍然依赖模型，但还需要文件操作、命令执行、上下文管理和权限控制等配套。模型提供判断和生成能力，整个系统才把判断变成行动。

上一篇介绍从想法生成应用，本篇进一步讨论：当用户已经拥有一个项目，AI 怎样在里面持续工作。

在它出现之前，开发者已经走到哪一步

Claude Code 并非第一个能操作代码的 Agent。

第 10 篇介绍过，2024 年的 AI 编辑器已经在探索项目理解和跨文件修改；第 13 篇也讲到，Replit Agent 等产品当年就能够执行开发操作。研究领域同样在推进。2024 年的 SWE-agent 论文研究了一个具体问题：怎样设计适合语言模型使用的工具界面，使它更有效地浏览仓库、修改文件、运行测试。SWE-agent 论文

“仓库”可以先理解为保存项目代码及其版本记录的地方。真实仓库里的任务，比一道单独的编程题复杂得多。用户报告某个功能异常，问题可能涉及页面、接口、数据库处理和测试文件；修好其中一处，还不能破坏其他功能。

因此，这条路线的进展有两部分：模型更能理解代码和任务，周围的工具也更能把项目实际状态提供给模型。找文件的结果是否清楚，编辑失败能否准确反馈，测试日志是否可读，都会影响最终表现。

2025 年的重要变化，是这套思路集中进入主流开发产品，并形成了终端、编辑器、云端等多种入口。早期探索开始变成更多开发者可以实际使用的工作方式。

从“一次生成”变成“根据结果继续行动”

普通代码问答的基本过程，是用户提供问题，模型生成回答。Coding Agent 则可以在回答之前完成多轮工作：

理解任务 → 查找与阅读 → 修改 → 运行检查 → 读取结果 → 决定继续修复或交回结果。

这个循环的关键，是后一步会受到真实执行结果影响。

假设 AI 修改了一个函数。运行测试后，系统返回“某个输入下结果不符合预期”。模型就能结合这个失败信息重新检查自己的修改，而不是只在语言上推测“这样应该可以”。执行环境为它提供了新的证据。

不过，循环不保证每次都朝正确方向前进。模型也可能误读报错、修改无关文件，或者把测试改得更宽松，让错误暂时不再暴露。一个有效的 Agent，需要知道何时继续、何时换思路，以及何时把不确定性交还给用户。

这也解释了为什么“会调用工具”和“能完成长任务”之间还有距离。调用一次搜索很容易描述；连续工作时，系统还要记住目标、理解当前项目状态、避免重复操作，并保留已经验证的结论。单次代码生成能力，只覆盖了其中一部分。

对入门读者而言，判断一个产品的 Agent 能力，可以先观察三件事：它是否真的操作了项目，是否取得执行反馈，是否根据反馈调整了后续动作。只输出很长的计划，并不能证明这个循环已经发生。

Claude Code 为什么从终端切入

终端是一个可以输入命令、运行程序的界面。它看上去不如可视化编辑器直观，却连接着软件开发里的大量现成工具：搜索文件、启动服务、安装依赖、执行测试、查看版本差异，都能通过命令完成。

这使终端成为 Agent 很有价值的入口。开发者已经在使用的工作步骤，可以成为 AI 能够调用的工具，不必先为每一步重新制作按钮和页面。

Claude Code 的产品变化还体现在协作关系上。用户可以给出一个目标，让它自行探索相关代码；过程中检查它提出的操作和改动；遇到理解偏差，再补充约束。用户的角色逐步转向定义任务、提供项目知识和审阅结果。

2025 年 5 月 22 日，随着 Claude 4 发布，Claude Code 正式可用，同时扩展了 VS Code、JetBrains 集成和 GitHub Actions 等工作流。官方也介绍了模型在推理过程中使用工具等进展。Claude 4 与 Claude Code 正式可用公告

因此，终端是重要起点，而非这类工具唯一的形态。编辑器更便于直接查看代码差异，后台任务适合不需要一直盯着的工作，终端则容易接入现成命令。它们可以围绕同一个项目相互配合。

还要分清“工具在本机运行”与“模型在本机运行”。一个 CLI，也就是命令行工具，可以在用户电脑上读取文件和执行命令，同时把必要上下文发送给远端模型。安装了本地编程工具，并不等于把大模型下载到了本地。

Codex：从身边协作，到把任务交出去

2025 年 4 月 16 日，OpenAI 在发布 o3、o4-mini 时推出 Codex CLI。这是一个开源的终端编程 Agent，把模型能力带入本地开发流程。Codex CLI 的首次发布

一个月后的 5 月 16 日，OpenAI 又发布云端 Codex 研究预览。它为不同任务准备独立的云端沙箱，预先放入项目代码，再在其中阅读、修改和执行检查。用户可以交出任务，稍后查看改动和运行证据。云端 Codex 发布公告

“沙箱”在这里指相互隔离的工作环境。它让 Agent 可以在一份受控的项目环境中运行程序，而不必直接操作用户日常工作的所有文件。不同任务各自工作，也更容易进行并行尝试。

这时的 Codex 是软件工程 Agent 产品；codex-1 则是当时为它提供能力的模型，基于 o3 面向软件工程进一步训练。产品负责组织环境和行动，模型负责其中的推理与生成。把两者分开，才能理解后来更换模型时，产品工作方式仍可继续演进。codex-1 系统说明

云端任务带来了不同的协作节奏。在本地实时协作时，用户很容易边看边纠正；把任务交到远端后，任务说明、环境准备和交付证据就更重要了。Agent 需要知道要解决什么、哪些文件与工具可用、怎样判断已经完成。

如果代码需要某种依赖，而远端环境没有安装，模型再聪明也可能无法运行项目。如果测试依赖用户电脑上的私有数据，云端任务也不会自动拥有那份数据。工作位置改变，项目所需条件必须一起考虑。

这并不是把一个聊天窗口搬到服务器。它开始把开发任务组织成可以委派、追踪、审阅的工作单元。到 2025 年 10 月，Codex 正式可用，终端、编辑器和云端之间的产品连接进一步加强。Codex 正式可用公告

编辑器和代码平台，也在重新安排工作

Cursor 的变化说明，Agent 并不要求用户离开熟悉的编辑器。

2025 年 2 月 19 日的更新中，Cursor 宣布 Agent 成为默认模式；5 月 15 日又开始逐步推出 Background Agent 预览，让任务在独立远端环境中后台执行，用户可以查看状态、补充指示或接手。Cursor 0.46 更新、Background Agent 预览

编辑器内的实时协作与后台委派，由此出现在同一个产品里。比如，用户可以自己继续调整页面，同时让另一个任务调查测试失败的原因。能否高效并行，仍取决于任务是否相互独立；如果两边同时修改同一段代码，最后就需要处理冲突。

GitHub 则把 Agent 放进了代码协作流程。2025 年 5 月 19 日，Copilot coding agent 进入公开预览：用户可以把 issue 交给它，它在基于 GitHub Actions 的环境里探索代码、修改和检查，再提交 pull request 等待审阅。GitHub 当时的发布记录

Issue 是记录问题或需求的条目；pull request，简称 PR，是一份请求合并代码改动的提案。它让人能够看到修改了哪些文件，讨论是否合理，再决定是否纳入正式项目。Agent 进入这套流程后，交付物可以是一份可审阅的改动，而不仅是聊天里的解释。

这里的 Copilot coding agent，与编辑器中实时工作的 agent mode 也应区分：前者突出后台接任务、交回 PR，后者突出开发现场的连续操作。名称相近，协作节奏与运行环境却可能不同。

6 月 25 日，Google 推出开源 Gemini CLI，提供文件处理、命令执行等能力，并与 Gemini Code Assist 共享相关技术。这进一步说明，模型厂商正在把“模型加开发工具”作为一条重要产品路线。Gemini CLI 发布公告

中国生态：模型能力与开发产品同时推进

2025 年的中国生态，也需要分成模型与工具两层来看。

在模型层，Qwen3-Coder 和 Kimi K2 展示了对 Agent 场景的投入。Qwen 团队在 7 月 22 日介绍 Qwen3-Coder 时，强调通过与环境多轮交互的训练，改善规划、工具使用和根据反馈决策的能力。同期还开源 Qwen Code，基于 Gemini CLI 适配提示和工具调用机制。Qwen3-Coder 与 Qwen Code 公告

这里的两个名字分别对应模型与命令行工具。开放模型让更多团队能够选择和改造能力基础，开放工具则让开发者能查看 Agent 如何组织行动。它们扩大了组合空间，但并不意味着换一个模型后，所有工具行为都会自动保持一致。

月之暗面的 Kimi K2 技术报告，同样把工具使用与环境交互放在重要位置，介绍了 Agent 数据合成和强化学习等训练工作。这说明当年的模型竞争，已经从“回答编程问题”，进一步走向“在任务过程中使用工具”。Kimi K2 技术报告

在产品层，一批工具开始突出任务委派。TRAE 于 2025 年 7 月介绍 SOLO，将需求、规划、编码和交付组织在一个工作流程里，并把编辑器、浏览器和终端的进展集中展示。Qoder 在 8 月发布的介绍中，则把 Agent 和 Quest Mode 等任务工作方式作为重点。TRAE SOLO 当时的介绍、Qoder 初期产品介绍

腾讯 CodeBuddy 的年内更新也反映了这一方向：到 2025 年末，版本记录已经包含任务拆解、Plan 模式以及终端执行方面的改进。这里值得关注的是开发过程如何被组织起来，不应把厂商宣称的效率倍数当作所有项目都能获得的收益。CodeBuddy 历史版本记录

这些产品各有不同的使用入口、模型选择和集成范围。对于学习者，这段历史最有价值的信息是：可选择的开发方式变多了。你可以根据项目、使用习惯和可承担的费用选择工具，而不必把某一家产品的界面当成 Agent 的唯一标准。

为什么编程特别适合这轮 Agent 探索

软件开发有一种很有用的反馈条件：相当一部分结果可以交给程序检查。

代码能否通过语法检查，某个函数对指定输入是否产生预期输出，旧功能的测试是否仍然通过，都能给出相对明确的反馈。模型因此可以经历“提出修改—执行—观察—再改”的过程。

这种反馈也进入了训练。OpenAI 对 codex-1 的说明强调真实编程环境中的强化学习；Qwen3-Coder 的介绍则讨论通过执行反馈与多轮环境交互训练。训练阶段的环境反馈帮助塑造模型行为，实际使用时的运行检查则判断眼前这份改动是否可用。这是两种发生在不同时间的过程。codex-1 训练说明、Qwen3-Coder 后训练说明

评测也随之更加关注真实项目。SWE-bench 从 GitHub 的问题与相应修复中构造任务，要求模型根据问题描述修改已有仓库，涉及跨函数、跨文件理解。SWE-bench 原始论文

但是，真实应用里仍有大量无法仅靠现有测试回答的问题：需求是否理解正确，交互是否好用，某条数据规则是否符合用户预期。测试只能覆盖它实际检查的内容。通过测试是有价值的证据，还需要结合改动本身与用户目标解释。

复习助手出错之后，Agent 怎样工作

延续上一篇的复习助手，构造一个具体任务：点击“保存错题”后，界面提示成功，但重新打开页面，记录消失。以下是教学示例，不是某款工具的实测记录。

如果只把症状发给聊天模型，它可能建议“把错题存进数据库”。这个方向未必错，但它还不知道你的项目是否已经连接数据库，也不知道保存失败发生在哪一步。

一个能够使用项目工具的 Agent，可以先找到按钮对应的代码，再追踪保存请求和读取记录的代码。它可能发现，按钮只修改了页面内存中的列表，根本没有调用保存接口；也可能发现，接口已经调用，但错误被吞掉，页面无论成功失败都显示同一条提示。

不同证据，会导向不同修改。前一种需要接通保存路径，后一种需要处理实际错误，并纠正成功提示。靠不断追加“请修好”，很难代替对这些证据的检查。

假设确认是页面只保留临时状态，且项目已有可靠的保存接口。一个合理的任务过程可以是：

先复现问题，确认刷新后丢失的是哪条记录。
找到现有接口与数据约定，修改按钮的保存逻辑。
检查成功和失败两条路径，避免请求失败仍提示成功。
重新打开页面，确认记录确实能从存储中读回。
查看修改差异，说明改动位置、验证结果和仍未确认的条件。

“修改差异”通常叫 diff，表示与原版本相比增加、删除或改变了什么。它帮助用户检查 Agent 有没有为解决一个小问题，顺便重写大量无关内容。

如果 Agent 没有可用的数据库测试环境，它应交代这一限制，而不是把局部检查通过写成整个功能已验证。用户也可以先让它在隔离环境里完成可做的检查，再补上实际使用验证。

这个例子展示了 Agent 的价值：它能够连接原本由人手工衔接的调查和修复步骤。结果是否可靠，仍然取决于证据、环境和验收条件。

新的瓶颈，是怎样把任务交清楚、验明白

任务能够连续执行后，项目说明的作用变大了。测试怎么启动，哪些文件是生成出来的，哪些接口不能随意改变，这些知识如果只存在于作者脑中，Agent 就需要反复猜测。

2025 年的 Codex 发布说明已经介绍 AGENTS.md：放在仓库里的文本说明，用来帮助 Agent 了解项目结构、测试命令和工作约定。它体现了一个朴素的原则：把必要的项目知识写清楚，能改善任务交接。当时对 AGENTS.md 的说明

这不要求初学者先写一套复杂规范。对复习助手，说明怎样启动、怎样验证保存、哪些地方使用真实服务，往往就比一段泛泛的“请写高质量代码”更有用。

成本也应按任务看。Agent 可能多次读文件、调用模型、运行程序；速度更快的模型如果反复返工，未必更省。一项任务的总投入包括模型与运行费用、等待时间，以及用户审阅和修正的时间。

2025 年 7 月，METR 公布了一项随机对照研究：16 位有经验的开源开发者在熟悉的项目中完成 246 项任务，允许使用当时 AI 工具的条件下，完成时间平均增加 19%。研究主要涉及当年较早阶段的工具，作者明确不把结果推广到所有开发者和场景。研究原文

这项结果与产品进展可以同时成立：工具具备新的能力，并不自动意味着每一种任务都更快完成。对于你的项目，应该观察的是达到验收标准花了多少时间，而非生成了多少行代码或屏幕上执行了多少条命令。

2025 年，AI 编程的一个重要边界因此被推进了：用户可以交出一项范围明确的任务，让系统在环境中连续行动，再接回包含代码与验证证据的结果。项目知识、工具接口、执行环境和人的审阅，由此成为模型能力能否发挥作用的关键条件。

这套变化也并不局限于代码。对于资料研究，人们同样希望 AI 能够搜索、比较、追问、综合，而不仅返回一次答案。下一篇将沿着另一条并行路线，回顾 Perplexity 与 Deep Research 等产品怎样把检索和推理结合起来。

上一篇：13｜2024—2025：从生成内容到生成应用，Vibe Coding 走向普及

下一篇：15｜2023—2025：从搜索答案到完成研究，检索与推理逐步结合

返回：第 0 部分大纲