Cursor 发布 Agent SDK：代码智能体开始走出 IDE

Cursor 今天（2026 年 10 月 28 日）正式发布 Agent SDK，把用于构建 Bugbot、安全审查智能体和 Rollouts 等内部产品的框架开放给开发者。团队可以用代码定义智能体，在本地迭代和执行评估，再通过一条 agent-sdk deploy 命令部署到 Cursor 的基础设施上。

Agent SDK 是一套用于定义、测试、部署和维护代码智能体的软件开发框架。 它解决的不是“如何再做一个聊天机器人”，而是如何让智能体接入代码仓库、Pull Request、合规审查和故障处理等真实工程流程，并在事件发生后持续、自动地工作。

这次更新真正值得关注的地方，是 Cursor 开始把自己从 AI 编辑器变成代码智能体平台。IDE 仍然是 Cursor 获取用户和理解开发流程的入口，但 Agent SDK 要争夺的是更靠近企业基础设施的一层：谁来运行智能体、隔离执行环境、管理工作流，以及把智能体生成的修改安全地送进代码仓库。

开放的不是提示词，而是 Agent Harness

Agent Harness 是包裹在大模型外部、负责工具调用、上下文管理、任务执行和结果交付的运行框架。 模型可以提出“修改鉴权逻辑”的方案，但真正让它完成任务的，是仓库克隆、代码检索、终端执行、测试验证、失败重试、权限控制和 PR 创建等一整套机制。

Cursor 这次开放的核心正是这层 Harness，而不只是一个模型对话接口。根据 Cursor 官方博客，Agent SDK 已经被用于构建其自有的 Bugbot、安全审查智能体和 Rollouts，这意味着它并非单纯为了发布而临时拼出的实验项目，而是从现有产品中抽取出来的框架。

这一差异决定了 Agent SDK 的实际价值。直接调用一个大模型并不难，难的是让智能体在大型代码库里连续工作几十分钟，期间正确读取文件、执行命令、处理测试失败，并最终留下可审查的代码变更。对企业团队而言，模型回答得是否漂亮只是第一关，任务能否稳定完成、过程是否可追踪、权限是否可收敛才是生产环境的门槛。

Cursor 给出的产品路径相当直接：开发者可以从模板开始，也可以让编程智能体阅读 Agent SDK 文档并协助搭建机器人；智能体定义完成后，可在本地迭代并运行评估，最后部署到 Cursor 托管环境。换句话说，它试图把智能体当成普通软件项目来管理，而不是把一段提示词藏在某个自动化平台的配置页里。

Agent SDK 和此前的 Cursor SDK 不是一回事

Agent SDK 的重点是事件驱动的托管智能体，而此前 Cursor SDK 更侧重把 Cursor 的编码运行时嵌入开发者自己的程序。 两者技术能力存在延续关系，但产品重心已经从“调用一次代码智能体”转向“长期运行一组与团队流程绑定的智能体”。

Cursor 在 2026 年 4 月公开测试 TypeScript SDK 时，已经允许开发者在 IDE 之外驱动其编码智能体，并选择本地工作区或云端环境执行任务。此次正式发布 Agent SDK，则进一步把策略定义、评估和部署串进同一个工程生命周期，并明确强调 PR 审查、合规工作流和事故排查等持续性场景。

| 对比维度 | 早期 Cursor SDK | 本次 Agent SDK | |---|---|---| | 核心定位 | 在外部程序中调用 Cursor 编码智能体 | 用代码构建和托管团队专属智能体 | | 主要交互 | 开发者主动发起编码任务 | 由 PR、审查、事故等事件触发 | | 生命周期 | 创建任务、执行、获取结果 | 定义、迭代、评估、部署、持续运行 | | 运行位置 | 本地工作区或 Cursor 云端环境 | 本地开发，部署到 Cursor 基础设施 | | 典型产物 | 代码修改、任务结果、PR | 长期运行的审查、合规或运维机器人 | | 官方案例 | 通用编码任务 | Bugbot、安全审查智能体、Rollouts | | 部署方式 | 由应用自行集成和调度 | 使用 agent-sdk deploy 部署 | | 当前定价 | 需依据当时产品方案确认 | 官方公告未披露独立价格 |

这个变化看起来只是多了一个 deploy 命令，实际却跨过了产品边界。一次性的 Agent 调用更像函数，事件驱动且长期运行的 Agent 则更像服务；前者主要考验模型和工具调用，后者还必须处理版本、评估、故障、权限和运维。

