2026年4月13日 · 阅读 —

Self-Improving Agent：主动工作与用户参与边界说明

Agent 与 Skills

Self-Improving Agent：主动工作与用户参与边界说明

Self-Improving Agent 怎么分工：哪些步骤 AI 主动做，哪些需要用户参与？

Self-Improving Agent 不是一个“会自己变聪明”的魔法 skill，它本质上是一套工程化复盘机制：当 AI 被纠正、命令失败、发现最佳实践、或者用户提出缺失能力时，先记录到 .learnings/，再把高价值结论逐步升级到 AGENTS.md 和长期记忆里。这样 AI 的改进就不会停留在当次对话，而会沉淀成下一次默认能用的规则。

更口语一点的说法

它就是给 AI 建了一个错题本。 错了要记，被纠正了要记，发现更好的做法也要记。 但重点不是“记下来”，而是以后遇到同类问题能直接用，最后还能升级成长期规则。

文件结构

~/.openclaw/workspace/ ├── AGENTS.md ├── MEMORY.md ├── memory/ │ └── agent-notes.md └── .learnings/ ├── LEARNINGS.md ├── ERRORS.md └── FEATURE_REQUESTS.md

它们分别干什么

文件作用什么时候写
.learnings/LEARNINGS.md记录纠正、知识缺口、最佳实践我答错了、你纠正我了、发现更好的做法
.learnings/ERRORS.md记录命令失败、工具异常、外部 API 故障命令报错、服务超时、接口异常
.learnings/FEATURE_REQUESTS.md记录现在没有、但你明确想要的能力你说“能不能支持这个”
AGENTS.md写默认流程规则某条规则已经值得固化
memory/agent-notes.md写长期执行守则某个方法以后会反复用到

1. 先说结论

  • Self-Improving Agent 不是让用户多做记录工作，而是让 AI 在完成任务后，顺手把“错误、修复路径、最佳实践、统一规则”沉淀下来。

也就是说，这套机制的理想状态不是：

  • 每次都要你手把手提醒“去记一条”

而是：

  • 我在合适的时候主动判断、主动记录、主动升级规则
  • 只有在涉及策略选择、跨任务规则定稿、或者需要你拍板时，才让你参与

2. 先把角色分清楚

在下面的示例里：

  • 莫菲 Murph = AI 助理 = 主要执行者
  • 蓝葛格 = 用户 = 决策者 / 需求提出者 / 纠正者

为了让边界更清楚，可以先看一个总表。

阶段由谁主导是否通常需要用户参与说明
发现问题莫菲主导不一定AI 在执行过程中发现 bug、错误、异常
修复当前问题莫菲主导视情况常规修复一般我先做；重大改动才需要你确认
判断是否值得沉淀莫菲主导通常不需要我应该主动判断这次修复是否值得写进 .learnings/
写入 .learnings/莫菲主导通常不需要这是 AI 的整理工作，不该转嫁给用户
升级为统一规则莫菲先提炼有时需要你确认如果规则会影响长期工作方式，最好由你拍板
后续复用莫菲主导不需要下次我应主动按既有规则执行

一句话版：

修 bug 是我干，记经验也是我干；只有“这条规则以后是不是要长期生效”这类问题，才更需要你参与。

3. 一个真实可理解的场景：代码 bug 缺陷修复

下面用一个非常典型的工程场景来说明。

场景设定

假设我们正在修一个 Python 服务 bug。

问题现象是：

  • 接口偶发 500
  • 日志显示某个字段为空时，代码直接调用 .strip()
  • 结果抛出异常

报错类似这样：

AttributeError: 'NoneType' object has no attribute 'strip'

这时，如果没有 Self-Improving 机制，可能只是：

  1. 修掉 bug
  2. 提交代码
  3. 结束

但这样的问题以后非常容易再来一遍。

有了 Self-Improving Agent，真正目标就变成两层：

  1. 先把当前 bug 修好
  2. 再把“以后类似 bug 怎么处理”的规则沉淀下来

4. 用对话方式看清楚：哪些是我主动做，哪些需要你参与

下面直接用对话来演示。

5. 对话示例：Bug 修复 + Self-Improving 沉淀

阶段 A：你提出任务

蓝葛格： 这个接口报 500 了，帮我修一下。

这一段是谁在工作？

  • 需要你参与的部分：提出任务
  • 莫菲主动工作：开始排查

这一步你只需要告诉我目标：“修这个 bug”。 后面的看日志、定位原因、找修法，默认由我主动推进。

阶段 B：我排查并定位问题

莫菲： 我先看了一下报错，触发点在这里：

name = payload.get("name").strip()

当 payload.get("name") 返回 None 时，会直接报：

AttributeError: 'NoneType' object has no attribute 'strip'

我判断这是一个典型的空值保护缺失问题，不是业务逻辑本身错了，而是输入边界没兜住。

这一段是谁在工作？

  • 莫菲主动工作：读代码、定位 bug、归类问题类型
  • 你不需要参与：除非日志不全、上下文缺失

这一段完全应该由我自己做，不需要你一步步带着排查。

阶段 C：我给出修复方案

莫菲： 修法我建议这样改：

