2.18 为本地智能体实现安全沙箱 · Cursor
目前还没接触过沙箱设计，后续有需要的时候再来分析。
3.3 Cursor 技术支持团队如何使用 Cursor · Cursor
不是目前关注的重点，但里面的信息有用，有时间回来看。
3.5 构建可自动运行的 Agent · Cursor
3.16 用自治智能体保护我们的代码库 · Cursor
cursor 的自动化博客。
做好一个自动化流程需要做很多很多细节的开发，这种经验只能从实践中习得，从博客中无法获得某种通用经验。
不同的自动化流程复杂度天差地别。因此这部分相关的内容我会单独开一个book去分析。我们在这里简单聊聊常见的自动化场景。
- pr/mr审查
这应该是所有程序员最常用的自动化，用一个bot去分析本地pr是否会产生冲突，或者是否符合整体的代码风格，代码是否存在风险等等。这里需要一套详细的规范，以及一套检查流程。 - 事件响应
可能是某个页面的埋点，也可能是某个节点启动来触发。这里主要的功能是通知到对应负责人，要注意相应的突发事件。比如训练oom....... - 个人助理
这是一个比较通用的场景，也就是最近比较火的工作台。但坦白讲，大部分人的工作台没有太高复杂度，简单的几个节点或者脚本就能实现。比如抓取xxx的信息，给我总结todo，排一下明天的日程，总结一下issue。但这些自动化确实高效，有用。
9.10 介绍 Projects · Cursor
我暂时把这篇博客提前分析，因为发现里面的很多设计思路和我的高度相似。
cursor在9月10日开放了project模式，是一个我之前一直在构思，但还没完成的设计。
先来看看cursor对projects模式的简介：
“Projects 让您能够承接更大规模的工作，比如一项功能、一次迁移，或是一个完整的应用。它能在长达数月的工作中维持上下文，向成千上万个子智能体委派任务，并无需提示就自动完成周期性工作。”
在我之前分析cursor 2月发布的博客的时候，我就指出，用户不应该去思考如何组织multiagent，用户的所有关注点就应该在项目本身，在需求，idea，架构本身。而剩下的执行过程应该被架构封装好。projects模式通过提升一个抽象层级，让开发者不必再费心管理智能体，而是直接指挥工作本身。
projects模式在我的账号中还没有体验，因此相应的功能我无法进行分析。但博客里提到：
“通过与 Project 的协调智能体对话来管理 Project。协调智能体本身不写代码，而是指挥其他负责写代码的智能体。由于它只负责委派而不亲自执行，因此永远不会被阻塞，始终能够响应你的指令。”
这和我的设计完全一样。Blog · Michel Johnson
想要做好一个coordinator，必须要将项目的所有context统一到云端，或者同一个机器。同时cursor的这道结构支持端云协同。那我的项目的优势就很明显了，不需要依赖cursor这个平台，可以支持多平台的协同。云端决定了context存在哪，而context怎么存，也非常关键。
cursor的博客里并没有context存储的技术细节，而这恰恰是最关键的部分。我对coordinator的要求是响应非常快，那这就要求尽量少的动态上下文，因为agent多轮去搜索上下文会消耗非常多的时间，这会给用户的体验非常差。
为什么要响应快？很简单，如果响应过慢，用户太多时间浪费在等待，而且由于想要重复利用时间，用户很可能同时开两个coordinator，做两个任务。而大部分人并行做任务的能力非常差，我也是这样。但当响应够快，交流足够流畅，问题想清楚后直接做，这样会让大脑稳定运转，而不是转一转歇一歇。集中精力1小时，可能就会把原来需要1天才能沟通清楚的任务做完。
此外，coordinator还会担任监督，验收，分配任务等工作，你可以理解为它就应该是这个任务的用户数字分身。所以你会发现，上限还是人。
其余的功能都是一些automation相关的动作，没有什么新技术。
从总体的设计来讲，这篇博客没有给我带来新东西，因为有些问题，有些方式我想过，也实践过，我们都在回答：
新一代的human-agent的交互方式应该是什么样的？我们要带给用户什么样的体验？
公司内部也有很多context manage，人与agent协作的工具。他们的功能非常丰富，但是客观来讲，他们的使用方法太复杂。为了标准化的流程，有太多的按钮，有太多的页面，用户的学习成本太高。
并且这些产品都没有做好一点：让ai的输出更可读。
一次输出400字的详细文档，对我重要的可能只有40字，而ai没办法把这40字找出来，因为ai不住在我的脑子里，如果我的prompt不够明确，ai根本找不到位置。而组织一个准确的prompt非常困难也非常耗时间，所以用户就硬着头皮读完ai的输出，然后骂着这个ai不说人话，太蠢。
但是我在对比fable5和seed 2.1 pro的时候，发现同样的prompt，二者的回复差距非常大。seed 2.1 pro输出的文本我根本读不下去，而fable5输出的文本我不仅能读下去，而且觉得它说的特别有道理，给了我很多启发。所以模型不说人话的问题也许从模型侧去解决，辅以简单的sp，应该就能很好解决。
3.11 我们如何在 Cursor 中比较模型质量 · Cursor
非常重要的一篇blog。
我在自己开发的时候，经常思考，如何去做模型的自动路由。这里最根本的问题是，你怎么知道对应的模型最合适的场景是什么，或者说，一个场景用什么模型性价比最高。而这一般要靠做实验来确认，而实验也需要一个标准，这就是benchmark。
而cursor也做了自己的Cursor · CursorBench
可惜的是，cursorbench只供内部评测使用，并不开源，而关于一些开源benchmark的分析，我后续会放到Benchmark · Blog
cursor列出了当前公开的benchmark的局限性：
- 一致性：目前公开的benchmark和实际开发者要求agent完成的编程工作并不契合。
- 评分：许多公开benchmark都假设只有一小组正确解法，但大多数开发者的请求本身就有很多没有明确的地方，因此往往会存在多种有效方案。而benchmark要么惩罚其他同样正确的方法，要么附加人为设计的要求来消除这种不确定性。这两种做法都无法准确评估真实性能。
- 污染：SWE-Bench都从公开代码库抽取任务，而这些任务最终会进入模型训练数据，从而提高分数。而openai发现模型可以凭记忆浮现标准布丁，停止了报告SWE-bench Verified的结果。
cursor给出的结论是：在前沿水平上，这些benchmark已经无法区分模型在开发者真实使用体验上的差异。
cursorbench的任务更贴近开发者与智能体交流时那种信息不充分，常常带歧义的表达方式。与公开的benchmark相比，cursorbench的任务描述可以保持简短，并使用agent进行评分。同时，cursor还有在线评估结果，进一步优化线下的评估指标。
cursor预计在未来一年里，绝大多数开发工作将转向在各种计算机上独立运行的长时agent来完成。而要做到这一点，需要考虑如何降低评测成本，这是一个很有趣的角度。