问题
在多仓库代码库的组织中，使用 Cursor 云端 Agent 的开发者发现它无法向组织内任意仓库提交 PR 并跟进评审反馈，而 Claude Code 可以做到。有团队负责人反映「About half my team refuse to switch because of the multi-repo limitations」，多仓库限制已直接阻碍工具迁移决策。现有 workaround 是给 agent 配 GITHUB_TOKEN 让它回退用 gh 命令行提交 PR，但「agent 的内置提示词拒绝使用 gh 提交 PR」，绕路也走不通。痛点核心：跨仓库提 PR + 评审反馈闭环（订阅 PR 事件、自动响应 reviewer 意见）在 Cursor 云端 Agent 中缺失。
目标用户
在多个 GitHub 仓库上工作、正在评估或已使用云端编码 Agent 的开发团队及其负责人。从信号看是被 Cursor 多仓库限制卡住的现有用户，属于明确的痛点人群，但信号量少（仅 2 条、互动低），市场规模只能定性判断为「中等偏小的开发者细分」。
解决方案
- 组织内仓库发现：输入任务后自动在 GitHub 组织内检索、定位目标仓库并 clone
- 跨仓库提交流程：开分支、改码、push、创建 PR，全流程 Agent 自主完成
- 评审事件订阅：通过 GitHub webhook 监听 PR 上的 review comment、approve、request changes
- 反馈自动跟进：LLM 解析评审意见，转化为修改任务，迭代 commit 直到评审通过或需要人工介入
AI 角色：任务理解与仓库检索、代码修改生成、评审评论的语义解析与后续行动规划。
为什么是现在
云端编码 Agent 在 2026 年快速成熟，信号中 Claude Code 已证明「跨仓库提交 PR + 订阅事件 + 自动跟进评审反馈」的技术路径可行，说明能力门槛刚刚降到可复现的水平；同时 Cursor 用户因多仓库限制而流失（团队一半人拒绝切换），形成了工具切换期的空档。
MVP 范围
第一版：以 GitHub App 形式接入单一组织，接收任务描述后自动定位仓库、克隆、开分支、提交 PR，并通过 webhook 订阅 PR 评审评论，把「需要修改」的评论转成新任务让 Agent 迭代再推 commit。明确不做：跨组织仓库、非 GitHub 平台、不试图修改或包装 Cursor 本身、不做代码审查本身的质量判断。
风险
平台依赖：深度绑定 GitHub API 与 webhook，接口变更或限流直接影响核心功能。 巨头风险（最大）：需求本身发在 Cursor 官方论坛，属于其路线图可轻松补齐的功能；且信号显示 Claude Code 已实现该能力，产品价值窗口可能很短。 可靠性风险：Agent 自动响应评审反馈并改码，出错时可能污染仓库历史，需要严格的权限隔离与 dry-run 机制。 需求验证不足：仅两条论坛信号、互动量低、无付费意愿，真实市场规模未经验证。
已有产品
| 产品 | 定位 | 价格 |
|---|---|---|
| Cursor | 被请求补齐该功能的现有工具，其官方论坛即需求来源，随时可能自行实现该能力 | — |
| Claude Code | 信号中已能跨仓库提交 PR 并跟进评审反馈的云端编码 Agent，是用户对比时的替代选择 | — |
信号证据
这张卡片依据的原始讨论。摘录保持原文，点“原文”查看上下文。
Cursor 论坛 · Ideas9月30日功能请求▲ 0
“About half my team refuse to switch because of the multi-repo limitations you confirmed.”
Cursor 云端智能体无法向组织内任意仓库提交 PR，多仓库场景受限，导致部分团队成员拒绝切换工具。原文
Cursor 论坛 · Ideas9月30日功能请求▲ 12 条评论
“It could then find that repo (in the same organization), clone it, do the work, push a branch, submit a PR, subscribe to events on the PR and automatically follow-up on review feedback. It cannot do this cross-org.”
Cursor 云端 Agent 无法跨仓库/跨组织提交 PR 并跟进评审反馈，而 Claude Code 的云端 Agent 可以做到。原文