自我改进代理系统
不是让模型更新权重，而是让模型周围的状态、Skill、验证和工作流持续复利的 Agent 系统。
简介
自我改进代理系统（self-improving agent system）指的是一种围绕大模型搭建的持续运行架构：模型每完成一次任务，不只是把结果交付给用户，还会把失败、验证过的事实、通用规则、评估样本和流程经验写回外部环境，使下一次执行继承更好的上下文和更锋利的 Skill。
本文素材特别强调：自我改进不等于自我学习。自我学习意味着代理根据经验更新自己的模型权重；当前公开生产环境中的 Fable 5 并不做这件事。自我改进的真实版本，是“系统环境在变好”：STATE.md 里已验证事实更多，Skill 里的边角案例更完整，eval 循环更能抓住失效模式，Routines 能在无人值守时持续跑检查，验证者子代理能独立裁决产出是否达标。
因此，自我改进代理系统的核心不是神秘的递归智能，而是工程纪律：执行者与验证者分离、状态文件持久化、教训蒸馏、预算控制、worktree 隔离、云端长任务执行、安全边界显式后备。它把“每次做完就忘”的聊天使用方式，改造成“每次执行都让系统资产变厚”的复利结构。
关键信息
- 类型：Agent 系统架构 / 工作流范式
- 核心目标：让每次执行沉淀为下一次的状态、规则、Skill 或 eval 样本
- 关键区别：模型权重不变，环境与流程变得更好
- 适用模型：Fable 5 可作为重型编排者，低成本模型可承担工人或验证任务
- 关键组件：状态文件、Skill、验证者子代理、/goal、Outcomes、动态工作流、Routines、worktrees、eval suite
- 相关主题：Loop Engineering、Claude Code、AI Agent 智能体、AI编程开发
核心特性
四层复利架构
素材将自我改进代理系统拆成四层：
| 层级 | 作用 | 典型组件 |
|---|---|---|
| Layer 1 · 原语 | 提供基础执行能力 | Fable 5、子代理、工具、worktrees |
| Layer 2 · 编排 | 把原语组织成可迭代工作流 | /goal、Outcomes、动态工作流、Routines |
| Layer 3 · 记忆 | 保存跨会话可继承的事实和流程 | STATE.md、Skill、Knowledge Bases、Lessons learned |
| Layer 4 · 自我改进 | 评分、蒸馏、写回 | 视觉验证、eval 循环、规则蒸馏、反模式沉淀 |
复利发生的路径是：执行层产生输出 → 自我改进层评分和蒸馏 → 记忆层保存规则和事实 → 下一轮执行读取更好的记忆和 Skill。模型本身依旧是无状态的，但系统不是。
记忆五阶段递进
有效记忆不是“把所有日志都堆起来”，而是沿五个阶段递进：
- Fail：记录失败，且有足够细节能让未来用得上。
- Investigate：先弄清失败为什么发生，而不是立即补丁式修复。
- Verify：把猜测变成经查核的事实。
- Distill：把个案事实上升为可复用规则。
- Consult：下一次任务开始时主动查阅规则，而不是重新推导。
这套递进区分了“有记忆”和“记忆会复利”。如果系统只记录失败但不调查、不验证、不蒸馏，状态文件会越来越厚，却不会越来越聪明。
状态文件是项目记忆
STATE.md 是自我改进代理系统中最朴素也最重要的持久化载体。它通常需要包含：
- Verified facts：已经验证过、以后不要再猜的事实。
- General rules：从多个案例中蒸馏出的通用规则。
- Open failures：尚未解决、下次应继续调查的失败。
- Lessons learned：事故、调试、迁移或评估之后沉淀的教训。
- Last session：上次运行状态、已完成事项、下一步。
两条操作规则决定状态文件是否有用：离开前先写，开场时先读。没有写回，下一次会话从零开始；没有读取，写过的记忆也不会进入行为。
Skill 是程序记忆
STATE.md 更偏项目记忆，Skill 更偏程序记忆。前者记录“这个项目里已经知道什么”，后者记录“这类事情以后应该怎么做”。自我改进代理系统的成熟标志，是每一条确认过的教训不只写进本项目日志，也能在适当时写回 Skill，成为跨项目可复用能力。
这意味着 Skill 不应是一次写完的静态提示词，而应包含真实失败模式、反模式、已验证修复、eval suite 和状态写回约定。两周有纪律的事故复盘和 Skill 更新，可能比一个全新项目里再强的模型临场推导更有价值。
独立验证闭合循环
自我改进代理系统必须把执行者与验证者分开。执行者负责生成代码、文档、迁移或分析；验证者只看产出和评分标准，不看执行者推理过程。这样能减少模型对自身答案的偏爱，也能防止循环停在“看起来差不多”。
对 UI、图表、设计还原等任务，验证者还应具备视觉能力，用截图、曲线图和目标描述做对照。这比纯文本自评更接近真实验收。
不同素材中的观点
-
2026-07-06-blocktempo-fable-5-self-improving-agent：自我改进是系统属性，不是模型属性。Fable 5 的长 context、子代理委派、视觉自检和数日续航只是原始能力；真正让系统复利的是 /goal 或 Outcomes 形成的循环、动态工作流的多代理编排、STATE.md 的持久记忆、Skill 的教训写回、eval 的持续评分和 Routines 的无人值守执行。文章还强调安全边界要作为架构后备处理，不能让分类器阻断变成静默失败。
-
2026-07-07-blocktempo-fable-loop-library-25-workflows：这篇素材把自我改进系统的抽象组件落成可运行的 25 个 Loop：每个循环用 状态文件 记录本轮做了什么、下轮排什么、哪些失败已确认；用停止点防止无限烧钱；用 Loop 工作流风险分级 决定自动化边界；用 难题升级队列 让便宜模型先跑，只有失败被记录后才升级 Fable。它补充了一个重要实践判断：系统复利不一定从复杂架构开始，最小起步可以只是“一个循环 + 一个状态文件”。
实用信息
最小可行自我改进系统
- 选一个可反复发生且能验收的任务，例如 CI triage、PR 审查、资料更新、UI 还原检查。
- 为任务写清楚目标和停止条件，避免“做好一点”这类不可判定目标。
- 建立 STATE.md，至少包含 verified facts、general rules、open failures、last session。
- 将执行者和验证者分开，让验证者只看产出物和评分标准。
- 每次失败后先调查，再验证，再把通用规则写入 STATE.md 或 Skill。
- 定期用 eval suite 检查 Skill 是否因为新规则退化。
- 设置预算、最大迭代次数和升级路径，防止循环无止境运行。
常见误区
- 把自我改进误解成模型会在生产环境修改权重。
- 只写日志不蒸馏规则，导致记忆膨胀但不复利。
- 让执行者给自己打分，出现自我偏好偏误。
- 没有状态文件，所有会话都从零开始。
- 从不把真实失败写进 Skill，Skill 永远停留在静态说明书阶段。
- 忽略预算控制和安全后备，让长任务变成烧钱或静默失败。