返回文档库
harness_evolve/notes/ref08_mce-meta-context-engineering.md

Meta Context Engineering via Agentic Skill Evolution

一句话总结：把"上下文工程（Context Engineering）"从人手写死的固定流水线（如 ACE 的 generation-reflection-curation）升级成一个双层优化问题——外层让一个 meta-agent 通过"agentic crossover"（在历史技能/执行/评测上做审议式搜索）不断进化一套自然语言"CE 技能库（skill）"，内层让一个 base-agent 执行当前技能、把上下文当文件与代码自由构造；技能与上下文协同进化（co-evolve），从而绕开"简洁 vs 冗长"两种归纳偏置，在五个领域上一致超过 SOTA 上下文工程方法。

TL;DR 速览

tags: #上下文工程 #context-engineering #agentic-skill-evolution #自我改进 #bi-level-optimization #skill-library #co-evolution

related: [[ref09_meta-harness]]（Meta-Harness 把 MCE 当基线；同为"自动优化 harness/CE"的姊妹工作）· [[ref07_ace-agentic-context-engineering]]（ACE，本文最主要的被超越基线，也是 MCE 能"重建"的一个特例）· [[ref17_self-harness]]（自我改进 harness 的受控切片）· [[ref19_gepa]]（GEPA，简洁偏置的代表）· [[ref20_alphaevolve]]（AlphaEvolve，程序级 LLM 进化）· [[ref13_adas-automated-design-agentic-systems]]（ADAS，meta-agent 编程新 agent）

摘要

大语言模型的运行效能高度依赖其推理时上下文，这确立了上下文工程（CE）作为一门优化这些输入的正式学科。现有 CE 方法依赖人手工设计的 harness——如僵化的"生成-反思"工作流和预定义的上下文 schema——它们强加结构性偏置，把上下文优化限制在一个狭窄、被直觉束缚的设计空间里。为此我们提出 Meta Context Engineering（MCE），一个通过协同进化 CE 技能与上下文产物来超越静态 CE 启发式的双层框架。

在 MCE 的迭代中，一个 meta-level agent 通过 agentic crossover（在技能、其执行、其评测的历史上做审议式搜索）来精炼工程技能；一个 base-level agent 执行这些技能、从训练 rollouts 学习、把上下文优化为灵活的文件与代码。作者在五个不同领域（金融、化学、医学、法律、AI 安全）、offline 与 online 两种设定下评估 MCE，取得相对 SOTA agentic CE 方法 5.6–53.8% 的相对提升（均值 16.9%），同时在上下文的适应性、可迁移性、以及使用与训练两方面的效率上都更优。

1 介绍：为什么"手工 harness"限制了上下文工程

论文的动机链条很清晰。首先，LLM 基础设施正从"单体聊天接口"演进为"复合 agentic 系统"，于是推理时上下文的编排（curation & orchestration）既是关键瓶颈、也是最有力的增强杠杆——这催生了 Context Engineering（CE） 这门学科。相比调模型参数，调上下文有四个方法论优势：

优势 含义
可解释性 经验以自然语言编码，而非不透明的权重
高效性 无需昂贵的参数更新即可快速部署
模块性 已建立的上下文可组合、可迁移
鲁棒性 把"能力获取"与"模型权重"解耦，天然免疫灾难性遗忘

[!TIP] 什么是 Context Engineering（上下文工程）？ CE 是一门"在不改模型权重的前提下，通过构造模型每一步看到的上下文来最大化下游效用"的学科。它的操作对象包括：系统 prompt、检索到的证据、示范样例、累积的记忆/经验、工具状态、动态输入等。直觉上，如果说微调是"改大脑"，CE 就是"改喂给大脑的材料 + 递材料的方式"。CE 之所以近一年爆火，是因为它比微调便宜、可读、可迁移、抗遗忘——但代价是"怎么构造上下文"这件事至今主要靠人手工设计固定流程（这正是本文要攻击的点）。本文进一步把 CE 抽象成一个上下文函数 \(c(x)\)（见 §3.1）：把任意 query 映射到它的上下文。

核心痛点：手工 harness 的两层归纳偏置。 作者把现有 CE 方法的局限拆成两个层次：

[!IMPORTANT] 简洁偏置 vs 冗长偏置——这是全文的靶子。 - Prompt-rewriting（如 GEPA）→ 偏简洁：反复精炼简洁的高层规则，在"需要详细策略和深度领域知识"的任务上失败。 - Additive-curation（如 ACE、Dynamic Cheatsheet）→ 偏冗长：通过"生成-反思-整理"流水线逐条累加上下文，导致三个问题：(1) 噪声更新（局部更新缺乏全局视野）；(2) 过量开销（instance-level 逐样本优化）；(3) 上下文膨胀（只加不合，没有整体综合）。

