能开 pull request 的编程 Agent 很有用。能在没人盯着的时候把 pull request 合进去的 Agent，则是一个拥有提交权限的风险源。这两句话之间的空白就是问题本身。一旦 Agent 能推分支、跑测试、点合并，问题就不再是「它能不能干活」，而是「它的权限到哪里为止」。
大多数团队是在意外中回答这个问题的：Agent 拿到 Runtime 给它的全部权限，审查发生在启动运行的那个终端里，谁批准了什么的记录只留在某个人的滚动历史里。直到你同时在两个仓库里跑三个 Agent，周五的部署又把一份没人读过的改动发出去，这套做法才撑不住。审批关卡正是解药，但前提是它真的落在共享系统里，而不是一种祈祷大家都记得执行的习惯。
这套共享系统就是 HiFox 提供的能力。你已经有编程 Agent；HiFox 把每次运行变成带状态、负责人和明确审查环节的任务。本文讲的就是背后的运行模型：谁派活、谁执行、谁审查、谁验收，以及关卡到底该设在哪里，才能让 Agent 永远不会在未审查时合并自己的改动。
审批关卡到底是什么
审批关卡是任务生命周期中的一个点：自动执行在这里停下，等人决定下一步。它不是警告，也不是一条可以划过去的日志，而是一种工作必须停在其中的状态，直到人把它推走。
最关键的区分，是 Agent 提出改动，和 Agent 落下改动。开 pull request 是提出；合并 pull request 是对生产环境做决定。两者是不同的授权行为，团队判断必须放在后一步。HiFox 把这条边界写得很明确：即使连接了 GitHub，合并 pull request 也不会改变任务状态。合并始终是记录在案的人为动作，不是 Agent 在完成运行时顺手触发的副作用。
记住这条边界，因为大多数「Agent 把生产搞坏了」的故事，本质上都是「提出」和「落地」之间少了一个关卡。
运行模型：派活、执行、审查、验收
HiFox 把任务拆成四个角色，每个角色只做一件事。契约很简单：Agent 负责调研、执行、测试和汇报；人负责定方向、授权和验收结果。
- 派活。人描述需求并设置负责人。一个任务有两个彼此独立的指派：任务上的人，以及唯一的执行负责人，也就是实际跑这项工作的 Agent 或小组。改其中一个，不会改另一个。
- 执行。执行负责人在独立的 git worktree 里工作，并行运行不会碰到彼此的文件。进度、阻塞和结果都会回到任务上。
- 审查。Agent 完成后，会把任务留给人审，而不是自己关掉。diff、测试输出和改动摘要附在任务上，而不是留在某个终端里。
- 验收。人阅读证据后决定：要求修改，或者接受并合并。验收是终态动作，而且只能由人来做。
价值不在于 HiFox 替你运行 Agent，而在于四个角色始终在同一个地方可见，不会再塌缩成「当时碰巧开着哪个终端」。想更深入看审查这一半，可以阅读关于 human-in-the-loop 编程 Agent 的说明。
把关卡做成状态，而不是靠习惯
需要你记住的关卡，最终一定会被跳过。所以要把它写进任务生命周期。
HiFox 通过状态分类赋予每个状态系统含义。待办是停放状态：即使已经指派了 Agent，待办里的任务也不会执行。把它移入可执行状态，运行才会开始。完成是终态，而进入完成是人做出的动作，不是 Agent 自己授予自己的结果。
任务状态刻意和 Agent 的工作状态分开。生命周期状态显示「进行中」时，底下的 Agent 可能正在工作、等待人的回复、等待人审，或者报告错误。这个分离就是关卡：Agent 可以结束运行并显示「等待人审」，而任务不会因此跨进任何暗示它已经上线的状态。工作回到任务上，停在那里，直到有人验收。
这也是多个 Agent 可以安全并行的原因。当五个在独立 worktree 中并行的 Agent 都落进同一列待审查时，你有一个地方统一分级，而不是五个终端逐个照看。
一个完整例子：从工单到合并的 PR
用一个任务从头走一遍，沿用 HiFox 里 SH-312 这样的编号。
- 建单。人创建
SH-312，一个 bug 任务：「修改筛选条件后，搜索结果仍然返回旧数据。」描述里包含目标、复现步骤和验收标准。负责人是一个绑定到搜索仓库的 Claude Code Agent。 - 定范围。Agent 调研代码库和相关历史，确认范围，再把计划发回任务。人读完计划，把
SH-312从待办移到已就绪，这就是可以开工的信号。 - 执行。Agent 领取任务，在一个新的 worktree 里工作。它写出修复，运行 typecheck 和测试套件，并开一个标题带
SH-312的 pull request，让 HiFox 把 PR 关联回任务。 - 停在关卡前。Agent 不合并。它附上改动摘要、通过的测试输出和已知限制，然后让
SH-312停在等待人审。工作已经回到任务上。 - 审查。人打开
SH-312，在一个视图里读 diff 和证据，发现修复碰到了共享的查询辅助函数。人留下评论，要求把改动收窄。对于已经绑定可用 Agent 负责人的任务，这条评论会重新排队运行，所以「要求修改」的循环留在记录里，而不是在私聊里重新开始。 - 验收并合并。第二次运行通过审查。人批准 pull request、执行合并，再把
SH-312移到完成。因为合并不自动关闭任务，验收和合并是两次被记录的人为决定，而不是一次自动级联。
这条链上的每一步以后都可以检查，这正是可追溯的「需求到代码」工作流的意义：你能回答「谁在什么证据下批准了它」，而不必去某个人的滚动历史里做考古。
哪些地方不要设关卡
关卡越多不一定越安全；它们会增加摩擦，把人训练成闭着眼点通过。关卡该设在「合错了代价真实存在」的地方。对于范围清楚、风险低、只交给一个 Agent 的小改动，合并前审查这一道就够了，不需要再叠一个小组或额外审批。只有当影响范围很大时才加重审查：共享代码、数据迁移，以及任何碰鉴权或计费的东西。
唯一永远不能拿掉的关卡是合并关卡。Agent 可以整天调研、写代码、测试和提出方案。它的改动能不能进入主分支，必须由人决定；即使 Agent 大多数时候是对的，这条也不该变。把 HiFox 的任务级审查和你现有的分支保护配在一起，让平台去强制执行流程想要的结果；同时保留团队已经在用的工具，连接 GitHub、把工单指派给 AI Agent，而不用重建现有流程。
如果你已经在跑多个编程 Agent，却分不清哪个完成了、哪个失败了、哪个正在等你，待审查那一列就是试用 HiFox 的理由。把现有 Agent 放进这条流程，让合并决定留在他该在的位置。
常见问题
HiFox 能阻止 Agent 自行合并吗？能。合并 pull request 不会改变 HiFox 里的任务状态，所以一次运行会停在「等待人审」，而不是直接落下改动。再配合 GitHub 分支保护，就可以在仓库层面强制要求审查。
任务状态和 Agent 状态有什么区别？任务状态是生命周期分类，例如待办、已开始、完成。Agent 状态是这次运行此刻在做什么：工作中、等待人的回复、等待审查，或者出错。任务可以在进行中，而 Agent 正在等你。
每个需要审查的任务都要建小组吗？不需要。小范围工作把任务交给一个 Agent，并设置合并前审查即可；只有目标需要队长 Agent 协调多个成员时，才用 HiFox 的小组。
HiFox