raw_name = payload.get("name")
name = raw_name.strip() if isinstance(raw_name, str) else ""

如果你希望保守一点，也可以在入口直接校验参数，不合法就返回 400，而不是默默兜底成空字符串。

这一段是谁在工作？

  • 莫菲主动工作：提出修复方案和备选路径
  • 你可能需要参与：如果涉及产品策略选择

这里有个边界：

  • 如果只是技术性 bug 修复，我可以直接修
  • 如果修法会影响业务行为，比如“空值时返回空串”还是“直接报 400”，那最好你拍板

也就是说：

技术修复我主导，业务策略你决定。

阶段 D：你做业务确认

蓝葛格： 这个字段不能为空，空了就返回 400，不要默默兜底。

这一段是谁在工作？

  • 需要你参与：业务规则拍板
  • 莫菲主动工作：据此实施修复

这一类信息是 AI 不该擅自脑补的，所以你在这里参与是必要的。

阶段 E：我完成修复

莫菲： 明白，那我按“参数缺失直接返回 400”改。修复后的逻辑如下：

def normalize_name(payload: dict) -> str:
    raw_name = payload.get("name")
    if not isinstance(raw_name, str) or not raw_name.strip():
        raise BadRequest("name is required")
    return raw_name.strip()

同时我会补一条测试，覆盖这两个场景：

def test_name_required_when_none():
    ...

def test_name_required_when_blank():
    ...

这一段是谁在工作？

  • 莫菲主动工作：改代码、补测试、完成修复
  • 你通常不需要参与

如果没有额外风险，这一段应该由我自己完成。

阶段 F：我判断“这次值不值得记”

莫菲： 这次修复不只是把 bug 补掉了，它还暴露出一个稳定问题：

对可空输入字段，不能直接链式调用字符串方法；必须先做类型和空值校验。

这类问题后面很可能反复出现，所以我建议把它记成一条统一规则。

这一段是谁在工作？

  • 莫菲主动工作：判断是否值得沉淀
  • 你通常不需要参与

这是 Self-Improving 最该由我主动做的部分。

如果每次都要你提醒“记一下”，那这套机制就废了。

阶段 G：我把经验写入 .learnings/

莫菲： 我会先把这次经验记到 .learnings/LEARNINGS.md，因为这里沉淀的是一条可复用的修复规则。

示例条目如下：

## [LRN-20260320-003] best_practice

**Logged**: 2026-03-20T11:45:00+08:00
**Priority**: high
**Status**: pending
**Area**: backend

### Summary
修复字符串字段相关 bug 时，先判断是否存在空值和类型不匹配，再决定兜底还是返回校验错误

### Details
本次接口 500 的根因是对 `payload.get("name")` 的返回值直接调用 `.strip()`，当输入为 `None` 时触发 `AttributeError`。这说明修复同类 bug 时，不能只盯着报错行，而要先检查输入边界、字段约束和业务期望。

### Suggested Action
以后处理同类 bug 时，默认按以下顺序：
1. 先确认字段是否允许为空
2. 再确认异常输入应兜底还是返回 4xx
3. 最后补对应测试，覆盖 `None`、空串、非法类型三类场景

### Metadata
- Source: conversation
- Related Files: app/api/user.py, tests/test_user_api.py
- Tags: bugfix, validation, backend, input-check

---

这一段是谁在工作？

  • 莫菲主动工作：写 learning
  • 你通常不需要参与

这一步是文档化沉淀，默认应该由我完成。

阶段 H：我要不要升级成长期规则

莫菲： 这条经验我倾向于进一步提升成长期规则，比如写进 memory/agent-notes.md，以后修这类 bug 默认按这个流程做。你要不要把它固化成统一规则？

这一段是谁在工作？

  • 莫菲主动工作：提出升级建议
  • 你可能需要参与：决定是否长期生效

这是最适合你参与的节点。

因为这里已经不是“记录一次经验”，而是在定以后工作的默认方法。

阶段 I：你确认长期规则

蓝葛格： 可以，定成统一规则。以后这类 bug 按这个流程修。

这一段是谁在工作？

  • 需要你参与：拍板长期规则
  • 莫菲主动工作：落到长期记忆

阶段 J：我升级成长期规则

莫菲： 明白，我会把它压缩成执行规则写进 memory/agent-notes.md，例如：

