上下文工程：从手写到自动进化 · 工作流设计：从手工到自动搜索 · 解读与音频稿件

本集对应模块 T6 的两节课：「上下文工程：从手写到自动进化」「工作流设计：从手工到自动搜索」。

来源：xueai.miyang.cn（小山学堂 · 洛小山《学 AI 产品，从入门到精通》）

本集要解决什么

一个正在发生的迁移：优化的对象从提示词内容，一层层往上搬到管理机制的代码本身。

随着 Agent 任务变长，上下文管理不再是可选项，它正在成为 Harness 优化的核心战场。把所有工具响应和模型生成简单追加到上下文里，会随着任务时长增加迅速失控——失控的方式很隐蔽，不是报错，是注意力被稀释。

能力地图

层级	优化对象	代表方法
Level 1	指令 Prompt	手写提示词
Level 2	结构化上下文	ACE
Level 3	工作流	AI Scientist / Autodata
Level 4	Harness 代码	Meta-Harness / ADAS
Level 5	优化器代码	MCE / AFlow

规律：模型越智能、越强大，我们能优化的目标就越复杂、方法也越通用。

---

上篇 · 上下文工程三级跳

ACE · Agentic Context Engineering（Zhang et al. 2025）

说人话：上下文是 AI 的工作记忆。ACE 的思路是别让记忆变成一锅粥，要维护一本条理清晰的工作手册。

组件	职责
Generator 生成器	执行任务、生成轨迹，参考剧本条目作为指引
Reflector 反思器	从成功和失败的轨迹中提炼洞察，萃取经验教训
Curator 策展器	用增量的、条目化的 entries 更新结构化上下文，定期精炼去重

关键设计（命门）：Curator 输出结构化的 (identifier, description) 条目，用确定性逻辑合并进剧本，从不重写整块 prompt blob。这避免了迭代重写时的两个经典问题：

• 上下文坍缩 — 越重写越短；
• 简洁偏差 — 越重写越泛，最后只剩下正确的废话。

提示1 · 增长 ≠ 演进

上下文是不断演进的剧本，不能任由 Prompt 不断增长。增长是往里加，演进是加的同时也在整理。用条目化、增量的方式更新，并用确定性逻辑合并，不要每次重写整块提示词。

MCE · Meta Context Engineering（Ye et al. 2026）

ACE 把手册整理好，MCE 追问更深的问题：整理手册的方法本身是不是也能优化？（按时间排还是按主题排？记大纲还是记细节？）

分离机制与内容，双层优化：一个 MCE Skill 定义上下文函数 c = F(x; ρ)

• ρ = 静态组件（prompts、知识库、代码库）
• F = 动态算子（搜索、选择、过滤、格式化）

双层优化（大白话）：

• 内层：用当前的记笔记方法，把笔记写到最好；
• 外层：比较不同的记笔记方法，选出最好的那套；
• 先优化内容，再优化方法，轮流来。

Skill 数据库：H = {(s_i, c_i, J_train_i, J_val_i)} 跟踪历史，进化有记忆，不会把试过的路再走一遍。

实现：一个 context function 被实例化为专用目录中的文件集合——静态文件 skill.md 存任务最重要的知识，动态文件存上下文数据和 rollout 记录。meta-level 与 base-level 优化都在标准编码环境中执行，使用 Read / Write / Edit / Bash / Glob / Grep / TodoWrite。

Meta-Harness（Lee et al. 2026）· 优化 Harness 的 Harness

被优化的不再是上下文内容，而是决定什么信息应该被存储、检索和呈现给模型的代码本身。相当于让 AI 重新装修整个车间。

实现细节	说明
Proposer	本身是一个编码 Agent，不是专门的优化器
输出	Pareto 前沿上的候选集合，不是一个「最优解」
历史访问	通过文件系统，coding agent 用 grep / cat 按需读取，避免全塞进 prompt
表示	每个 harness 是文件系统中的字典：源码、分数、轨迹、状态更新

代价：威力最大（优化空间最大），但最烧算力——每改一版都要完整试运行打分。不适合频繁迭代，更适合阶段性重构。

三种方法对比

	ACE	MCE	Meta-Harness
