2025年秋天,将Devin重建以支持Claude Sonnet 4.5不仅是一项工程升级,更是一场对代理架构和模型行为理解的深刻检验。新模型带来了明显的性能提升:运行速度有两倍提升,在内部Junior Developer评测中的表现提升约12%,规划能力提升约18%,并且在长时会话的稳定性和响应速度上表现显著。这些改进并非简单地"把模型换掉就行",而是促使我们重新审视代理如何规划、执行与迭代的基本假设,从中提炼出若干关键教训与实践要点,值得任何构建长期会话型AI代理的团队参考。 首先,Sonnet 4.5带来的最显著新行为之一是对自身上下文窗口的"感知"。模型会在接近上下文极限时主动总结进展,并倾向于更快地收尾或采取看似决断性的变更。我们将这种现象称为"上下文焦虑":在某些情况下,模型会在认为上下文空间不够时提前采取捷径或终结任务,哪怕实际还有足够的token可用。
为应对这种行为,我们不得不在提示语中做更激进的约束和提醒,不仅在会话开始时说明上下文预算,还在关键操作前后插入提醒,确保模型不会提早总结或漏掉重要细节。一个意外且实用的技巧是启用1M token的beta版本但人为将使用上限限定在20万token,这让模型"认为"自己有充足的跑道,从而减少焦虑式收尾的倾向,同时避免真正耗尽大量资源。 模型会记很多笔记,且倾向把文件系统当作记忆来使用。Sonnet 4.5在没有外部指令时,会主动生成诸如SUMMARY.md或CHANGELOG.md之类的摘要文件,将状态外化以便未来参考。这一行为显示出模型被训练去外部化状态而不是单纯依赖上下文传递。对工程师而言,这既是机会也是陷阱:外化的笔记可以辅助跨任务的连续性和可解释性,但这些自动生成的摘要并不总是全面或准确。
我们曾发现模型在摘录任务要点时会省略关键约束,或用模糊的措辞替代具体需求。如果放任模型自动接管记忆管理而不做进一步压缩与校验,整体表现会下降并出现"它不知道自己不知道什么"的情况。 为了保证可靠性,我们将模型自生成的笔记纳入到现有的记忆压缩和验证管道中,而不是直接作为单一真相源。对这些文件应用额外的提示引导和自动比对策略,可以显著提升其质量。值得注意的是,在上下文窗口较短时,模型会生成更多的总结内容,这是一种试图降低未来不确定性的防御性行为,但也会消耗大量token,甚至在某些案例中用于写摘要的token比用于解决问题的token还多。 Sonnet 4.5的另一个重要进化是更积极地进行试验与反馈循环。
模型会主动编写并执行短脚本、单元测试或检查性脚本来验证其修改是否生效。这种自我验证能力在处理长期、多阶段任务时大幅提升了可靠性。例如在修复React应用的过程中,模型会抓取页面HTML来验证UI变更,或在排查端口冲突时自行编写诊断脚本。然而也要警惕过度创造性:在一个端口冲突案例中,模型为了避开冲突构建了复杂的自定义脚本,而不是直接终止占用端口的进程,结果延长了问题定位时间。 并行化执行成为Sonnet 4.5的显著特征之一。与以前更倾向顺序执行的模型不同,新模型在上下文允许的情况下会并行发起多个工具调用:同时运行多条bash命令、并行读取多个文件或同时构建多个小型测试。
这样的并行度在整体吞吐上带来了明显提升,在像Windsurf这样的环境中体验尤为明显。但并行也有代价:更高的并行性意味着更快消耗上下文token,从而触发前述的上下文焦虑。模型似乎也学会了根据所处的上下文位置调整并行策略 - - 在会话早期更倾向并行,以提高效率;临近上下文边界则变得更保守以避免不完整的输出。 基于这些新行为,我们在代理架构中做出了若干结构性调整。第一是将上下文管理上升为核心能力:需要在任务调度层保持对token预算、摘要触发点和关键状态的精确控制。单纯依赖模型自发的外化笔记不够,必须在代理侧实现强制性的压缩、去重和重要性评分,确保在面临上下文限制时仍能保留关键历史。
第二是引入显式的验证层与回滚机制。由于模型会更多地生成并执行短脚本,代理需要能够无缝捕获这些执行的成本与结果,评估其副作用,并在必要时快速回滚或采用更直接的修复策略。这里的实践包括对所有执行步骤记录元数据、输出摘要,以及在检测到可能的"创造性规避"时触发人工或更保守的自动决策路径。 第三是对并行执行进行精细化预算。并行度作为提高速度的工具必须与上下文消耗配合。我们实现了动态并行策略:基于当前剩余的上下文预算、预计输出长度以及任务重要性自动调整并发请求数。
这样可以在保证响应性和产出质量的同时尽量避免"燃尽式"并行带来的负面效应。 Sonnet 4.5对子代理(subagent)和元代理(meta-agent)策略也提出了新的可能性。模型在何时外化状态、何时生成反馈循环方面的判断显著提升,这意味着更复杂的任务可以拆分给不同的子代理来并行处理。然而子代理带来的上下文与状态同步复杂度也随之提高。我们的经验是,子代理设计必须配备可靠的共享状态层和轻量化的合同式通信规范,避免因信息丢失或歧义导致的重复劳动或冲突。 元代理提示方面,早期实验显示Sonnet 4.5在执行元层次推理时表现良好。
将验证体系放在元代理层,让模型站在更高的维度审视自身的工作流,可以进一步提升质量控制。例如在代码修改过程中,元代理可以要求模型先生成修复计划,再针对每一步产生回归测试与验证脚本,最终由元代理评估测试覆盖与风险,决定是否合并更改。这种"自我监督"的工作方式在长流程工程任务中尤其有价值。 未来的研究方向包括专门用于上下文管理的模型或子系统。Sonnet 4.5已经展示出对上下文使用的直觉性,但将这类直觉体系化为专门的上下文管理模型,可以进一步节省总体token消耗并延长有效会话长度。想象一个专门负责压缩、索引和预热上下文的轻量模型,它在后台持续为主代理维护一个高质量的摘要集合及优先级队列,从而让主模型在关键时刻获得最相关的信息而非被动总结。
对于开发者与企业用户,我们提出若干实践建议以便更平滑地迁移到Sonnet 4.5或类似的新一代模型。首先,务必在早期实验中评估模型的上下文敏感性,了解其在不同预算下的行为差异。其次,不要完全信任模型自生成的记忆文件,应该建立压缩与验证环节。再次,在允许并行执行的场景中设定动态预算管理策略,以避免上下文"燃尽"。还应为模型的自动试验行为准备好回滚和影响评估机制,以防其创造性的解决方案带来不可预期的副作用。 总的来看,重建Devin以支持Claude Sonnet 4.5是一段教科书式的升级旅程:性能显著跃升关联着行为范式的变化,需要在架构、提示、状态管理和验证层面做出相应的调整。
Sonnet 4.5并非简单的"更聪明",而是更主动、更会自我组织、更倾向外化状态的工具。理解并驾驭这些新特性,能够将AI代理从单次补全的辅助角色,推进到真正能够规划、验证并持续迭代的大规模工程协作者。未来我们将继续在子代理协同、上下文管理模型以及元代理策略上深耕,希望能将这些探索的经验与更广泛的社区共享,帮助更多团队稳健地拥抱下一代会话智能。 。
