大模型掀起的 AI 辅助编程风潮已经吹了两三年了，许多企业和管理层也强制性要求程序员必须学会使用 AI 工具提升效率。从一开始的 Copilot，到 Cursor、Windsurf……工具不断升级，功能日渐完善。每隔一段时间，就会有新的功能出现，刷新大家的认知。

最近，市场上多了一些「Code Agent」的产品，比如百度编程助手 Comate 上线的 Zulu，还有开源中国老朋友、资深开发者祝海林上线的 Auto-Coder，主打一个让编程工具自己思考，自己就能干完活。先来看看官方的介绍：

Auto-Coder 的

zulu 的

关键在于通过智能体模式让 AI 编程更好用。那么问题来了，「Code Agent-编程智能体」到底是怎么用，能用来干什么，和升级前的工具比优秀在哪，有没有一些弊端？

OSCHINA 邀请了某公司技术合伙人、Auto-Coder 作者祝海林，跟他一起聊聊所谓的「编程智能体」到底是什么？这个功能和之前的 AI 编程能力本质区别是什么？

以下为采访实录：

从技术发展的角度来看，历史上经历过几次重大变革。第一次是 Web 革命，那时建立一个个人博客、个人站点，对技术人员来说就是一个机会；随后是移动 APP 时代的到来。我认为，当前 AI 技术的浪潮同样孕育着新的机遇，这个领域甚至可能出现大公司难以抗衡创新型小企业的局面。

我个人工作是从web,到搜索，推荐，再到大数据与传统自然语言处理，所以一直和机器学习AI有点关系。从2023年起，我便开始研究大模型相关的技术，早期是大模型微调、部署应用等，相应的工作成果为开源的 byzer-llm，2023年底又开发过一个 Agent 框架（byzer-agent，应该是全球第一个基于 Ray 的分布式Agent框架）。

到2024年，我觉得大模型技术已经出现了一个清晰的应用场景——并且我认为，任何新技术必然率先颠覆其原生领域——大模型首个规模化落地的应用场景必然是 AI 辅助编程。从去年下半年至今年上半年的行业动态也可见端倪：以估值已达百亿美金的Cursor为例，各类 AI 编程工具，如 Augment 等持续涌现并获得资本青睐。

值得注意的是，这些工具的功能演进正逐步趋同，这种现象恰恰标志着 AI 编程辅助技术已发展至相对成熟阶段——只有当技术达到特定阈值后，产品形态才会进入收敛期。这也验证了我的预判：AI 辅助编程一定是大模型技术第一个落地场景，也是真正能赚到钱的。

所以从 2024 年3月，我正式开始投入做自己的 AI 辅助编程工具——Auto-Coder。

Auto-Coder 下载地址：https://pypistats.org/packages/auto-coder

不同 AI 辅助编程的实现原理对比

目前，AI 辅助编程的实现原理有 2 大类，一是基于规则流程的普通编辑模式，比如说早期 Cursor 工具的“Composer”模式，Auto Code 里也会提供，这种模式的运行逻辑如下：

• 根据query 自动查找上下文
• 将源代码文件输入系统

• 生成特定格式的修改格式（可apply）

• 将生成内容合并回源码文件

此过程的特点在于完全预设的执行流程：

1. 上下文检索

1. 大模型生成格式化文本

1. 自动合并到源码文件

本质上是工具化的大模型应用，模型不具备自主决策能力，所有操作步骤均按预设规则执行。在 Auto Code 体系中，我们将其归类为“普通编辑模式”,一般也叫 Context/Manual模式。

二是大模型主导的 Agentic 模式，核心区别在于：所有流程不做提前规划，交由大模型自主决策。

像是在 Auto-Coder 里，我们会提供一些工具，比如阅读、搜索文件、修改文件的工具，把这些工具的使用说明告诉大模型，大模型会根据输入的需求拆解目标，计划每一步需要调用哪个工具。同时，大模型也会据工具调用结果更新系统状态，相当于边走边看，持续决策直至满足以下任一终止条件：

• 模型判定需求已实现

• 达到预设执行阈值

• 模型请求人工干预

因此，Agentic 模式是变成了一个完全自驱的模式，给定需求后它会想办法实现你的目标，大模型在其中是有主观能动性的。

Code Agent 的实现流程

先来聊一下 Agent 本身，Agentic 模式下便是 Code Agent。从一个高的角度来看，  Agentic AI 系统的核心是根据用户的需求，完成两个动作：

1. Reasoning: 查看当前项目，思考解决方案

2. Acting: 根据思考做实现（修改代码，通过调用一些工具）Agentic Ai 系统会不断重复着两个动作，直到他自己认为已经解决了问题。

