项目介绍

Aider是一个可运行于GUI和命令行的结对编程助手，它可以处理自然语言需求以及来源于github issue的需求。在GUI界面可以使用/命令（如/help），在命令行界面则可以使用–传递参数。

由于这是个2023年的项目，那时Agent思想尚未出现，但这个项目包含了大量后来Agent使用的技术要点和思想，包括感知—决策—行动闭环，使用工具，状态管理，上下文检索与压缩，动态扩展上下文，权限管理，Git Checkpoint 与回滚，模型路由和角色分工，可观测性。本文不落到具体源码，只介绍思想和实现逻辑。

该项目的github地址为https://github.com/Aider-AI/aider。

技术要点

感知—决策—行动闭环

每次调用LLM的过程称为一个轮次。在一个轮次中，aider将代码文件和用户需求等构建为上下文传递给模型，模型分析上下文的环节称为感知，然后模型生成决策，包括shell命令，工具使用以及对代码的直接修改等，将决策返回给aider，aider进行行动。这整个过程称为“感知—决策—行动闭环“。

在aider实际执行中，还有两个额外要点。当模型返回决策时，aider会检查编辑格式，确认返回的格式合法；在aider根据模型决策行动后，会使用Lint和Test分别进行代码静态检查和运行测试，确认用户需求得到解决，如果没有解决或出现其他问题，则重新进行决策。

使用工具

工具是指 aider 中代表各种功能的 python 函数。一般情况下，在构建上下文时，aider 会将可能会用到的工具名称列出清单，在上下文中一起传递给模型，包括这个工具的名称、需要什么参数、以及返回的结果有何意义，模型在决策时可能会告诉 aider”应调用这个工具“，aider 在行动时就调用相应工具完成操作。

在 aider 中，出于对当时模型性能限制的考虑，没有上述 LLM 自主调用工具的机制，工具调用完全掌控在用户和 aider 固定调用手中，这样的机制已经落后，因此不多赘述。

状态管理

在每个会话中，aider会维护一套状态，包括当前任务消息、已经归档的历史消息、当前会话中涉及的文件、git仓库相关信息等，这一套状态在整个闭环时供aider随时使用。这是一种将状态分离的思想。

上下文检索与压缩和动态扩展上下文

在每一个会话开始后，aider会提前解析代码结构，将函数、类、文件等代码看作节点，通过识别结点间引用等关系建立关系树和索引，再通过关键词检索等检索关系树，对每一个结点的重要性进行排序，并在组织这个轮次的上下文时挑选重要的结点作为上下文，以压缩其篇幅。

同时，aider也会将同一个会话中之前历史轮次内发现的同样相关的结点也放入当前轮次内，实现上下文的动态扩展。另外，有些代码文件的权限是只读的，这也会在上下文中区分开来。

权限管理

aider对模型有比较严格的权限管理，对于每个新的文件加入上下文、创建文件时，都需要用户授权；整个项目的workspace仅限于git仓库范围内，并在每次模型想要运行shell命令时，默认询问用户。

Git Checkpoint 与回滚

在每次AI修改前，aider先检查用户是否有未提交的修改，如果有修改，则分别记录初版以及用户修改版，作为两个检查点；如果没有则只记录初版即可。
记录检查点后，aider先提交用户修改，之后开始AI修改。在进行AI修改后，先直接提交，如果lint/test发现问题再进行回滚，重新修改。如此，可以保证AI修改和用户修改分开，并让AI修改出现问题时可以回滚并保存出现的问题。

模型路由和角色分工

aider可以连接多个模型，并可以给每一个模型设置一个”职责“，以此让每个model可以聚集在自己的部分职责，达到更好的效果。具体在项目中，该项目只有三个model角色：

Main model：负责对话等，并在Architect 模式下负责规划方案，是最常用的model。
Editor model：在Architect 模式下负责将方案落地到代码。
Weak model：负责生成git提交信息并管理提交历史，以及压缩会话历史。

可观测性

Aider 能够记录或展示模型请求、流式响应、Token 使用量、调用成本、文件修改、Git Diff、提交记录、Lint/Test 输出、重试过程以及异常信息。这些信息已经构成现代 Agent Runtime 中执行轨迹的基础。不过，目前它们主要分散在终端输出、Git 历史和日志中，尚未被统一抽象为结构化事件，也缺少面向任务的可视化轨迹。因此，用户可以观察最终结果和局部过程，但仍难以完整追踪一次任务中的模型调用、工具执行、代码变更、验证结果、失败重试及其因果关系。