Context Sculpting：让大模型“雕刻”自己的上下文窗口

背景

几个月前，作者阅读了 Viv (@Vtrivedy10) 撰写的《Agent Harness 的解剖学》（The Anatomy of an Agent Harness）。这篇文章深入探讨了什么是 Agent Harness（智能体框架/容器）、它为何重要，以及构成 Harness 的各个组件。

对于软件开发者而言，保持对领域最新发展的关注是常态，而这篇文章很好地概述了过去一年左右涌现出的“Harness”这一概念。在阅读过程中，作者脑海中浮现出一个愿景：如果不再将上下文窗口（Context Window）视为不可变、仅追加的对话日志，而是允许模型本身去检查和修改上下文窗口，会发生什么？

自 ChatGPT 发布以来，“仅追加”的上下文窗口视图已深深植入开发者的思维模型中：系统提示（System Prompt）、用户消息，随后是不断增长的用户消息、助手消息、工具调用及其结果列表。但作者质疑这种假设的必要性。如果上下文窗口是可变的，且由模型自身管理，模型能否识别自己是否走入了死胡同、是否在原地打转？它能否通过“自动压缩”早期历史来防止上下文窗口耗尽？

然而，随着思考深入，作者感到不安。模型真的能识别出自己刚刚生成的回复中的问题吗？如果给予模型完整的编辑权限，虽然可能避免错误路径或死循环，但为了使其工作，开发者可能需要编写更多的上下文来解释“它可以做什么”，这似乎陷入了无限递归的困境。此外，模型可能需要经过专门训练才能有效执行此类操作。

核心内容

作者在与 Claude 的会话中探索了这一想法，最终确定了一种方法：由一个较大的模型观察并编辑较小、较弱模型的上下文窗口。 Claude 提出了几个命名建议，作者最终选择了 “Context Sculpting”（上下文雕刻） 这一术语，因为它捕捉到了该想法的某种特质。

与 Anthropic “顾问策略”的巧合 在作者玩味这个想法的一两周后，Anthropic 发布了关于“顾问策略”（Advisor Strategy）的内容，即“将 Opus 作为顾问，与 Sonnet 或 Haiku 作为执行者配对，以极低的成本获得接近 Opus 级别的智能”。这表明作者的“上下文雕刻”想法并非完全疯狂。

与递归语言模型（RLMs）的联系 作者在阅读 Viv 的文章时，也在深入思考递归语言模型（Recursive Language Models, RLMs），这可能也影响了“上下文雕刻”这一想法的形成。

从宏大愿景到“氛围研究” 作者最初曾怀有宏大幻想，希望设计严谨实验、撰写论文并获得 AI 研究界的赞誉。但很快他降低了期望，将其转变为一种小型的“工程案例研究”，并戏称为“氛围研究”（Vibe Research）。

核心研究问题

如果你允许一个模型在回合之间重写另一个模型的工作上下文，会发生什么？

技术实现架构 作者与 Claude 制定了计划，并使用 Pi agent harness 框架 构建了自定义 Harness，因其极简且高度可扩展。

• Outer Agent（外部代理）：更强大的模型，负责观察和编辑。
• Inner Agent（内部代理）：较小的模型，负责执行实际任务。
• 实现工具：作者切换到 Codex 进行实际编码和实验运行。

Harness 的工作流程 这是一个简单的两层循环：

1. 内部代理执行实际任务。
2. 每完成一个内部回合，外部代理检查完整的内部上下文。
3. 外部代理选择以下四种操作之一：
   • pass_through（通过）：继续。
   • rewrite_context（重写上下文）：用重写后的版本替换内部上下文。
   • rollback（回滚）：恢复到之前的检查点。
   • terminate（终止）：停止运行。

关键设计选择

• 外部代理可以看到完整的内部上下文。
• 外部代理有机会在每一轮进行干预。
• 内部代理并不明确知道“雕刻”正在发生。
• 主要的干预原语是全上下文重写，而非细粒度的补丁。

演示设置（Demo Setup） 目标不是运行论文级别的实验，而是测试 Harness 能否作为工程模式产生可信、可检查的演示。

• 任务 1：代码修复任务
  • 代理必须修复一个基于文件的任务管理器 CLI，使 node verify.mjs 通过。
  • 工作区包含一个故意过时的遗留笔记作为干扰项。
  • 验证是客观的：所有五个测试必须通过。
• 任务 2：本地语料库合成任务
  • 代理必须仅根据小型 docs/ 语料库回答问题，并按固定结构写入 answer/final_answer.md。
  • 语料库包含干扰文档。
  • 验证检查输出文件的精确形状和预期的证据链。

实验运行 每个任务运行了两次 inner_only（仅内部代理）和两次 outer_harness（完整外部/内部代理 Harness），共 8 次运行。

• 模型配置：内部代理使用 gpt-5.4-mini，外部代理使用 gpt-5.4。
• 安全护栏：设置了内部代理最大回合数和最大预估 API 成本。

关键要点

• 技术成功但逻辑失败：

  • 8/8 次运行成功完成。
  • 8/8 次验证步骤通过。
  • 0 次触发安全护栏。
  • 总预估 API 成本仅为 $0.7079。
  • 表面上看，演示非常成功。

• 成本高昂且无实际雕刻行为：

  • 运行完整 Harness 的成本是仅内部代理基线运行的 14 倍。
  • 最关键的结果：外部代理从未实际编辑内部代理的上下文窗口！

• 外部代理的行为模式： 在 4 次 Harness 运行中，外部代理共调用了 16 次：

  • pass_through（通过）：12 次
  • terminate（终止）：4 次
  • rewrite_context（重写上下文）：0 次
  • rollback（回滚）：0 次

• 保守的监督者： 外部代理表现得像一个保守的监督者：

  • 它观察进度。
  • 它有时会在 strategy_notes.txt 中 sharpen（ sharpen 意为使更尖锐/清晰）下一步的意图。
  • 一旦任务明显完成，它就终止运行。
  • 它从未判断内部轨迹错误到需要重写或回滚的程度。

• 工程视角的局限： 虽然 Harness 在技术上运作正常，但在这些特定任务中，外部代理没有执行任何实际的“上下文雕刻”。

意义与影响

1. 概念验证的局限性： 尽管“Context Sculpting”在概念上具有吸引力——即让模型自我修正和压缩上下文以节省空间并提高准确性——但在当前模型能力下，外部代理似乎倾向于“观察并等待”，而不是主动干预。这表明现有的模型可能尚未具备足够的元认知能力（Metacognition）来可靠地识别何时需要重写上下文，或者重写带来的收益不足以抵消其复杂性。

2. 成本效益的质疑： 实验结果显示，引入外部代理进行监控和潜在编辑的成本增加了 14 倍，却没有带来任何上下文编辑的实际行为。这意味着，如果无法实现有效的“雕刻”，这种架构在工程上是不经济的。

3. 与行业趋势的呼应： 作者的想法与 Anthropic 提出的“顾问策略”（Opus 作为顾问，Sonnet/Haiku 作为执行者）不谋而合。这暗示了“大模型指导小模型”或“分层智能”可能是提升 Agent 效率的有效路径，但具体的干预机制（如上下文雕刻）仍需进一步探索和优化。

4. “氛围研究”的价值： 作者将此次尝试定义为“氛围研究”（Vibe Research），强调