结论：任何单一 agentic harness 都不是普适最优的。既然"该用简洁还是冗长""该用列表还是图"本身是任务相关的决策，就不该把它写死——而应该让它可学。这就是 MCE 双层设计的动机。

解法：MCE = 用可学的"技能"替换固定的"脚手架"。 MCE 把 CE 形式化为双层优化，解耦"工程策略（怎么表示和优化上下文）"与"工程产物（学到了什么上下文）"。关键论断是：像 ACE 的"生成-反思-整理"这样的 SOTA 流水线，只是"所有可能 CE 技能这一广袤流形上的单个点"；而 MCE 赋予 AI 完整的自主权和能力（写任意代码、调用其他 LLM、操作文件结构），因此能重建这类流水线、发现新的 CE 架构、并动态调整 CE 策略。

Figure 1: MCE 的卡通式概念总览

Figure 1 逐元素解读（招牌卡通图，一眼抓住"双层协同进化"的直觉）： - 右上「Meta Context Engineering」标题下的两个机器人：一个说"用进化出的技能，我能学到完美的上下文！"，另一个说"我能通过学习和进化发现最好的 CE 技能！"——点题：技能与上下文两条线同时进化。 - 中部「The Meta-Agent at Work」：meta-agent 面对一个 Skill Database（Skill A: 65% / Skill B: 72% / Skill C: 68%），在想三个问题——"Skill A 里什么起了作用？""为什么 Skill B 成功？""怎么组合各自最好的部分？"。这正是 agentic crossover 的拟人化：不是机械合并，而是审议式地挑好零件重组。 - 「Agentic Crossover: Combining the Best Ideas」→ A better skill emerges：一个更好的技能诞生，带来 +10% Improvement。 - 底部「CE workspace」：base-agent 执行技能、优化上下文——工作区里是一堆文件：context_1.md / context_2.md / context_3.md / retrieval.py / management.py，配合 Coding Toolkits。这具象化了"上下文 = 文件 + 代码"的 base-level 设计。 - 左下角点出病根："当前 CE 方法从根本上被人手工设计的 harness 所约束。" - 总标语："Success through co-evolution!（协同进化带来成功）"

论文用一句"Magic Formula"把方法浓缩为四步：① meta-agent 通过 agentic crossover 进化 CE 技能；② base-agent 执行技能构造上下文产物；③ 系统从执行历史与环境反馈中学习；④ 技能与上下文协同进化。

2 相关工作：三条线索的交叉

MCE 坐落在三条线索的交叉点：agentic 上下文工程、LLM 驱动的进化计算、以及（隐含的）meta-learning / 解耦范式。下面把关键前作讲透。

2.1 Agentic Context Engineering（本文的主战场与主基线）

[!TIP] ACE（Agentic Context Engineering）[Zhang et al., 2026] 本文最主要的被超越基线。ACE 用一组模块化 agent——生成器（generator）、反思器（reflector）、整理器（curator）——迭代地做 on-policy rollout、文字反思、上下文更新，把上下文维护成一份逐条列表（itemized playbook）。它能增量累加洞见（additive curation），是"additive-curation 偏冗长"这一派的代表。MCE 的核心论证之一就是：ACE 只是 MCE 技能空间里的一个特例——MCE 的 base-agent 完全可以"重建"出 ACE 的生成-反思-整理流水线，但也可以不这么做。见 [[ref07_ace-agentic-context-engineering]]。

[!TIP] GEPA [Agrawal et al., 2025] "反思式 prompt 进化"：用对采样轨迹的反思来驱动完整的 LLM 重写，偏好抽象的高层规则而非详细领域知识——即简洁偏置（brevity bias），产物通常只有 1–2K token。它证明了"反思式 prompt 优化能超过 RL"，是本文对照的另一极。见 [[ref19_gepa]]。

[!TIP] Dynamic Cheatsheet (DC) [Suzgun et al., 2025] "测试时学习 + 自适应记忆"：在推理时把有用的经验累积进一份"小抄（cheatsheet）"。本文用它的累积模式（DC-CU）作为 online 基线。它同属 additive-curation 一派。

[!TIP] MIPROv2 [Opsahl-Ong et al., 2024] / Reflexion [Shinn et al., 2023] - MIPROv2：DSPy 里的多阶段 prompt/示范联合优化器（本文用 auto="heavy"）。 - Reflexion：把"口头反馈（verbal feedback）"存起来供后续尝试用的"言语强化学习"——CE/自我改进谱系的开山工作之一。

