当前位置：

社区首页

文化娱乐

在线教育

IT互联网

文章详情

AI-native 实践：Agent 全自动无人值守接需求

每天凌晨 0 点 40 分，HiFox 空间中的一个自动化流程会定时启动，扫描空间里所有带 workflow:auto 标签、状态为「待开始」的任务，按优先级和任务编号排序，然后逐条派给一个 Agent。

这个 Agent 叫张无忌。

把批量任务排在凌晨跑，是因为模型在闲时价格比较低，而且反应比较快——等到人早上一觉醒来，提测包已经在任务里等着人确认验收了。

张无忌跑在 HiFox 团队的共享开发机上，使用 Antigravity Runtime 和 gemini-4-argon-high 模型。张无忌 10 月底上线，最近 10 天一共接了 52 个 bug 和小需求：35 个已发布到生产，8 个测试中，1 个待发布——合计 44 个（85%）已通过开发进入交付通道；7 个开发中，仅 1 个被测试打回。这 52 个任务共产生 69 次运行：52 次完成、16 次失败（失败即重试，状态机断点续跑）、1 次取消。完成运行的中位时长约 72 分钟，最长一次 202 分钟。

HiFox 是我们团队打造的一款多人与多 Agent 的协作平台，可以轻松指挥一堆 Agent 同时并行工作。
你可以访问 hifox.com 下载 HiFox。

HiFox 是我们团队打造的一款多人与多 Agent 的协作平台，可以轻松指挥一堆 Agent 同时并行工作

张无忌是如何工作的？

我们拿一个真实案例来理解张无忌的工作流程。

11 月 5 日 17:31，同事 Jesse 贴出一张截图：一个会话运行到 84 分 18 秒被停止，错误卡片写着「会话达到运行时长或长时间无进展的上限」——但配置的上限明明没到。Quinlan 转给任务助手：「建 bug，标签 workflow:auto。」17:35，任务 HF-15156 建好，优先级 high，人类处理人 Quinlan。

张无忌是如何工作的？

当晚没有人再碰这个任务。凌晨 00:40，夜间派单自动化把它派给张无忌；00:42，张无忌开工。

它先复盘了截图对应的生产运行，发现那次 84 分 18 秒的执行里，最后一次工具调用发生在第 54 分 11 秒，之后模型流首包连续 5 次 300 秒超时重试，满 30 分 06 秒没有任何新轨迹消息，被服务端的 30 分钟无活动清扫器「误杀」了——和 24 小时的运行时长上限毫无关系。顺着这条线，它挖出了三处根因：一是 ACP 空参数工具（比如等待后台任务的 await）在执行中阶段不上报进展，导致长耗时工具必然触发 30 分钟无活动判定；二是 Daemon 闲置看门狗的比较符写反了（< 写成了 >），30 分钟的窗口实际每 15 分钟才巡检一次；三是错误卡片文案和「前往运行设置调整时长」按钮对两类超时不加区分，把用户引向一个调了也没用的设置。

凌晨 01:54，它发出一条非阻塞播报（发完继续干，不等回复）：近月 commit 考古已读 63 个文件、核验 18 个核心文件，交叉比对三个历史需求后确认了文案复用的来龙去脉，v1 诊断的盲区已被证伪，v2 终案定稿，正进入编码。

凌晨 01:54，它发出一条非阻塞播报

凌晨 02:34，提测包交出，运行结束——从 00:41 到 02:35，113 分 33 秒，全程无人值守。在提测包里，张无忌给出了：

