AutoPatch-J

面向 Java 仓库的代码修复 Agent，自动审阅代码，并针对发现的问题生成高质量补丁。

它既可以在本地 CLI 中使用，也可以接入 CI/CD。

持续交付经得起审查和验证的补丁。

开始使用 · Patch Safety 契约 · Memory 设计

自动修复难在哪

静态扫描器提供的是规则、位置和问题描述，自动修复还需要解决这些问题：

• 信息怎么给： 正确修复可能依赖类型定义、调用关系和测试。信息太少会误判，把整个仓库交给 LLM 又会引入噪声，需要按任务逐层补充。
• 修改怎么落地： LLM 只能提出修改，真正作用于仓库需要受控工具。补丁必须绑定当前 finding，准确落到当前源码，并限制修改范围。
• 执行怎么推进： 修复不是一次问答，需要判断信息是否充分、调用工具、生成补丁并检查结果。同一文件的前序修改还可能改变后续 finding 的位置。
• 哪些内容需要被记住： 任务进度、中间判断和待审补丁需要持续保存；代码风格、提交规范等工程偏好可以跨任务复用，但普通对话 Memory 不能无边界地进入代码修复。
• 结果由谁验收： 不能由 LLM 自己宣布完成。扫描器、编译、测试或团队规则提供独立证据；证据不足时继续补充、修正或停止。

如何稳定交付

Agent = LLM + Harness Engineering

LLM 负责理解代码，Harness Engineering 保障交付质量。

真实工程实践：

• 上下文管理： 以当前 finding 附近的源码为起点，只在需要时扩展到方法、类型或文件。focus scope 限定可读路径，普通代码分析还可以通过符号索引查找关联代码。
• 工具系统： 任务类型决定 LLM 当次可以使用哪些工具。代码审阅可以读取 finding 和源码、准备补丁；补丁修订只能处理当前待审项。未授权工具和绕过审核的文件写入会被程序拦截。
• 执行编排： 扫描结果进入 finding 队列逐项处理。信息不足时继续读取上下文，补丁准备完成后进入审核；工具调用反复没有进展或达到执行上限时，任务停止而不是无限循环。
• 状态与记忆： 扫描快照、finding 队列和补丁审核状态保存在 LLM 对话之外。前序补丁改变源码位置后，后续待审项随之更新；项目约定和历史决策可以写入 Memory，普通对话 Memory 不会无边界地混入代码审阅。
• 评估与观测： 补丁进入审核前，需要对应当前 finding 和当前源码，并提供可审查的 diff；应用后重扫原规则，以扫描结果判断问题是否消除。未来可以把编译、测试和团队规则纳入独立验收证据。
• 约束与恢复： 可读路径、可用工具和执行轮次都有明确边界。源码变化时，后续补丁会重新定位或停止；工具失败、证据不足或执行没有进展时，不继续猜测。未来可以支持有限重试、失败兜底和稳定状态恢复。

工程效能

当 AutoPatch-J 进入 CI/CD 流水线，代码扫描不再止于发现问题，修复结果将以可评审的 MR/PR 交付。代码修复也从零散的人工作业，变成随流水线持续运行、可跨项目复用的工程能力。