Cursor 把造 agent 的工序做成了产品

过去两年，团队造 agent 的方式大概是：找一个低代码面板，配提示词，接几个 webhook，然后在某个没人记得的账号里，堆出一坨没有版本号的东西。

Cursor 想把这件事拉回到代码仓库里。

一、发生了什么

Cursor 正式开放了 Agent SDK。这不是新造的工具，而是它自己做 Bugbot、安全审查、Rollouts 这几款托管 agent 时用的那套框架。

一个 agent 在 SDK 里就是一个文件夹：常驻指令写在 Markdown 里，工具是 TypeScript 函数，另外还有按需加载的技能、MCP 连接、子 agent、HTTP 入口、只读事件订阅和定时任务。因为全是文件，改动可以走和其他代码一样的评审与版本管理。

它能响应的事件包括 GitHub、GitLab、Bitbucket 的 PR，Slack 的提及和私信，自定义 webhook，以及 cron 定时。遇到复杂任务，可以把活交给另一个带独立工具的 agent，也可以拆给多个子 agent 并行跑。

部署是一条命令，构建后拿到一个 URL，跑在 Cursor 的托管环境里；也可以自己托管，每个 agent 是单个 Node 进程，塞进容器就能跑。密钥和集成在面板里管，本地的日志、评测和调试台与线上一致。

官方给的例子很具体：内部有个团队攒了一大堆经验笔记，希望每个 PR 都对着笔记检查一遍，用 SDK 大约一天做出来，现在跑在主库的每个 PR 上，指出和既有结论冲突的改动，并标注依据的是哪条笔记。PGA Tour 是公开的客户，用它搭所谓"软件开发工厂"。

二、跟你有什么关系

中大型研发团队，价值在"可评审"。以前 agent 行为藏在面板里，出问题只能靠截图复现；现在提示词、工具、测试用例都在仓库里，能 diff、能回滚。

平台/效能团队，这是把重复劳动产品化的捷径：PR 分派、安全审查、CI 修复、工单分流，都有现成模板可以改。

个人开发者，先别急着上。它的收益来自"团队有稳定的重复流程"，一个人维护三五个 agent 的评测集，成本可能高于收益。

三、怎么用

1. 从一个真实痛点起步。选那种每周都要重复、且标准明确的活，比如"PR 改动是否触碰了某类禁区"。
2. 先写指令和工具，再谈部署。工具函数的返回结构定清楚，后面评测才有得测。
3. 建评测集。把过去二十个真实案例做成输入，跑之前先跑一遍，确认基线。
4. 用事件回放查失败。线上跑挂了，回放当时的输入，比看日志猜快得多。
5. 部署前决定托管还是自建。涉及内部网络和合规的，单进程容器自托管更省事。

四、三个别信的说法

「内置评测说明它效果有保证。」 这里的评测是给你自己的 agent 做的回归测试，不是对外可比的能力榜单。它衡量的是"你改完有没有变差"，不是"它有多强"。

「一条命令部署，就等于不用管运维。」 托管省了机器，没省权限设计和成本监控。agent 跑在 PR 上是会烧 token 的，触发条件不收紧，账单会先提醒你。

「模板开箱即用。」 模板解决的是骨架问题。真正决定它有没有用的，是你们团队自己的规则写得够不够清楚。

五、一句话结论

它真正卖的不是 agent，是"把 agent 当软件来管"的那套工序——这大概是今年工具链里最不性感、但最耐用的一步。

信息来源

• Cursor 官方博客：Introducing the Agent SDK（2026 年 10 月）

功能与价格以官方公告为准。本文写于 2026 年 10 月 31 日。