---
title: "把 AI Coding Agent 变成会持续改进的工程伙伴"
source_url: "https://towardsdatascience.com/how-i-continually-improve-my-claude-code/"
source_summary: "/home/lin/.hermes/projects/hermes-gsummary-workflow/runs/outputs/20260519-162949-How-I-Continually-Improve-My-Claude-Code-2653629-777971080-summary.md"
created: "2026-05-19"
type: "tutorial"
---

# 把 AI Coding Agent 变成会持续改进的工程伙伴

> 适用对象：已经在使用 Claude Code、Codex、Hermes Agent 或类似 AI coding agent 的个人开发者 / 小团队。  
> 核心目标：不要只“用” Agent，而是给它建立一个可验证、可回滚、不过度膨胀的持续改进闭环。

## 1. 一句话原则

AI coding agent 的能力提升，不应该只依赖模型升级；更现实的路径是：

```text
会话记录 / 运行日志
→ 只读复盘
→ 识别高频失败模式
→ 生成候选改进
→ 分层沉淀到文档 / skill / wiki / memory / cron
→ 验证后再进入 active 行为
```

这篇教程基于 Eivind Kjosbakken 的文章《How I Continually Improve My Claude Code》，但不会照搬“每天自动改规则文件”的做法。这里采用更适合 Hermes / 本地 Agent 工作流的安全版本：**先生成候选，后验证，再最小落地**。

## 2. 为什么需要持续改进闭环

很多人使用 AI coding agent 的方式是一次性的：

- 给需求
- 看代码
- 修报错
- 结束会话

问题是，同样的错误会反复出现：

- Agent 不知道项目约定
- 重复运行错误命令
- 总是忘记测试路径
- 把临时任务状态写进长期记忆
- 过早问用户，而不是先查工具
- 或者相反，擅自执行有副作用的操作

持续改进闭环要解决的是：**让每一次失败都变成下一次更少失败的输入**。

## 3. 不要直接自动写全局规则

文章里提到的做法是让 Agent 定时复盘，然后自动更新类似 `agents.md` 的规则文件。这个方向有价值，但直接照搬有风险。

主要风险：

- **上下文膨胀**：每个小教训都写进全局提示词，长期会拖慢并污染推理。
- **规则冲突**：旧规则和新规则可能互相矛盾。
- **记忆污染**：一次性任务状态被误写成永久偏好。
- **过度自动化**：cron 每天输出低价值噪音，最后没人看。
- **active 行为漂移**：Agent 自动改自己的行为，但没有审查和回滚点。

更安全的原则是：

```text
自动发现问题可以；自动修改 active 行为要非常克制。
```

## 4. 推荐架构：五层沉淀

把复盘结果分层，而不是都塞进一个规则文件。

### 4.1 Project report：先放证据

用于保存复盘报告、候选问题、验证记录。

适合内容：

- 最近 7 天失败模式
- 哪些会话出现了重复问题
- 哪些建议还没有验证
- 哪些改动需要审批

示例路径：

```text
.hermes/projects/hermes-continual-review/reports/2026-05-week3.md
```

### 4.2 Skill：保存可重复流程

适合内容：

- 如何调试某类问题
- 如何做代码审查
- 如何执行 TDD
- 如何处理某类文章摘要和入库

判断标准：如果一个流程未来会重复 3 次以上，且有明确触发条件，就考虑 skill。

### 4.3 Wiki：保存概念和长期知识

适合内容：

- AI coding agent 持续改进闭环
- 多 Agent 协作模式
- 本地知识治理原则
- 某个外部文章提炼出的稳定方法论

Wiki 不应保存大量临时操作日志。

### 4.4 Memory / User profile：只保存稳定偏好和事实

适合内容：

- 用户偏好先 one-shot 验证，再 recurring cron
- 用户偏好执行类任务先明确边界
- 环境长期事实，例如 Hermes wiki 路径

不适合内容：

- “今天修了某个 bug”
- “某篇文章已总结”
- “某个计划 Phase 2 完成”

