AutoPatch-J

KO | EN

gitlite — search

#javascript #python #hacktoberfest #react #ai #typescript #llm #go #golang #android #machine-learning #rust #deep-learning #linux

★ 21 Open GitHub ↗

Evidence-grounded AI agent for Java code repair with LLM-guided patches and human-in-the-loop review.

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

<h1 align="center">AutoPatch-J</h1>

面向 Java 仓库的代码修复 Agent，自动审阅代码，并针对发现的问题生成高质量补丁。
它既可以在本地 CLI 中使用，也可以接入 CI/CD。
持续交付经得起审查和验证的补丁。

<a href="docs/getting_started.md">开始使用</a> ·
 <a href="openspec/specs/patch-safety/spec.md">Patch Safety 契约</a> ·
 <a href="docs/memory_design.md">Memory 设计</a>

## 自动修复难在哪

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

- **信息怎么给：** 正确修复可能依赖类型定义、调用关系和测试。信息太少会误判，把整个仓库交给 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 交付。代码修复也从零散的人工作业，变成随流水线持续运行、可跨项目复用的工程能力。

AutoPatch-J

Explore Similar Repositories

Was this content helpful?

Recent Feedback

Download README