AI 接入 CI 后，哪些检查仍须确定执行

Agent 越来越能干，GitHub Actions 还值得继续投入吗？作者的答案是肯定的：必须执行的检查和部署关卡，不该取决于模型是否决定运行它们。更合适的组合，是让 Actions 执行检查，让 Agent 调查失败，再由工程师审核证据。这篇短文值得读的地方，在于把 AI 的调查能力与工程流程的约束分开了。

Agentic Workflows 和 Actions 并不是二选一

作者先纠正了一个容易混淆的比较：这不是 YAML 与 AI 的竞争。GitHub Agentic Workflows 本身就运行在 Actions 里面。

两者承担的职责不同。传统工作流适合执行已经明确的步骤；Agent 适合处理需要调查、收集线索、判断下一步的问题。

例如，检查流程已经规定要运行哪些任务，就应该让工作流按配置执行。至于任务为什么失败、哪些证据能帮助定位问题，则可以交给 Agent 调查。这里的例子是对作者分工思路的解释，原文没有展示具体配置。

已知步骤由流程保证执行，未知原因交给 Agent 调查。

因此，Agent 能力增强，并不会自动消除维护 Actions 的价值。检查规则、执行入口和部署关卡，仍然需要有人明确配置。

为什么修复之后，还得重新跑同一套检查

作者提出的协作流程很清楚：Actions 运行检查，Agent 调查失败，工程师审核调查证据；任何修复建议，都必须再次经过相同的检查。

这个闭环里，Agent 的输出是调查结果和建议。它能帮助工程师理解问题，但不能因为解释听起来合理，就让修复绕过验证。

对程序员来说，这个区别很实用。读懂一份失败报告，与确认修改后满足合并条件，是两件事。前者可以借助模型推理，后者仍然需要执行检查来确认。

作者还强调，权限和审批边界应当在提示词之外强制执行。大白话解释就是：可以在提示词里要求 Agent 遵守规则，但真正能做什么、哪些操作需要批准，应由工作流或权限机制限制。

原文没有给出具体权限配置，也没有说明审批如何接入。这是一条设计原则，还不是可以直接复制的实施方案。

我的判断

我赞同作者对职责的划分，尤其是保留必跑检查和修复后的重新验证。相比把检查是否执行也交给 Agent 决定，这种安排更容易审查：工程师可以明确知道哪些条件必须满足。

但这篇短文没有实验过程、耗时统计、成本数据，也没有与人工排查、日志分析脚本等做法进行对照。它提供的是工程判断，不能据此认定引入 Agent 一定能提高效率。

适用前提也很关键。如果一种失败模式固定，脚本已经能准确识别原因，再加一层模型调查，收益未必明显。需要综合多个线索、排查路径不固定的问题，才更符合作者建议使用 Agent 的条件。

另外，保留检查不代表检查就足够有效。团队原有的验证覆盖是否充分，仍然要单独评估；Agent 的调查能力无法替这件事兜底。

能拿来做什么

• 梳理前端或 Node 项目的必跑检查，把已经确定的步骤保留在 Actions 中，不让模型决定是否执行。
• 为失败后的调查划出入口，让 Agent 收集证据、解释可能原因并提出下一步建议，再由工程师审核。
• 把 AI 提出的修复送回原有检查流程，避免用一份看似完整的分析替代实际验证。
• 接入 Agent 前，先明确它能执行哪些操作、哪些操作需要批准，并通过提示词之外的机制落实这些限制。