两个促成 MCE 的技术趋势（作者明确点出）： 1. Agent 架构在去脚手架化：从僵化的多 agent scaffold 转向"统一、自循环、自派生、最大自主权 + 最小但通用工具"的框架（Claude Agent SDK、LangChain DeepAgents、Manus 等），领域特异性被封装进agent skills（可动态发现和加载的指令/脚本/资源文件夹）。→ 启发 meta-level 设计：CE 是一个无脚手架约束的全 agentic 过程，任务特异性通过学到的技能注入。 2. Coding toolkits + 文件系统访问已成为通用/垂直 agent 的核心 harness——因为 Turing-complete 语言提供最大设计灵活性 + 天然可验证性。→ 启发 base-level 设计：上下文产物 = 文件与代码，是不受 schema 约束的通用、agent-native 表示。

2.2 LLM 驱动的进化计算（本文最相似的一支）

[!TIP] LLM-as-genetic-operator 谱系 传统进化计算（EC）依赖人手工设计的算子（变异/交叉），难以捕捉复杂解结构。近期研究发现 LLM 可作为智能遗传算子，用语义知识生成有意义的变异，无需显式规则。已有工作按"进化的抽象层级"可分为三档—— - 解级（solution level）：进化 prompt [Guo et al., 2024, EvoPrompt]、文本解 [Lee et al., 2025]、数值参数。 - 函数级（function level）：进化启发式 [FunSearch, EoH]、奖励函数 [Eureka]。 - 程序级（program level）：进化搜索算法 [AlphaEvolve, ShinkaEvolve]、神经架构、agent 工作流 [AFlow]。见 [[ref20_alphaevolve]]。

MCE 的关键创新：引入"agent skill"作为一个全新的、集成的进化抽象层级。 作者论证 skill 这个抽象为 meta-level 优化提供三大独特优势：

优势 解释
无缝协同进化不同解层级 skill 把"指令 + 资源 + 脚本"封装进统一表示，从而同时进化"自然语言方法论 + 可执行代码 + 上下文模板"，克服了以往协同进化框架的碎片化
模块化的 harness 接口 skill 把"优化目标"与"核心 agent 架构"解耦，提升稳定性（改 skill 不动 agent 本体）
更 agentic 的遗传算子 agent 能灵活检视并选择性重组祖先技能目录里的组件，实现更细粒度、上下文感知的进化更新

2.3 与 Meta-Harness / ADAS 的关系（放进本项目坐标系）

[!TIP] Meta-Harness [ref09] / ADAS [Hu et al., 2024] - Meta-Harness：用一个强编程 Agent（Claude Code + Opus）通过文件系统读全部历史候选的源码/分数/轨迹，直接搜索并改写整个 harness 代码。见 [[ref09_meta-harness]]。 - ADAS：用 meta-agent 从历史发现里"编程出"新 agent（靠 archive）。见 [[ref13_adas-automated-design-agentic-systems]]。

MCE 的差异定位：三者都属"自动优化 agent 支架"，但 MCE 选择在"skill"这个有语义的中间抽象层上进化（而非裸 harness 代码），并把它专门用于 context engineering。这让 MCE 比 Meta-Harness 更结构化、更可解释（skill 是人类可读的方法论），代价是"skill 抽象"可能不如"任意代码"表达力强。反过来看，Meta-Harness 论文把 MCE 直接列为文本分类的一个基线并超过它——两篇是互为镜像的姊妹工作（详见文末对比表）。

3 方法：一个协同进化"技能 + 上下文"的双层框架

MCE 把 CE 形式化为双层优化：meta-level 精炼技能（§3.2）、base-level 执行技能优化上下文（§3.3），由一个极简的 (1+1)-ES 编排（§3.4）。方法总览见 Figure 2。

Figure 2: MCE 方法论总览

Figure 2 逐区块解读（这张图是全文方法的心脏，四大功能区）：

3.1 问题形式化：上下文函数与双层目标

定义一个上下文函数 \(c\)，把每个 query \(x \in \mathcal{X}\) 映射到它的上下文，由一个二元组 \((\rho, F)\) 指定：

\[ c(x) = (F_k \circ \cdots \circ F_1)(x;\ \rho) \tag{1} \]

其中 \(\rho = \{\rho_1, \dots, \rho_m\}\) 是静态组件（系统 prompt、知识库、代码库），\(F = \{F_1, \dots, F_k\}\) 是动态算子（检索、选择、过滤、格式化、组装），它们以 query \(x\) 为条件变换并拼装这些组件。

给定 agent \(f_\theta\) 产出 \(\hat y = f_\theta(x, c(x))\)，CE 的目标是找最优上下文函数：

\[ c^{*} = \arg\max_{c \in \mathcal{C}}\ J(c) \tag{2} \]

\(J(c)\) 是任务专用目标（监督设定下 \(J(c) = -\sum_i \ell(f_\theta(x_i, c(x_i)), y_i)\) 即预测准确率；RL 设定下 \(J(c) = \mathbb{E}_x[R(f_\theta(x, c(x)))]\) 即期望奖励）。

