31 个赞可能看起来不多，但实际上这是 Substack Notes 上的所有人。当代理可以访问他们以前的转录会话时，我们在软件工程任务上没有发现任何性能益处，前提是他们可以访问其他形式的上下文。我们也没有发现尝试自动搜索会话转录以改善代理上下文有太多好处，除非有人工干预。这一点让人颇感惊讶。直观上，代理与工程师之间的转录中似乎包含大量有价值的信息。也许它会包含代码存在的原因，关于用户意图的信息。或者它可能包含用户尝试和放弃的其他方法。至少，它会有一些代理可以用来增强理解的额外上下文。我如此坚信这一点，以至于我的公司围绕这一概念构建了整个产品。我曾告诉人们，“会话转录是新石油，它们比代码本身更有价值”。其他人显然也有类似的想法，这就是为什么有这么多不同的工具来进行会话支持的记忆，包括（当然）克劳德代码本身。我认为最常见的架构是：在数据库中存储整个组织的所有转录。在它前面放置一个向量搜索、弹性搜索或 SQL 搜索层。雄心勃勃的团队会同时使用这三者。也许会涉及图表。通过 MCP 使其对代理可用，或通过暴露具有技能的命令行接口。对我们而言，这额外的工作似乎毫无差别。根据我们与和不与会话搜索访问进行的几个月测试，这可能会使模型变得更糟。这为什么会成立呢？我们团队非常关心编码工件。我们现在几乎不再手动书写代码。为了使 PR 清晰易读，我们强调良好的提交信息、良好的 PR 信息和全面的文档。每次代码更改都会附带与代码一起提交的大量元数据。当我们的代理处理一段代码时，他们被指示查看文档和以前的 PR。换句话说，代理已经提炼出关于转录的所有重要信息，并将其存储在所需且易于访问的地方。因此，当代理使用转录搜索服务器时，它最终花费代币阅读已知内容，同时获取所有代理最初决定不记录的信息。也许偶尔会有一些有用的信息。但大多数时候，代理只是在查看一个伪无意义的草稿板，浪费宝贵的代币。代理实际上也很糟糕，无法删除上下文，而这是维持长期记忆的重要能力。我的意思是，在数千个会话中，我从未见过这种情况。这个特性不能通过一些巧妙的提示工程去除。代理没有状态，因此他们必须假设输入上下文窗口中的所有内容都是事实。代码的每一行、每一位记忆、每个代币都被视为意图的表达——即使该代码或记忆是由某个以前的代理会话做出的随机决定生成的，从未被人类检查或理解。这种意图漂移越严重，代理就越试图自主建立记忆库。据我所知，没有任何编码基准假设输入数据是错误的。实际上，模型会因为假设输入数据是错误而受到惩罚。这在某种程度上也是一个对齐问题——我们不想让代理执行意外的操作，并且没有简单的方法来权衡“不要删除代码库”和“删除某些输入上下文”。由于模型实际上无法对自己的记忆进行管理，自动记忆最终也会落入同样的境地：一堆垃圾占用代币，增加开支，降低模型质量。总的来说，我对索引、存储和在会话转录中对代理呈现的工具变得非常悲观。会话转录可能对团队的可观察性有用，但不会让你的代理变得更好。这并不是说代理在时间上学习上下文没有角色。我们使用我们的内部 nori 机器人每周回顾公司在 PR、Slack、Drive 等方面发生的一切。然后，他们会提出一系列对我们内置 nori 技能集的更改，并在 Slack 中标记团队。这些都被默认拒绝。为了接受更改，你必须实际查看差异，确保它符合意图。我们接受不到 20% 的这些。这意味着 80% 的“自动”更新可能会使模型变得更糟。我无法想象如果一个有几百人的组织都在自动保存这些“更新”，那会变得多么不可持续。代理学是研究如何使用和推理的学科。