接入 CI 与自动化检查流水线

官方提供新版 GitHub Action，并支持在 Shell 工作流中用 codex exec 接入自动化。CI 中的代理定位应是"隔离流水线里的协作者与检查员"：产出评审建议、受限补丁或检查结论，再由既有门禁和人工收口，而不是在无人值守环境里自动合并代码。本节给出流水线集成要点、安全与质量门禁设计，以及常见落地形态；Action 的具体名称、触发字段与配置以当前官方仓库说明为准。

一、CI 中代理的正确定位

环节	推荐做法
代码获取	流水线独立检出提交（PR 或指定 ref），不挂载开发者本地脏工作区
运行权限	默认受限/只读或工作区内可写；不以高权限身份直连生产环境
产出方式	生成评审意见、检查结论、建议补丁或制品文件，供人评审与既有流程采用
合并控制	代理结果不绕过测试、构建、代码评审与分支保护，不自动推送到主干
状态反馈	把成功/失败/建议摘要写回检查状态或评论，保持流水线可观测

二、流水线集成关键要点

1. 触发时机明确：常见为 Pull Request 触发、定时巡检或手动发起；不同任务对应不同触发方式，避免全量高频运行造成成本与噪声。
2. 环境隔离与依赖一致：在标准镜像/检出中安装 CLI 与项目依赖，保证运行条件可复现，减少"本地能跑、流水线报错"的环境差。
3. 任务输入结构化：把差异范围、检查清单、期望产出格式与禁区写成明确输入，让代理知道看什么、交付什么。
4. 凭据最小化：使用流水线提供的短期、最小权限凭证；不把长期密钥写入配置或日志，产物中不出现真实密钥。
5. 结果回传：将建议以评审评论、检查状态、报告文件或建议补丁形式输出，避免结果只留在无人可读的日志里。
6. 失败与限流：区分"任务报错""检查发现问题""无建议"三种结果；对运行频率、资源与额度设上限，失败保留日志便于排查。

三、安全与质量门禁设计

防线	设计要点（结合官方安全原则）
执行边界	受限沙箱与工作区边界，超出边界的写操作不自动放行
命令规则	只读检查类命令可放行，安装、删除、联网、部署等高风险动作在 CI 中默认受限或禁用
网络策略	最小可达范围与白名单；未知来源下载、外发数据先拦截确认
既有测试门禁	单元测试、类型检查、构建、静态检查仍由传统门禁把关，代理建议不替代自动化测试
人工评审	建议补丁与结论进入常规 PR 评审，由人确认后合并
审计留痕	保留任务输入、审批决策、工具执行与网络放行/拒绝记录，便于追溯异常行为

四、常见落地形态与收口方式

落地形态	主要产出	人工/门禁收口
自动化代码评审建议	质量、隐患、可读性建议评论	评审人筛选采纳，不直接自动改代码
规则类问题修复建议	针对类型、风格、明显缺陷的建议补丁	跑通测试与构建后人工合并
变更说明与文档生成	基于差异生成更新说明或文档草稿	编辑校核后发布
依赖与升级风险提示	依赖变更影响、测试覆盖缺口提示	安全与维护者复核，不自动升级关键依赖
定时健康巡检	代码库现状报告、技术债清单	纳入迭代计划，分批处理

五、FAQ

问题	处理建议
Action 怎么配、YAML 字段是什么	以官方 GitHub Action 仓库当前 README 与示例为准；先在手动触发任务上验证稳定，再固化到常规流水线。
能否让 CI 自动合并代理修复	默认不建议；至少应通过自动化测试、构建与人工评审，主干分支保持分支保护。
代理建议很多、噪声大怎么办	收窄任务范围、提供检查清单、只在关键路径启用；把低价值建议改为提示而非阻断。
如何控制 CI 中的运行成本与额度	限定触发场景与频率、优先只读分析、设置超时与并发上限、复用缓存，定期复盘必要性。

六、动手练习

• 练习：为一个已有仓库设计"PR 只读评审建议"流水线草图：写明触发方式、隔离检出、只读边界、允许的命令与网络限制、产出回传到哪里、由哪道既有测试/评审门禁兜底；先不追求全自动合并。