我们基于 Claude Sonnet 4.5 重构了 Devin。

新版本的速度提升了 2 倍，在我们的初级开发人员评估中得分提高了 12%，现已在智能体预览版 (Agent Preview) 中可用。习惯旧版 Devin 的用户仍可继续使用。

你可能会问，为什么不直接将新模型替换进去就草草了事，而要大费周章地进行重构？答案是，这个新模型的运作方式与众不同，它打破了我们对智能体架构的许多固有假设。

Devin 是一个能够自主规划、执行和迭代的智能体，而不仅仅是代码自动补全工具或编程助手。这种特性为我们提供了一个独特的窗口来观察模型的核心能力。每一次架构上的改进都会在 Devin 的反馈循环中产生复合效应，让我们能更深刻地理解模型的真正变化。

与 Devin 正式发布时使用的 Sonnet 3.6 模型相比，Sonnet 4.5 带来了巨大的飞跃：规划性能提升了 18%，端到端评估得分提高了 12%，并且长达数小时的会话任务在速度和可靠性上都有了显著改善。

为了实现这些提升，我们不仅需要围绕模型的新功能重构 Devin，还必须应对一些前几代模型中从未出现过的新行为。以下是我们观察到的一些关键点。

模型能感知自身的上下文窗口

Sonnet 4.5 是我们见过的第一个能够感知自身上下文窗口的模型，这一特性深刻地影响了它的行为。

我们观察到，当接近上下文长度限制时，模型会主动总结当前进展，并更果断地实施修复方案以尽快完成任务。这种“上下文焦虑”有时反而会损害性能：即使上下文空间还很充裕，模型也会因为认为自己即将“耗尽内存”而选择走捷径或不完整地结束任务。

为了纠正这种行为，我们不得不采用相当激进的提示词工程。我们发现，仅在对话开始时给出提示是不够的，必须在提示词的开头和结尾都加入提醒，才能防止它过早地收尾。

在研究解决方案时，我们意外发现了一个窍门：启用 100 万 Token 的 Beta 版本，但将实际使用上限限制在 20 万 Token。这样一来，模型会认为自己拥有充足的“跑道”，从而表现得更正常，避免了因“焦虑”而导致的性能下降和行为捷径。

这一发现对我们如何设计上下文管理架构具有现实意义。现在，在规划 Token 预算时，我们必须把模型的自我感知也考虑进去：判断何时让它自然地进行总结，何时需要我们通过上下文压缩等手段进行干预。有趣的是，模型总是会低估自己剩余的 Token 数量，而且这种错误的估算还相当精确。

模型热衷于做笔记

Sonnet 4.5 的一个显著变化是，它会通过查阅文档和动手实验，主动地构建关于问题领域的知识体系。

自发撰写笔记

在没有明确指令的情况下，模型会把文件系统当作自己的记忆体。它频繁地创建（或试图创建）总结和笔记文件（例如 CHANGELOG.md、SUMMARY.md），既是给用户看，也是为了自己将来参考。这表明该模型经过训练，倾向于将状态外部化，而不是单纯依赖上下文记忆。当接近上下文窗口末端时，这种行为会更加明显。

起初，我们曾设想是否可以移除我们自己开发的内存管理系统，让模型自行处理。但在实践中，我们发现模型生成的总结不够全面，例如，它有时会转述任务，却遗漏了关键细节。当我们依赖模型的笔记而关闭我们自己的压缩和总结系统时，性能出现了下降，模型在特定知识上出现了断层——它不知道自己不知道什么（或者将来可能需要知道什么）。

通过提示词工程，模型的笔记质量很可能会提高，但这并非一项开箱即用的完美功能。在某些情况下，我们甚至哭笑不得地发现，智能体花在写总结上的 Token 比解决问题本身还要多。

我们还注意到，模型投入的精力并不均衡：上下文窗口越短，它生成的总结 Token 就越多。虽然这种行为在某些场景下有用，但当我们明确指示智能体使用我们系统先前生成的状态时，其效果不如我们现有的内存管理系统。

这无疑是 Anthropic 公司探索的一个新方向，很可能预示着未来模型将更具上下文感知能力，并通过这种方式实现多智能体之间的通信。尽管强化学习训练尚未使这一功能完全可靠，但我们将持续关注其发展。

通过测试创建反馈循环

Sonnet 4.5 在编写和执行小型脚本与测试以创建反馈循环方面表现得更为积极，并且能很好地判断何时使用这种能力。这通常能提高长耗时任务的可靠性。

例如，在编辑一个 React 应用时，我们注意到模型会获取页面的 HTML 来检查自己的工作，以确保行为正确。

不过，这种能力偶尔也会导致它在调试时采取过于“创新”的变通方法。在另一个案例中，模型试图解决一个看似无害的错误——两个本地服务器试图在同一端口上运行。它最终没有去终止冲突进程这个根本原因，而是创建了一个异常复杂的自定义脚本来绕过问题。

模型偏爱并行工作

Sonnet 4.5 擅长通过并行工具执行来最大化每个上下文窗口内的操作效率，比如一次运行多个 bash 命令、同时读取多个文件等。它不再严格地按顺序（完成 A，再做 B，然后是 C）工作，而是在可能的情况下将任务重叠执行。同时，它在自我验证方面也表现出不错的判断力，能够边工作边检查。

然而，并行化也需要权衡。它会更快地消耗上下文，从而引发我们前面提到的“上下文焦虑”。但当模型在一个空的上下文窗口中开始运行时，这种更并发的工作方式让整个会话感觉更快、更高效。这是一个微妙的转变，但它影响了我们对架构的思考。

模型似乎还被训练成在上下文窗口的早期阶段更快地消耗并行工具调用，而当接近极限时则变得更加谨慎。这表明它能够意识到其工具调用将产生多少输出 Token。

未来的探索方向

这些新行为为我们开辟了许多有趣的研究途径，我们尚未能全部探索。以下是我们期待继续测试的几个方向：

  • 子智能体与上下文感知的工具调用 模型在判断何时外部化状态和创建反馈循环方面表现出的更强能力，表明它可能更有效地处理子智能体委托。然而，管理子智能体的上下文和状态非常复杂，必须谨慎使用。Sonnet 4.5 似乎对哪些任务适合委托有更好的判断力，这可能使该方案更具实用性。

  • 元智能体提示 (Meta-agent prompting) 我们对该模型如何处理关于智能体工作流的元级别推理特别感兴趣。早期实验表明，它与验证系统协同工作得很好——让模型能够反思自己的开发过程，而不仅仅是执行任务。

  • 上下文管理模型 Sonnet 4.5 似乎对如何管理自身上下文有初步的直觉。或许可以训练专门用于智能上下文管理的定制模型，从而同时提升性能和速度。

随着我们不断学习和探索，未来会分享更多成功（和失败）的经验。与此同时，我们期待您体验集成了 Sonnet 4.5 的新版 Devin。

👉 如果你需要 ChatGPT 代充 / Claude / Claude Code / 镜像 / 中转 API：