MCE 的关键一步：不像先前方法"用预定义组件/算子实例化 \(c\)、再用固定流程直接优化 \(c\)"，MCE 引入一个技能 \(s \in \mathcal{S}\) 作为"如何表示和从数据中学习上下文函数"的可执行规格；给定技能 \(s\)，base-agent 执行它产出上下文函数 \(c_s = (\rho_s, F_s)\)。于是 MCE 求解双层问题：

\[ s^{*} = \arg\max_{s \in \mathcal{S}}\ J_{\text{val}}(c^{*}_s) \quad \text{s.t.} \quad c^{*}_s = \arg\max_{c_s}\ J_{\text{train}}(c_s;\ s) \tag{3} \]
符号 含义
\(x \in \mathcal{X}\) query（任务实例）
\(c(x) = (\rho, F)\) 上下文函数：静态组件 \(\rho\) + 动态算子 \(F\)，把 query 映射到上下文
\(f_\theta\) 固定（冻结）的生成模型（如 DeepSeek-V3.1），搜索中不改权重
\(J(c)\) 任务目标（准确率 / 期望奖励）
\(s \in \mathcal{S}\) 技能：定义"上下文函数该怎么表示和学习"的可执行规格（= 一个 skill 文件夹）
\(c_s = (\rho_s, F_s)\) base-agent 执行技能 \(s\) 后产出的上下文函数
内层 \(c^{*}_s\) 给定技能 \(s\)，在训练集上找最优上下文函数（base-agent 干的活）
外层 \(s^{*}\) 找能在验证集上产出最优上下文的技能（meta-agent 干的活）

[!TIP] 把双层目标 (3) 讲透 + 类比 + 举例 核心思想是"解耦 what 与 how"：MCE 把"学到什么上下文（\(c_s\)）"与"怎么表示和学它（\(s\)）"分开优化。作者给了一个极精准的类比——这就像 ML 里把"学到的参数"与"模型架构 + 训练算法"分开：内层 \(c_s\) 相当于"参数"，外层 \(s\) 相当于"架构 + 训练算法"。区别在于 MCE 站在更高的抽象层——这里的"ML 模型（即 LLM）"本身已经训练好并冻结了，MCE 优化的是它外面那层"学上下文的算法"。正是这种解耦催生了 meta-learning、AutoML、NAS、超参优化等领域；MCE 把它抬到 CE 层。

式 (1) 的谱系举例（\((\rho, F)\) 能表达从简到繁的一切 CE）： - 静态 prompt：\(c(x) = \rho_0\)（恒等算子，\(F\) 什么都不做）——最简单的 CE。 - 检索增强系统：\(c(x) = F_{\text{retrieve}}(x; \rho)\)——在固定资源 \(\rho\) 上按 query 检索。 - Agentic 系统：可插入 pre/post-model hooks、链接多个算子，在推理时动态生成/修改/丢弃组件。

双层的一个具体例子（FiNER 财务标签分类）：内层——给定技能"Error-Driven Generalization（错误驱动泛化）"，base-agent 读训练 rollout 里的错误预测，把上下文构造成 reasoning-chains.md + semantic-principles.md + tag-reference.md 三个文件 + 一个检索脚本，使训练准确率最高；外层——meta-agent 比较"这个技能 vs 上一版技能"在验证集上产出的上下文谁更好，据此进化出更强的技能。式 (3) 就是在问：什么样的"学上下文的方法论"，能让固定的 DeepSeek-V3.1 在这批财务标签题上的验证 F1 最高？

3.2 Meta-level：Agentic Skill Evolution（技能进化）

meta-agent 维护技能库 \(H_{k-1} = \{(s_i, c_i, J^{\text{train}}_i, J^{\text{val}}_i)\}_{i=1}^{k-1}\)——一个总结了"历史技能、它们产出的上下文函数、以及评测指标"的文件夹。在第 \(k\) 轮，meta-agent 通过 agentic crossover 生成新技能：

\[ s_k = \text{CROSSOVER}(\tau,\ H_{k-1}) \tag{4} \]

其中 \(\tau\) 是任务规格（任务描述、数据格式、评测准则）。

[!IMPORTANT] 什么是 Agentic Crossover？—— MCE 最核心的算子，务必讲透。 传统 LLM 驱动的进化算子用固定重组规则（例如"把两个程序合并成一个更好的"）。Agentic crossover 则是一个灵活、审议式（deliberative）的过程：这个 Agent 1. 推理任务规格 \(\tau\)； 2. 任意检视工作区文件夹（历史技能目录、它们的执行、评测）； 3. 识别成功与失败模式（"Skill A 的哪部分起了作用？为什么 Skill B 成功？"）； 4. 合成一个改进的新技能（"怎么组合各自最好的部分？"）。

