工单已经写好了。它有标题、描述、验收标准，也有在迭代里的位置。它和一份 diff 之间，还隔着一个人：打开终端，把工单贴进编程 Agent，看着它跑，再把结果手工抄回 Jira。工作和关于工作的记录住在两个窗口里，让它们保持同步，会占掉某个人的一下午。
把 Jira 工单派给 AI Agent，就是把这个缺口合上：Issue 变成 Agent 可以领走的一份工作，对着你们的仓库执行，再交回一个可以审查的变更，而不离开团队已经在用的跟踪系统。你们不用把团队搬离 Jira。你们加上一层，让这张工单真的能被做掉。
这一层是 HiFox，一站式的 Agent 指挥和管理平台。它连接 Jira，把 Issue 变成可以指派的任务，路由到你们的编程 Agent（Claude Code、Codex、Gemini 和其他命令行工具），每个都隔离运行，再把结果交回任务。这篇把整条循环走一遍：工单进来，Agent 接上，工作在隔离的 worktree 里完成，Pull Request 和讨论回到记录上。
用一句话讲完这个循环
HiFox 的任务是一份工作的共享记录。接上 Jira 之后，每条 Jira Issue 都会变成这样一条任务。从这里开始，约定很简单：Agent 调研、执行、测试并汇报；人定方向、授权，并接受结果。这篇文章剩下的部分，只是这句话的机制。
留下 Jira，加上执行层
HiFox 不替代 Jira。它在团队已经在用的跟踪系统外面，加上共享任务、连接的电脑、执行和审查。没有人必须先学会一块新看板，或先迁移待办，才能开始。
两边用同步链接接上。打开 Jira 集成，连接账号。Jira Cloud 用你们的 *.atlassian.net 主机、账号邮箱和 Atlassian API token。Server 和 Data Center 用基址、用户名和个人访问令牌。然后把一个 Jira 项目配到一个 HiFox 空间。核心映射是你预期的那样：
- Jira Issue 变成 HiFox 任务
- Jira Epic 变成 HiFox 专项
- 处理人、状态、评论和附件一起过来
这里有一对要诚实选择的做法。想让一个正在进行的项目保持连接、从此 Jira 和 HiFox 之间的变化继续流动，用同步。想把历史 Issue 复制进来、做一次受控迁移，用导入。只开同步，不会把项目的过去补进来。多数刚开始的团队，只需要在一个活跃项目上建一条双向同步，别的先不要。完整设置，包括 Jira 管理员做一次的 webhook，写在 HiFox 文档里。
把工单派给 Agent
项目关联之后，Issue 会作为任务出现在空间里。把它派给 Agent，和派给同事是同一种操作：你选的是 Agent，不是一个人。
Agent 不只是选一个模型。它的指令、运行时、仓库和运行设置决定它怎么处理工作，就像岗位说明决定一个新人会做什么。运行时是底下的引擎：Claude Code、Codex，或团队已经在跑的命令行 Agent。模型用量继续走这些工具里配置的订阅或 API Key，所以 Agent 的访问和代码都留在你们自己的硬件上。HiFox 协调的是指派，它不接管你们的凭据。
如果这是第一次跑，把范围留小，边界写清楚。把任务写成 Agent 真的能执行的样子，本身就是一项技能，值得在把 Agent 指向任何承重的事情之前先做对。一张紧的工单、完成标准清楚，会得到一份紧的 diff。含糊的工单，得到的也含糊。
在隔离的 worktree 里执行
Agent 开始之后，运行发生在一台已连接的电脑上，在它自己的隔离 worktree 里。这份隔离，是这件事可以重复做、而且仍然安全的原因。每次运行有一份新的工作目录，所以两个 Agent 对着同一个仓库做两张工单时，不会覆盖彼此的文件，也不会抢同一个分支。这和你手工用 git worktree 跑 AI 编程 Agent 是同一套纪律，只是这里替你做好，而且每条任务都可以重复。
这也是工作流能越过一张工单继续放大的原因。隔离一旦是自动的，多个 Agent 并行就不再是一手抛接，因为通常会坏掉的东西（磁盘上的共享状态）被设计掉了。如果整个模型你还生疏，先把第一条任务派给 Agent，会是接上 Jira 之前更缓的入口。那篇中文还没发布，这里先不放链接。
把 Pull Request 记回原处
Agent 的工作回到任务上：对话、执行日志、阻塞和结果变更，都落在一个地方，而不是散在终端和聊天线程里。Agent 打开 Pull Request 之后，把任务编号写进分支名、PR 标题或 PR 正文，把它和任务连上。HiFox 的 GitHub 集成看到编号，把 Pull Request 关联到任务，并可以留下一条回链评论，让工单上的任何人直接跳到代码。
因为 Jira 同步是双向的，这些动态也会继续流向原来的 Issue。提这张工单的人不用打开任何一个终端，就能看见工作在动。这就是把工作走共享任务、而不是走私人提示词的回报：上下文、进度、阻塞、结果和审查，从请求到发布都看得见。
诚实的边界：人来接受
没有东西会自己合并。这是故意的，值得说清楚，因为读者可能会以为相反：合并 Pull Request 不会改变任务状态，也从来不会自动发生。自动化停在需要团队判断的地方。
分工一直保持到最后。Agent 跑工作、打开 Pull Request，并报告它做了什么、验证了什么、哪里不确定。人对照原来的验收标准读 diff，要求修改或接受，并做合并和发布的决定。Agent 会很乐意用主动来填满沉默，所以审查不是仪式。它是让自动的那一部分值得信任的控制。最终的接受和发布决定留在人这里。
这就是整条循环。一张 Jira 工单进去，一个 Agent 领走，工作隔离运行，作为你可以读的 Pull Request 回到记录上，由你决定它发不发布。如果要看这套做法怎么放进一支 Agent 团队、而不只是一次运行，原文还写了面向研发团队的 Agent 编排，以及整套平台的概览。那两篇中文还没发布，这里先不放链接。
想在一张真实工单上试：从 官网 下载客户端，在 app.hifox.com 登录，接上一台电脑，再关联一个风险不高的 Jira 项目。
常见问题
HiFox 会替代 Jira 吗？
不会。HiFox 在 Jira 外面加上执行和审查。你们的 Issue、Epic、状态和工作流留在原来的地方。同步链接让它们保持连接，同时 Agent 把工作往前推。
哪些 Jira 版本可以用？
两种都可以。Jira Cloud 用主机、账号邮箱和 Atlassian API token 连接。Jira Server 和 Data Center 用基址、用户名和个人访问令牌连接。
必须先迁移待办吗？
不用。同步链接连接的是一个正在使用的项目，让此后的变化继续流动，不导入历史。只有当你明确想把过去的 Issue 复制进来时，才另外做一次导入。
合并 Pull Request 会关掉工单吗？
不会。合并 Pull Request 按设计不改变任务状态。人接受结果，并决定合并和发布。审查这一环怎么走，原文另有一篇「把第一条任务派给 Agent」。那篇中文还没发布，这里先不放链接。
代码和模型访问放在哪里？
在你们自己的硬件上。Agent 跑在你连接的电脑上，使用编程工具里已经配置的订阅或 API Key。HiFox 协调指派、上下文和审查。它不托管你们的仓库，也不托管模型额度。
HiFox