这和传统意义上的 prompt -> response 是不一样的。

大家用的聊天工具，包括chatgpt, deepseek 网页，其本质就是一个 prompt -> response流程。而 Agentic AI 的流程则是，思考->调整->思考->调整 来完成循环。

所以相比直接和大模型的一问一答模式， Agentic AI 系统是领取任务，自己做决策，觉得什么时候，如何使用工具，以及下一步应该干什么，最终期望是能给“老板”你提供一个满意答卷。

这是 Agentic AI 和大模型的本质区别。同时这也和推理模型有本质的区别，推理模型本质上是 prompt -> thinking -> response ， 你可以理解为提供你答案之前，自己先打个草稿，然后再发言。

Code Agent 细化了前面的 Reasoning-> Acting 循环。

基本循环为：

1. 分析当前用户的需求，以及当前的代码的现状（以及上一步工具执行的结果），给出一个解决流程。

2. 从流程的第一步开始，选择合适的工具(比如搜索，阅读代码文件，罗列目录等)

3. 执行工具

4. 观察执行结果

5. 重复第一步。

二选一怎么选？

目前， Auto-Coder 的系统允许用户根据不同场景选择不同的工作方式。例如，如果用户希望加快工作速度，可能会避免使用 Agent，因为 Agent 的运行速度相对较慢。为了完成一个任务，Agent 可能需要尝试五六次甚至十几次，每次都与大模型进行交互，消耗较多 token，总体速度较慢。

对于非常熟练且对项目熟悉的程序员，他们可能更倾向于使用 Context/Manual模式，直接指定需要修改的文件并给出修改指令，这样可以在几十秒内完成普通程序员可能需要一两个小时才能完成的任务。

如果需求复杂或程序员对需求不够清晰，他们可能会将需求交给 Agent，让 Agent 去理解和消化，同时自行查看相关文件，再决定如何进行修改。这种情况下，使用 Agentic AI 系统更为合适。

因此我们鼓励用户根据自身需求选择最合适的工作方式，以提高效率和节省成本。

在 AI 辅助编程中，成本是一个重要考虑因素。例如，目前最好的编码模型之一是 Sonnet 3.7，但其成本较高，每100万 token 的输入成本为5美金，输出成本为15美金。以我个人的经验，一次编程需求如果人工完成大约需要30分钟到1小时，而使用 Sonnet 3.7的话，成本大约在0.6到2美金之间。这是在理想状态下的估算，因为 AI 生成的代码可能存在 bug，导致合并失败需要重试，这样成本可能会翻倍。因此，成本是选择工作方式时的重要考量。Context/Manual 模式相对节省成本，而 Agentic AI  模式成本较高，速度也较慢。

工具调用的两种模式

Code Agent 的核心是大模型自主决策并调用工具完成任务。这里的工具调用有两种模式，据我所知，Windsurf、Cursor 等工具调用的是原子性工具，即非智能工具。所谓非智能工具，指的是例如我们提供的 readfile 函数和 certify 函数，我们会指导大模型如何调用这些函数。在自主决策过程中，大模型可能会决定首先查看文件，但由于其自身无法执行该操作，便会触发 readfile 函数的调用，执行后返回文件内容给大模型。大模型接收到结果后，再决定下一步操作。

这种方式下，大模型调用的是非智能工具，并自由组合这些工具以完成编程任务，所有决策和操作都由大模型或 Agent 自行完成，例如决定替换文件中的哪部分内容。

第二种方式则是调用已具备智能的工具。以 Auto-Coder 为例，其中包含名为 coding 的 Agent 和名为 chat的 Agent ，后者主要负责设计。当提出需求时，chat Agent 会提供详细设计，而 coding Agent 则直接根据需求进行编码实现。

具体而言，在 Auto-Coder 中，核心的 Agent 首先会根据对需求的理解，可能还会调用类似 read file的工具以更清晰地理解需求，然后决定下一步是调用 coding Agent 还是先让 chat Agent 进行设计。如果需求简单且明确，核心 Agent 会直接调用 code Agent，并将需求细化后传递给 code Agent 执行，完成整个流程。这种方式下，存在一个总的 Agent 负责调度和编排其他 Agent 的工作。

综上所述，目前存在两种模式：第一种是底层使用非智能工具；第二种是智能工具和非智能工具的组合，由 Agent进行调度和编排。目前，我们的 Auto-Coder 已经实现了这两种模式。

