上下文工程：从手写到自动进化
ACE → MCE → Meta-Harness：优化对象从 prompt 内容演进到管理机制代码
本页解决的问题
先给结论「上下文工程：从手写到自动进化」要解决的关键问题是什么？
ACE → MCE → Meta-Harness：优化对象从 prompt 内容演进到管理机制代码
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
长上下文研究会持续进步，但目前长上下文智能和上下文工程往往交织在一起：上下文管理是在 LLM 有限注意力下构建更结构化、简洁上下文的关键层。
一个 MCE Skill 定义了上下文函数
c = F(x; ρ)：• ρ = 静态组件（prompts、知识库、代码库）
• F = 动态算子（搜索、选择、过滤、格式化）
• 静态文件：
skill.md（存储任务最重要的知识）• 动态文件：上下文数据和 rollout 记录
meta-level 和 base-level 优化都在标准编码环境中执行，使用工具集：
Read, Write, Edit, Bash, Glob, Grep, TodoWrite
• Proposer 本身是一个编码 Agent
• 输出是 Pareto 前沿上的 Harness 候选集合
• 执行历史通过文件系统访问：coding agent 用
grep/cat 按需读取，避免全塞进 prompt• 每个提出的 harness 是文件系统中的字典：包含源码、分数、轨迹和状态更新
「优化对象的演进」为什么能找到相关内容
「ACE → MCE → Meta-Harness：优化对象从 prompt 内容演进到管理机制代码」把检索问题从“把资料存起来”推进到“怎样找到真正相关的资料”。这一步决定了 RAG、推荐和以图搜图最后交给模型的输入质量。
相似度不是答案，召回之后还要核对
在「ACE → MCE → Meta-Harness：优化对象从 prompt 内容演进到管理机制代码」对应的流程里，Embedding 负责把对象放到可比较的语义空间，近邻索引负责减少搜索范围，最终的回答仍然依赖召回片段是否覆盖问题、距离指标是否合适，以及内容有没有过期。
先区分找得到和找得准
把「ACE → MCE → Meta-Harness：优化对象从 prompt 内容演进到管理机制代码」落成一次小测试：准备几条有明确答案的查询，记录召回的相关性、遗漏和无关结果，再决定是否需要换切分方式、索引或重排。
从「优化对象的演进」走到「问题：上下文膨胀」
「优化对象的演进」先把问题落在「Level 1 指令 Prompt Level 2 结构化上下文 Level 3 工作流 Level 4 Harness 代码 Level 5 优化器代码 模型越智能、越强大，我们能优化的目标就越复杂、方法越通用。这条演进线从调 prompt 一路到优化写优化器的代码」上；到了「问题：上下文膨胀」，讨论继续推进到「简单追加 = 失控 把所有工具响应和模型生成 简单追加 到上下文中，随着 Agent 任务时长增加会迅速失控。 长上下文研究会持续进步，但目前 长上下文智能 和 上下文工程 往往交织在一起：上下文管理是在 LLM 有限注意力下构建更结构化、简洁上下文的关键层」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
检索系统也可以这样看：先确定什么算相关，再观察召回是否覆盖问题，最后检查排序、切分和时效性有没有把真正有用的内容挤出去。
- 「优化对象的演进」：Level 1 指令 Prompt Level 2 结构化上下文 Level 3 工作流 Level 4 Harness 代码 Level 5 优化器代码 模型越智能、越强大，我们能优化的目标就越复杂、方法越通用。这条演进线从调 prompt 一路到优化写优化器的代码
- 「问题：上下文膨胀」：简单追加 = 失控 把所有工具响应和模型生成 简单追加 到上下文中，随着 Agent 任务时长增加会迅速失控。 长上下文研究会持续进步，但目前 长上下文智能 和 上下文工程 往往交织在一起：上下文管理是在 LLM 有限注意力下构建更结构化、简洁上下文的关键层
- 「直观对比：看三种策略逐轮变化」：运行 10 轮对比 重置 就绪 朴素追加 上下文占用 （第 0 轮） — 任务成功率 — 每轮把所有历史全部塞进上下文… ACE 结构化 上下文占用 （第 0 轮） — 任务成功率 — Curator 只增量写入结构化条目… MCE 元进化 上下文占用 （第 0 轮） — 任务成功率 — Skill 与内容双层同时进化… 点击上方 运行 10 轮对比 ，观察三种策略随轮次推进的实时变化：谁在膨胀、谁保持稳定、谁越跑越…
最后的「直观对比：看三种策略逐轮变化」把讨论落到「运行 10 轮对比 重置 就绪 朴素追加 上下文占用 （第 0 轮） — 任务成功率 — 每轮把所有历史全部塞进上下文… ACE 结构化 上下文占用 （第 0 轮） — 任务成功率 — Curator 只增量写入结构化条目… MCE 元进化 上下文占用 （第 0 轮） — 任务成功率 — Skill 与内容双层同时进化… 点击上方 运行 10 轮对比 ，观察三种策略随轮次推进的实时变化：谁在膨胀、谁保持稳定、谁越跑越…」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。