最有用的场景，不是“替我写代码”

Agent SDK 最适合规则明确、重复频繁、结果可以验证的工程任务。 让智能体独立决定一套复杂系统的架构仍然风险很高，但让它检查每个 PR 是否违反内部规范、定位测试失败原因，或者为依赖升级准备修改，则更容易形成可靠闭环。

PR 审查是最直接的落地场景。Bugbot 已经证明 Cursor 希望把代码审查做成编辑器之外的持续服务，而团队自建智能体可以进一步加入内部规则，例如检查某类接口是否缺少鉴权、数据库迁移是否具备回滚路径、日志中是否包含敏感字段，以及新模块是否补齐了测试。

合规工作流是更有企业价值的场景。通用审查产品通常只能覆盖公开最佳实践，但不同企业对许可证、依赖来源、数据访问和审批顺序的要求并不相同。Agent SDK 允许团队把这些策略写进可检查、可修改的项目中，至少在产品设计上，比把规则散落在提示词、CI 脚本和人工检查表里更容易维护。

事故排查是更难但潜力更大的场景。智能体可以在告警发生后收集相关提交、检查近期配置变化、运行诊断命令并整理可能原因，但生产环境中的自动修改必须保持克制。更合理的第一阶段不是让 Agent 直接修复线上系统，而是让它生成调查报告、建议补丁和待执行步骤，由值班工程师确认后继续。

以下几类任务尤其适合先行接入：

• 为每个 PR 执行团队定制的安全与合规检查；
• 自动分析 CI 失败，并判断是代码缺陷、环境波动还是测试不稳定；
• 根据依赖漏洞公告定位受影响模块，生成升级方案和候选补丁；
• 在事故发生后关联近期提交、配置变更与日志线索；
• 对照内部工程规范检查新服务是否补齐监控、测试和文档；
• 处理格式迁移、弃用接口替换等可批量验证的维护任务。

这些场景的共同点是“完成标准可以被机器检查”。如果智能体修改后能够通过编译、测试、静态分析和策略校验，它就有机会成为稳定的自动化节点；如果任务只能依赖模糊的主观判断，Agent SDK 再完整也无法消除模型的不确定性。

Cursor 正面进入智能体基础设施竞争

代码智能体基础设施正在成为模型之上的新竞争层。 当不同厂商的模型都能完成代码生成、仓库检索和工具调用时，开发者最终比较的不只是基准测试分数，还包括智能体能否稳定运行、能否接入现有流程，以及出了问题是否容易定位。

| 产品或框架 | 主要定位 | 代码仓库执行 | 托管部署 | 事件驱动工作流 | 差异化重点 | |---|---|---:|---:|---:|---| | Cursor Agent SDK | 面向软件团队的代码智能体框架 | 是 | 是，部署到 Cursor 基础设施 | 是 | Cursor 编码运行时与现有产品经验 | | Claude Agent SDK | 基于 Claude 工具使用能力构建智能体 | 是 | 通常由开发者自行设计部署方案 | 可自行实现 | Claude 模型及其工具调用生态 | | OpenAI Agents SDK | 通用智能体编排与观测框架 | 可通过工具接入 | 通常由开发者选择运行环境 | 可自行实现 | 多智能体编排、工具与追踪 | | Vercel AI SDK | 面向 TypeScript 应用的 AI 开发工具包 | 需开发者接入 | 可结合应用部署平台 | 需开发者实现 | Web 应用、流式交互与前端集成 |

这张表的关键不在于谁“功能最多”，而在于各家抽象的层级不同。OpenAI Agents SDK 更接近通用智能体编排，Vercel AI SDK 更靠近应用开发，Claude Agent SDK 强调让 Claude 使用计算机和开发工具；Cursor 则从代码仓库和软件团队流程切入，尝试把运行环境、编码能力和托管部署打包提供。

Cursor 的优势是它拥有真实的代码工作流数据和成熟产品入口。大量开发者已经在 Cursor 编辑器中完成代码检索、修改、测试和调试，这些使用经验可以反过来帮助其优化 Agent Harness。相比从通用聊天场景进入编码市场的厂商，Cursor 更了解一次编码任务在哪些环节容易失败。

Cursor 的劣势同样明显：平台越完整，团队对其基础设施的依赖越深。智能体定义虽然由团队掌握，但执行环境、部署方式和部分运行能力仍与 Cursor 绑定。对有严格数据驻留要求、必须在内网运行，或者已经建设自有 Agent 平台的大型企业来说，这种便利是否值得平台依赖，需要单独评估。

