Oracle与公司（5分钟阅读）

# 神谕者与公司 来源：https://calv.info/the-oracle-and-the-firm 和互联网上的大多数人一样，过去24小时我一直在深入研究Fable 5。也和大多数人一样，我对它的质量感到非常震撼。 但在同时使用Fable和GPT-5.5的过程中，我不禁注意到它们在方法上存在明显差异，这使得两个模型的行为截然不同。我们正在目睹两种截然不同的训练策略展开。 对于任何前沿模型来说，完成实际工作都是一项**上下文管理**的练习。模型需要在大量词元上解决问题；有些词元通过工具调用探索，有些则是模型的思考过程。然后它需要产生一个结果。 为了让模型解决越来越难、运行时间越来越长的任务，你需要弄清楚如何扩展这种上下文管理。 ## OpenAI：神谕者 大约从ChatGPT 5.3-Codex开始，我注意到该模型在处理长上下文窗口方面有了很大提升。即使是在长时间运行的任务或`/goal`实现中，它也能保持连贯性，尽管它的上下文窗口比相应的Opus模型小（约20万 vs 100万）。 Codex采用的方法是**压缩**，有两种简单的方法可以使用： 1. 你让一个单独的（有时是更小的）模型根据轨迹输出一条新消息。- *例如，要求5.5将线程中所有内容总结到1000个词元以内* 2. 你从对话中移除某些类别的调用。- *例如，移除所有工具调用，然后开始推理* 你甚至可以想象并行执行此操作：压缩线程中一定数量的消息，然后保留较新的消息的完整保真度。 从今年早些时候开始，Codex已经在Response API中内置了原生服务端压缩功能（https://openai.com/index/equip-responses-api-computer-environment/）。当生成的词元开始超出上下文窗口时，Codex可以运行一个进程来压缩所有内容，仅保留相关信息。 由于压缩发生在服务端，它具有两个不错的特性：a) OpenAI可以轻松随意地更改实现，而不会影响客户端；b) API可以通过路由到正确的GPU，为长时间运行的线程利用更好的K/V缓存。 最终结果，我认为类似于一个'神谕者'。Codex通常会保持一个长时间运行的线程，并频繁进行压缩。你会看到子代理在清晰的路径上执行，但这种情况往往较少发生，除非用户推动。 由于单个线程管理着与用户响应相关的所有内容，它保持高度的连贯性。与整体轨迹相关的小细节会被*记住*。 ## Anthropic：公司 压缩只是处理上下文窗口的一种方式。另一种可以采用的方法是*拆分*上下文窗口到各个代理之间。在这种技术中，你将问题拆分为多个子问题，然后让每个代理在自己的上下文窗口内执行子问题。 至少从Opus 4.1开始，我注意到Claude Code会热切地采用这种方法。对于任何代码库研究，模型会调用`Explore`子代理，利用Haiku快速生成摘要。 而在运行Fable 5时，它简直*疯狂*了。 生成一个审查代理 这是一种非常不同的方法：子代理现在能够在上下文窗口内完成大量工作，然后只将相关信息传回给父代理。 实际上，这*更像*人类组织的运作方式。每个人都有自己的一套目标、输入和输出。他们看到可用信息的一部分，并据此做出决策。我们都通过语言进行交流，但我们看不到彼此头脑中的隐藏状态。 Claude模型*也*进行压缩，并且它利用了其中一些不同的方法（https://news.ycombinator.com/item?id=47601622）。但压缩速度较慢，且需要用户持续升级客户端，所以我推测其训练策略更倾向于委托给子代理。 ## 要点 **成本和词元效率**：我怀疑Anthropic模型往往成本更高，因为子代理经常最终做重复的工作。它们可能会搜索类似的文件，因为它们没有积极通信。 **感知速度**：Anthropic模型通常看起来“做得更多”，因为词元是并行而非串行生成的。在此期间会产生更多的词元。 **“遗忘”**：一位朋友向我指出了一些案例，Anthropic模型似乎不太连贯，或者更容易向用户误报事实。我认为这是真的，并且这很容易用子代理采用的消息传递方法来解释。如果子代理认为某个事实不值得报告给父代理，那么该事实就会从上下文中缺失。这样一来，Anthropic模型更容易“遗漏”明显的事实，即使它们似乎曾经做过研究。压缩也可能发生这种情况，但可能性较小，因为模型在省略或保留词元方面做了“较少的工作”。 最终，我预计我们会看到**两种**方法的结合。Anthropic将改进其压缩（目前过于有损），而OpenAI将针对多代理设置进行训练。