lightbulb 引言

我们为Claude Sonnet 4.5重建了Devin。新版本速度提升2倍，在我们的初级开发者评估中表现提升12%，现已在Agent Preview中提供。对于偏好旧版Devin的用户，旧版本仍然可用。

为什么不直接将新的Sonnet模型替换掉就完事呢？因为这个模型的工作方式不同——它打破了我们关于如何构建智能体的假设。以下是我们学到的经验：

由于Devin是一个能够规划、执行和迭代的智能体，而不仅仅是自动完成代码（或作为副驾驶），我们获得了观察模型能力的独特窗口。每次改进都会在我们的反馈循环中复合，让我们对真正发生了什么变化有了更清晰的视角。使用Sonnet 4.5，我们看到了自Sonnet 3.6（与Devin GA一起使用的模型）以来的最大飞跃：规划性能提升18%，端到端评估分数提高12%，多小时的会话速度更快、更可靠。

为了获得这些改进，我们不得不重新设计Devin，不仅围绕模型的一些新能力，还围绕一些我们在前几代模型中从未注意到的新行为。我们在下面分享一些观察结果：

visibility 模型对上下文窗口的感知

Sonnet 4.5是我们见过的第一个意识到自己上下文窗口的模型，这塑造了它的行为方式。当接近上下文限制时，我们观察到它会主动总结自己的进展，并对实施修复以完成任务变得更加果断。

这种"上下文焦虑"实际上可能损害性能：我们发现当模型认为自己接近窗口末尾时，会采取捷径或留下未完成的任务，即使它还有足够的空间。

我们最终通过相当激进的提示来覆盖这种行为。即便如此，我们发现对话开始时的提示还不够——我们必须在提示的开头和结尾都添加提醒，以防止它过早地结束任务。

在研究解决这个问题的方法时，我们发现了一个意想不到的技巧：启用1M令牌测试版但将使用量限制在200k。这给了我们一个认为自己有充足运行空间且行为正常的模型，没有焦虑驱动的捷径或性能下降。

这种行为对我们围绕上下文管理的架构设计有实际影响。在规划令牌预算时，我们现在需要考虑模型自身的感知：知道它何时会自然想要总结，以及何时我们需要通过上下文压缩进行干预。

有趣的是，模型总是低估自己还剩下多少令牌——而且它对这些错误估计非常精确。

note_alt 模型记录笔记的行为

Sonnet 4.5最显著的变化之一是它主动尝试通过文档和实验来建立对问题空间的知识。

为自己写笔记

模型在没有提示的情况下将文件系统视为自己的记忆。它经常编写（或想要编写）摘要和笔记（例如CHANGELOG.md、SUMMARY.md，但不是CLAUDE.md或AGENTS.md），既为用户也为自己的未来参考。这表明模型被训练为外部化状态，而不是纯粹依赖上下文。当模型更接近其上下文窗口末尾时，这种行为更加明显。

当我们看到这一点时，我们对可能移除一些我们自己的内存管理并让模型处理它的可能性感兴趣。但在实践中，我们发现这些摘要不够全面。例如，它有时会转述任务，省略重要细节。当我们依赖模型自己的笔记而没有我们的压缩和摘要系统时，我们看到了性能下降和特定知识的空白：模型不知道它不知道什么（或者它将来可能需要知道什么）。很可能这些笔记可以通过提示来改进。你只是不应该认为你可以免费获得一个完美的系统。

在某些情况下，有些幽默的是，我们看到智能体花费更多令牌写摘要而不是实际解决问题。我们还注意到模型的努力程度不均匀：模型倾向于在上下文窗口越短时生成更多的摘要令牌。

在我们的测试中，我们发现这种行为在某些情况下有用，但当我们明确指示智能体使用其先前生成的状态时，效果不如我们现有的内存系统。

这是一个有趣的范式和模型发展的新轴，特别是对于更简单的智能体架构或围绕子智能体委托构建的系统。这显然是Anthropic的一个新方向：可能指向一个未来，模型更加上下文感知，这成为多个智能体相互通信的方式。强化学习还没有完全发展到可靠的程度，但我们将跟踪它的发展。

测试以创建反馈循环

Sonnet 4.5在编写和执行短脚本和测试以创建反馈循环方面明显更加主动，并且在何时使用这种能力方面表现出良好的判断力。这通常提高了长时间运行任务的可靠性，尽管我们偶尔看到它在调试时尝试过于创造性的变通方法。例如，在编辑React应用时，我们注意到模型获取页面的HTML以便在过程中检查自己的工作，以确保行为正确。在另一个案例中，当试图修复一个与两个本地服务器试图在同一端口上运行相关的看似无害的错误时，模型最终使用这种行为创建了一个过于复杂的自定义脚本，而不是解决根本原因问题（终止进程）。

compare_arrows 模型并行工作的能力

Sonnet 4.5通过并行工具执行——同时运行多个bash命令，同时读取多个文件等——高效地最大化每个上下文窗口的操作。它不是严格顺序工作（完成A，然后B，然后C），而是在可能的地方重叠工作。它还表现出良好的自我验证判断：在过程中检查自己的工作。

这在Windsurf中非常明显，是对Devin现有并行能力的改进。也就是说，存在权衡。并行性更快地消耗上下文，这导致我们前面提到的上下文焦虑。但当模型在空的上下文窗口中运行时，这种更并发的方法使会话感觉更快、更高效。这是一个微妙的转变，但影响了我们对架构的思考。

模型似乎也被训练为在其上下文窗口的早期更快地消耗并行工具调用，但在接近限制时变得更加谨慎。这向我们表明，它被训练为意识到其工具调用将产生多少输出令牌。

explore 未来探索方向

这些行为开辟了许多有趣的途径，我们还没有能够探索所有这些。以下是我们渴望继续测试的一些方向：

  • subdirectory_arrow_right
    子智能体和上下文感知工具调用：模型在何时外部化状态和创建反馈循环方面的改进判断表明，它可能更有效地处理子智能体委托。然而，正如我们学到的，你必须非常小心何时使用子智能体，因为上下文和状态管理很快变得复杂。Sonnet 4.5似乎更清楚要委托的任务类型，这可能使这更实用。
  • subdirectory_arrow_right
    元智能体提示：我们对这个模型如何处理关于智能体工作流的元级推理特别感兴趣。早期实验表明它与验证系统配合良好——让模型推理自己的开发过程，而不仅仅是执行任务。
  • subdirectory_arrow_right
    上下文管理模型：Sonnet 4.5似乎对如何管理自己的上下文有一些初步直觉。可能定制训练的智能上下文管理模型既能带来更快更好的性能。

随着我们了解什么有效（什么无效），我们将分享更多。与此同时，我们很兴奋让你尝试带有Sonnet 4.5的新Devin和Windsurf。