在 Agentic Edit 模式下，我们提供的工具集覆盖全面且尽量精简，功能交叉很少。例如，我们可能只提供两个用于文件查找的工具：一个是搜索功能，另一个是罗列特定目录下的文件。这两个函数功能不重叠，如果提供太多工具，且没有很好地进行抽象，那么大模型在组合这些工具以完成通用代码任务时会更困难。因此，我们需要在保证功能覆盖的基础上，尽量减少工具数量，以免大模型难以找到最优解。

此外，大模型本身可能会忽略一些工具。如果工具太多，它通常会专注于几个熟悉的工具，而不是充分利用所有提供的工具。因此，在正常情况下，如 Agenda 这类范式所能使用的工具一般不会超过10个。

在 AI 辅助编程中，基本上10个类的原子工具就能满足几乎所有的编码需求。但是，为了扩展功能，我们会加入一些特殊工具，比如最近热门的 MCP。MCP 工具的使用也会控制在一定范围内，即在实际使用过程中，激活的工具数量是有限的。不会激活所有外部 MCP 工具，通常在当前会话中只激活两三个。

我们实际上设计了两种机制：第一种是通过代理 Agent 来选择子 MCP 的执行；第二种是由最外层的 Agent 决定是否调用某个 MCP 的执行。两种方式各有优劣，增加中间层会导致信息损耗，而不增加则可能导致单个 Agent 管理的工具太多，从而影响效果。这与人类管理层的扁平化与深度化的优缺点非常相似。

MCP 与我们之前提到的 AI 辅助编程工具类似，都会内置一些基础工具。例如，像 Windsurf、Cursor 这样的工具，通常内部集成的都是非 Agent 类的工具，数量大约在五到八个之间。然而，为了扩展其使用其他工具的能力，比如连接谷歌进行搜索，如果每个 AI 辅助编程工具都自己去实现这些功能，就会变得非常冗杂。因为用户的需求是多样的，甚至可能需要访问公司内网的 API，这种情况下无法提前为所有可能性做好准备。

在这个过程中，MCP 提供了一种解决方案：通过注册 MCP，Agent 在运行时动态调用这些 MCP 工具，这相当于为工具扩展留下了一个接口。只要遵循相应的规则或协议注册，大模型就可以调用这些工具。但需要注意的是，在这个过程中信息可能会有损耗。因为不同人实现的工具在自描述能力上存在差异，工具启动后会提供一系列信息来描述自身，大模型通过阅读这些描述来决定工具是否适合当前需求。

由于 MCP 工具的质量参差不齐，类似于插件的质量问题。相比之下，辅助编程工具内置的工具经过了反复调优和适配，其品质相对较高。

真实场景：迭代老项目而非 5 分钟写个小游戏

目前，大部分文章、自媒体或科技媒体的宣传，都在强调我们的 Agent 能够快速实现项目，比如一分钟内完成一个游戏的设计。确实大模型在创建新项目时成功率很高，例如 Gemini 的最新版本 Gemini 2.5 pro在新项目开发上的表现就非常出色，能编写出大量、高质量的代码。

然而，实际上，全球99%甚至99.9%的程序员主要是在迭代现有项目，这对模型的能力提出了不同的要求。

Gemini 2.5 pro 在老项目的修改上能力相比 sonnet 3.7 显著偏弱，与开发新项目时表现出的能力截然不同。随着新项目逐渐变为老项目，像 Gemini 这样的模型可能会越来越力不从心。而Sonnet 的3.5、3.7版本模型在处理老项目时表现出的能力则明显更强。

因此，判断一个 AI 辅助编程工具是否真正实用，核心在于它对老项目的支持能力。即，能否在现有项目的基础上继续进行迭代。这才能真正考验一个 AI 辅助编程工具的优劣。这其中涉及许多挑战，除了模型能力之外，我再举几个例子。

首先，大模型都有处理窗口的限制，如64K、8K或200K tokens。现在，像 Gemini 和 GPT 4.1 这样的模型提出 1M token的处理能力，但实际上这仍然有限。例如，有些项目的一个文件就超过了64K tokens，导致大模型无法直接处理。在这种情况下，如何让大模型有效地修改文件就成为了一个挑战。

另一个挑战是，用户的需求可能涉及多个文件，比如一次重构可能涉及到20-100个文件，每个文件都都很大，这显然超出了大模型的处理窗口。在这种情况下，如何让大模型有效地修改多个文件也是一个难题。这与单文件大小的问题类似，都是AI辅助编程工具需要克服的挑战。

这些挑战通常只在开发老项目时才会遇到。因为新项目代码量较少，可以一次性将所有代码发送给大模型进行修改。但对于老项目，如我们遇到的 Auto-Coder 项目，动辄就有上万个庞大的 Java 文件,此外还有古老的 JSP, PHP 等非常庞大的老项目存在。

