Cursor 把内部造 agent 的框架做成 SDK：一个目录、一条 deploy，agent 当软件项目管

Cursor 10 月 20 日发布 Agent SDK，把它自己做 Bugbot、Security Reviewer、Rollouts 用的框架开放出来。agent 按普通软件项目组织：提示词是 Markdown，工具是 TypeScript 函数，评测和事件回放放在同一目录；本地用 playground 调试，执行 agent-sdk deploy 后跑在 Cursor 基础设施上，也可以打包成单个 Node 进程自托管。

它解决的是什么问题

团队想做的 agent 往往和自己的流程绑得很紧：谁的 PR 需要谁审、哪些目录不能动、什么情况下必须升级给人。过去两条路，要么用现成产品去适配别人的流程，要么从零搭一套。Agent SDK 的定位是第三条：把 agent 拆成提示词、工具、连接器和评测几个文件，像普通项目一样进版本控制和代码评审。

一个 agent 就是一个目录

按官方示例，入口用 defineAgent 定义名称、模型和本地工作目录，模型可以带 effort、fast 这类参数。提示词写成 Markdown，工具写成 TypeScript 函数，评测与事件回放和它们放在同一个项目里。这样做的好处很直接：改提示词会留下 diff，改工具要过测试，出了事故可以用同一段事件重放。

import { defineAgent } from "@cursor/agent-sdk";

export default defineAgent({
  name: "pr-reviewer",
  model: { id: "composer-2.5", params: [{ id: "effort", value: "high" }] },
  local: { cwd: "./.work" },
});

部署与运行

在项目目录执行 agent-sdk deploy，SDK 会构建 agent、分配一个 URL，并把它跑在 Cursor 的基础设施上；密钥和集成在控制台管理，本地用的日志、评测和 playground 继续可用。不想托管也可以自托管：每个 agent 是一个 Node 进程，可以打进容器。对需要把代码留在内网的团队，这一点比托管本身更重要。

一个可核对的内部案例

Cursor 自己的一个团队维护着一份不断增长的「踩坑经验」知识库，希望每个 PR 都对照检查。用 Agent SDK 做的 kb-reviewer 大约一天完成，现在跑在主代码库的每个 PR 上，标出与既有经验冲突的改动，并引用对应的那条记录。这个案例说明 SDK 擅长的不是「通用编程」，而是把团队已有的、写得出来的规则变成每次都会执行的检查。

该不该现在上

适合的场景有三个共同点：事件源明确、判断标准能写成文字、错了可以回滚。反过来，如果需求本身还在变、或者「做得好不好」只能靠人感觉，先别急着上 agent，先把验收标准补出来。SDK 提供的是工程外壳，不会替你想清楚流程。

agent 能不能进生产，不取决于它会不会写代码，而取决于出错时你能不能重放、定位、回滚。