Cursor 发布 Agent SDK：编辑器变成 Agent 的分发渠道

Cursor 这周发布了 Agent SDK，把自己那套编码智能体的循环开放给第三方产品调用。这件事在纸面上很小，在含义上很大：Cursor 卖了两年更好的 IDE，现在开始卖 IDE 里面那个东西。

SDK 给的是什么

把你的任务和代码库上下文交给它，它规划、改文件、跑命令、回报结果——和编辑器里的体验同形，只是去掉了键盘前的人。区别在于触发者：不再由开发者在侧边栏里提问，而是你的产品去调它，比如客服机器人改一段配置、CI 任务修一个 lint 失败、内部工具重构一个模块。

为什么现在做

IDE 是个有天花板的生意，规模取决于有多少开发者愿意在里面打字，这个数字被习惯、采购和键位学习成本锁住。SDK 的规模取决于有多少产品调用它，这个上限高得多。把这个动作理解成「放弃编辑器」是错的，它只是承认编辑器一直是 Agent 的分发渠道，而这个渠道比市场窄。

真正要自己扛的部分

编辑器里人会在几秒内打断失控的循环，SDK 调用里没人看着，除非你建了这套观察。所以工程重点不在 Agent 有多聪明，而在把它当成不可信进程对待：超时、输出上限、不依赖 Agent 自己判断成功与否的回滚路径。官方给的示例都共享一个性质——任务边界窄。改配置不需要理解产品，修 lint 不需要做架构，重构一个模块以模块为界。把示例当作用例清单读是误读，应当当作范围规范读。

没人回答的那个问题

Cursor 一直是按席位计价，SDK 换了计价单位：从按开发者付费变成按调用付费，而调用量跟你的用户数走。官方还没公布能让团队拿去建表的单次调用价格，所以第一批尝鲜的团队，实际上是在替行业试出这个数字。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

SDK 调用里没人在几秒内打断失控循环，这才是真正的工程难点。超时、输出上限、不依赖 Agent 自己判断成功与否的回滚，这三样比模型能力更决定线上表现。

这个 SDK 真正的变量不是能力，是责任边界。产品去调它改配置、修 lint，改坏了算谁的。我关心三点：能不能只给最小范围的代码库上下文，每次改动有没有结构化日志可回溯，单次调用的成本和延迟上限在哪。这三点不清楚，把它塞进 CI 我是不敢的。

从卖 IDE 到卖 IDE 里那个循环，这个转向很聪明，但成本结构也换了：以前按人头收订阅，现在按任务消耗算力。真正要评估的是失败重试的成本，Agent 跑偏一次可能烧掉几十轮上下文，没有预算上限和中断策略的话，月底账单会比预期难控得多。