思路	从轨迹中学习	进化管理机制	优化整个系统代码
做法	规则化 Generator→Reflector→Curator 管线维护结构化 bullet points	不固定上下文格式，free-form skills 双层迭代	Proposer 是编码 Agent，输出 Pareto 前沿候选集
局限	更新规则仍手工设计	机制本身可变	最通用但计算最重

提示2 · 一旦设计变成可执行的搜索空间，自动化就能接手

AI 不是在发明某种人类看不懂的诡异结构，它是在人类原本就在用的那个设计空间里搜索，只是搜索得快得多、也彻底得多。

结论：上下文工程的未来是让系统自动学会什么时候存什么、怎么检索、怎么呈现。再聪明的手写 prompt 也只是过渡。

注意措辞——是过渡，不是没用。就像手写汇编被编译器取代，但理解汇编依然有价值。竞争力来源变成了：你能不能把任务表达成一个可被搜索和评估的形式。

---

下篇 · 工作流设计：从手工到自动搜索

手工设计的两个最强例子

	AI Scientist（Lu et al. 2026）	Autodata（Kulikov et al. 2026）
定位	完整科研自动化管线	数据科学家 Agent：合成难度恰到好处的数据
流程/角色	提出想法→写代码→跑实验→分析结果→写论文→同行评审	Challenger 出题 / Weak Solver / Strong Solver / Verifier 裁判
关键创新	每步由 LLM 驱动，端到端自动化；评审引入 LLM-as-judge	用难度差作为数据质量信号：只有「强者能解、弱者不能解」的题目才保留

手工设计能做到很高水平，但天花板明显——依赖设计者的经验和直觉，而你没法穷举。

ADAS · Automated Design of Agentic Systems（Hu et al. 2025）

让一个 Meta-Agent 在 Agent 设计空间中自动搜索最优方案（"meta-agent search"）。

1. Meta-Agent 先生成一个高层描述（架构、工具使用、推理策略）；
2. 将高层描述实现为可执行代码；
3. 通过 self-refine 检查新颖性，确保不是简单重复；
4. 在基准任务上评估，保留表现最好的设计。

关键创新：用代码作为 Agent 设计的搜索空间表示，使设计可以被自动生成、修改和评估。

AFlow（Zhang et al. 2025）· 用 MCTS 搜索工作流

把工作流表示为有向图：节点是 LLM 调用动作，边是代码中的逻辑操作（条件分支、循环、数据传递）。然后用蒙特卡洛树搜索在这个图空间中自动寻找最优工作流。

MCTS 优化流程：

1. 初始化起始工作流作为搜索树的根节点；
2. 用 soft mixture of score and uniform exploration 选择待扩展节点（平衡利用与探索）；
3. 让 LLM 生成修改后的工作流变体（添加/删除/修改节点和边）；
4. 在目标任务上执行并评估；
5. 有改进则加回搜索树作为新候选；
6. 重复直到 top-k 平均分稳定或达到计算预算。

一次搜索过程的真实数字

轮次	候选	得分	结果
起始	W₀: Plan → Execute	52	无反思、无验证、无并行
扩展 1	W₁: +Reflect / W₂: +Verify / W₃: +Decompose	61 / 58 / 55	W₁ 最高，选为父节点
扩展 2	W₄: Reflect×2 / W₅: Reflect+Verify	65 / 78	W₅ 大幅领先
收敛	W₃: 55 ✗ / W₆: 56 ✗ / W₅: 78 ✓	—	比手工设计高出约 50%

价值不在于找到某个具体工作流，而在于展示一种可重复的方法：你不需要知道最优工作流长什么样，只需要能生成候选、能打分、能组织搜索。

提示3 · 做不了自动搜索时，先补评估

自动化的三个前提：① 候选能被自动生成；② 分数能被自动打出；③ 搜索能被有效组织。缺任何一件都跑不起来。

评估是自动化的地基。 没有可靠的打分方式时，越往上搬越危险——搜索会在错误的方向上高效地收敛。先把尺子做对，再谈搜索。

三种工作流设计方式对比

方法	设计方式	搜索策略	核心优势
手工设计	人类专家迭代	无（凭经验）	可解释性强
ADAS	Meta-Agent + 代码	Self-refine	自动化设计
AFlow	图表示 + MCTS	蒙特卡洛树搜索	系统化搜索 + 稳定收敛

