Agent 无人值守接需求实战：10 天 52 个任务，85% 进入交付

团队让 Agent 接 bug，通常卡在两点：不敢放手，以及放手后不可控。HiFox 的做法不是写更长的提示词，而是把「方案确认」换成四道脚本可验的门，只保留一道【提测】令牌门。下面是 10 天的真实数据和可复制部分。

一、先看结果：10 天 52 个任务

张无忌 10 月底上线，跑在共享开发机上，使用 Antigravity Runtime 和 gemini-4-argon-high 模型。每天 0:40，一条自动化扫描 HiFox 空间里带 workflow:auto 标签、状态为「待开始」的任务，按优先级和编号排序后派单。

指标数值接收任务52 个 bug 和小需求已发布到生产35 个测试中8 个待发布1 个进入交付通道44 个（85%）开发中7 个被测试打回1 个运行次数69 次：52 成 / 16 败 / 1 取消完成运行中位时长约 72 分钟最长运行202 分钟

16 次失败不是 16 个事故：失败即重试，状态机从断点续跑；监控要把任务级结果和运行级结果分开看。

图 1：10 天 52 个任务的交付分布与 69 次运行结果

图 1：52 个任务交付分布与运行结果

二、一个真实任务的全过程

案例 HF-15156：一个「运行 84 分钟被超时停止」的误报。

图 2：HF-15156 从误报截图到提测包的无人值守时间线

图 2：HF-15156 无人值守时间线

时间事件执行者11-05 17:31贴出截图：运行 84 分 18 秒被停止人11-05 17:35建 high 任务，标签 workflow:auto任务助手11-06 00:40夜间派单扫描并派出自动化11-06 00:41–02:35诊断、自省、实现、评审、验证张无忌11-06 01:54非阻塞定案播报张无忌11-06 02:34交出提测包，等待【提测】张无忌11-06 早晨人审包、下变基指令、确认人 + 张无忌之后合入 staging、转待测试、测试链接力张无忌 + 测试 Agent

Agent 没有停在「超时」表象：最后一次工具调用在第 54 分 11 秒，之后模型流首包连续 5 次 300 秒超时重试，30 分 06 秒没有新轨迹消息，被 30 分钟无活动清扫器误杀。它挖出三处根因：ACP 空参数工具在执行中不上报进展；Daemon 闲置看门狗比较符写反（< 写成 >），30 分钟窗口实际每 15 分钟才巡检一次；错误卡片不区分两类超时，把人引向无效设置。

最终修复横跨 Go 服务端清扫器、Rust CLI Daemon、前端视图三层，22 个文件、+212/−42 行；vitest 914 通过，Go/Rust 测试全绿，两类超时卡片各留一张真实浏览器截图。

三、13 个阶段里，真正关键的是四道量化门

流程从初始化、截图语境、初诊、初案，到自省深潜、计划、实现、净室评审、验证、待评审、等待提测、提测执行、完成，共 13 个阶段，在同一次运行里不间断推进。其中「自省深潜」承担了原本由人工方案评审承担的责任，靠四道门：

1. commit 考古：≥15 个核心文件，近 30 天提交历史 2. 阅读台账：≥50 个相关文件，写入 read-ledger.json 3. 强制证伪：对 v1 诊断和方案发起三类证伪，写入 self-audit.md 4. 脚本硬门：coverage.mjs --collect / --verify，退出码非 0 不得进入实现 ​

HF-15156 的实际值是 21 个核心文件、54 个阅读文件、v1 被证伪后重写 v2、coverage.mjs --verify 退出码 0。关键不在数字本身，而在「由脚本记账」：Agent 说自己读够了不算，脚本说够了才算。

图 3：13 个阶段、4 道量化门与唯一人工门

图 3：13 阶段、4 道门与 1 道人工门

阶段产物也是硬约束。diagnosis-v1.md、idea-v1.md、self-audit.md、read-ledger.json、review-report.md、verification/matrix.md、ship-summary.md 缺一个，就不能宣称阶段完成。会话断了，靠 .xwing-task/state.json 和阶段产物续跑，不从聊天记忆重建进度。

四、没有方案确认门，怎么防止跑偏

答案是保守自动决策加硬限熔断。在发现点枚举合理候选，按「最小爆炸半径」拍板，只取核心修复加必要支撑，不扩张未授权的公开 API、schema 或迁移；每个决策连同理由写入 state.auto_decisions，在【提测】门一次性交人追认。HF-15156 的超时拆分有 A/B/C 三个方案，最终选了零数据库迁移的 A。净室评审最多 6 轮，仍有阻断问题就熔断转人工。只有四类硬限允许真正停下：不可逆或破坏性变更、需求正面互斥、系统级阻断、仓库规则互相冲突。

代价是自动决策会积累「待追认」的债：人只看结论不看候选，追认就会退化成盖章。

五、唯一的人工门：【提测】令牌

只有来自任务处理人、且以「【提测】」确切结尾的消息能解锁交付；「可以」「继续」「approved」永不解锁，Agent 也绝不自己发令牌。想改选方案，可以回复 Q2=B 【提测】，一并生效。

人在整个任务里只做三件事：贴截图发起任务、早上审一次包、确认测试验收。门少了，单次审包的责任反而更重：提测包里写明的「真实 30 分钟模型卡顿在测试环境难以构造」，人读到了，才会接受「难复现」的测试口径。

六、可复制的落地顺序

1. 先选低风险、边界清楚的任务，打上统一标签，例如 workflow:auto。

2. 把验收标准写进任务本身，而不是散落在聊天里。

3. 先跑「诊断 + 提测包」，不要一上来就给合并权限。

4. 加阅读台账和证伪脚本，让「读够了」可验证。

5. 最后才接自动派单和测试 Agent 链，保留一道令牌门。

七、HiFox 在流程里的位置

这套流程把任务、标签、状态机、定时派单、共享开发机和空间知识库放在同一个协作面里：自动化在 HiFox 空间扫任务，Agent 在任务里留下诊断、证据和提测包，测试 Agent 链继续接力。三个分身共享同一份协议指令，合计 60 路并发；同一套体检指标还能反过来说明 Runtime 和模型怎么选。

图 4：HiFox 任务页中把任务指派给 Agent 的官方界面

图 4：在 HiFox 任务里指派 Agent

如果想试，动作可以很小：在 HiFox 建一个带 workflow:auto 标签的 bug 任务，配一条 0:40 的派单自动化，先只要求它产出诊断和提测包。