Cursor Projects 上线后，我更确信 Agent 不该被当作聊天记录

发表于2026-09-13|更新于2026-10-23|视界AI研究

|浏览量:

9 月 10 日，Cursor 把一个颇有野心的产品推到 beta。

它说一个 coordinator Agent 可以调度数千个子 Agent，持续几个月做一个功能、一次迁移，或者一件永远做不完的维护工作。新用户合并的 PR 多了 30%，主要用 Projects 的用户多了 6 倍。

这些数字当然来自厂商自己，不能直接拿去写 ROI 报告。但我读完产品说明，真正想聊的不是「数千个 Agent」这个很容易上头的词。

我更在意它把 Agent 的工作单位，从一次对话，换成了一个长期项目。

这听起来只是产品形态的变化，落到工程实践里却很不一样。很多团队做 Agent，第一版往往是一个很能聊天的助手。它能读代码、查文档、提 PR，演示时几乎无敌。可一旦任务跨过几天、几十个文件和多轮反馈，聊天记录就开始变成负担。上下文会丢，决定会漂，失败会被遗忘。每次开新会话，都像给一个很聪明但完全失忆的新同事重新入职。

Cursor Projects 给出的答案并不神秘。它只是把一个老问题摆到了台面上。

长期工作，到底该由谁负责记住、拆开、验收和收尾？

不是更多 Agent，而是把不该堵塞的人拿出来

Cursor 对 Projects 的描述里有一个细节很关键。coordinator 不写代码，它负责指挥写代码的 Agent。

很多人看到多 Agent，第一反应是拉一个总管出来，既做规划又改代码又跑测试。小任务没问题。可任务一长，这个总管很快会被自己的执行动作堵住。它在等测试、读一个巨大的 diff、处理冲突时，就没法及时响应新的约束，也难以判断其他分支是否已经偏航。

这很像 Java 服务里的控制面和数据面。

控制面不应该亲自处理每一个请求。它负责路由、策略、限流和状态。数据面负责真正干活。把两件事塞进同一个组件，刚开始代码少，后面排障会很痛苦。

coordinator 也一样。它的职责应该收得很窄。

把目标翻译成有边界的工作包
维护依赖关系、风险和当前优先级
决定什么时候并行，什么时候必须串行
根据测试、CI、人工反馈决定重试、回滚或升级
把已经验证的发现沉淀成下一轮可用的上下文

它不需要比子 Agent 更会写代码。它需要比子 Agent 更不容易忘记为什么要写这段代码。

这句话听着有点抽象，但放进迁移任务就很好理解。比如把一个 Spring Boot 服务从一套旧鉴权链路迁到新方案，工作并不只是把 Filter 改掉。你得先摸清哪些入口走 WebFlux，哪些老服务仍是 Servlet，哪些合作方在用旧 token，回滚开关在哪里，集成测试到底覆盖了什么。让十个 Agent 同时开改，产量会很高，事故概率也会很高。

更可靠的顺序是 coordinator 先产出迁移清单和验收条件，再把互不重叠的模块拆出去。涉及共享接口和数据迁移的部分，宁可排队。

并行不是目标。

可控地并行才是。

共享上下文不能再等同于无限聊天记录

Cursor 的第二个设计，比数千个子 Agent 更有工程味。每个 Project 维护一组会同步到云端与本地机器的文件。Agent 会把研究结果、产物、对代码库的理解，以及用户偏好写进去。后来接手的 Agent 不必从头猜测试怎么跑、命名有什么约定、上次为什么否掉某个方案。

这是 Agent 长任务里最常被低估的一层。

不少系统把 memory 理解成把所有聊天记录塞进向量库，再在每轮召回几段。它有用，但不够。聊天记录是一种过程痕迹，不是一份可执行的项目状态。你把一个月的讨论全找回来，仍然可能不知道当前决策是什么，哪些假设已被推翻，哪个 PR 是最后可信的基线。

我更愿意把长期上下文分成四类。

第一类是稳定约束。比如仓库如何启动、Java 版本、代码风格、哪些目录不能改、生产操作必须经过什么审批。这类信息变化不快，应该有明确的文件和所有权。

第二类是任务状态。目标、范围、待办、阻塞项、依赖和下一个动作。它不必写得像日报，但每次工作结束都得能让下一位接手者在两分钟内知道现场。

第三类是证据。测试命令及结果、关键日志、可复现步骤、外部文档链接、人工确认过的截图。没有证据的「已经修好了」，在 Agent 系统里基本等于没说。

第四类才是可检索的过程记忆。失败尝试、探索路线、相似问题。它适合按需召回，不应该和当前指令抢上下文窗口。

你会发现，这套分层和正常的工程项目并没有区别。区别只是过去由人自觉维护，现在必须被工作流逼着维护。

一个很好用的判断标准是，关掉所有聊天窗口后，一个新 Agent 能不能只靠项目目录继续推进。如果不能，系统拥有的不是项目记忆，只是一段很长的对话。

Cursor 把共享文件放在产品核心，我觉得是对的。但这件事也有明显局限。上下文会增长，错误也会增长。一个未经核验的结论被写进共享记忆，后面几十个 Agent 都可能把它当事实。共享记忆不是知识库的自动胜利，它需要版本、来源和过期机制。

尤其是架构结论，最好写清三个东西。

结论对应的代码版本或 PR
支撑结论的测试、日志或人工确认
结论何时应当重新验证

没有这三项的记忆，很容易从经验变成传说。

让 Agent 常驻，先把触发器当成生产入口

Projects 还有第三条能力。coordinator 能监听 Slack、观察 PR，或者按计划执行，在发现信号时主动动作。

这正是很多 Agent 从玩具走向系统的分水岭。

一个只会等 prompt 的 Agent，像一把放在抽屉里的电动螺丝刀。它确实好用，但需要有人每次拿出来。一个能接收事件、维护状态、按规则行动的 Agent，才更接近一个服务。

不过这块也是最容易做得别扭的地方。

「自动」不是让 Agent 对每一个事件都动手。Slack 里有人提到 bug，它不该马上改生产代码。CI 红了一次，它也不该连发三十条评论。触发器只是入口，后面还需要去重、优先级、权限和升级规则。

假如要在 Spring 体系里做类似的东西，我会把事件链分成这样。

GitHub Webhook / CI 结果 / Slack 指令
            ↓
        Event Router
            ↓
   幂等校验 + 策略判断 + 风险分级
            ↓
     Project State + Task Queue
            ↓
 Coordinator 生成或更新工作包
            ↓
 Worker Agents 执行受限工具调用
            ↓
   Evidence Store + 人工验收 + 回写状态

关键不在图画得多漂亮，而在每一层都要能停下来。

Event Router 要能丢掉重复 Webhook。策略层要能把「格式检查失败」和「支付链路告警」分到不同队列。Worker Agent 的 shell、数据库和部署权限不能跟 coordinator 一样大。Evidence Store 要留住可验证的输出，而不是只存一段自然语言总结。涉及生产的动作，默认应该停在待批准状态。

这套设计会让第一天的 Demo 变慢。

但它会让第九十天的系统还可解释、可排错、可收回。