举例（结合论文附录 B 的真实 meta-agent 系统 prompt）：meta-agent 被要求先做过拟合检查（"训练准确率是否显著高于验证？若是，技能可能在死记训练样例而非学可泛化模式"）和欠拟合检查（"两者都低？技能可能没抽出足够有用的模式"），再执行 crossover——把成功元素组合、针对失败模式改进、并鼓励创新。它只写 {iter_name}/.claude/skills/learning-context/SKILL.md，其余全是只读参考。这就是为什么 crossover 不是"盲目变异"而是"带诊断的审议"——它和 Meta-Harness 提议者"对失败做因果推理"的精神一致，只是把产物约束在了 skill 层。

一个技能 \(s\) 长什么样？（论文说它是 base-agent 工作区里的一个文件夹，实践中可能包含但不限于）：

技能组成 例子
(1) 方法论（自然语言） 核心哲学、带错误分析的多阶段流程、上下文剪枝策略
(2) 可执行脚本 Python 代码做错误模式提取、LLM 驱动的上下文生成、embedding 相似度分析
(3) 结构化上下文模板 决策框架、消歧规则、gap-driven 精炼
(4) 验证协议 评估上下文质量、度量泛化的函数
(5) 动态上下文算子 基于 query 特征选择性过滤/组装上下文的检索函数（关键词抽取、embedding 匹配、易错样例的规则检测）

[!TIP] 什么是"Agent Skill"（本文进化的对象）？ Agent Skill 是 Anthropic 提出的抽象 [Anthropic, 2025]：一个有组织的文件夹，装着"指令 + 脚本 + 资源"，agent 能动态发现并加载（progressive disclosure：只在相关时才把细节读进上下文）。它本是给人手工写的（如本项目的 pdf-paper-reader skill 就是一个 Agent Skill）。MCE 是最早"动态进化 skill"的工作之一——把"手工技能工程"和"自主自我改进"之间搭了一座桥。选 skill 作进化载体的妙处：它天然把"领域方法论 + 可运行代码 + 上下文模板"统一在一个可读、可版本化、可选择性重组的对象里。

进化出的技能揭示三个技术优势（作者对学到的 skill 做定性分析）： 1. 动态调节自主度、表达力、粒度：学到的技能按需规定僵化工作流或委派完全自主，实现整体批量综合或针对性的逐实例更新。 2. 按任务复杂度与模型能力裁剪上下文冗长度：简单任务/弱模型→简洁规则；否则→详细解释。 3. 监控训练/验证信号、检测过拟合：把技能进化导向更好的泛化。

展开：一个真实进化出的技能（FiNER 最佳技能，节选自附录 C） 论文附录给出了 FiNER 上的**最佳学到技能**，标题是 **"Error-Driven Generalization for XBRL Tag Classification"**（面向 XBRL 标签分类的错误驱动泛化）。它提供一个 **8 阶段**系统化上下文精炼流程，把上下文组织成三个文件：`reasoning-chains.md`、`semantic-principles.md`、`tag-reference.md`，并**编排 3 次 LLM 调用**把预测错误转化为可泛化的推理原则（① LLM 做错误分析 → ② LLM 泛化具体规则 → ③ LLM 生成推理链）。其核心哲学（原文）： > The key innovation is focusing on **why** errors occur at a semantic level, not memorizing specific examples.（关键创新是聚焦"错误为何在语义层发生"，而非死记具体样例。） 它的 Phase 3 用一个极清晰的 **BAD vs GOOD** 对比示范"如何从具体样例抽象出可泛化原则"： 
BAD（太具体、依赖样例）：
  "Tranche A loan facility of up to $16.0 million" -> DebtInstrumentFaceAmount

GOOD（可泛化原则）：
  If the facility is a TRANCHE or TERM LOAN (not revolving), it represents
  a specific debt instrument principal, NOT a flexible borrowing capacity.
  Key indicators: "Tranche A/B", "term loan", "loan facility" (vs "credit facility")
这个技能是"**上下文表示（三个语义分层文件）+ 上下文优化算子（3-call 错误泛化流水线）+ 剪枝策略（去掉过拟合的具体样例）**"的统一体——正好印证了"skill 是集成抽象"的论点。而且它是**进化出来的**：Core Philosophy 里写着"上一轮捕获了 29 个具体模式，但……"，说明它建立在前代技能的诊断之上。

3.3 Base-level：Fully Agentic Context Optimization（上下文优化）