核心洞见

1. 搜索空间巨大 — 工作流的组合可能性远超人类手动探索能力，手工设计只能触及冰山一角；
2. 设计即搜索 — 把工作流设计当作搜索问题，用算法取代直觉；
3. 代码是通用语言 — Harness 本质上就是编排 prompt、工具调用、子 Agent、控制流、记忆和工作流逻辑的代码；
4. 从 ADAS 到 AFlow — 自动化程度不断提升，从让 LLM 设计进化到让算法系统化搜索。

三个容易忽略的观察

观察一 · 为什么重写整块 prompt 走不通。 每次让模型重新压缩整份上下文，它都会倾向于保留放之四海皆准的内容，丢掉看着琐碎但关键的具体经验。压缩十次后剩下的是一份政治正确的通用指南。简洁偏差不是模型的错，是「重写」这个动作的结构性后果。 条目化更新的好处在于单调性——一条经验写进去就不会被顺手删掉，而累积正是自我改进的前提。

观察二 · 内层与外层的节奏要错开。 内层优化跑得勤（成本只是重新组织内容），外层优化跑得稀（每换一套方法都要重新验证）。两个循环周期差着一个量级，别把它们放在同一频率上跑——否则要么内层被外层拖慢，要么外层还没验证充分就被换掉。

观察三 · 加环节要看是不是带来新信息源。 MCTS 搜索中「反思+验证」得 78 胜过「双重反思」得 65：两次反思面对的是同一套判断标准，容易原地打转；而验证引入了一个独立的判断标准。往流程里加环节时先问：它带来的是同一标准的重复执行，还是一个新的信息源？ 前者收益递减很快，后者才可能带来阶跃。

审查清单

1. 上下文是靠追加增长，还是条目化增量演进？
2. Curator 是不是用确定性逻辑合并，而非重写整块 prompt？
3. 有没有把「记什么」和「怎么记」分开？
4. 优化对象在梯子的哪一级？通用性与算力成本是否匹配当前迭代频率？
5. 自动化的三个前提（生成候选 / 打分 / 组织搜索）是否都具备？
6. 评估尺子可靠吗？没有可靠打分时，搜索会在错误方向上高效收敛。
7. Meta-Harness 类方法的每版完整试运行成本，是否在预算内？

约束说明

• 引用年份约束：ACE/ADAS/AFlow 为 2025 年工作，MCE/AI Scientist/Autodata/Meta-Harness 标注为 2026 年，均依素材原文标注，引用时请以原论文为准。
• 搜索数字约束：52 / 61 / 58 / 55 / 65 / 78 与「高出约 50%」是素材中演示的示意性搜索过程数值，用于说明 MCTS 的收敛行为，不是可复现的基准结果。不同任务下数值差异极大。
• 算力成本约束：Meta-Harness「每改一版都要完整试运行打分」，这决定了它不适合高频迭代。选型时先算清单次评估成本再决定层级。
• 评估前提约束：本集所有自动搜索方法都建立在「有可靠打分」这一前提上。尺子不对，搜索越高效越危险。
• 过渡性约束：「手写 prompt 只是过渡」指的是竞争力来源的迁移，不表示手写能力无价值。
• 取材约束：本集只使用本集素材内资料，不跨集引用，不虚构源文档未出现的数据、案例与引文。

可带走的设计原则

1. 别让上下文靠追加增长。 条目化增量更新 + 确定性合并，不重写整块 prompt。
2. 把内容和机制分开。 凡是手工维护方法的地方，都问一句：这个方法本身能不能也被优化。
3. 优化对象可以一层层往上搬。 每上一通用性变强、算力变重，按评估成本和迭代频率选层级。
4. 一旦设计变成可执行的搜索空间，自动化就能接手。 三前提是生成候选、打分、组织搜索。
5. 先做对尺子，再谈搜索。 没有可靠评估时，自动化的效率会放大错误方向。

---

音频与稿件

• 音频：si02-播客.mp3
• 字幕：si02-播客.srt
• 口播稿：script.txt
• 集页：https://xueai-podcast.pages.dev/t/si02/

本内容改编自小山学堂《学 AI 产品，从入门到精通》，为二次演绎配音版。

来源：xueai.miyang.cn（小山学堂 · 洛小山）