把 agent 当成代码项目来交付
10 月 20 日，Cursor 在官方 Changelog 与博客中宣布 Agent SDK 正式可用（generally available）。它要解决的核心问题很具体：团队里已经有人在拿 AI 智能体做代码审查、修 PR、分流工单，但这些能力大多停留在聊天窗口里，难以复用、难以测试、更难一致地上线。Agent SDK 的思路是反过来——把一个 agent 定义成一个普通的代码文件夹，让它像应用一样被版本化、被测试、被部署。
在这个模型里，instructions.md 就是提示词，tools/ 目录下的每个文件是一项带类型的动作，skills/ 存放模型按需加载的流程，mcp-connections/ 把外部 MCP server 的工具接进来，channels/ 定义这个 bot 从哪些入口收消息、往哪些出口回消息。开发者跑一次 agent-sdk validate 检查项目结构，再用 agent-sdk info 打印被识别到的能力，一个 agent 就从一段对话，变成了一份可审阅、可提交、可回滚的源码。
agent 长在哪、怎么被调到
Agent SDK 的第二个看点，是它把 agent 接进了开发者已经在用的协作与运维通道。agent 可以被挂在 GitHub、GitLab、Bitbucket 的 Pull Request、评论与 CI 事件上，挂在 Slack 的提及与私信上，挂在任意 provider 的 webhook 上，也可以按 cron 定时触发。一个细节很关键：GitHub 事件经由用户的 Cursor 账号拉取，因此不需要对外暴露公网 webhook 地址，这降低了把 agent 接到代码仓库时的攻击面。
每一轮对话都会保留自己的独立会话，以及完整的消息与工具调用记录；在 PR 或 Slack 线程上的后续追问，会自动续接同一个会话，而不是从头开始。对工程团队来说，这意味着 agent 不再是一次性的问答，而是一个有状态、可追溯的长期工人——它可以记得上次修到哪一步，也能把每一步动作摊开给人审计。
测试与部署：本地和云端同一套
可测试、可上线，是 Agent SDK 区别于随手写脚本的地方。agent-sdk eval 会向 bot 发送一条固定消息，并断言它做了什么：跑了哪些工具、输入是什么、回复长什么样。开发者既可以在本地 CI 里跑 eval，也可以在本地用 playground 调试。更进一步，agent-sdk github replay 能把一个真实的 PR 重放成带签名的 webhook 载荷发给 bot，让基于 GitHub 事件的 bot 不必等真实推送就能被测到。
部署时，agent-sdk deploy 会从项目目录构建 agent、给它一个 URL，并运行在 Cursor 的基础设施上；密钥与第三方集成在控制台里管理，本地用过的日志、eval 与 playground 在云端同样可用。Cursor 同时给出了一批开箱模板：安全审查员、owner 策略审批人、PR 自动修复器、Linear 或 Jira 分流器，团队可以从这些起点改起，而不是从空白开始。
为什么值得关注：开发者工具进入 agent 运维阶段
过去两年，Copilot 类工具把「写代码」自动化了；Agent SDK 这类 SDK 的意义在于把「运营 agent」也工程化了。当 agent 能长在各种协作与定时通道上、能像服务一样被部署和监控，开发团队的瓶颈就从「怎么让模型写出初稿」转向「怎么让一批 agent 稳定、可观测、可审计地持续运行」。这也呼应了同周 GitHub Octoverse 2026 里那组数字——由 AI 编码智能体初稿启动的 PR 已超 40%，真正的约束正在变成评审与质量闸门。
从生态位看，Cursor 把自家编辑器里的 agent 能力往外扩了一层：它不再只是 IDE 里的补全，而是一套可以部署到自家基础设施、也能接第三方 MCP 的智能体运行时。对想把 agent 嵌进内部流程、又不愿被单一闭源平台锁死的团队，这种 agents-as-code 的形态，大概率会成为接下来开发者工具的标准件之一。