给定 meta-level 的技能 \(s_k\)，base-agent 执行它产出上下文函数。它的工作区含：(1) 技能文件夹 \(s_k\)；(2) 上一轮最佳上下文函数 \(c^*_{k-1}\)（warm-start，不从零开始）；(3) 用 \(c^*_{k-1}\) 在 \(D_{\text{train}}\) 上评估得到的训练 rollouts \(R_k = \{(x_i, \hat y_i, \text{eval}_i)\}\)；(4) 可选的工具函数（调用其他 AI 模型）。目标是从 rollout 反馈中学习、更新上下文函数：

\[ c_k = \text{ENGINEER}(\tau,\ s_k;\ c^*_{k-1},\ R_k) \tag{5} \]

上下文函数被实例化为指定目录里的一组文件（静态组件 \(\rho\)：知识库/决策规则/样例；动态算子 \(F\)：检索/过滤/组装逻辑）。这种"代码 + 文件"的表示不施加任何结构约束，允许任意计算过程来生成和操作上下文——与"预定义僵化上下文表示和优化流程"的先前方法形成对比。

[!TIP] 为什么必须是"全 agentic + 文件/代码"，而不是填 schema？（讲透 + 对比） 先前方法（ACE 等）预定义 context schema（如"逐条列表"），优化时只能往这个 schema 里增删条目——这就是结构刚性和上下文膨胀的根源。MCE 的 base-agent 拿的是一套通用工具（Read/Write/Edit/Bash/Glob/Grep/TodoWrite），可以：写一个知识库 .md、写一个 retrieve_context.py 做关键词/embedding 检索、写过滤逻辑、甚至调别的 LLM 做批量反思——上下文表示和优化过程都由 agent 自己临场决定。 - 全局视野 vs 局部更新：base-agent 一次读一大批 rollout、维持对累积上下文的全局视野，能重构/精炼已有知识，而非像 ACE 那样盲目 append。这是 MCE 上下文更紧凑、非冗余的原因（见 §4.2 Obs.6）。 - 批量 vs 逐样本：ACE 是 instance-by-instance 优化，MCE 是 batch-level——这也是它训练快 13.6×的原因（§4.2 Obs.8）。

3.4 算法编排：一个 history-informed 的 (1+1)-ES

[!NOTE] Algorithm 1｜Meta Context Engineering（伪代码复述） 输入: 任务规格 τ, 数据 D = D_train ∪ D_val, 迭代数 K 初始化: 技能库 H_0 ← ∅, 最佳上下文 c*_0 ← ∅ for k = 1..K: # —— Meta-level: 进化技能 —— s_k ← CROSSOVER(τ, H_{k-1}) # 可参考全部历史 # —— Base-level: 执行技能产出上下文 —— R_k ← ROLLOUT(c*_{k-1}; D_train) # 用上一轮最佳上下文跑训练集，收集 rollout c_k ← ENGINEER(τ, s_k; c*_{k-1}, R_k) # base-agent warm-start 地更新上下文 # —— 评估并更新数据库 —— J^train_k ← J(c_k; D_train); J^val_k ← J(c_k; D_val) H_k ← H_{k-1} ∪ {(s_k, c_k, J^train_k, J^val_k)} c*_k ← argmax_{c ∈ {c*_{k-1}, c_k}} J^val(c) # (1+1)-ES: 留下更好的 return 最佳上下文函数 c*_K 及其对应技能 三阶段/轮：① skill evolution（meta-agent 分析 τ 和历史 \(H_{k-1}\) 生成 \(s_k\)）；② context optimization（跑训练 rollout，base-agent 执行 \(s_k\) 产出 \(c_k\)）；③ evaluation（在验证集评 \(c_k\)，更新技能库和 best-so-far）。数据大时 base-agent 可选批处理。整体是一个 history-informed (1+1)-ES：每轮生成一个后代 \(c_k\) 与当前最佳比较，留优。作者说选这个策略是为了简单，更高级的搜索算法可能进一步提升。

实现细节： - 两层都是全 agentic 优化：各 agent 通过标准工具集 \(T = \{\)Read, Write, Edit, Bash, Glob, Grep, TodoWrite\(\}\) 与编程环境交互，靠操作文件系统产出结果。两层的读写权限严格按角色和当前迭代限定（meta-agent 只写 skills/，base-agent 写 context/）。 - 兼容 Claude Agent SDK 和 LangChain DeepAgents，可直接接入现有基础设施。 - 为便于 rollout/评测时程序化调用，要求 base-agent 实现有预定义输入输出签名的可调用接口（本文实例化为一个 one-shot 检索函数：query → context），每次 base-agent 执行完成时校验接口。

4 实验：五个领域，一致超过 SOTA CE 方法

4.1 设置

4.2 主结果

Context Performance（Table 1）——四条核心观察：

