直接答案
MCP 第一阶段只用于读取 Issue 和仓库上下文。把需求整理成任务契约，批准文件级方案，在隔离分支完成修改并运行仓库检查；评论、推送分支或创建 PR 等远程写操作通过独立授权工具执行，最终仍由维护者审查和合并。
关键结论
- Issue 文本和链接内容即使来自内部系统也属于不可信输入。
- 读取工具与写入工具分离，并使用不同凭据或审批关卡。
- 方案和 PR 都绑定到固定 Issue 标识与仓库版本。
- PR 正文必须提供验证证据和残余风险。
关键事实
这篇内容解决什么问题
使用支持 MCP 的编码代理建立受控的 Issue 到 Pull Request 工作流。
MCPCodex CLIClaude CodeGitHub IssuesGit Pull Request
核验范围与限制
- 证据类型
- 官方文档协议规范本地验证
- 核验范围
- 覆盖 MCP 信任边界、Issue 读取、方案审批、隔离实现、验证、PR 创建和维护者批准。
- 限制与失效条件
- - 可用工具、认证与审批行为取决于具体 MCP 服务和客户端版本。
- - 流程不能判断 Issue 的业务优先级或需求本身是否正确。
01
定义 MCP 与仓库信任边界
连接前列出服务、工具、资源、凭据、网络目标和写能力，并检查服务运行位置、日志与配置。使用只对目标仓库和 Issue 系统有最小权限的身份。
Issue、评论、附件和外链可能包含与仓库策略冲突的指令；它们是任务数据，不是可信命令。
02
把 Issue 规范化为已批准任务契约
按稳定标识读取 Issue，汇总预期行为、证据、验收条件、影响区域和问题；标签和优先级按照跟踪系统策略确认，不能从描述文字推断授权。
- 记录 Issue URL、仓库、基线分支和起始提交。
- 删除秘密及不必要的个人或客户数据。
- 编辑前由 Issue 所有者解决歧义。
- 拒绝超出仓库或凭据范围的请求。
03
批准文件级实现方案
代理使用只读工具探索并列出修改文件、测试命令、风险和停止条件，维护者批准后才获得工作区写权限。依赖、Schema、协议或部署变化重新进入显式决策。
04
在没有远程写权限的隔离分支实现
基于批准的 commit 创建本地或临时分支，限制路径和命令。生成与测试代码时不提供 Issue 或 PR 修改凭据，降低提示注入和误选工具的影响。
05
先本地验证，再通过保护步骤发布
运行聚焦及仓库要求的检查、审查 diff，并生成含证据和残余风险的变更摘要；只有这时才允许保护步骤推送分支或创建关联原 Issue 的 PR。
- 01检查在模型声明之外独立运行测试和策略。
- 02审阅检查路径、生成文件和敏感输出。
- 03授权批准精确分支和 PR 元数据。
- 04发布短期写身份创建远程制品。
06
让合并和 Issue 关闭保持人工控制
审查者按正常分支规则验证行为、安全和所有权；只有被接受的改动或解决说明满足条件后才关闭 Issue。任务结束后撤销凭据，并为失败保留脱敏审计证据。
官方来源与核验范围
本文以公开官方文档为事实依据；命令和配置可能随客户端版本变化，执行前请同时核对对应来源。
查看技术核验方法