AI辅助编程背后技术揭秘：Code Agent 是怎么实现的

2025 是 Agent 的元年

我们都听说一句话： 2025 是 Agent 的元年。  其实与其说是 Agent 元年，倒不如说是 AI辅助编程的开花结果期,因为 AI 辅助编程是跑的最早，最深的应用场景。 

但是 Agent 的概念众说纷纭，似乎一切和AI沾边的应用，都可以用 Agent 来解释。那么到底什么是 Agent ? 今天，笔者尝试从 AI 辅助编程领域来给大家介绍，Agent 到底是什么。

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 的基本流程

Code Agent 细化了前面的 Reasoning-> Acting 循环。基本循环为：

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

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

3. 执行工具

4. 观察执行结果

5. 重复第一步。

为了有更直观的感受，我这里贴一张 auto-coder.web 的实际执行案例，可以和上面的步骤对应上：

Auto-Coder 提供的实现概览

auto-coder 实际实现一套预定义流程编码模式，一套纯 Agentic 的编码模式。

1. Context 模式： 事先根据场景规划好的工作流程，每个流程会调用特定的Agent。你可以理解为Agent 套用Agent,每个Agent 做的事情都非常专一，比如有查找上下文的Agent,有根据需求和上下文生成代码的Agent。这种方式严格意义上不输于前面的 Agentic AI System,原因是因为他的自主决策能力有限。

2. Agent 模式：整个工具和流程完全由大模型自助决策。

其中 Agent 编码模式又根据工具抽象程度，我们分成两种：

1. Agents 模式。 这个模式我们提供了诸如 /coding,/chat 等非常高阶的 agent 作为工具，让最外层的Agentic让系统自由组合，每个 agent 内部又可以自由组合多个工具来完成自己的任务。相当于一个三个层级的工具组合。外部编程Agent的Agent->根据场景定制的原子工作Agent ->  Agent可以使用的基础工具集

2. Agent Edit 模式。我们给的工具非常底层，只提供查找，罗列，修改等几个有限的原子工具，然后 Agent 自己来前面的决策流程。

Agent Edit

该模式实际上是当前主流的做法，比如cline/cusor/windsurf 都是这种做法. 而 Agents 模式则属于auto-coder正在持续探索的方向，因为我们认为大模型一定要学会更好的使用高阶工具/agent 而不是一些原子组合。cline 把希望放在了MCP上，但是我们认为在编程领域，还是需要内置更好的agent组合，而不是希望一招鲜吃遍天下。

如何实现

步入今天正题，我们看看 auto-coder 是如何实现 Agent Edit 的。首先我们会给定一个系统 prompt, 大概是这个样子的

目标你是 balabla,你的目标是xxxx.,
=====工具使用
## 搜索工具
搜索工具是为了xxx,具体格式为：<search><path>xxx</path></search>
## 结束工具
<completion><response>xxx</response></competion>====工具使用示例...====规则和经验流程....

接着用户发起一个需求，回答的时候，系统会流式输出内容。我们需要提供一个函数，流式的解析这个输出,提取工具，然后执行：

while true
  reponse = 发起对话得到  for text in response    tool =    extract(tool)    result = execute(tool)    把 result 添加到对话中    break，跳出当前流式解析过程   遇到结果工具调用则跳出最外部true 循环

可以看到，提取工具，执行工具，添加工具结果到会话，然后如果没有工具了就break,然后将再次将结果带上，重新提交给大模型。

这个流程实际上是：

1. 把系统提示词和用户需求发送给大模型。

2. 大模型流式输出带有xml 工具调用的文本

3. 流式解析文本，非工具调用照样输出，工具调用抽取完整的一个后直接执行，然后把结果添加到对话，中断当前的流式输出。重新发起一次请求，让大模型根据当前现状，重新调整下一次动作。

可以看到，基本调用一次工具，就是发起一次新的请求，再流式解析和调用，这样相当于把当前的现状（修改结果），大模型重新进行了获取，从而能够指导接下来如何做决策。

从这里可以看到，agentic 实际上是有点动态决策树的概念，而且往往只能获得局部最优解。

Agents

简单说说 auto-coder 中的  Agents 模式，和agent edit 一样，都是提供一个工具，让大模型自己决策如何使用，什么时候使用，根据使用结果动态调整下次决策流程。但是实现和上述流程略微有点区别：

1. 前面的工具调用，大模型会输出xml来描述，在 Agents 中，我们是通过json 来描述的。每次请求，我们会严格要求大模型只输出一个工具。

2. 对输出的解析，我们没有采用流式，而是等全部输出后再展示（因为只输出json工具调用，所以很快）。

3. 展示的不是大模型的思考过程，而是每个agent 内部自己的执行状态和日志。

可以看下面的图有个更直观的感受：

Agents/Agent Edit对比

两种实现的最核心区别是工具的抽象程度。Agent Edit 实际上就是一个Agent ，相当于一个程序员，使用编辑器对工具做修改。比如如果要做修改，该Agent 会生成修改的diff,然后让工具去做合并。而 Agents 则是根据当前项目状态，选择合适的agent 完成工作，然后只做review ，比如如果需要修改文件，他会调用 /coding 工具，并且用文字，二次阐述要做什么，/coding Agent 会根据他的描述，实现具体的需求。 

整体而言， Agent Edit 模式把控力最好，你可以看到非常详细的设计，原子工具调用，就像一个普通程序员的视角。而施一公 Agents ，则更加关注结果，后续的review 的工作较重。

总结

这篇文章我们详细的描述了 Agentic AI System 特性是什么，然后以 auto-coder 的两个实现，来展示具体的实现逻辑和细节，并且对比两者的优缺点。

最后，欢迎访问 https://auto-coder.chat 来了解我们的产品。