### 4.5 Cron：只调度稳定、低噪音、可回滚的流程

适合内容：

- 每周运行一次只读健康检查
- 每周生成候选复盘报告
- 有明确输出质量门槛的监控任务

不适合一开始就 daily 自动改配置。

## 5. 最小可用闭环：一周一次只读复盘

先从最小版本开始。

### 输入

- 最近 7 天会话记录
- 最近失败或中断的任务
- 用户纠正过的行为
- 被加载但暴露缺陷的 skills
- cron 最近状态

### 输出

一份只读报告，包含：

```text
1. 高频失败模式
2. 证据来源
3. 建议落点：memory / skill / wiki / cron / project docs / 不沉淀
4. 风险等级：低 / 中 / 高
5. 是否需要用户审批
6. 最小修改建议
7. 验证方法
```

### 不做的事

第一阶段不要自动：

- 写 memory
- patch skill
- 改 wiki
- 创建 recurring cron
- 修改 Hermes runtime config

## 6. 可复制 Prompt：只读复盘版

下面这个 prompt 可以用于 Claude Code、Codex、Hermes 子任务或其他 Agent。

```text
你是 AI coding agent 持续改进审查员。

目标：只读分析最近一段时间的会话/日志，找出可复用的改进候选。

硬性边界：
- 不要修改 memory、skills、wiki、cron、runtime config 或项目代码。
- 不要创建新任务。
- 不要把一次性任务状态当成长期知识。
- 所有建议必须带证据和落点。

请输出：
1. Top 5 高频失败模式
2. 每个失败模式的证据摘要
3. 推荐沉淀层：project report / skill / wiki / memory / cron / discard
4. 为什么不是其他层
5. 风险等级
6. 最小改动建议
7. 验证方法
8. 需要用户审批的事项
```

## 7. 可复制 Prompt：候选落地审查版

当只读复盘报告质量稳定后，再用第二个 prompt 审查是否值得落地。

```text
你是 Hermes 知识治理审查员。

输入是一份 continual-review 候选报告。请判断每条候选是否应该进入 active 层。

规则：
- workflow 候选优先进入 skill/reference，不进入 memory。
- 概念知识优先进入 wiki，不进入 skill。
- 稳定用户偏好才考虑 user profile。
- 临时任务进展直接丢弃。
- cron 只能在 one-shot 结果连续稳定后再建议 recurring。
- runtime/config 改动必须有备份、check、doctor、smoke 和回滚路径。

输出表述：
- 采纳 / 暂缓 / 拒绝
- 推荐落点
- 最小修改范围
- 验证方法
- 回滚方式
- 是否需要用户批准
```

## 8. Hermes 映射示例

如果你使用 Hermes，可以这样映射文章里的机制。

```text
Claude Code conversation log    → Hermes session_search
Daily review cron               → Hermes cronjob one-shot / weekly job
agents.md                       → AGENTS.md / CLAUDE.md / skill / wiki 分层
review-past-performance skill   → continual-review skill 或 project-local prompt
recap / agent view              → 子任务边界、delegate_task 摘要、cron 输出记录
```

重点不是工具名字，而是闭环结构：

```text
观察 → 归因 → 候选 → 分层 → 验证 → 最小落地
```

## 9. 一个具体例子：Agent 总是忘记跑测试

### 观察

最近 5 次代码修改里，有 3 次 Agent 在总结时说“已完成”，但没有实际运行测试。

### 错误落地

不要直接写入全局规则：

```text
永远必须运行所有测试。
```

这太粗暴，可能导致小文档修改也跑完整测试套件。

### 更好的候选

沉淀到 coding workflow skill：

```text
当任务修改 src/ 或 tests/ 下代码时，完成前必须运行对应最小测试；
如果测试耗时过长，先运行目标模块测试，并说明未运行全量测试的原因。
```

### 验证

下一次代码任务检查：

- 是否识别修改范围
- 是否选择最小测试
- 是否报告测试命令和结果
- 是否没有把“计划运行”当作“已经运行”

## 10. 一个具体例子：Agent 反复问本可查到的问题