## Bug Fix 默认规则
- 处理字符串字段相关 bug 时，先判断字段是否允许为空，再决定是兜底还是返回 4xx。
- 不要直接在 `payload.get(...)` 的结果上链式调用字符串方法；先做类型与空值判断。
- 修复后必须补测试，至少覆盖 `None`、空串、非法类型` 三类输入。

以后只要再出现同类 bug，我就不需要重新发明流程，而会按这套规则直接修。

这一段是谁在工作？

  • 莫菲主动工作：提炼规则、写入长期记忆、后续复用
  • 你不需要继续参与

6. 用流程图看，就更清楚了

你提任务
  ↓
我排查 bug
  ↓
我提出修复方案
  ↓
如果涉及业务策略，你拍板
  ↓
我完成修复和测试
  ↓
我主动判断这次是否值得沉淀
  ↓
我写入 .learnings/
  ↓
如果要升级成长期统一规则，你确认
  ↓
我写入 memory/agent-notes.md / AGENTS.md
  ↓
下次我默认按新规则执行

这个流程里，真正需要你介入的，核心就两类：

  1. 业务含义需要拍板的时候
  2. 长期规则要不要正式生效的时候

除此之外，绝大多数工作都应该由我主动完成。

7. 什么时候一定要你参与，什么时候我应该自己做

7.1 我应该自己做的部分

这些属于 AI 默认责任区：

事项默认谁做
排查 bug 根因莫菲
提出修复方案莫菲
修改代码 / 补测试莫菲
判断这次是否值得记录莫菲
写入 .learnings/莫菲
提炼候选统一规则莫菲
下次按既有规则复用莫菲

7.2 更适合你参与的部分

这些通常需要你参与或拍板：

事项为什么需要你
业务规则选择AI 不该擅自决定业务含义
是否允许破坏性修复影响范围大，需要你授权
是否将经验提升为长期规则会改变以后默认工作方式
是否对外发布 / 对团队生效涉及更大范围影响

8. 记完了有什么用

这是很多人第二个疑问。

如果只是“写一条记录”，当然意义不大。

真正的价值在于，它会逐步改变后续工作的默认行为。

8.1 短期价值：下次不用重新踩坑

比如下次再出现：

payload.get("xxx").strip()

这种写法，我会优先警惕：

  • 这里可能有空值问题
  • 要先看字段约束
  • 要判断该兜底还是返回 4xx
  • 修完要补边界测试

这就省掉了重新摸索的成本。

8.2 中期价值：形成统一修 bug 流程

慢慢地，这类经验会收敛成稳定套路：

  1. 先看根因是不是输入边界
  2. 再问业务规则
  3. 再决定修法
  4. 最后补测试和记录

这样修 bug 就不再是“看运气发挥”，而更像一套方法论。

8.3 长期价值：变成默认规则

等某类经验足够稳定后，就可以写进：

  • memory/agent-notes.md
  • AGENTS.md
  • 甚至项目内的开发规范文档

这时候，Self-Improving 就不再只是“记一条 learnings”，而是：

把一次修复，升级成长期可复用的工程规则。

9. 什么时候用 Self-Improving，什么时候不用

9.1 应该用的时候

以下任一情况出现，就建议触发：

触发场景该记到哪里
你纠正了我的理解或做法.learnings/LEARNINGS.md
命令 / 工具执行失败.learnings/ERRORS.md
发现更优修复流程 / 最佳实践.learnings/LEARNINGS.md
你提出了当前没有的新能力.learnings/FEATURE_REQUESTS.md
某条经验想长期生效memory/agent-notes.md / AGENTS.md

9.2 不建议滥用的时候

以下情况通常不用记：

  • 一次性偶发、没有复用价值的噪声问题
  • 常识性修复，没有形成新方法
  • 纯机械执行，没有值得抽象的经验
  • 还没确认清楚事实，就急着写长期规则

核心原则是：

不是所有 bug 都值得记，但值得复用的 bug 修法一定要记。

10. 这套机制最容易误解的地方

误解 1：是不是每一步都要用户参与？

不是。

正确理解是：

  • 大多数步骤由我主动做
  • 用户只参与关键决策

误解 2：是不是修完 bug 就必须写很多文档？

也不是。

正确做法是：

  • 先修当前问题
  • 再判断这次有没有复用价值
  • 有价值才沉淀
  • 有长期价值再升级规则

误解 3：是不是记录完就结束了？

不是。

记录只是第一步。

真正目标是：

  • 下次能直接复用
  • 多次出现后升级成默认规则
  • 最终让 AI 的默认行为越来越稳

11. 一句话记住这套边界

最简单的记法是：

干活是我主动干，定规则你来拍板；记录我来做，长期生效最好你确认。

如果再压缩一点，就是：

修 bug 我主动，抽经验我主动，升规则时你参与。

12. 最后的结论

Self-Improving Agent 最容易被误解成“让用户多记点东西”，但它真正的工程价值恰恰相反：

它是为了让 AI 主动承担复盘、沉淀、提炼规则 这部分工作。

在一个典型的 bug 修复场景中，正确分工应该是：

  • 你负责提任务、补业务判断、拍板长期规则
  • 我负责排查、修复、测试、记录、升级和后续复用

只有这样，这套机制才不会变成额外负担，而会真正变成：

  • 一次 bug 修复 → 一条可复用经验
  • 多次经验复用 → 一条长期规则
  • 多条长期规则积累 → 一套稳定工作流

这也是 Self-Improving Agent 最值得保留的地方：

它不是为了“留档”，而是为了让后续工作默认变得更聪明、更稳、更省力。

还有一个问题:

  • Self-Improving Agent 这套机制和 openclaw的三层记忆+qmd 冲突不? 下一篇介绍

#OpenClaw #AIAgent #SelfImprovingAgent #BugFix #WorkflowDesign #TechnicalWriting #KnowledgeManagement #AI自动化

Continue reading

继续阅读