你们的 Issue 已经在 GitHub 里。代码、Pull Request 审查，以及团队花了一个季度才对齐的分支规则，也都在那里。没有人想再养一块看板，去和第一块保持同步。缺的是一条路：把其中一个 Issue 交给编程 Agent，收回一个可以审查的 Pull Request，而且不离开它本来所在的仓库。
把 GitHub 接到 HiFox，做的就是这件事。HiFox 是一站式的 Agent 指挥和管理平台：它把 GitHub Issue 变成可以指派的任务，路由到编程 Agent（Claude Code、Codex、Gemini，或团队在跑的任何运行时），在一台电脑上的隔离 worktree 里执行，再把结果交回成你按平时方式审查的 Pull Request。这里最要紧的有两件事：谁真正可以碰这个仓库，以及人还要在哪里说一声可以。
用一句话讲完这个循环
连上 GitHub，把一个仓库关联到一个空间，新的 Issue 就会变成任务。把它派给一个 Agent 之后，HiFox 里到处适用的那份约定同样生效：Agent 调研、执行、测试并汇报；人审查 diff，决定什么可以发布。
两层连接，为什么不是同一件事
GitHub 集成有两层。把它们混在一起，是搞不清「谁能看见什么」最快的办法。
第一层是组织连接。组织所有者或管理员打开外部应用集成，找到 GitHub，针对它应该看见的仓库安装 GitHub 应用。有了这层连接，Pull Request 关联和回链评论才成为可能。成员也可以连接个人 GitHub 账号，但那只改变同步评论时显示谁的身份，不改变组织连接已经做的事。
第二层是把其中一个仓库关联到一个空间。做完之后，新的 GitHub Issue 会开始变成任务；已有的 Issue 不会被导入。一个仓库可以单向喂给空间（Issue 的变化流进来，不流回去），也可以双向（Issue 和任务两边保持同步）。一个空间同时只能有一个双向仓库，所以要选仔细。
容易绊倒人的边界在这里：这些都不是 Agent 获得克隆代码权限的方式。GitHub 集成覆盖的是 Pull Request 链接、Issue 同步和回链评论。它不会把任何仓库的读或写权限交给 Agent。
代码权限要另外给
代码访问是另一项配置，设在 Agent 或空间上，不设在 GitHub 连接上。Agent 自己没有仓库时，会退回到这条任务所在空间的配置。如果它只应该碰空间所引用的多个代码库中的一个，就在 Agent 自己身上把这份列表收窄。
无论哪种，运行仍然需要电脑上可用的 Git 访问：SSH key、HTTPS token，或这台主机上已经配好的凭据。组织连接不提供、也不代替这些。如果一次运行克隆不了，那是电脑的问题，不是 GitHub 应用的设置问题。
把 Issue 派给 Agent
仓库关联之后，新的 GitHub Issue 会落成一条任务。Issue、Bug、Feature、Ticket 都是有效的任务类型，用你们空间里实际在用的那种。把它派给 Agent，和派给同事是同一种操作：打开处理人，选 Agent，而不是选人。
Agent 是一份保存下来的工作配置，不是一句用过即弃的提示词。它的指令、运行时、仓库和运行设置决定工作怎么做，就像岗位说明决定一个新人会做什么。如果任务落在待办里，还不会开始跑，那里是暂存区。把它移到工作中的状态，电脑和运行时就绪之后，HiFox 才会派出这次运行。
两个 Agent 碰到同一个仓库
这是团队最担心的一段。默认模式是临时目录：每条任务有自己的隔离目录，带仓库的运行会准备一份新的 worktree。同一个仓库里、两条不同 Issue 上的两个 Agent，各自拿到自己的检出，不是共享的一份。所以它们改不了彼此的文件，也不会抢同一个分支，即使在同一台电脑上。这和手工作业时用 git worktree 跑 AI 编程 Agent 是同一套纪律，只是这里自动完成。
并发有自己的上限。临时运行默认大约是这台电脑总上限的一半。你手动调高之后，一旦数值超过可用的目录容量，产品会警告你。碰撞真正开始的地方就在这里。另外还有指定目录模式：Agent 重复使用一个固定目录，而不是新的 worktree。它一次只服务一次运行，不适合多个 Agent 同时打进来的仓库。
收回来的是 Pull Request
Agent 打开 Pull Request 之后，你把任务编号写进分支名、标题或正文，把它和任务连上。三处写一处就够。只写 HF-123，和写 Fixes HF-123 一样有效，因为系统不会特殊处理 fixes、closes 或 skip 这种词。公开仓库只关联可信作者：所有者、成员或协作者。陌生人的 Pull Request 不能伪装进你们的任务。
关联上的 Pull Request 还可以收到一条指回任务的回链评论。私有仓库默认开启，公开仓库默认关闭。这个开关在 GitHub 设置里，和空间本身是公开还是私有不是一回事。
审查关口：判断留在这里
合并 Pull Request 不会改变任务状态，也从来不会自己发生。这是故意的。任务状态和 Agent 的工作状态分开记录。一条已开始的任务还可以显示为工作中、等待人回复、等待人审查或出错。这些信号会出现在负责人的收件箱里。关闭或重新打开底层的 GitHub Issue，可以带动双向同步任务的状态；合并 Pull Request 不可以。
Agent 调研、执行、测试并汇报。人对照原来的 Issue 读 diff，要求修改或接受，自己做合并和发布的决定。这条分工一直成立，在 GitHub 上和在 HiFox 其他地方一样：自动化停在团队判断开始的地方。审查这一步为什么不是仪式，人在环路里怎么看 diff，原文还单独写过。那篇中文还没发布，这里先不放链接。
什么时候 GitHub 自己的 Agent 中枢就够了
如果团队完全押在 GitHub 上，源码、CI、审查，再加上付费的 Copilot 席位，GitHub 自己的 Agent HQ 可以在那个生态里把 Agent 协调得很好，你也许不需要别的东西。HiFox 出现的理由，是工作同时还要经过 Jira，或者 Agent 跑在 GitHub 云之外的电脑上，或者团队混用多种运行时，不想每次「现在最好的那个」一变就重建整套流程。如果这里面有 Jira，把 Jira 工单派给 Agent 走的是同一条循环，只是从那一侧进入。那篇中文还没发布，先不放链接。
想在一条真实 Issue 上试：打开 HiFox 的 GitHub 集成，以及 Jira、Slack 的集成说明，连上 GitHub 组织，把一个流量不高的仓库关联到空间，把下一个小 Issue 派给 Agent，而不是派给自己。
常见问题
连上 GitHub 组织，Agent 就能访问代码了吗？
不能。组织连接覆盖的是 Pull Request 链接、Issue 同步和回链评论。代码访问另外配置，在 Agent 或空间上。运行仍然需要电脑上自己的 Git 凭据。
两个 Agent 做同一个仓库，会撞车吗？
默认的临时目录模式下不会。每次运行有自己的隔离 worktree，并发的 Agent 不会共享同一份工作副本，即使在同一台电脑上。
合并 Pull Request 会关掉 GitHub Issue 或任务吗？
合并本身从不改变任务状态。在双向同步的仓库上，关闭底层的 GitHub Issue 可以带动任务状态，但那是和合并 Pull Request 分开的另一个动作。
Agent 的 Pull Request 实际指向哪里？
HiFox 靠分支、标题或正文里的任务编号来关联 Pull Request，写在运行时实际写出的那一处。它不规定分支策略。所以在把比试验 Issue 更要紧的事派出去之前，先确认运行时默认的基线分支行为。
已有的 GitHub Issue 能保留吗，还是只有新建的？
关联仓库之后，同步的是此后新建的 Issue。已有 Issue 不会自动导入。
HiFox