### 观察

Agent 经常问：

```text
项目测试命令是什么？
配置文件在哪里？
wiki 路径是什么？
```

但这些信息其实可通过文件或已有记忆查到。

### 推荐改进

补到对应 workflow skill：

```text
提问前先做 prerequisite discovery：
- 查 CLAUDE.md / AGENTS.md
- 查项目 README
- 查已有 skill
- 查 session_search 或 wiki
只有工具无法找回且问题会改变执行路径时，才向用户提问。
```

### 不推荐

不要把所有项目路径都写进 memory。普通项目路径会过期，应放项目文档或 wiki index。

## 11. 一个具体例子：复盘发现适合入 wiki 的文章

### 观察

某篇文章不是单次新闻，而是提出了稳定方法论，例如“AI coding agent 持续改进闭环”。

### 推荐落点

- raw source：保存原文链接和摘要路径
- concept page：提炼方法论
- index/log：记录来源和更新时间

### 不推荐

- 不要直接写成 skill，除非已经有可重复操作步骤。
- 不要写 memory，因为这不是用户偏好。
- 不要立刻创建 cron，因为还没验证输出质量。

## 12. 多 Agent 并发的简化规则

文章提到作者用 Warp 管理多个 Agent。对 Hermes 或其他 Agent 系统，更通用的规则是：

```text
一个子 Agent = 一个清晰边界 = 一个可验证输出
```

实践建议：

- 子任务不要共享同一个可写文件，除非有明确合并顺序。
- 子 Agent 不要做外部副作用，除非主 Agent 会验证结果。
- 每个子任务必须返回证据：路径、命令、测试结果、URL 或 ID。
- 父 Agent 不要直接相信“完成了”，必须读回文件或跑检查。

示例任务拆分：

```text
任务 A：只读审查最近 20 条失败会话，输出候选问题。
任务 B：只读审查现有 skills，找出可能承接候选的 skill。
任务 C：只读审查 wiki 是否已有相关概念页。
父任务：合并 A/B/C，提出最小落地方案。
```

## 13. 推荐成熟度路线

### Level 0：人工复盘

偶尔回看会话，总结失败点。

适合刚开始。

### Level 1：one-shot 只读复盘

手动触发一次 Agent 复盘，输出报告。

适合验证 prompt 和报告格式。

### Level 2：每周只读复盘

每周 cron 生成候选报告，但不自动改 active 层。

适合个人长期使用。

### Level 3：半自动落地

低风险 skill/reference patch 可以由 Agent 提案，人类批准后执行。

适合已有稳定治理规则的环境。

### Level 4：受限自动落地

只允许少数低风险、可回滚、带测试的改动自动应用。

大多数个人环境不需要一开始做到这里。

## 14. 落地检查清单

在把复盘机制变成定时任务前，先检查：

- [ ] 是否已有至少 2 次 one-shot 报告？
- [ ] 报告是否能正确区分 memory / skill / wiki / cron / discard？
- [ ] 是否避免把任务进度写成长期事实？
- [ ] 是否给每条建议提供证据？
- [ ] 是否明确哪些改动需要审批？
- [ ] 是否有回滚方式？
- [ ] 是否不会每天制造低价值通知？
- [ ] 是否有一条明确的停止规则：连续低价值输出就暂停？

## 15. 推荐默认策略

如果你是个人开发者或小团队，建议默认采用：

```text
每周一次，只读复盘；
只输出候选，不自动修改；
候选按层分类；
经验证和审批后最小落地；
稳定后才考虑更高频或半自动。
```

这比“每天自动改规则文件”慢一点，但长期更安全，也更不容易污染 Agent 的长期行为。

## 16. 结语

AI coding agent 的持续改进不是靠堆更多规则，而是靠一个小而稳定的反馈系统：

```text
少写全局规则，
多保存证据，
按层沉淀，
先验证，再自动化。
```

当这个闭环跑起来后，Agent 不只是执行工具，而会逐渐贴合你的项目、偏好和工程边界。真正的收益来自长期复利，而不是一次 prompt 优化。