更大的上下文窗口是编程智能体的错误抽象
更大的上下文窗口虽然有用,但对于编程智能体而言,连续性比上下文更重要。文章区分了上下文和记忆,指出检索不足以解决问题,并介绍了Sigilix提出的记忆原生智能体方法,该方法通过持久可信的底层存储来继承先前的决定和修正,从而避免每次从零开始。文章还讨论了一个较小模型(Boreas)在记忆原生设置下如何胜过更强模型,以及记忆系统的潜在陷阱和设计原则。
大上下文窗口很有用,我也在使用它们。它们允许模型在必须总结或遗忘之前,容纳更多文件、日志、讨论和中间状态。但对于编程智能体而言,上下文大小常常被误认为是连续性。
连续性不同。连续性意味着系统知道在当前提示之前发生了什么。它知道哪些发现是真实的,哪些被否定了,团队纠正了哪些约定,哪些文件通常一起变化,哪些死胡同不应再次探索,以及哪些假设已被证明错误。
更大的窗口可以携带更多文本,但它不决定什么是值得记住的,也不知道该信任什么,更不会将上周的纠正转化为当前审查的约束。上下文不是记忆。
大多数编程智能体是上下文原生或工具原生的。上下文原生智能体通过将正确的文件打包到提示中工作。工具原生智能体可以搜索、grep、检查符号并调用外部系统。两者都重要,但都倾向于将每个任务视为新的调查。
Sigilix正朝着不同的方向推进:记忆原生编程智能体。在这种模型中,智能体不仅仅在提问时获取上下文。它针对一个持久的代码库底层工作,该底层通过审查、否定、评论、修复、问题分类和智能体会话更新。每次交互都可以留下证据供未来交互使用。
这并不意味着永远保留一切。大多数交互数据在几天后就是噪音。有用的部分是决策、修正、任务状态、约定、依赖关系和证据。记忆层必须有选择性,否则就会变成另一个令人淹没的上下文堆。
更多上下文携带文本。记忆携带约束。
上下文窗口智能体:差异、附近文件、搜索命中、聊天历史 → 模型重建代码库 → 它必须从当前运行的原始上下文中推断相关性、信任、约定和先前的修正。
记忆原生智能体:代码图、信任分类账、团队约定、证据收据 → 模型在准备好的基底上推理 → 先前的决策在模型开始为当前问题花费token之前就约束了任务。
区别不是模型能看到多少文本,而是先前的决策、修正和证据是否成为下一个任务的一部分。
检索也不够。
明显的反对意见是好的检索应该解决这个问题。索引代码库,构建图,找到相关文件,放到模型面前。这比将差异粘贴到聊天窗口有了真正改进。但这不是记忆。
检索回答的问题是:现在什么文本可能相关?记忆回答不同的问题:代码库已经教会我们什么,应该约束答案?这两者不可互换。搜索结果可以向模型展示当前实现,但它不会告诉模型这个团队在三次审查前已经拒绝了一个提议的模式,或者一个看起来很可疑的发现以前被证明是误报,或者存在一个奇怪的本地约定是因为生产环境依赖它。
这就是为什么一个编程智能体可以有很好的检索却仍然感觉健忘。它能找到正确的文件,但仍然问同样的问题。它能读取同一个帮助函数,但仍然提出同样的错误抽象。它能检查同一个差异,但仍然没能继承使上次审查有用的人工修正。
当记忆成为原生时,循环发生变化。
在上下文优先的循环中,智能体从提示开始,收集文件,推理,发出答案。如果答案错误,用户纠正。在许多产品中,该纠正只是聊天历史的一部分,可能存活在会话中,可能被总结,但通常不会成为下一个智能体运行的持久约束。
在记忆原生的循环中,纠正不仅仅是对话,它是一个信号。否定、接受的修复、审查回复、合并PR、分类的问题和失败的假设都可以更新底层。下一次智能体触到同一个表面时,它不应从零开始。它应该继承代码库学习到的形状:什么重要,什么已被检查,团队偏好什么,以及哪些主张需要证据才能被相信。
这改变了模型的工作。模型仍在推理,但它不再负责每次从原始文本重建所有机构记忆。它可以将其容量用于当前问题,因为周围的系统在携带持久部分。
一个修正成为架构,而不是聊天历史。
工作发生:PR、问题、Slack线程、审查和智能体会话。人类修正:否定、接受的修复和回复将信号与噪音分开。证据附加:持久记忆保留来源、范围、证据和过期行为。下一次运行继承:智能体从学到的约束开始,而不是空白会话。并非每一行记录都持久,过时的观察会衰减,主张保留其证据。在记忆原生的循环中,审查的重要输出不仅仅是评论,而是更新底层从而改变下一次运行。
记忆访问不等于记忆能力。
这个区别在我测试Boreas(Empyrean系列的第一个模型)时变得清晰。Boreas不是前沿模型。没有Sigilix底层,它并不令人印象深刻。有趣的结果只在模型被设计为通过记忆工作而不是将记忆视为另一个工具调用时出现。
实时比较:同一代码库/同一提示/同一记忆访问。Boreas使用底层作为基底,接地任务,直接移动到代码库特定的答案。Opus 4.8有相同的访问,但花费运行时间争论该信任什么,而不是将记忆视为操作上下文。本地运行/行为,非基准测试。在该运行中,双方都能访问相同的代码库和相同的记忆支持的上下文。更大的模型可以看到基底,但它不知道如何生活在其中。它不断推理自己进入不确定性,反复检查该信任什么。
这是我认为从外部容易错过的地方。让模型访问记忆并不会自动让模型很好地使用记忆。一个通用模型可以将底层视为另一堆观察结果来辩论。它可以花费预算决定记忆是否相关,名称不匹配是否意味着记忆过时,代码库是否有另一条等效路径,以及是否该信任索引。这种谨慎并非不合理,只是代价高昂,并且在编程智能体中可能成为整个任务。
Boreas做了不那么戏剧化但更有用的事情。它获取了代码库图,将任务接地到先前的代码库状态,然后直接回答。这就是重点。我并不是声称Boreas总体上优于Opus,它没有。我声称一个围绕持久记忆塑造的模型可以在连续性密集的编程任务上击败更强的通用模型。
失败模式看起来不太像幻觉,更像是过度审议。更强的模型不断试图证明脚下的地面。较小的模型,因为被调整通过基底工作,使用了基底并继续前进。这是我关心的设计教训。
什么应该真正持久?
记忆的朴素版本是记录。保存每个提示、每个答案、每个文件、每个审查、每个Slack线程,并希望检索后来能够整理。那只是更大上下文窗口但更差的可用性。
有用的版本更接近工程分类账。它存储未来工作可以安全依赖的事实:
决策:团队为什么选择一种模式而不是另一种。 修正:系统做错了什么,而人类接受了什么。 死胡同:已经尝试过并证明无关的检查。 约定:代码库真实的本地规则,而非通用风格建议。 任务状态:已经完成什么,什么被阻塞,下一步需要验证什么。 证据:使最初发现可信的证明。
模型不必很大。
今天的昂贵模式是要求一个前沿模型在每个任务上重建世界。它打开文件,推断约定,重新推导调用路径,检查历史,决定什么重要,然后最终开始编码或审查。更大的窗口使这成为可能,但也鼓励系统一次携带太多原始材料。
记忆原生智能体改变了预算。模型仍然花费token,但它不必每次都重新发现代码库。底层提供图、信任记录、相关决策和有用的先前失败。模型的工作缩小到在准备好的基底上推理。
这就是为什么较小的模型在这种设置下会变得惊人地有能力。不是因为较小的模型秘密地变成了前沿模型,而是因为任务不再要求模型同时成为数据库、搜索引擎、记忆系统、判断者和执行者。
记忆也可能使智能体更差。
记忆原生系统比无状态聊天模型有更尖锐的失败模式。如果记忆过时,智能体可能自信地将旧规则应用于已变化的代码路径。如果记忆过于急切,智能体可能过度拟合到仅适用于一个功能的团队偏好。如果记忆没有证据纪律,系统可能将过去的幻觉转化为未来的基础设施。
这就是为什么我坚持使用“可信”这个词。只有当系统记录了主张的来源以及为何应该信任时,记忆才有帮助。记住的约定应有示例。记住的否定应知道什么被否定以及在什么条件下。记住的发现应带有使其真实的证据。没有这些,记忆就成了带API的传说。
还必须有衰减。一些事实应该消失,一些应该降级,一些应该被新决策覆盖。目标不是完美的档案馆,而是保持工程判断的持久部分,同时让过时的观察消退。
记忆需要门控,否则变成传说。
过时的记忆:旧规则应用于变化的代码路径。过度拟合的记忆:本地偏好被误认为是代码库范围的约定。未经证实的记忆:过去的幻觉被提升为未来上下文。可信的门控:来源(记忆来自哪里)、范围(适用于哪些文件或表面)、衰减(何时降级或遗忘)、证据(什么证据使其可安全重用)。系统应该仅在有来源、范围、衰减和证据的情况下记住。否则旧的错误成为未来的默认。
我不是在声称什么。
我不是在声称上下文窗口不重要,它们确实重要。我不是在声称Sigilix解决了通用智能,它没有。我不是在声称Boreas在开放推理上优于前沿模型,它不优。
我更关心的狭义主张是:编程智能体需要持久可信的底层,超过它们需要另一个数量级的提示空间。当工作与一个活的代码库绑定时,智能体必须将代码库视为变化的系统,而不是文档转储。
我同时不认为这消除了对强模型的需求。有些任务需要前沿推理是正确的工具。错误在于要求前沿模型补偿缺失的产品架构。更好的模型有帮助。更好的记忆基底改变了要求模型执行的任务。
这走向何方?
如果每个PR、审查、否定、问题和智能体会话都改善底层,代码库开始发展连续性。