将经验写成程序与自我修改的发布流程
什么经验适合编译为程序？
- 判据: 经验描述的是稳定、重复且可验证的操作;
- 动因: 每次都让模型重新阅读文档和推理并不经济;
- 目标: 把一次探索变成可重复执行的程序;
- 定位: 关注的不是一般代码生成，而是 Agent 如何根据自己的轨迹修改未来版本的自己;
Agent 可以修改自身的哪些层次？
| 层次 | 可修改对象 |
|---|---|
| 操作层 | 把浏览器轨迹编译为参数化工作流；为变化的 API 生成适配器 |
| 控制层 | 工具路由、重试、熔断、上下文压缩策略 |
| 验证层 | 根据生产失败新增参数检查、状态验证器与回归测试 |
| 架构层 | 增加 Reviewer Agent，改变规划与执行之间的信息流 |
- 边界: 能力来自第五章的“创造工具、修改系统”；这里新增的是由经验触发、以验证闭环约束的自我修改方法;
自我修改为什么不等于进程覆盖自身？
- 隔离: 从当前稳定版本创建隔离更新分支，由 Coding Agent 生成最小补丁;
- 检查链: 静态检查 → 单元测试 → 安全扫描 → 失败轨迹重放 → 旧任务回归;
- 发布: 通过后生成可灰度部署的新版本;
- 效果: 把“自我修改”转化为可审计的软件发布流程;
Git worktree 与 Pull Request 扮演什么角色？
- Skill 的指导: 为任务创建独立 worktree，确认需求与 Spec，完成实现与测试，提交有意义的 commit，并在 Pull Request 中写清背景、方案、测试结果与剩余风险;
- Harness 的检查: 在 Agent 准备结束任务时检查是否仍在
main上直接提交、是否遗漏 worktree 或 Pull Request; - 否决: 一旦违反边界就否决这次操作，要求 Agent 返回修复;
- 分工: Harness 不负责替模型做这些判断，只负责在边界被越过时拦住;
什么是可证伪的变更契约？
- 不足: 仅有“补丁尽量小”还不足以支持可靠归因;
- 契约内容: 失败证据、推断根因、归属的 Harness 组件、修改提案、预期修复的行为、可能受损的既有行为，以及分别验证两者的用例;
- 作用: 让每次编辑在执行前声明影响预测，由下一轮结果验证;
三层可观测性如何支持归因？
| 层 | 内容 |
|---|---|
| 组件 | 可编辑组件都有文件级表示 |
| 经验 | 海量轨迹整理为可逐层下钻的证据 |
| 决策 | 每次编辑声明影响预测，由下一轮结果验证 |
- 收益: 分数上涨才能与某个具体机制建立联系，而不只是一次不可解释的试错;
提案生成器还需要哪些输入？
- 成功约束: 必须保留的成功行为，告诉 Agent 哪些性质不能在修复时被破坏;
- 历史尝试: 此前被拒绝的修改记录，避免换一种说法重复提交已经失败的方案;
- 有界方案空间: 失败证据、成功约束与历史尝试共同构成边界，比把全部源码和原始日志无差别塞给修改 Agent 更容易产生局部、可验证的改动;
工具创造是否遵循同一协议？
- 案例: Agent 要从一段由《指环王》中咕噜配音演员解说的 YouTube 360 VR 视频中，找出恐龙首次出现后紧接着提到的数字;
- 过程: 发现自己缺少字幕读取能力后，搜索并测试
youtube-transcript-api，将其封装为新的字幕工具，最终从字幕中得到答案100000000; - 准入门槛: 只有安全扫描、功能测试和后续任务复用都通过，新工具才进入能力库;