Method FiNER Acc↑ USPTO50k Acc↑ Symptom2Disease Acc↑ LawBench F1↑ Aegis2.0 F1↑ Avg. Rel. Gain↑
Base Model 58.0 6.0 63.7 0.36 0.54 –
Offline
ICL 64.0 9.0 84.4 0.57 0.59 32.1
MIPROv2 69.0 14.0 73.1 0.60 0.59 48.6
GEPA 66.0 15.0 70.8 0.69 0.76 61.5
ACE 71.0 18.0 79.2 0.65 0.68 70.7
MCE 75.0 20.0 89.2 0.70 0.80 89.1
Online
DC 61.0 14.0 73.1 0.46 0.53 35.8
ACE 64.0 13.0 62.3 0.63 0.57 41.1
MCE (w/o skills) 67.0 18.0 76.9 0.70 0.68 71.3
MCE 68.0 20.0 76.4 0.66 0.63 74.1

Context Adaptability / Efficiency（Figure 3 + Obs.5–7）：

Figure 3: FiNER 上的上下文效率（准确率 vs 上下文 token）

Figure 3 逐元素解读：横轴 = 上下文大小（token 数），纵轴 = 准确率。蓝色方块是 ACE 在不同阶段的上下文（Step 20 / Epoch 1 / 2 / 5），红色圆点是 MCE（MCE-S 小上下文、MCE-L 大上下文两个迭代产物）。关键信息： - MCE-S 在 ~1.5K token 处达 73% 准确率，而 ACE 在同等长度（Step 20）只有 65%——同样短，MCE 质量高得多。 - MCE-L 用仅 20K token 达 75%，超过 ACE 跑满 5 epoch 后的成绩（70% @ 79K token）——ACE 用了近 4× 的上下文还更差。 - 虚线（70%）标出 ACE 的天花板，MCE 的两个点都在其左上方（更少 token、更高准确率）。

Obs.❺（自适应长度）：GEPA 偏简洁（~1–2K token），ACE 偏膨胀（5 epoch 后达 ~80K，用 200 训练实例时）；MCE 学会为每个任务产出合适长度——FiNER 最有效的两个上下文是 1.5K 和 20K，LawBench 和 USPTO50k 则达 44K 和 86K，彻底摆脱简洁/冗长偏置。 Obs.❻（更高效上下文）：归因两点——(1) agent 维持累积上下文的全局视野，能重构精炼而非盲目 append；(2) 批量处理 rollout，聚合多例反馈后再更新，产出连贯、非冗余的上下文。 Obs.❼（更好迁移）：把 DeepSeek-V3.1 学的上下文迁到小模型（Llama3.3-70B / Qwen3-8B / Gemma3-4B），MCE 的相对性能下降一致低于 ACE（Table 2）；ACE 迁移的上下文有时甚至把性能压到 base 以下（LawBench 在 Llama3.3-70B 上 0.24→0.19）。归因：MCE 上下文更紧凑（小模型长上下文处理吃力）+ 更可泛化（批量优化不易过拟合训练模型的错误模式）。

Training Efficiency（Figure 4 + Obs.8–9）：

Figure 4: FiNER 上的训练效率（训练准确率 vs rollout 数）

Figure 4 逐元素解读：横轴 = rollout 数（MCE 含训练 + 验证推理），纵轴 = best-so-far 训练集准确率。红线 = MCE，蓝线 = ACE。关键标注： - MCE 在 450 rollouts 就达 95%（4.8× 更高效），而 ACE 峰值 94% 要跑到 2169 rollouts。 - 时间上：MCE 1.9h vs ACE 25.8h（13.6× 更快）——分别标在两条线的终点。 - 红线陡峭上冲后早早饱和，蓝线缓慢爬升——直观展示"批量 agentic 优化" vs "逐样本优化"的效率差。

Obs.❽（训练更快）：13.6× 加速源于 batch-level 优化——base-agent 要么直接分析训练数据整理上下文（读错误预测、找模式、更新文件，无需重 LLM 脚手架），要么写代码并行化跨 rollout 的反思与整理。 Obs.❾（rollout 更省）：全局视野 + 批量优化也加速收敛。

4.3 消融研究

Ablating Bi-level Design（Table 3, FiNER）——验证双层设计的必要性：

Method Offline Online
Base Model (zero-shot) 58.0 58.0
ACE 71.0 64.0
MCE (w/o skills) 73.0 67.0
MCE (w/ a fixed skill) 71.0 68.0
MCE (full, w/ evolving skills) 75.0 –

[!IMPORTANT] 三个发现： 1. meta-level 技能进化有明确增益：full MCE 75% vs 无技能变体 73%（offline）。 2. 即便无技能引导，base-agent 单独也超过 ACE（73% vs 71% offline，67% vs 64% online）——说明全 agentic CE 本身就能奏效、不需人手工脚手架（这是对"agentic > 固定流水线"的强证据，即使不进化技能）。 3. 固定技能跨任务方差大（见 Table 1），因为其质量只取决于任务规格、没有从验证性能学习。 注：full 版不适用于 online（单遍处理无法迭代进化技能）。