三个根因的修复，横跨 Go 服务端清扫器、Rust CLI Daemon、前端视图三层，22 个文件 +212/−42 行；
自省摘要：相关文件已读 54 个（门槛 ≥50）、30 天 commit 考古 21 个核心文件（门槛 ≥15）、coverage.mjs --verify 退出码 0；
v1→v2 修正对照：考古发现别的需求建过的「Pending 空参去噪」防线不能顺手拆掉，只对执行中阶段放行；按钮门禁要加两个入口；看门狗触发时无条件归因；
两项自动决策待追认：超时拆分策略给了 A/B/C 三个方案（选了零数据库迁移的 A），无进展超时的多语言文案给了 5 个候选；
测试与证据：vitest 914 通过、Go/Rust 测试全绿，真实浏览器开两个会话分别验证「30 分钟无进展」和「单次时长上限」两种卡片，各留一张截图；
三条如实写明的残余风险，其中「真实的 30 分钟模型卡顿在测试环境难以构造」打上了「难复现」提测备注。

三个根因的修复，横跨 Go 服务端清扫器、Rust CLI Daemon、前端视图三层

第二天早晨，Quinlan 审包，确认修复后回复【提测】，张无忌把代码合入 staging 分支，任务转待测试。

测试流程同样自动进行，接口测试分析（确认零接口变更，免补用例）、白盒验证（Rust/Go/前端三组专项单测全过）、测试用例设计（3 条用例）由测试 Agent 链自动接力。最后由测试同事确认验收通过。

接口测试分析（确认零接口变更，免补用例）、白盒验证（Rust/Go/前端三组专项单测全过）、测试用例设计

任务解决时间线

人在这个任务里总共做过三件事：贴一张截图发起任务、早上审一次包确认合并代码、确认测试验收通过。

张无忌的工作流程

张无忌的指令不是角色提示词，而是一张 13 个阶段的固定流程图。从初始化到等待提测，全部阶段在同一次运行里不间断推进：

张无忌的指令不是角色提示词，而是一张 13 个阶段的固定流程图

以下详细解说这 13 个阶段：

初始化。确认自己所在的工作区，读仓库自有规则（AGENTS.md、测试命令、分支策略），读任务快照与全部附件；按任务优先级确定基线分支。同时拉取「经验账本」：所有被人类纠正过的教训，开局先读一遍。
截图语境。截图、录屏、红框、箭头、附件都是一等证据，先把现象看懂，再进代码。HF-15156 的入口就是那张 84 分 18 秒的截图。
初诊。写出可证伪的候选根因（diagnosis-v1.md），把视觉症状映射到候选代码路径和核心文件。此时只许诊断，不许改代码。
初案。起草初步方案（idea-v1.md），每个改动点分级：CORE_FIX（核心修复）、REQUIRED_SUPPORT（必要支撑）、ARCHITECTURE_FOLLOW_UP（架构后续，这次不动）。
自省深潜——这是全流程的心脏。张无忌没有人工方案确认门，方案的可靠性全部由这个阶段扛住，具体做法是对自己刚写的 v1 诊断和 v1 方案发起四道攻击：攻击不倒的部分，重铸为 v2 定稿（diagnosis.md + idea.md），附一张 v1→v2 修正对照表；随后发一条非阻塞定案播报（凌晨 01:54 那条就是它：说清 v1 盲区、考古发现、修正点，状态标「运行中」），发完直接进入下一阶段。
commit 考古：对不少于 15 个核心文件做近 30 天提交考古，弄清这段代码最近被谁、为什么改。这不只是找根因，更是防呆——考古中经常发现「某条看似多余的逻辑其实是上个需求刚立的防线」，拆了就会引入回归。HF-15156 在这一步考古了 21 个核心文件，交叉比对三个历史需求，才确认误导文案是被谁复用的。
广度台账：不少于 50 个相关文件进 read-ledger.json 阅读台账，由脚本记账，杜绝「看了三个文件就下结论」。HF-15156 最终读了 54 个。
强制证伪：对 v1 诊断和方案发起三类证伪指控，写进 self-audit.md。HF-15156 在这一步把 v1 的「疑似时长上限判定错误」证伪成「30 分钟无活动清扫误杀」，还顺藤摸出看门狗比较符写反这种纯靠通读代码很难注意到的缺陷。
脚本硬门：以上数字由 coverage.mjs --collect/--verify 双模脚本核验，退出码非 0，不得进入实现——「我读够了」由脚本判定，不由 Agent 自述。
计划。按 v2 方案生成实施计划。
实现。改代码、补测试，按仓库既有范式来。
净室评审。放下实现者身份，以评审者标准重新检查：根因真的解决了吗？调用方全部迁移了吗？测试覆盖风险了吗？有没有残留旧路径？发现阻断问题就修补后重审，最多 6 轮；6 轮仍有阻断问题就熔断转人工——防止 Agent 在自己写、自己审、自己修的循环里无限运行。
验证。跑仓库声明的测试，并按改动性质做真实验证。测试通过只算证据的一半：界面改动要开真实浏览器留截图，后端改动要留接口、日志或命令输出。HF-15156 在本地任务环境开了两个真实会话，分别触发两类超时卡片并各留一张截图。
待评审。整理提测包：前后行为对照、自省修正摘要、分层架构影响表（哪层改了、哪层验证过零改动）、全部自动决策及候选方案、验证证据、Compare 链接。
等待提测。唯一的门。只有来自任务处理人的、以「【提测】」确切结尾的消息能解锁交付；「可以」「继续」「approved」永不解锁，Agent 也绝不自己发令牌。想改选方案也可以：回复 Q2=B 【提测】，一并生效。
提测执行。变基到最新基线、合入、推送、git merge-base --is-ancestor 祖先校验、任务状态更新，并给测试打「提测备注」标签——只标注代码里看不出来的信息，比如 HF-15156 的「难复现」。
完成。收尾时把本任务新产生的类级教训写回经验账本（全局账本 + 空间知识库双写），下次任务初始化自动拉取。

