Cursor 的 Slack、Teams、Jira、Linear 四种集成怎么选：各自把入口开在哪
如果你的团队打算让 Cursor 从聊天工具或工单系统里接活，摆在面前的是四个看起来差不多的集成：Slack、Microsoft Teams、Jira、Linear。四页官方文档的开头几乎一个模子——mention @Cursor 加一句话，启动一个 Cloud Agent。真正的差别不在这句话，而在入口开在哪、发起时能把话说到多细、状态怎么回到你面前、以及追问会在哪一步断掉。
下面只对照 cursor.com/docs/integrations/ 下这四页都白纸黑字写明的维度。有一方文档里查不到的，我会直接说不比，不去猜。
第一道闸：装不装得上，先看门槛
选型往往在这一步就被砍掉一半，所以先说这个。
Jira 的前置条件是四页里写得最长的。官方文档《Jira》页的 Requirements 一节列明：需要 Jira Commercial Cloud 且启用 Rovo、需要目标 Jira 站点的 admin 权限、需要 Cursor 团队的 admin 权限、需要已经把 GitHub、GitLab、Azure DevOps 或 Bitbucket 之一接到 Cursor。同一页还写明两条限制：该集成目前仅在 Cursor Teams 与 Enterprise 计划可用；Atlassian HIPAA 与 FedRAMP（含 Government Cloud）实例不受支持。FAQ 里再补一句，初始安装得由一个同时是 Jira admin 和 Cursor team admin 的人来做。
Linear 页写明连接集成需要 Cursor admin，其它团队设置非 admin 成员也能用。Slack 与 Microsoft Teams 两页的安装步骤里没有写明谁有资格安装——这一点我们在文档里没有找到对应说明，不比。
四页的收尾步骤大体相同：连好仓库提供方、启用 usage-based pricing、确认隐私设置；Jira 页比其它三页多一条——在 Cursor Dashboard 的 Cloud Agents 设置里先选好默认仓库、模型与基础分支。Jira 页 FAQ 把它说得最直白——Cloud Agents 需要 usage-based billing。这是能力开关，不是价格问题，本文不涉及任何金额。
结论很直接：如果你在受管制行业用 Atlassian 的合规实例，Jira 这条路文档明说不支持，别在它上面花时间。
入口形状：只能 mention，还是能”指派”
这是四者最结构性的差别。
- Slack / Microsoft Teams：只有 mention 这一种起手式。Slack 页的命令表列了五条（发起、
@Cursor settings、带选项发起、@Cursor agent、@Cursor list my agents），Teams 页的命令表同样五条，但内容不同——它有@Cursor help、@Cursor unlink、@Cursor disconnect，没有 settings 和列出 agent 的命令（@Cursor help两页正文其实都提到了，只是只有 Teams 把它写进了命令表）。 - Jira / Linear：两个入口。既可以在评论里
@Cursor，也可以直接把工作项 / issue 的 assignee 字段指给 Cursor。文档给的用法差异也很清楚：Jira 页说，工单本身已经把事情描述清楚时用指派，需要额外交代时用评论 mention。
Linear 还多一层：《Linear》页的 Triage rules 一节说明，可以在 Linear 项目设置里配自动化规则，按条件自动打标签、把 issue 指给 Cursor、触发 Cloud Agent。但这一节被官方标注为 Advanced 且有当前限制——文档写明 Linear 要求规则必须有一个人类 assignee 才会触发，并说这个要求未来可能移除。要按”未来可能移除”来做排期，风险自己评估。
另外，《Linear》页还写了一句其它三页没有的话：Cursor 会分析 issue 并自动过滤掉非开发类工作。文档只说了这个行为存在，没说判定规则，我们也就到此为止。
发起时能把话说到多细
四页都有一张”选项”表，颗粒度差得很明显。回源数过的行数：
| 集成 | 可用选项 | 数量 |
|---|---|---|
| Slack | repo、env / environment、branch、model、autopr、worker / machine、pool、self_hosted、channel | 9 |
| Microsoft Teams | repo、env / environment、branch、model | 4 |
| Jira | repo、branch、model | 3 |
| Linear | repo、branch、model | 3 |
只有 Slack 那一列写明了执行目标类的选项：worker / machine 指向命名的 My Machine，pool 指向命名的 self-hosted pool，self_hosted=true 走团队的自托管池。也只有 Slack 有 autopr（开关自动建 PR）和 channel（把 agent 更新发到另一个你和 Cursor 都能访问的频道）。这些选项在其余三页里没有对应说明，不比。
语法上有一个真会咬人的差别：Slack、Teams、Jira 三页用的都是裸的 key=value，Linear 用的是方括号 [key=value]。官方文档原样给的例子是这样的——
Slack 页的 inline 写法：
@Cursor env=Platform branch=dev model=opus autopr=false Fix the login bug
Linear 页的写法：
@cursor implement feature [model=claude-3.5-sonnet] [branch=feature-branch]
以上两行原样取自官方文档，没有做任何拼装。其中的模型名只是文档当时的示例值，平台上有哪些模型随时在变，别当清单用。把 Slack 那套裸写法直接搬到 Linear，或者反过来，是最容易犯的错。
Linear 另外有两条其它三页没有的配置通道：issue 标签与项目标签，用父子标签结构，父标签是配置键、子标签是值。文档还特意强调，标签组必须正好叫 repo（大小写不敏感，但不能写成 Repository 之类的变体）。这是那种写错了不会报错、只会默默不生效的地方。
你没说清楚时，它去哪里找仓库
四页都给了仓库选择的优先级链条，但层数和内容都不同：
- Slack（“How routing works”，5 层）：消息内容 → 近期 agent 活动 → 路由规则 → 频道默认 → 默认仓库
- Microsoft Teams（“Routing behavior”，4 层）：显式选项 → 消息内容 → 近期 agent 活动 → 默认仓库
- Jira（5 层）：显式值 → 工作项内容 → 路由规则 → 近期 agent 活动 → 默认仓库
- Linear（4 层）：issue 描述 / 评论里的
[repo=owner/repository]→ issue 标签 → 项目标签 → 默认仓库
两处值得指出来。第一，只有 Slack 和 Jira 写明了 Routing Rules（Dashboard → Cloud Agents 下的关键词到目标的映射）。Slack 页的映射目标除了仓库还可以是一个命名的 cloud agent environment，文档说明环境可以打包多个仓库，因此一个关键词就能带起一整套；Jira 页的映射目标只写了仓库。Teams 与 Linear 两页没有 Routing Rules 一节，不比。
第二，同一页文档内部就有两份不完全一致的清单，这不是我们的推断，是两处并列摆着的文本：Slack 页 Settings 里的”Repository Selection”列了四条，而后面”How routing works”列了五条，多出来的”频道默认”排在第四；Teams 页的”Repository selection”列了三条，而”Routing behavior”列了四条，多出来的”显式选项”排在第一。真要依赖优先级排查问题，以你正在读的那一页的最新内容为准，别拿记忆里的顺序去推。
Slack 还独有频道级默认：@Cursor settings 配置的是团队级、对该频道生效的默认值，会覆盖个人默认，但仍可被消息里显式写的仓库覆盖；文档明确写了频道设置只对公开频道生效。Jira 则分 Team Settings 与 My Settings 两层，且只有 Jira 页写了 Branch prefix（Cloud Agent 建分支时的名字前缀），其余三页没有对应说明。
状态怎么回到你面前
这一段是”回写能力”的正题。四页写明的东西差别很大：
- Slack：运行时先给一个 Open in Cursor 的选项；完成后在 Slack 收到通知，并可查看在 GitHub 上创建的 PR。agent 消息上的上下文菜单（⋯）里有四项：Add follow-up、Delete（停止并归档）、View request ID（联系支持时带上）、Give feedback。此外，权限表里
reactions:write一条写明它会用 emoji 标状态：⏳ 运行中、✅ 完成、❌ 失败；files:write用于上传变更的可视化摘要。 - Microsoft Teams：启动时给一张 launch card，上面带本次选中的仓库、模型、分支；卡片操作共七项：Add follow-up、Switch repository、Delete、Open in Web、Open in Desktop、Update settings、Give feedback。完成时给通知，若开了 PR，卡片上带查看 PR 的入口。
- Jira：工作项上显示 agent 状态，工作过程中持续 post progress，完成时返回 summary；若开了 PR，完成更新里带 PR 链接。
- Linear：在 Linear 里显示实时状态，完成时自动创建 PR，也可以在 Cursor dashboard 里跟踪。
值得单独拎出来的两条：Switch repository 只在 Teams 页写明——把同一个请求换个仓库重跑，这在仓库猜错时很实用，其它三页没有对应说明；View request ID 在 Slack 页写在上下文菜单里，Linear 页则是让你在 agent activity 里找 request ID 再联系支持，两者都能拿到 ID，路径不同。Jira 与 Teams 页没写这一项，不比。
追问会在哪里断掉
这是四者里最容易在真实协作中翻车的一处。
Slack 的规则最细：线程里已经有 agent 时，@Cursor [prompt] 是追加追问而不是新建；谁能追问由 Team follow-ups 设置决定，文档写明该设置为 Disabled 时只有 owner 能追问。想新起一个 agent，得用 @Cursor agent [prompt]，或者用自然语言（文档举例 “create a new agent”、“launch a fresh agent”、“new agent please” 都算）。线程里同时挂着多个 agent 时，用某条回复上的上下文菜单里的 Add follow-up 指定跟哪一个。
Microsoft Teams 有一条硬边界：频道线程里可以在 agent 的线程内再 @Cursor 追问，但在个人聊天与群聊里，文档要求用 Open in Web 或 Open in Desktop 回到 Cursor 继续。也就是说，你在私聊里起的活，追问要换个地方做。
Jira 的追问入口是 Rovo chat——从工作项里打开 Rovo chat 继续对话，或者干脆到 Cursor 里打开这个 Cloud Agent 继续。这里只把文档里两处并排的写法摆出来：Requirements 一节要求「Jira Commercial Cloud with Rovo enabled」，追问一节又把入口落在 Rovo chat 上。文档没有说明这两处的因果关系，我们也不替它补。Linear 最简单：在 agent session 里回复就会作为 follow-up 发过去，或者在评论里 @Cursor 给运行中的 agent 补充指引。
顺带一提，四页里 @Cursor 与 @cursor 的大小写写法本身就不统一（Slack 页正文用 @cursor、表格用 @Cursor，Linear 页的例子用 @cursor）。文档没有说明大小写是否敏感，我们也不替它下结论。
审批材料要多细
要过公司的应用审批，这一项常常比功能更卡人。四页给出的颗粒度是这样的：Slack 页列了一张 Slack scope 表，共 18 条，每条都带用途说明（例如 channels:history 用于读线程历史做上下文、app_mentions:read 用于检测 @提及）；Teams 页列了 6 条 Microsoft 权限并说明用途，同时写明该应用支持个人聊天、团队频道与群聊；Jira 页没有列具体权限项，只写了四条用途，并让你在 Atlassian Marketplace 的权限提示里自己看；Linear 页没有权限章节，不比。
隐私侧三页口径一致：Slack、Teams、Jira 都写明 Cloud Agents 支持 Privacy Mode，而 Privacy Mode (Legacy) 不受支持，原因文档自述是 Cloud Agent 运行期间需要临时的代码存储。Display agent summary（可能包含文件路径或代码片段）的开关在 Slack、Teams 两页都有；Slack 独有一项 Display Agent Summary in External Channels，针对 Slack Connect 跨工作区或含 Guest 等外部成员的频道。Linear 页没有隐私章节，不比。
从你的处境倒推
- 任务本来就写在工单里、你希望”指派”这个动作本身就是触发器 → 走 Jira 或 Linear。先确认 Jira 那串硬门槛（Rovo、双 admin、计划限制、合规实例不支持）你都过得去；过不去就看 Linear。
- 任务是在群聊里吵出来的、需要 agent 读整段讨论 → 走 Slack 或 Teams，两页都写明 agent 会读线程上下文。
- 发起时就要指定跑在自己的机器或自托管池上 → 目前只有 Slack 页写明了
worker/pool/self_hosted这组选项。 - 需要关掉自动建 PR，或把噪音更新引到单独频道 →
autopr与channel也只在 Slack 页写明。 - 仓库经常被选错、你希望能一键换库重跑 → Switch repository 只在 Teams 页写明。
- 要按关键词把工单自动分流到不同仓库 → Routing Rules 只在 Slack 与 Jira 页写明；Linear 用的是标签体系（记住标签组必须正好叫
repo）。 - 团队里大量协作发生在私聊 → 注意 Teams 的私聊 / 群聊追问要回到 Cursor 里做。
还有一个跟这四个不太一样的入口：Cursor 在 Notion 里的集成。《Notion》页明确标注该集成处于 beta，面向持有 Notion Business 或 Enterprise 计划的用户；它需要你在 Notion 里填一把 Cursor User API Key（写配置时一律用 <YOUR_API_KEY> 这类占位，别把真实值贴进任何文档或工单），并且文档写明连接绑定的是个人 API key、访问与活动关联到个人 Cursor 账号而非整个工作区，每个 agent 只能访问你在 Notion 里共享给它的内容、权限按 agent 设定且不继承发起人。它的排查清单里还有一条很实在：在评论里 @ 比在页面正文里 @ 更可靠。beta 阶段的能力边界随时可能变，别按它排关键路径。
最后说一句边界：这四个集成的入口都开在各自的 SaaS 端，官方文档没有区分 Windows 与 macOS / Linux 的操作差异，只有交接那一步会回到本地——Slack 页的 Open in Cursor、Teams 页的 Open in Desktop，都是把会话交回你装了 Cursor 的那台机器。文档没写更多，我们也不补。
本文依据 Cursor 官方文档（cursor.com/docs 与 cursor.com/help）于 2026-08-18 的公开内容整理。
该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现；
我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。
该产品迭代频繁，文中涉及的设置项与命令随版本变动，请以官方文档最新内容为准。
本文不涉及订阅价格、额度与模型清单，相关信息请以官方定价与模型说明页为准。
本文对照的是同一产品内的多种集成形态，依据均为上述官方文档，不对各形态做优劣排名， 选型结论只在官方文档写明的能力边界内成立。
安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。 合规与许可条款请以官方原文与你所在组织的要求为准，本文不构成法律意见。