夜雨聆风
上一篇文章提出，AI 自我改进在近期更可能从模型外部的 Harness 开始。模型在任务中看到什么、能调用哪些工具、按什么步骤行动、如何检查结果，都由 Harness 编排；这些机制可以写成配置、文档或代码，研究者不必重新训练模型，也能单独修改并验证它们。
Lilian Weng 在《Harness Engineering for Self-Improvement》中沿着一条从微观到宏观的路径梳理了相关研究成果：指令提示词、结构化上下文、工作流、Harness 代码一直到全局优化算法。本文从中选取上下文与工作流，因为它们已经是当前 Harness 的常见组成部分，也最能说明原本由开发者固定的运行机制是如何开始根据执行结果发生变化。
上下文决定模型能够依据哪些信息作出判断，工作流决定模型、工具和子智能体按照什么过程完成任务。现在的智能体已经会检索、反思和重试，但运行中的调整什么时候只是在修正当前任务，什么时候已经改变了下一次任务的做法？这条界线是理解后续研究的起点。
我们先回到前一篇讨论过的Coding Agent场景，区分两种常见的反馈循环。代码没有通过测试时，模型可以读取错误信息，修改代码后重新运行；检索没有找到证据时，也可以调整查询，继续寻找其他来源。这些变化都服务于当前任务，任务结束后，临时计划和上下文不会被系统保留，下一项任务仍由原来的提示词、上下文规则和工作流驱动。本文把这种局限在单次任务中的反复尝试称为“任务内循环”。
另一种循环从任务结束之后开始。系统继续分析执行轨迹，找出反复出现的问题，将经验写回可复用的规则，再通过评测决定是否把修改用于后续任务。改变可能发生在上下文、检索规则、工作流或相应代码中。本文把这个过程称为“机制改进循环”。
两种循环都使用反馈，任务内循环能够在当前任务下得到更好的结果，机制改进循环则能改变系统处理后续同类任务的方式。文章认为，只有能在一次任务完成后被保留的改动才能算作是自我改进。已有的上下文工程以及工作流领域的研究成果中已经在逐步体现对机制的持久化改进，接下来选重点的几个项目进行详细分析。
任务内循环结束后，第一个问题是怎样把经验留下来。首先想到的是长任务的执行轨迹，包含了模型输出、工具返回、错误日志和中间文件。可这些轨迹信息保存后却很难直接供下一项任务使用，因为原始记录中夹杂着大量临时信息，全部放进上下文会迅速占满窗口，真正可复用的经验也会淹没在具体任务的细节里。
Agentic Context Engineering（ACE）把这些轨迹整理成一份持续更新的结构化 Playbook。每次执行任务，先由 Generator 读取当前 Playbook 并据此执行，留下新的轨迹；任务结束后，Reflector 对任务进行复盘，从过程中提取其中可以复用的经验，再交给 Curator 整理成独立条目，写回 Playbook；下一轮任务会从更新后的Playbook中读取。Playbook 采用增量更新。Curator 处理带有标识符的具体条目，再按照既定规则合并、去重和整理；相比反复重写整份手册，这种方式能保留更多有效细节，也能减少多轮摘要带来的信息损失。
举个简单的例子，假设一个编码智能体多次修改公共接口，却反复遗漏对调用方的检查，系统从这个失误中吸取教训，提取了一条改进规则，在修改公共接口时必须检查调用范围并运行相关测试。Curator 将它写入 Playbook，后续处理同类代码任务时，这项检查就会成为上下文的一部分。写入 Playbook 后，一次任务中的具体错误便成了可以跨任务使用的经验。
一份不断增长的 Playbook 仍然不够。面对一项新任务，系统还要重新决定信息来源、信息源重要程度，以及怎样把信息组织进有限的上下文；如果系统内的这些规则不加以调整，Playbook 中积累的经验再多，也可能在错误的时间以错误的方式提供给模型。
Meta Context Engineering（MCE）因此把上下文的构造方法也放进优化过程。它用Agent Skills描述资料来源和处理步骤，规定信息如何搜索、筛选、组织和呈现。执行真实任务前，需要在该任务上构建一个评测集，根据这个集合来优化上下文构造方法。优化过程中，智能体先对 Skill 进行调整，再比较当前 Skill 与上下文构建方法在评测集上的效果，最后根据效果对skill进行反馈。这种方式的构建仍然不能实时对一个新任务进行适应。
例如，原有 Skill 可能要求编码智能体先做关键词检索，再摘要匹配到的文件。经过多轮离线优化反馈，新版本可以改为先定位接口定义和测试，再沿调用关系读取相关文件。两种方法最终获得的资料可能接近，上下文的读取顺序和组织方式已经不同，这会影响Agent最终在真实任务中的表现。
ACE 和 MCE 的差异，前者在线更新 Playbook 中保存的内容，后者开始更新产生上下文的方法，却大部分是离线的。信息应该怎样准备，也成了系统可以从任务结果中学习的东西。
上下文决定模型在每一步能够看到什么，工作流则决定这些步骤怎样连接起来。当前很多智能体通常依赖工作流来运作，这些工作流一般是开发者预先设计好。以 AI for Science 为例，研究员把自动科研拆成提出想法、编写代码、运行实验、分析结果、撰写论文和评审等环节，再让模型与工具沿着这条流程推进。这套系统能够完成一项较长的研究任务，因为阶段划分和连接方式在运行前已经确定。工作流也通常设计了简单的错误处理，例如实验失败后修改代码，论文评审发现问题后也可以返工论文，但工作流并不会因为某类失败反复出现，就改变自身的检查步骤、调整阶段顺序或改变环节之间的连接，除非开发者重新设计工作流。
要让执行反馈改变流程本身，工作流首先需要能够被程序读取和修改，不同方案的结果也要能够比较，这就依赖工作流的环节能够灵活调整。AFlow 把工作流抽象成一种图结构，节点对应模型调用，边规定节点之间的顺序、分支和循环。有了这种表示，系统便可以直接生成、修改和评测流程结构。AFlow 使用蒙特卡洛树搜索组织这个过程。每轮搜索先从已有流程中选择一个候选，让模型根据执行分数和反馈提出修改，随后运行并评测新版本；后续搜索会沿着表现较好的候选继续展开，也会尝试其他分支，避免始终局限在少数早期方案附近。工作流设计由一次性的人工选择，变成了多轮生成、执行和比较。
AFlow 的搜索机制不会脱离开发者对于任务预先划定的范围：任务、评价方法、初始模板和搜索预算都仅是当前任务下的条件，因而优化得到的流程也未必适用于其他类型的任务。在代码、数学或问答任务上获得高分的结构，不一定适合开放研究或企业决策。更重要的是，搜索只能沿着某些指定好的评测指标所指示的方向前进；如果指标只看正确率，成本、延迟和可维护性就很容易被忽略，工作流的改进方向非常依赖评测指标的制定。
把这些研究连起来看，Harness 的改进可以从基础的机制中开始。一次执行留下的经验先被整理进 Playbook，供后续任务继续使用；随后，搜索、筛选和组织信息的方法也开始变化；工作流被表示成图以后，步骤及其连接关系同样可以根据评测结果重新组合。改进的范围就这样从当前任务延伸到了后续任务的运行方式。
不过，当前这些系统仍在开发者给定的范围内运行。任务目标、评测标准、可用工具和可编辑范围没有随执行结果变化，负责提出和筛选修改的优化器通常也保持固定。运行机制已经进入改进循环，负责改进它的机制仍留在循环之外，递归在这里停了下来。
下一篇将从这个位置继续：当整个 Harness 以及负责改进 Harness 的优化器都进入修改范围，递归怎样进一步发生；进化搜索和模型权重更新，又提供了哪些不同的自我改进路径。
参考文献
Lilian Weng, “Harness Engineering for Self-Improvement”, 2026. Qizheng Zhang et al., “Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models”, 2025. Haoran Ye et al., “Meta Context Engineering via Agentic Skill Evolution”, 2026. Yoonho Lee et al., “Meta-Harness: End-to-End Optimization of Model Harnesses”, 2026. Chris Lu et al., “Towards End-to-End Automation of AI Research”, 2026. Jiayi Zhang et al., “AFlow: Automating Agentic Workflow Generation”, 2024.
