Cursor Agent SDK发布：用代码构建自有AI代理

Cursor 正式开放了 Agent SDK——这正是它用来构建自家 BackBot 等智能体的同一套框架。按照官方演示，Agent 可以对 pull request 或故障等事件做出反应，开发者现在可以用它搭建属于自己的自动化代理。

Agent 即代码：Markdown 写指令，TypeScript 写工具

据 YouTube 频道对该 SDK 的解读，Agent SDK 的核心设计是「Agent 即代码」。开发者用 Markdown 编写指令，用 TypeScript 函数定义工具，代理的每一处改动都像普通代码一样进入 Git 审查流程。

这种设计带来的直接好处是可追溯、可评审。代理行为不再是藏在某个黑盒配置里的玄学，而是可以 diff、可以 code review 的工程产物。对于需要合规审计的团队，这一点比功能本身更有价值。

「Agent 即代码」（Agent-as-Code）借鉴了基础设施即代码（IaC）的思路：把智能体的系统提示词、工具定义、触发条件等全部以文本形式纳入版本控制，而不是依赖可视化配置面板或云端数据库中的隐藏状态。这样做的好处是，提示词的每次调整都能通过 diff 看出具体改动了哪句话，工具函数的签名变化也能在 code review 中被同事质疑。对多环境部署而言，同一份代码可以在测试与生产环境复现完全一致的代理行为，避免「本地能跑、线上失灵」的漂移问题。

一条命令完成部署

SDK 提供了 agent sdk deploy 命令：自动构建代理、分配 URL，并托管在 Cursor 侧运行。如果不想依赖托管环境，也可以把代理作为单个 Node 进程跑在容器里，部署方式相对灵活。

这种「托管 + 自托管」双轨的思路，降低了从原型到上线的摩擦。团队可以先在 Cursor 侧快速验证，再迁移到自有基础设施。

把代理作为单个 Node 进程运行，意味着它本质上是一个长驻服务：监听事件、调用模型、执行工具、返回结果。相比无服务器函数，单进程模型在冷启动延迟和状态保持上更有优势，但需要自行处理进程守护、日志采集与水平扩展。容器化则让团队可以把代理纳入现有的 Kubernetes 或 ECS 编排体系，复用既有的监控告警与滚动发布流程。托管模式省去了这些运维工作，代价是对运行环境的可控性下降，尤其在需要访问内网系统或敏感数据时，自托管往往是合规上的硬性要求。

真实案例：一天写出代码评审机器人

据该视频介绍，Cursor 内部一个团队用大约一天时间构建了一个代码评审代理：它检查每一个 pull request，并基于知识库给出意见，还会引用所依据的笔记出处。

这提示了一个务实的方向：与其追求通用智能体，不如先做贴合团队规则的垂直 bot。代码评审、告警分诊、PR 摘要这类高频、规则明确的任务，正是知识库 + 引用机制的用武之地。官方还提到 PGA Tour 已在使用 Agent SDK。

带引用的知识库问答（retrieval-augmented generation，RAG）是这类评审代理的技术底座：先把团队文档、规范、历史讨论切块并向量化存入索引，代理在评审时检索相关片段，再让模型基于片段生成意见并标注来源。引用机制的价值在于可验证——评审者能点开链接确认依据是否成立，而不是盲信模型输出。这也解释了为什么垂直场景比通用代理更快落地：知识库边界清晰、评判标准明确，模型出错时容易被人工发现和纠正。

需要警惕的信息缺口

视频作者也点出了两点保留意见。其一，相关介绍中没有提及任何定价信息；其二，示例主要来自 Cursor 自身，目前尚无独立的第三方测试。

在选型阶段，这意味着实际稳定性、事件触发延迟、知识库规模上限等关键指标仍缺乏外部验证。建议先在非关键流程中小范围试用，再决定是否接入核心工作流。

据该视频，Agent SDK 目前已对所有人开放。对于想从「用 AI」转向「造 AI 工具」的开发者，门槛正在明显降低——先从一个贴合你自己规则的评审 bot 开始，或许是成本最低的切入方式。