为什么 AI 编程助手总像刚入职
AI 编程助手已经能够生成函数、修复 Bug、解释报错和编写测试。
但当任务从一个独立问题扩展到真实软件项目时，很多 AI Coding Agent 仍然会遇到一个明显问题： 它们每次开始工作时，都像刚加入项目的新员工。
它们可能不知道某段代码为什么这样设计，找不到之前处理过的类似 Issue，也无法理解某个模块经历过哪些版本变化。
这并不一定是因为模型不会写代码，而是因为它缺少项目级别的长期上下文。
SWE-ContextBench 正是为研究这一问题而设计的 Benchmark。
软件工程不是一次性任务
真实的软件工程任务往往具有长期性。
一个 Bug 可能经历多个版本，一个功能可能经过多次重构，一次测试失败可能与几个月前的代码修改有关。 因此，代码 Agent 需要理解的不只是当前文件，还包括：
- 历史 Issue；
- Pull Request；
- Commit 记录；
- 构建日志；
- 测试失败信息；
- 相关模块和接口；
- 项目的设计规范。
如果 Agent 只能看到当前代码，它可能生成语法正确的修改，但无法判断这段代码是否符合整个项目的历史和约定。
上下文窗口不等于代码记忆
很多人认为，只要给 LLM 更大的上下文窗口，模型就能够理解整个代码库。
但上下文窗口解决的是“能放多少内容”，并没有解决“哪些内容真正重要”。
大型代码库往往包含大量文件和历史信息。如果把所有内容直接放入提示词，模型可能会遇到几个问题： 一是无法快速定位与任务最相关的内容；二是新旧实现混在一起，容易误用已经废弃的代码；三是上下文长度和推理成本快速上升；四是历史原因和设计背景仍然没有被真正理解。
因此，Coding Agent 需要的不只是更大的上下文窗口，而是更好的 Code Memory。
Code Memory 应该保存什么
一个面向软件工程的 Memory 系统，应该能够保存代码结构、项目历史和开发经验。
代码结构包括模块、类、函数、接口和依赖关系。项目历史包括 Issue、Pull Request、Commit 和重构记录。开发经验还包括测试失败、构建日志和过去的解决方案。
这些信息共同构成了代码库的长期上下文。
当 Agent 接收到一个新任务时，它不应该只检索相似代码，还需要了解：
- 当前文件属于哪个模块；
- 相关接口在哪里定义；
- 过去是否出现过类似问题；
- 这个模块最近是否发生过修改；
- 当前变更可能影响哪些测试。
Stateless Agent 与 Context-Aware Agent
SWE-ContextBench 重点区分两类系统。
Stateless Agent 每次接收到任务时，只使用当前问题和当前代码。它不会主动访问历史 Issue，也不会检索过去的开发记录。
Context-Aware Agent 则能够访问和利用项目的长期上下文，包括代码提交、历史问题、测试日志和开发规范。
这种对比能够帮助研究者回答一个关键问题： 一个 Coding Agent 的能力提升，到底来自模型本身更强，还是来自更好的上下文管理和代码记忆？
SWE-ContextBench 如何评估代码记忆
SWE-ContextBench 将软件工程任务放在更完整的项目环境中进行评估。
Agent 不仅需要修改代码，还需要从历史信息中找到真正有帮助的内容，并将这些内容应用到当前任务。
评测重点包括：
- 是否找到正确的历史上下文；
- 是否理解历史信息与当前问题的关系；
- 是否能够复用过去的解决方案；
- 是否避免使用过时的代码和规则；
- 最终修改是否符合项目设计；
- Agent 是否能够解释自己的修改原因。
相比单纯的代码生成评测，这种方式更接近真实的软件开发工作。
从代码生成到软件工程协作
未来的 AI Coding Assistant 不应该只是一个自动补全工具。
一个能够长期参与软件工程的 Agent，需要理解项目是如何发展到今天的，知道过去做过哪些技术决策，也要能够在新的任务中复用已有经验。
这意味着 Coding Agent 需要具备三种能力：
第一是代码理解能力，能够读懂当前文件和模块结构；第二是项目记忆能力，能够访问历史 Issue、PR 和提交记录；第三是长期学习能力，能够根据任务结果更新自己的理解。
SWE-ContextBench 将 AI 编程 Agent 的评估从“能不能写出代码”，推进到了“能不能理解整个项目”。
对于 MemoraX AI 来说，代码智能不仅是代码生成问题，也和 Agent Memory、Retrieval 以及 Long-Term Reasoning 密切相关。
真正成熟的 AI Coding Agent，应该能够从一次性代码生成工具，发展为能够持续学习和长期协作的软件工程伙伴。