张无忌的 Agent 提示词可以在这个飞书文档读到：张无忌 - 全自动开发-无人值守

张无忌的设计原理

只留一道人工门，靠的是把评审变成度量

传统流程用一道「方案确认」门挡住「方案错了就白写代码」的风险。张无忌不设这道门，替代它的是自省深潜里那四道量化指标：15 个文件的提交考古、50 个文件的阅读台账、三类强制证伪、脚本退出码硬门。当方案的每个论断都能回溯到考古证据和阅读台账，人工确认方案的边际价值就很低了——真正值得人做的，是在证据最完整的时刻做终局追认。

保守自动决策 + 硬限熔断

没有人工方案确认，遇到未决分支怎么办？靠「保守自动决策协议」。在发现点枚举全部合理候选，按最小爆炸半径拍板——只取核心修复加必要支撑，不扩张未授权的公开 API、schema 或迁移；每个决策连同候选与理由记入 state.auto_decisions，在【提测】门一次性交人追认。HF-15156 的超时拆分选了「零数据库迁移」的方案 A，而不是更「漂亮」但需要跨版本改枚举的方案 B，就是这个原则的直接体现。

只有四类「硬限」允许它真正停下来等人：不可逆或破坏性变更、需求正面互斥、系统级阻断（元数据缺失、状态损坏、评审 6 轮超限）、仓库规则互相冲突。硬限触发时用紧凑的选择表列出选项；人对「等待人工输入」的回复本身就是决策，不需要确认令牌，记录后自动继续。

状态机与阶段产物

持久化状态机。.xwing-task/state.json 是阶段唯一权威，原子写、断点可恢复；会话断了靠状态文件和阶段产物续跑，绝不从聊天记忆重建进度。
阶段产物即证据。diagnosis-v1.md、idea-v1.md、self-audit.md、read-ledger.json、review-report.md、verification/matrix.md、ship-summary.md——缺对应文件就不能宣称阶段完成，聊天里说一句「诊断完成」没有效力。
阶段专属 Skill。主指令只管流程与权限，六个协议 Skill（context / idea / selfaudit / implement / verify / deliver）管各阶段的具体做法；进入阶段前必须完整读取并在状态历史留痕，产物还须符合 Skill 模板。
回复契约。每条消息以状态页脚收尾：阶段、状态、证据、阻塞项、授权者、技能加载、下一步。