在这种情况下，我们发现一些工具，如Cursor，在处理上万个 Java 文件时可能会直接崩溃，在建索引过程中就出现故障。这实际上是真正考验 AI 辅助编程工具真实能力的场景。

在 Auto-Coder 中，我们应对超大单一文件的设计了一套方案，具体来说就是对文件实现：滑动、抽取、合并三个动作。比如遇到当前文件内容过长，相当于一张超长图占据了整个屏幕，而大模型无法一次性查看整个图片的内容，每次只能查看一个窗口。假设这个窗口大小为1000行，那么在修改过程中，由于不确定需要修改的具体部分，就需要逐步滑动窗口来定位。例如，可以每10行滑动一次，每次滑动后检查当前窗口内的内容。当发现某个窗口中包含可能需要更改的代码片段时，就将这部分内容抽取出来，然后继续滑动窗口进行判断。那为什么需要合并操作呢？在滑动过程中，会出现大量重叠的内容，这就需要通过合并操作去除这些重叠部分，确保抽取出来的内容是完整，有效的，可编辑的。

最终，我们获取到的将是用户真正关心的关键信息。无需将整个文件内容输入大模型，只需提供这些关键信息，大模型就能知道需要修改的部分。最后，将大模型的修改结果解析并合并回原始的超大文件中。

这个过程包括窗口滑动、抽取和去重合并三个环节，我们实际测试效果非常好，例如之前测试过修改 Linux 内核里庞大的单一文件。

通过这种方式，我们能够精确地定位并自动化地修改和合并内容。而传统的技术往往难以实现这一点，因为文件规模太大，无法像我们这样以窗口为单位进行有效处理。例如，某些技术会以整个文件为单位输入大模型，这样在定位修改位置时就会遇到困难。还有一些技术虽然有一定的滑动窗口概念，但在处理大量信息时依然无法胜任。目前，这应该是 Auto-Coder 中较为独特且其他竞品尚未具备的功能。

对于熟练的程序员来说，如果清楚自己的任务且不需要大模型来寻找上下文，那么在日常工作中，使用非 Agent的Manual模式一次需求通常可以在30秒内完成，基本上在3到60秒之间大模型就能处理完毕。而如果手动完成这些任务，可能需要1到2小时。因此，使用大模型的效率提升是非常显著的。

当然，这也取决于模型的速度。速度越快，用户体验就越好。你会发现代码在短短一秒内就完成了，而人工编写可能需要两三个小时。

下一步：突破“记忆”局限

目前，AI 辅助编程工具面临的最大挑战，我个人认为，并非之前提到的那些问题，因为随着时间的推移，我们在工程上会不断改进。真正的问题在于，大模型本身不具备记忆能力，这究竟意味着什么呢？

以 Auto-Coder 或 Cursor 为例，即使我使用它们开发了1000次，迭代了1000个功能，但每次新建一个回话后，对于 Cursor 或 Auto-Coder 来说，都相当于第一次接触这个项目。

这是因为底层模型本身没有记忆能力，所有的“记忆”都局限于当前窗口。你必须将相关信息放入窗口，模型阅读后才能理解。现在，我们真正需要实现的功能是，随着使用次数的增加，比如我使用 Auto-Coder 或 Cursor 开发项目的次数越多，模型对项目应越来越理解、越来越熟悉。就像人类在持续迭代过程中，脑海中会自然形成项目结构、文件功能及修改需求的条件反射。

然而，大模型并非如此。每次对它来说都是全新的开始，即使已经读过无数次某个文件，下次遇到新需求时仍需重新阅读，走完整个流程：先看文件，再搜索另一个文件，然后继续阅读。

此外，大模型也不知道之前发生了什么修改。尽管大部分AI辅助编程工具都引入了一定的记忆系统（例如会自动抽取和发现回话中的一些有用的内容并且记录下来）

我认为这是大模型自身难以解决的问题，可能需要通过 AI 辅助编程工具自身来解决。目前市面上也有一些尝试，比如 Auto-Coder、Cline 的文档追踪系统。所谓文档追踪系统，就是记录项目所有变化对应的文档。下次编程时，带上这些记录，就能了解项目的迭代历程，判断哪些变量、哪些代码与当前需求相关。随着迭代次数的增加，这个记忆系统会越来越完善，大模型能收集到更多有效信息来理解项目，从而实现——使用 Auto-Coder 开发项目次数越多，提出的需求数量可以越少，甚至不需要指定文件，模型就知道应该修改哪个文件。

这是我坚信未来所有 AI 辅助编程工具都应努力实现的目标。