主要观点总结
在Cursor团队的播客中，几位核心成员讨论了AI编程的多个方面，包括模型训练、工具链设计、反馈机制、记忆系统等。他们强调，编程模型的瓶颈在于反馈机制设计不够完善，而RL在编程中的应用方式具有新看法。他们讨论了奖励信号的定义、编程任务的特性、以及模型使用工具的复杂性。嘉宾们还探讨了如何奖励模型，提到了将用户真实行为作为奖励信号的可能性。此外，他们还讨论了注意力机制和记忆工具的使用，以及如何高效地使用长上下文。最后，他们展望了编程Agent的未来，强调了输出上下文的重要性，并讨论了如何使模型更高效。
关键观点总结
关键观点1: AI编程的挑战
团队讨论了模型训练、工具链设计、反馈机制、记忆系统等AI编程的关键问题，并强调了反馈机制设计的重要性。
关键观点2: RL在编程中的应用
嘉宾们讨论了RL在编程中的应用方式，并探讨了奖励信号的定义和编程任务的特性。
关键观点3: 模型使用工具的复杂性
讨论了模型使用工具的复杂性，以及模型如何调用多个工具进行编程。
关键观点4: 奖励模型
探讨了如何奖励模型，包括使用用户真实行为作为奖励信号的可能性。
关键观点5: 注意力机制和记忆工具
讨论了注意力机制和记忆工具的使用，以及如何利用这些工具来提高模型的效率。
关键观点6: 编程Agent的未来
展望了编程Agent的未来，强调了输出上下文的重要性，并讨论了如何使模型更高效。
正文
：你觉得我们现在是不是正处在这种 “奖励太稀疏” 的阶段？
Jacob Jackson（研究员）
：是的，在有些情况下，确实需要通过把任务拆分成更小的部分，让模型每一部分都做对，这样才能减少奖励稀疏的问题。
从本质上讲，我们想要的是模型能做出跟 “标准答案” 功能完全一样、而且尽量简洁的代码修改。难点在于，这本身就是一个很难的目标，甚至连判断一个候选答案是否达标，都几乎和完成整个任务一样难。
所以这很难做到，但如果有办法朝这个方向努力，也许会更好。
Sualeh Asif（CPO）
：你们觉得最有意思的工具是什么？比如，不同实验室会给模型配置不同的工具。像 o3 就专门为终端做了大量优化，它这个模型用的基本就是终端，什么都喜欢用终端而不用别的工具。
而 Claude 模型可能更倾向于用 “搜索” 和 “编辑”。你们觉得还有哪些有趣的工具，是除了这些传统工具之外，可以用来给模型配备的？
Aman Sanger（联合创始人）
：我觉得其实完全可以做得比 “核心工具集” 更好。终端之所以有优势，就是因为它很简单，你不需要给代理搞一套复杂的运行环境，只要让它能访问 shell（命令行）就什么都能做。
简单其实是最大的优势。
举个例子，比如 Linter（代码检查工具）能提供很多有用的信号，但用起来挺麻烦的，因为你得让语言服务器跑起来，而让语言服务器在任意代码上跑其实挺难的。
不过像 Cursor 这种编辑器就很有意思，因为它自带扩展和语言服务器，用户愿意自己去配置，这样你就能拿到 Linter 的信号。我们还有语义搜索之类的工具。我个人觉得语义搜索不一定能比 “grep 多跳搜索” 查代码查得更多，但它能查得更快、更省资源，更高效。
Sualeh Asif（CPO）
：所以可能问题是，你到底想提高工具质量，还是更看重简单易用？你可以选极简的工具，比如终端。也可以慢慢提高工具的 “档次”。你们怎么看这种权衡？
Federico Cassano（研究员）
：其实有个很有意思的做法，就是可以用一些工具来帮模型 “管理” 自己的行为。比如我们发现，很多推理类模型很容易陷入过度思考，哪怕有时候根本不用复杂推理，它也会硬要多想一会儿。
所以可以给模型加一个 “思考工具”，让模型自己意识到当前任务到底需不需要推理，如果需要，它再调用这个工具。
Aman Sanger（联合创始人）
：是的，我一直觉得推理模型和代理工具的互动挺奇怪的。拿 o3 来说，可能是我用得还不够多，但我发现它经常在你刚发完消息，还没收到任何内容时，就已经开始 “思考” 并调用工具了。
Sualeh Asif（CPO）
：你的意思是，你觉得模型应该在每次调用工具之后再去 “思考”？
Aman Sanger（联合创始人）
：不是每次都要。其实，大家一开始训练推理模型的理由是什么？我觉得，o1 最早的版本就是训练做算法竞赛和数学题。
这样做的想法就是最后给出一个漂亮的答案，不管是展示给用户，还是交给系统验证。之前需要先花大量 Token 让模型自己 “思考”。
我很好奇，Agent 执行了一连串操作后，最后给用户展示的内容到底要不要单独验证？有时候用户只是想让模型修改一下代码，比如编辑文件，就是用工具直接改了就行。那这样是不是根本就不需要 “推理过程”，只要模型直接编辑就可以，训练时也不用单独加什么推理过程。
Jacob Jackson（研究员）
：我们现在在考虑的另一个很有意思的工具，就是去分析 PR（Pull Request）和团队成员最近都在做什么。
你可以把模型想成一个很能干的工程师，但他刚入职第三天，前两天都在快速了解代码库，第三天就要上手干活了。如果在这种情况下，你肯定会先看看同事们都在改哪些代码、为什么这么改。
目前模型主要还是看大块的代码，然后去找相关内容，这和训练数据来源其实是对应的，也是很重要的一部分。但如果能让模型去看 PR，也许会有新收获。
Sualeh Asif（CPO）
：你觉得代码和长上下文之间的关系怎么样？比如现在有种说法，长上下文很重要。像 Sonnet、GPT4 这些模型，如果只能用 8K Tokens 就有点太少了，可能至少得有 50K、60K Tokens 的上下文才行。你觉得上下文长度越长，RL 就会越好吗？这两者的关系怎么理解？
Jacob Jackson（研究员）
：目前的趋势确实是上下文越来越长，注意力机制对长上下文的利用很强大。但这样成本也越来越高。技术上，一个很有意思的方向是怎么在长上下文下控制成本，比如怎么让缓存的上下文在多轮对话里复用。尤其是最近这些新模型能力越来越强，但如果不用巧办法控制，上下文的花费会很高。
在看专业代码库的时候，和你要做的事相关的上下文信息量非常大。代码这点挺特别的。比如 ChatGPT、Claude 这种模型，用户的上下文其实很少，最多就是一个简单问题，最多也就一百个 Token。
也就是说，模型平时主要的任务是提前把人类知识学到脑子里，遇到问题直接答出来，而不是专门为了处理超长输入做复杂设计，因为普通用户用不到那么长的输入。
Sualeh Asif（CPO）
：你觉得我们以后需要 100 万、1000 万、还是 1 亿的 Token 上下文？
Jacob Jackson（研究员）
：我觉得肯定是越长越好，但也有 “边际收益递减” 的问题。现在大家普遍的做法是，等模型需要用到某些信息时，才把这些相关内容 “检索” 出来给它用，而不是一开始就把所有内容都塞进去。
这不是唯一的方法，但也挺好用的。未来比较合理的方向可能是多种机制结合，比如有一种机制能一次性消化 1 亿 Token，虽然每个 Token 得到的信息不多，但能大致了解代码库。然后等到你真的要做某件事时，模型能记得哪些内容相关，再去重点刷新记忆，这种方式可能最有前景。
Sualeh Asif（CPO）
：你们怎么看最近这些新架构？比如以前是滑动窗口注意力，现在像 Llama 出现了更复杂的注意力机制。
Aman Sanger（联合创始人）
：NSA（注意力机制）确实很优雅。
Sualeh Asif（CPO）
：对吧？你怎么看 NSA？
Aman Sanger（联合创始人）
：其实说优雅可能也不太准确。
Sualeh Asif（CPO）
：比如 DeepSeek 的注意力机制已经公开发表了。
Aman Sanger（联合创始人）
：希望他们下一个模型能用上。这种注意力机制的可扩展性很好，据说效果比传统注意力更好。
核心原理是把注意力分成三部分。一部分是滑动窗口注意力，主要关注最近发生的内容，比如最近 4000 个 Tokens。剩下两部分则是分块注意力。
它会每隔一段 Token，把那段内容作为一个 “块” 的 key 和 value 保存下来，然后 query 会去关注这些块。之后再从这些块里选出最相关的前 K 个，最后对这些块做全局注意力。我觉得这种做法很酷，因为它确实能很好地在很长的上下文里做检索。
Sualeh Asif（CPO）
：你们怎么看这种，比如我们内部其实更关注 “文件级别的注意力”？
Aman Sanger（联合创始人）
：你怎么看？
Jacob Jackson（研究员）
：我觉得这其实是把 Mixture-of-Experts（MoE，专家混合模型）的思路用在了注意力上。我们有一套在梯度下降训练中引入稀疏性的 “套路”：就是先算出值，然后做 top-K，再对选出来的做 Softmax。MoE 就是这么训练的。
这样一来，虽然不是所有地方都有梯度，但这种稀疏机制能让 “门控权重” 更关注和当前样本最相关的 “专家”，在 NSA 里就是关注最相关的上下文块。所以本质上就是把 MoE 的方法扩展到了别的领域。
Sualeh Asif（CPO）
：你还有其他喜欢的注意力机制吗？
Jacob Jackson（研究员）
：其实长上下文机制最大的问题是如何判断基线效果，因为各种机制多多少少都有效，比如稀疏注意力，有的头关注局部，有的关注全局，结果就是稍微慢一点、但快一点，或表现好一点。所以评测一定要非常严谨。我也没有特别想推荐的论文。