关于持久化状态机、阶段产物和阶段专属 Skill 的更详细解说，可以阅读我们其他的文章：AI-native 实践：Sharkly 团队如何让 Agent 自动修 bug、狄仁杰 - 快速开发需求和修复 BUG。

经验与教训

门越少，效率越高

这套流程的早期版本设过多道人工门，Agent 走几步就要停下来等人，人被反复打断，流程快不起来。一路做减法，现在只剩【提测】一道。我们的体会是：人工门的价值不在数量，而在它停下的时刻证据是否完整。【提测】门前，自省修正、架构影响、自动决策、验证证据全部成包，人做的是一次信息完整的追认，远比过程中的频繁点头可靠。

门越少，对人的要求越高

做减法拆掉的是流程负担，不是判断负担——它把散落在多道门里的频频点头，压缩成了【提测】前的一次重审。这一次审得认真与否，直接决定整套流程的下限：

审包要真的读包。根因、架构影响、自动决策、残余风险都在提测包里；盖章式提测等于亲手拆掉最后一道防线。HF-15156 的提测包里写明「真实的 30 分钟模型卡顿在测试环境难以构造」，人读到了，才会接受「难复现」的测试口径，而不是事后追问为什么没测到。
要有能力改选。自动决策都附了候选：超时拆分给了 A/B/C 三个方案，多语言文案给了五个候选。追认不只是「同意」——发现更合适的选项，回复 Q2=B 【提测】 一句话就能改。这要求审的人看得懂取舍：为什么默认选了零数据库迁移的方案 A，而不是更彻底的枚举拆分。
纪律反过来也约束人。令牌门防住了 Agent 的自作主张，防不住人的随手一挥——【提测】一经发出即全部追认，所以它必须被当成合并代码前的 final review 来对待，而不是已读回执。

门少了，人的把关就更重要，更关键。决不能盲过。

夜里跑任务，便宜、快、还没人抢

把批量任务排到凌晨，除了错峰的人力时间，还有两层实际收益：模型在闲时价格比较低、响应比较快；共享开发机夜里空闲，20 路并发不会和白天人盯着的交互任务互相干扰。凌晨 00:40 派单、两小时内交包、早上人审——时间表本身就是流程设计的一部分。

一份协议，三个分身

张无忌不是一个 Agent，而是一个母体加两个分身，使用同样的指令。母体跑 Antigravity Runtime、gemini-4-argon-high 模型；张无忌 AgyK 同为 Antigravity，跑在另一台机器上；张无忌 omp 换成 oh-my-pi Runtime 和 glm-5.3 模型。三者共享同一份逐字节的协议指令——升级指令时三端同步生效，行为差异只能来自 Runtime 和模型本身。

分工也是设计过的。夜间派单把任务一比一交错分给母体和 AgyK，两台机器轮着消化、互为对照；omp 不走夜间派单，专门承接直接指派的活，其中不少是基于 main 分支的紧急 hotfix——三条路进来，一套纪律出去。

同一份协议、同一套体检指标（完成数、失败率、时长）摆在同一张表上，我们就可以更有效地选择 Runtime 和模型的选型。顺带的工程收益很实际：三台机器合计 60 路任务并发，单个 Runtime 出故障时另外两个照样接单。

自动决策宁保守，教训要闭环

拍板原则永远是「最小爆炸半径」：拿不准的方案降级、扩张的选项留给 ARCHITECTURE_FOLLOW_UP。
打回不可怕，可怕的是不记账。11 天里唯一一个被测试打回的任务（HF-14811，网络代理核心链路）恰好是耦合最深的一类——这类教训会进经验账本，约束下一次同类任务。
证据出现在决策发生的地方：截图直接贴进会话，点开好几层目录才能看到的证据等于没有证据。