HiFox “自动化”是什么？到点或状态变化时，用固定指令启动 Agent

每个工程团队都背着一层没人计划、但人人在付的重复工作。有人拼每日站会摘要。有人读每一份新来的缺陷报告再分发出去。有人从六个标签页的散落状态里编周五的进度报告。这些都不难。它们全都是苦工：可预测、可重复，而且悄悄地贵，因为它总落在第一个注意到的人身上。

这正是 AI Agent 擅长的工作，前提是有东西在正确的时刻把 Agent 启动起来，而不用人再打一段提示词。在 HiFox 里，这个启动机制就是自动化。自动化是空间拥有的一份定义，用来重复执行 Agent 或小队的工作：写好的指令、一个执行处理人、一个或多个触发器，以及你可以检查的运行历史。

重点不是把判断自动化。HiFox 自己的说法很直：自动化停在需要团队判断的地方。自动化可以起草站会摘要，对缺陷做第一遍阅读，并把周报组装出来。人仍然决定团队对此做什么。如果你对 HiFox 本身还生疏，先看「HiFox 是什么」再回来。那篇中文还没发布，这里先不放链接。

先说结论

HiFox 里的自动化，是空间拥有的一条规则。触发器一响，它就用一套固定指令启动一个 Agent 或一支小队。触发器有四种：日程（带时区的五段 cron）、任务状态变化、评论里包含某句配置好的话，以及给外部服务用的密钥 webhook 地址。另外还有一个「立即运行」按钮，用来手工测试。每次运行都记在运行历史里，带上来源、结果和失败原因。修改的时候可以暂停，改完再恢复。自动化适合边界清楚的重复工作：站会摘要、缺陷的第一遍分级、定期报告。Agent 负责读和起草。人审查输出，并做决定。

自动化是什么，不是什么

一条自动化存的是一份小而完整的、可重复作业的定义：名称，以及描述目标、步骤、约束和预期结果的指令；拥有它的空间；处理人，也就是执行工作的 Agent 或小队；优先级；状态是启用还是暂停；一个或多个触发器；还有运行历史，记下每次运行的来源、结果、Agent 运行和失败原因。

有两条边界，不然会让你意外。

第一，自动化不会为每次运行创建一条任务。它直接启动一次 Agent 或小队的运行。这次运行、它的输出和任何失败，都落在这条自动化的运行历史里，而不是落在你的任务列表里。所以看板不会在每天早上九点被机器生成的任务填满。

第二，自动化不是 HiFox 的工作流画布。一个空间有两个自动化表面：这里说的自动化，是单条规则；自动化工作流，是一块由触发节点和动作节点组成的画布，可以调用第三方连接器。当一个 Agent 或一支小队应该针对一个可预测的事件，跑一套指令时，用自动化。当你需要在 Agent 介入之前做多步或跨应用的动作时，用工作流。

因为处理人是一个完整的 HiFox Agent，你已经在那个 Agent 上配置的一切都适用：它的指令、运行时、技能、仓库和运行设置。如果你还没建过一个，Agent 那篇讲的是一份保存下来的工作配置怎么变成团队可以复用的东西。那篇中文还没发布，这里先不放链接。自动化实际上就是和那个 Agent 的一个长期约定。

四种触发器

一条自动化可以有多个触发器，每个都能单独启用或停用。一份定义可以服务几个入口：同一套分级指令可以在状态变化时触发，也可以在一条斜杠命令时触发，不用复制任何东西。

日程用标准的五段 cron 表达式和一个时区，并带常见的每小时、每天、工作日和每周预设。这个触发器是为「因为今天是星期二就该发生」的工作准备的，不是因为有东西变了。

任务状态变化在任务进入某一个选定的组织状态时启动自动化。有一个细节要紧：状态是可复用的组织级定义，当前的事件匹配范围是整个组织。如果几个空间用了同一个「待分级」状态，其中任何一个空间里的匹配转移，都可能启动你的自动化。指令里要让 Agent 在行动前先核对触发它的那条任务。

评论短语在任务评论包含一句配置好的话时启动运行。匹配不区分大小写，评论里任何位置都算，而且同样在整个组织里听。文档的建议是：用有辨识度的斜杠命令，例如 /triage-bug，而不是「check」，并让指令校验触发它的那条任务。

Webhook会生成一个密钥地址，接受外部服务的 POST。完整地址只在触发器创建或重新生成时显示，之后不能再查看，因为默认情况下地址本身就是持有者密钥。如果你配置了签名密钥，请求还必须通过签名校验，和 GitHub 对自己的 webhook 用的是同一套做法。这些密钥不要进源码库。一旦暴露就重新生成。webhook 之外怎么用脚本驱动 HiFox，是 CLI 和 API 那篇的内容。那篇中文还没发布，这里先不放链接。

还有一种启动方式根本不是触发器：「立即运行」直接启动这条自动化。用它在把这四类触发器托付给这项工作之前，测试指令和处理人是否可用。

自动化实际跑的是什么

触发器一响，HiFox 就用这条自动化的指令启动被指派的 Agent 或小队。这些指令就是整份约定，所以文档对它们应该写明什么说得很具体：要产出什么结果，要检查哪些输入，要遵循哪些步骤，结果记在哪里，允许哪些变更，以及什么时候必须由人审查或决定。

最后一项值得强调。写得好的自动化会自己点明停在哪里。「起草摘要并记下来；不要改任务状态」比一段更长、却把权限留得含糊的指令更好。文档的铺开建议同样直白：从可观察、可撤回的工作开始，先审查几次运行，再扩大范围。

值得先自动化的三件苦工

