状态文件
在 Agent 循环中跨轮次保存历史、已验证事实、下轮计划和失败证据的持久化文件，是让 Loop 每一轮比上一轮更聪明的最小记忆机制。
简介
状态文件是 Loop Engineering 和自我改进代理系统 中最朴素但最关键的组件。它通常是一个普通 Markdown 或文本文件，例如 STATE.md、shadow-prompt-STATE.md、weekly-content-STATE.md。它不依赖模型内部记忆，而是把每一轮 Agent 做了什么、验证结果如何、下一轮要做什么、哪些失败已经确认下来，写到一个下一轮必读的外部文件里。
这篇素材强调，Loop 永远包含五个部分：排程、每轮只改一件事、固定检查、状态文件和停止点。很多人会写排程和目标，却跳过状态文件，结果每一轮 Agent 都像第一次醒来一样重新推导，重复已经做过的事，甚至重新踩同一个坑。状态文件的作用就是阻止这种“无状态循环”：模型每轮开始先读自己的历史记录，知道哪些假设已经被否定、哪些数据口径已经固定、哪些下轮行动已经排定。
状态文件与普通日志的区别在于，它不是为了事后审计而堆全部过程，而是为了下一次执行能更好地行动。它应当压缩为可用事实、决策、待办和失败证据，而不是完整聊天记录。一个好的状态文件越跑越锋利；一个坏的状态文件只会越跑越厚。
关键信息
- 类型：Agent 记忆机制 / 工作流持久化文件
- 常见形式：
STATE.md、*-STATE.md、执行分类账、状态表、运行摘要 - 核心作用：保存跨轮次记忆，让 Agent 不重复做已完成或已否定的工作
- 适用场景：/loop 定时任务、/goal 长任务、Prompt 影子测试、KPI 监控、内容待办库、SOP 偏移检测、CI 修复
- 相关概念：Loop Engineering、自我改进代理系统、Goal 提示语、Shadow Prompt Loop、Fable 5
核心特性
让每轮循环可比较
状态文件让本周的结果能和上周比较。本素材要求每个 Loop “每次都做同一项检查”，但如果没有状态文件，就没有地方记录基线、上轮分数、当前分数和差异。比如模型占有率品牌监看每周问同样问题，状态文件需要记录品牌在答案中的排名、被引用语句、竞争对手变化和本轮解释。只有这样，Loop 才是在看趋势，而不是每周重新猜一次。
只记录能改变下一轮行为的信息
状态文件不是全文日志。它应该记录已验证事实、上一轮动作、当前指标、开放问题、失败证据、下一轮候选动作和停止条件进度。无关推理、临时想法、重复输出可以删掉。状态文件的目标是让下一轮 Agent 快速进入正确上下文，而不是把上一轮的全部 token 再烧一遍。
支撑失败升级和成本路由
本文的“难题升级队列”要求便宜模型先处理，只有在留下被记录的失败之后，Fable 5 才出手。这意味着状态文件也是成本控制证据：如果小模型没有写清楚自己失败在哪里，任务就不应升级；如果 Fable 接手，它应该先读失败记录，避免重复低成本模型已经尝试过的路径。
与停止点绑定
状态文件应持续记录停止条件进度：已运行几轮、已花费多少预算、已收集多少有效案例、当前是否达到“完成”或“卡住”的定义。没有这个字段，Loop 很容易在“再跑一轮可能更好”的诱惑下无限运行。状态文件让停止不再靠感觉，而是靠可读计数和证据。
不同素材中的观点
- 2026-07-07-blocktempo-fable-loop-library-25-workflows：这篇素材把状态文件列为每个 Loop 必备五件套之一，并直说“状态檔是幾乎所有人都會跳過的部分，而它正是讓每一輪都比上一輪更聰明的關鍵”。文章强调模型每轮前读自己的历史记录，因此不会重做已经完成的工作；25 个工作流中的内容纲要库、KPI 异常监看、SOP 偏移捕手、影子提示词循环和累犯摘要都依赖状态文件保存跨轮次证据。
实用信息
推荐结构
# STATE.md
## Current objective
本循环当前目标与边界。
## Baseline / metrics
- 基线：...
- 本轮指标：...
- 与上轮差异：...
## Last run
- 时间：...
- 做了什么：...
- 检查结果：...
- 是否保留本轮修改：是/否，原因：...
## Verified facts
- 已确认事实 1
- 已确认事实 2
## Failed attempts
| 尝试 | 预期 | 实际 | 失败原因 | 是否可复用为规则 |
|------|------|------|----------|------------------|
## Next queue
1. 下一轮优先处理的一件事
2. 备选动作
## Stop conditions
- 最大轮数：x / y
- 最大预算：x / y
- 完成条件进度：...
- 卡住条件：...使用纪律
- 每轮开始先读状态文件，不允许直接从用户目标重新推导。
- 每轮只更新与下一轮有关的信息，避免把状态文件写成聊天转录。
- 失败要写清楚证据和原因，而不是只写“失败了”。
- 达到停止条件时必须停止并输出报告，不因“可能还能更好”继续烧钱。
- 状态文件中的通用教训若跨项目可复用，应进一步蒸馏进 Skill 或团队规范。