集成、API 与 SDK
集成、API 与 SDK相关的 Cursor 官方教程中文版。
当团队已经有 issue、PR、工单、监控、内部平台时，需要让 Cursor 接收上下文、提交结果并纳入权限治理。这一组是 Cursor 的扩展层——Slack、GitHub、Linear、Admin API、Dashboard API、Marketplace 和 deeplinks 把 Cursor 接进外部系统。
阅读方式：先看判断和路径，再进入具体章节。Cursor 的资料变化很快，模型、价格、用量和企业策略以官方页面为准。
GitHub 集成
连接 GitHub 工作流。
GitLab 集成
连接 GitLab 工作流。
Slack 集成
从 Slack 触发或跟踪 Cursor 任务。
Linear 集成
连接 Linear issue 和 Cursor Agent。
JetBrains 集成
在 JetBrains 生态里使用 Cursor。
Xcode 集成
在 Xcode/iOS 工作流中使用 Cursor。
TypeScript SDK
Cursor SDK 的 TypeScript 用法。
Deep Links
Cursor deep links 参考。
这组适合什么时候读
集成、API 与 SDK 层适合团队已经有稳定开发流程之后再读。它解决的是“Cursor 如何进入现有系统”，不是第一天入门问题。
典型场景：
- 从 GitHub 或 GitLab PR 触发任务。
- 从 Slack 或 Linear 把讨论变成可执行上下文。
- 用 Admin API 或 Dashboard API 接入组织治理。
- 用 SDK 或 deep links 把 Cursor 接进内部平台。
- 用 Marketplace 管理团队扩展。
接入前检查
任何集成都要先回答：
- 谁可以触发。
- 触发后能访问哪些 repo、issue、PR 或消息。
- 结果回写到哪里。
- 是否会创建任务、评论、提交或修改状态。
- 日志、权限和审计由谁负责。
如果这些问题没答清楚，先不要上线到团队空间。集成入口越方便，越容易把模糊讨论直接变成大范围任务。
SDK 与 deep links 的边界
SDK 和 deep links 适合把 Cursor 嵌进已有工具，但不应该绕开权限治理。内部平台触发 Cursor 任务时，仍然要携带明确的 repo、branch、scope、validation 和 owner。否则只是把 prompt 表单换了一个入口。
官方能力边界
按官方文档，几个关键入口的职责不同：
| 入口 | 官方定位 | 使用边界 |
|---|---|---|
| GitHub app | 连接 repositories，支持 Cloud Agents 和 Bugbot | 需要配置 repo 访问、PR、issues、checks、actions 等权限 |
| Slack | 在 Slack 中 mention @Cursor 启动 Cloud Agent | 要写清 repo、branch、model、autopr 等选项 |
| TypeScript SDK | 通过 @cursor/sdk 从代码里调用 Cursor Agent | public beta，API 可能变化，适合脚本和内部平台 |
| Deep Links | 分享 prompts、commands、rules | 打开后需要用户 review，不会自动执行 |
GitHub 企业环境还涉及 GHES 版本、入站访问、webhook 出站、IP allow list、PrivateLink、Private Service Connect 或 reverse proxy tunnel。团队接入前要把网络路径和权限面列清楚。
Slack 派发要写清
官方 Slack 文档支持自然语言和 inline options，例如指定 repository、model、base branch、autopr=false。因此 Slack prompt 不应该只写“修一下”，建议写成：
@Cursor in backend-api branch=main autopr=false
请修复登录接口的 500 错误。
范围只限 auth service。
完成后跑对应测试，并在结果里说明是否需要开 PR。Slack thread 可以提供上下文，但也可能混入噪音。涉及多个 agent 时，要区分“追加 follow-up”还是用 @Cursor agent 强制创建新 agent。
SDK 接入要控范围
Cursor TypeScript SDK 用 @cursor/sdk 调用同一个 Agent，可以选择 local runtime、Cursor-hosted cloud runtime 或 self-hosted cloud runtime。local 适合 dev scripts 和 CI against a working tree；cloud 适合调用方没有 repo、需要并行 agent、或任务需要在调用方断开后继续运行；self-hosted pool 适合代码、secret、build artifacts 必须留在团队环境里的场景。
SDK 接入前要确认：
CURSOR_API_KEY从安全环境注入，不写进源码。- local runtime 的
cwd是预期工作树。 - cloud runtime 的 repo、starting ref、auto PR 行为明确。
- session env vars 只传短期需要的凭据。
- runs 的 stream、wait、cancel 和 artifact 下载都有日志。
Deep Links 不等于自动化
Deep Links 可以分享 prompt、command 和 rule。官方文档明确说明，用户点击后需要 review 和确认，deeplink 不会自动执行。这一点很重要：它适合知识共享和团队模板分发，不适合绕过审批直接触发任务。
分享前要检查：
- prompt 里没有 API key、password、客户数据或专有代码。
- command 不会误导用户执行破坏性操作。
- rule 不会扩大权限或覆盖团队标准。
- URL 长度没有超过官方限制。
如果要真正自动化，应该走 CLI、Cloud Agent API 或 SDK，而不是依赖 deeplink。
验收方式
集成上线前至少做一次 dry run：
- 用测试 repo 或低风险 issue 触发。
- 确认触发人、repo、branch、权限和模型都符合预期。
- 检查 Cursor 是否创建了预期任务或 PR。
- 检查回写位置：Slack thread、GitHub PR、Linear issue 或内部平台。
- 检查日志、request ID、失败提示和人工接管路径。
这些验收项通过后，再扩大到团队频道、生产 repo 或自动化入口。