下面每一件都停在产品实际支持的保真度上：Agent 阅读、起草、记录；决定留在人这里。

每日站会摘要。触发器：日程，工作日预设，用团队的时区。处理人：一个对相关上下文有读权限的报告 Agent。指令：检查当前迭代里的任务，记下什么动了、什么被挡住、什么在等审查，然后在团队会读的地方记一份短摘要，不改任何任务。Agent 做的是站会里没人喜欢的那部分，把画面组装起来。站会就变成关于那两件需要判断的事的对话。如果团队的节奏走 HiFox 的迭代，迭代提供的就是 Agent 要检查的结构。迭代那篇中文还没发布，这里先不放链接。

缺陷的第一遍分级。触发器：缺陷接收状态上的任务状态触发，或者一句有辨识度的评论短语，例如 /triage，或者两个都要。处理人：仓库覆盖受影响代码的分级 Agent。指令：确认触发它的任务是目标空间里的缺陷，读报告，检查代码库里相关的区域，然后记下这个缺陷看起来碰到了什么、报告里的信息够不够行动，以及一个带理由的建议优先级。建议，不要决定。核对这一步不是装饰：因为状态和评论的匹配范围是整个组织，指令就是你的范围过滤器。回报是每条缺陷在到达后的几分钟里，都得到同样仔细的第一遍阅读。工作从 HiFox 外面进来时，同一套分工仍然成立。Jira 工单怎么变成 Agent 的工作，那篇中文还没发布，这里先不放链接。

定期报告。触发器：日程，每周预设。处理人：同一类报告 Agent，指令的窗口拉长：总结完成了什么、延误了什么、挡住了什么。它和站会的差别只是范围和读者。这正是它属于自动化的原因。每个星期五都以同样的保真度存在的报告，好过那份只在有人有空时才存在的更好的报告。

这三件里，注意指令中永远不出现的词：接受、批准、发布、关闭、决定。

运行历史、健康状态，以及暂停和恢复

不能检查的自动化就是不能信任的自动化，所以每次运行都有记录。运行历史把每次运行标成运行中、已完成、失败或已跳过。运行详情里可以打开触发载荷、Agent 运行、输出，以及记下的失败原因。在单次运行之上，一个健康信号概括最近有用的状态：从未测试、运行中、健康、已跳过，或需要关注。

有一条否定值得在脑子里加粗：已完成描述的是这次自动化运行，不是承诺下游的每个结果都正确。已完成的意思是机器转了。摘要准不准、分级判断站不站得住，仍然要人来读。

暂停和恢复就是为你预期的那些时刻准备的。修改指令、触发器或处理人时，暂停自动化，让新的触发运行停下来。配置好了再恢复。中间这段时间，定义和它的历史都还在。删除是唯一的移除路径，所以只留给你不再需要运行历史的那些定义。归档一个 Agent 之前，先看还有没有自动化依赖它。

在依赖任何一条自动化之前，文档建议过一遍短清单：用「立即运行」手工跑一次，确认 Agent 或小队有所需的访问，检查这次运行和它的输出，把每个触发器分开测试，状态收窄或评论短语要有辨识度，webhook 密钥不要进源码库。

自动化停在哪里

很容易得出结论，说目标是一条无人值守的流水线。不是。产品自己的设计就是这么说的。自动化不接受自己的输出，而且每次运行都记下来给人审查。

所以诚实的决定规则是这样。同一件边界清楚的工作应该反复开始，或者应该响应一个可预测的事件，而且一份稳定的初稿好过一份偶尔才有的优秀稿，这时用自动化。工作是一次性的，就直接把任务派给 Agent。工作本身就是判断时，整件事留给人：互相冲突的压力下的优先级、一次接受决定，以及「稳定地错」比「偶尔慢」更糟的任何事。

从小的、无聊的开始。先完成安装，创建一个报告 Agent，写一条工作日日程的自动化，指令以「不要改任何任务」结尾，再手工跑一次。读输出。如果有用，就让日程接过去。更细的说明在 自动化文档里，工作流画布也在文档中单独说明。入门那篇中文还没发布，这里先不放链接。

常见问题

HiFox 的自动化支持哪些触发器？

四种：带时区的五段 cron 日程；任务进入某一个选定的组织状态时触发；评论里出现一句配置好的话时触发；以及在密钥地址上接受 POST 的 webhook。一条自动化可以组合多个触发器，每个都能单独启用或停用。「立即运行」用来手工启动一次，供测试。

自动化每次运行都会创建任务吗？

不会。现在的自动化直接启动 Agent 或小队的运行，不为每次运行创建任务。运行、输出和失败原因记在这条自动化的运行历史里。如果你希望结果出现在团队会读的地方，写进指令里。

自动化和自动化工作流有什么不同？

它们是空间里两个分开的表面。自动化是一条规则：什么时候开始，哪个 Agent 或哪支小队来跑，遵循什么指令。自动化工作流是一块触发节点和动作节点的画布，可以通过连接器调用第三方应用。重复检查和评论命令用单条规则。多步、跨应用的流程用画布。

自动化能自己做缺陷分级吗？

它能做第一遍：核对触发它的任务，读报告，检查相关代码，并记下发现和建议优先级。分级决定留在人这里，指令里应该明确这么写。文档建议从可观察、可撤回的工作开始，先审查几次运行，再扩大范围。

自动化运行失败时会发生什么？

这次运行在运行历史里记成失败，有失败原因时会一并记下，健康信号变成需要关注。打开运行详情，检查触发载荷、Agent 运行和输出，修好指令、触发器或处理人，再用「立即运行」验证修复，然后才重新信任那些触发器。