从更新产物到更新更新方法
持续进化的第二条正交轴是什么？
- 第一条轴: 经验最终写到哪种载体——知识、指令、程序还是参数;
- 第二条轴: 系统正在优化的究竟是某份产物的内容，还是产生、管理和验证这些产物的方法;
- 性质: 这不是一组新的更新载体，而是不同的搜索尺度; 知识、Prompt、Skill 和程序都可能出现在其中多个层级;
优化对象可以分成哪几种搜索尺度？
- 逐层扩大: 单条规则或记忆 → 结构化上下文 → 工作流 → Harness 代码 → 产生更新提案的优化器代码;
- 尺度含义: 每一层改变的是“搜索空间的大小”，而不是“改哪一类文件”;
- 优先级: 应优先采用可归因、可验证、可回滚的局部修改;
为什么修改产物内容应当是默认选择？
- 典型做法: 根据失败轨迹给系统提示增加一条局部规则，或给经验文档补充一个例外条件;
- 优点: 作用面小，容易归因和回滚;
- 对照: 越向外层，一次修改影响的行为面越大，验证成本越高;
反复重写整份 Prompt 会造成什么退化？
- 退化一: 为了追求简洁，旧版本中的少数重要细节可能在多轮改写后逐渐消失;
- 退化二: 相互制约的条件可能被合并成一句过度抽象的原则;
- 对策（Agentic Context Engineering, ACE）: 把上下文维护成带稳定标识符的条目集合，由生成、反思和整理模块提出增量更新，再用确定性逻辑合并与去重，而不是每轮重写一个越来越短的文本块;
- 意义: 它为“最小 diff、保留来源”的原则提供了具体研究实例;
“优化上下文”与“优化上下文管理方法”如何区分？
- 拆分（Meta Context Engineering, MCE）: 内外两个循环;
- 内层: 在给定管理方法下优化当前任务的上下文产物;
- 外层: 根据多轮执行和验证结果，修改搜索、选择、过滤、格式化这些上下文操作本身;
- 关键区分: 修改一条检索规则是在改内容管理机制；让系统比较多种检索与整理机制、保留迁移效果更好的版本，才是在学习“如何管理上下文”;
同样的思想如何扩展到工作流与整个 Harness？
| 工作 | 优化对象 |
|---|---|
| AFlow | 把由多个 LLM 调用组成的工作流表示为代码图，通过执行反馈搜索节点与控制流的组合 |
| Meta-Harness | 让 Coding Agent 读取待验证 Harness 版本的源码、分数和轨迹，搜索决定信息如何存储、检索和呈现的代码 |
- 新增之处: 代码不只是一次生成的产物，还可以连同评估历史一起成为持续搜索的对象;
外层搜索为什么很快遇到反馈成本问题？
- 探索策略的内容: 从哪个候选继续、何时另开分支、并行投入多少 Worker、什么时候停止;
- 特性: 它的好坏往往要经过很长的生成—评估链条才能显现;
- 成本: 若每个候选策略都必须重新调用 Agent 和评估器，优化探索策略本身可能比完成任务更昂贵;
- 出路: 需要一种不重跑历史就能比较探索策略的机制，见发现树回放;