Ruling Out Model Confounds（Table 4）——排除"增益来自更强的 agentic 模型（MiniMax M2.1）"这一混淆：把 ACE 的反思器/整理器换成 MiniMax M2.1，结果反而更差——尽管 playbook 更冗长（114K vs 79K token），最终准确率更低（67% vs 70%），且训练更早终止（epoch 3 就超上下文窗口）。这排除了"知识从 agentic 模型迁移"作为 MCE 增益来源——MCE 的优势来自方法论设计本身（但确实需要一个能与编程环境交互、产出有效文件/代码的 agentic 模型）。

5 结论与讨论

个人思考

⭐ 与 [[ref09_meta-harness]] 的正面对照（本项目最该写的一组对比）

这两篇是互为镜像的姊妹工作：Meta-Harness 明确把 MCE 列为文本分类基线（并超过它），两者都在回答"能否自动优化那层决定'模型看到什么上下文'的支架"。放在一起能把"自动 harness/CE 优化"的设计空间讲清楚：

维度 MCE (ref08) Meta-Harness (ref09)
进化/搜索的载体 Agent Skill（指令+脚本+资源的文件夹，有语义的中间层） 整个 harness 代码（单文件 Python 程序）
谁来改 一个 meta-agent（MiniMax M2.1）做 agentic crossover 一个强编程 Agent（Claude Code + Opus-4.6）做提议
提议者看到什么 技能库 \(H_{k-1}\)：历史技能 + 上下文 + 训练/验证分数（可任意翻工作区） 文件系统：所有候选的源码 + 分数 + 原始执行轨迹（可 grep）
结构分层 显式双层：meta（进化 skill）/ base（构造 context），解耦 what vs how 极简单层外环：把结构下放给 Agent，无 parent-selection
搜索算法 (1+1)-ES（每轮一个后代，留优） 维护种群 + Pareto 前沿（多目标）
优化对象范围 专注 context engineering（构造上下文的过程） 更宽：分类/检索/终端 agent 的任意 harness
关键实证 上下文自适应长度（1.5K–86K）、训练13.6× 快 原始 trace 是决定性成分（消融：摘要≈只给分数）
共同基座/基准 DeepSeek-V3.1 等；FiNER/USPTO/S2D/LawBench/Aegis Opus/Haiku；文本分类/数学检索/TerminalBench-2

我的判断：两篇选了"自动优化 harness"光谱上抽象层的高低两端。 - MCE 在"skill"这个有语义的中间层进化——好处是产物人类可读、可版本化、可选择性重组，且天然解耦"优化目标 vs agent 架构"；代价是天花板受制于"skill 抽象是否总能表达最优策略"（作者自己承认在推理密集/超长轨迹任务上未必占优）。 - Meta-Harness 直接在"裸代码 + 无损全历史"上搜索——天花板更高、更"苦涩教训"，但依赖一个很强的提议者，且丢弃了 skill 这种可解释中间层。 - 一个自然的合流猜想：用 MCE 的"skill 层"当 Meta-Harness 的可解释动作空间的高层脚手架——让强提议者先在 skill 层做审议式重组（可读、可迁移），需要时再下钻到裸代码。或者反过来：给 MCE 的 crossover 喂 Meta-Harness 式的原始执行轨迹（而非只喂聚合分数），可能进一步提升——因为 ref09 的消融强烈暗示"原始 trace 不可替代"，而 MCE 目前 crossover 主要看的是技能/上下文/分数摘要。

与更广谱系的关联

方法论启示（可迁移的通用思路）

  1. "进化 skill"这个抽象层选得很好：skill 把"领域方法论（NL）+ 可运行代码 + 上下文模板"统一在一个可读、可版本化的对象里。任何"想让系统自我改进但又要可解释、可审计"的场景，都值得考虑"在 skill/配置这个中间层进化"而非直接改裸代码。
  2. "解耦 what 与 how"是通用杠杆：把"学到什么"（产物）和"怎么学"（策略/技能）分开优化，正是 meta-learning/AutoML 的精髓，MCE 把它干净地平移到了 CE。
  3. "我的方法能重建你的方法"是强论证范式：把 SOTA 基线论证成自己搜索空间里的一个特例（ACE ⊂ MCE 技能空间），比单纯刷分更有说服力。
  4. 上下文该多长应由任务决定，而非由方法的归纳偏置决定——Figure 3 的"自适应长度 1.5K–86K"是对"别把简洁/冗长写死进方法"这一点最干净的证据。

在我的工作中能怎么用

开放问题 / 疑问

局限性（补充作者未强调的）