一条部署命令背后，是更复杂的生产责任

agent-sdk deploy 降低的是部署操作复杂度，而不是生产风险。 一个可以读取私有仓库、执行终端命令并提交代码的智能体，本质上拥有接近初级工程师的操作权限，同时又缺少人类对组织背景和异常情况的完整理解。

权限边界将是团队接入前必须确认的第一件事。智能体是否只能读取指定仓库，是否可以访问密钥，是否能向受保护分支写入，是否能够触发生产部署，以及它创建的 PR 是否必须经过人工批准，都不应由默认配置决定。

评估体系将是决定智能体能否长期使用的第二件事。Agent SDK 支持本地迭代和运行评估，这是此次发布中容易被忽略但十分重要的能力。团队需要用历史 PR、已知漏洞和真实故障案例建立测试集，测量任务成功率、误报率、平均执行时间和人工返工比例，而不是只看几次演示是否成功。

成本控制将是第三个现实问题。Cursor 在本次公告中没有披露 Agent SDK 的独立价格、云端执行费用、并发额度或计算资源计费方式，因此目前不能把“正式发布”理解为“可以免费无限运行”。代码智能体通常会长时间占用模型推理、沙箱和仓库计算资源，实际成本可能明显高于一次普通聊天。

可观测性将是第四个生产门槛。团队至少需要知道智能体读取了哪些上下文、执行了哪些命令、为什么修改某个文件、在哪一步失败，以及某次行为对应哪个 Agent 版本。没有完整的执行记录，自动化程度越高，事故发生后的追责和复盘反而越困难。

对开发团队意味着什么

Cursor Agent SDK 值得尝试，但不适合从高权限任务开始。 最合理的接入顺序是先做只读分析，再允许创建候选补丁，之后才考虑自动开启 PR；直接赋予合并代码或操作生产环境的权限，并不是效率提升，而是在放大模型偶发错误的影响范围。

一个相对稳妥的落地路径可以分为四步：

1. 只读阶段： 让智能体分析 PR、CI 失败和事故记录，只输出报告；
2. 建议阶段： 允许智能体生成补丁，但不写入远程仓库；
3. 协作阶段： 允许自动创建 PR，并强制要求人工审查；
4. 自动化阶段： 仅对低风险、可回滚且测试充分的任务开放自动合并。

团队还应把 Agent 定义与普通服务放在同样的工程治理框架下。策略变更需要代码审查，Agent 版本需要可回滚，评估集需要持续更新，运行权限需要定期检查。Cursor 所说的“像管理其他软件项目一样管理智能体”，真正有价值的部分不是代码形式本身，而是让智能体接受版本控制、测试和发布流程的约束。

Cursor 不想只做 AI 编辑器

Agent SDK 标志着 Cursor 正在把核心资产从编辑器体验扩展为代码智能体运行平台。 如果说早期 Cursor 的竞争对象主要是 GitHub Copilot 和其他 AI IDE，那么 Agent SDK 面对的竞争对手已经包括通用 Agent 框架、云端沙箱、CI 自动化平台和企业内部开发者平台。

这一步的商业逻辑并不复杂。模型能力会持续趋同，编辑器功能也容易被大型平台追赶，但一套能在大型代码库上稳定运行、被企业流程长期依赖的 Harness 更难替换。只要越来越多的审查、维护和故障处理机器人部署在 Cursor 基础设施上，Cursor 就不再只是开发者每天打开的工具，而会成为软件生产链中的常驻服务。

不过，Agent SDK 目前仍有几个关键问题没有在公告中得到量化回答，包括独立定价、并发限制、支持的事件源、数据保留策略、企业审计能力和私有化选择。对于准备正式接入的团队，这些信息的重要性不低于模型效果，甚至会直接决定产品能否通过安全与合规审查。

Cursor 这次发布的方向是对的，而且比再增加一个编辑器按钮更有战略价值。它让开发者第一次可以较完整地复用 Cursor 构建 Bugbot 等产品时积累的运行框架，但真正的考验将从演示结束后开始：智能体是否能在数百次真实任务中保持稳定，以及 Cursor 能否给企业足够透明的权限、成本和审计控制。

参考来源

• Cursor 开放自用框架，一天造出智能体后，长期维护靠什么？ — 对 Agent SDK 的定义、评估、部署和长期维护方式进行了中文梳理。