2026年6月5日 几个月前，我正在阅读Viv（@Vtrivedy10）的《代理装置解剖》。这是对什么是装置、为什么它很重要以及哪些组件构成装置的深入探讨。从某种意义上说，作为一名软件开发者，始终需要跟上自己领域的最新发展，而这篇文章很好地概述了这一年多以来出现的“装置”概念。在我阅读文章的某一刻，一个想法突然出现：如果我们不把上下文窗口视为不可变的，仅可附加的对话日志，而是让模型检查和修改上下文窗口本身呢？我意识到，自从ChatGPT发布以来，附加历史视图的上下文窗口观念已经根深蒂固。几乎每个开发者现在都有一个系统提示、用户消息以及不断增长的用户消息、助手消息、工具调用和工具调用结果的心理模型。但如果我们抛弃这个假设呢？如果让模型自己来修改上下文窗口呢？我在进一步思考时有些头晕。假如模型能够识别其下行的错误路径，或者发现自己陷入困境时间的沉重的后果呢？如果它能够管理上下文窗口，自行“自动压缩”历史的早期部分，以防止或至少延迟耗尽上下文窗口呢？凭借这种方法，我们还可以做哪些事情，或者说模型真的可以做到什么？但我越想越不确定。模型真的能识别出它刚刚生成的响应中的问题吗？最初，我认为让模型完全控制上下文窗口的编辑可以产生更高效的结果，避免走入错误的路径或陷入循环，或者编辑掉不再相关的早期部分。但我开始对这个想法感到不安，似乎为了在实践中实现它，我只是在上下文窗口上包裹更多的上下文以向模型解释它可以做什么。我想知道模型是否需要先接受这种想法的训练，在有效地实践之前。我开始在与Claude的会议中探索这个想法，我们决定采用一个更大的模型观察和编辑更小、更弱模型的上下文窗口。Claude提出了几个建议来命名这个想法，我最终选定了“上下文雕刻”，因为这个名字捕捉到了我所喜欢的某种品质。顺便提一句：在我玩弄这个想法的一两周后，我看到Anthropic发布关于“顾问策略”的帖子，您可以将Opus与Sonnet或Haiku配对作为执行者，以仅花费一小部分的成本获得接近Opus级别的智能。因此，也许“上下文雕刻”的想法并不是完全疯狂。来源：https://x.com/claudeai/status/2042308622181339453 另一个顺便提一下：在我阅读Viv的文章时，我对递归语言模型（RLMs）思考得比较多，因此这可能对上下文雕刻的想法也产生了一些影响。我决定想知道这个想法是否可行。我必须承认，最初我抱有一种宏大的幻想，认为我可以设计一个严格的实验，写出结果的论文，获得来自AI研究者的赞誉等。我迅速收回了我的雄心，并转向更适合描述的小型“工程案例研究”。就个人而言，我更喜欢把它称为“气氛研究”。我与Claude一起制定了一个计划，这就是我的“气氛研究”致力于解决的核心问题：如果你允许一个模型在回合之间重写另一个模型的工作上下文，会发生什么？我建议我们使用Pi代理装置框架构建一个定制的装置，因为我喜欢其简约且高度可扩展的方法，Claude也同意，因为Pi具有实现这个想法所需的所有钩子。我们称更强大的模型为“外部代理”，而将较小的模型称为“内部代理”。在与Claude达成一个感觉上可靠的计划后，我转向Codex进行实际的实现和实验运行。Codex还主动起草了一篇博客文章。为了明确一点，我并不是在这里简单复印/粘贴模型的博客文章——这些是我自己的话和想法——但我认为在这里穿插一些Codex的写作也会很有帮助。例如，这是关于项目架构的部分：装置是一个简单的两层循环：内部代理处理实际任务。每次完成内部回合后，外部代理检查整个内部上下文。外部代理选择四种操作之一：pass_through rewrite_context rollback terminate 从高层次来看，循环如下：while run_is_active: inner_agent.take_one_turn() outer_agent.observe(full_inner_context) decision = outer_agent.decide() if decision == pass_through: continue if decis