给 Agent 自动发布接 CI 时，我会先把产物包和发布密钥拆开
最近把一条 AI 技术图文自动化从本地脚本迁到 CI 时，我被一个细节提醒了：生成文章、生成图片、校验来源和发布到 CMS，像一条命令，风险却分布在不同阶段。生成阶段需要模型上下文和文件写入，发布阶段需要 Halo token，复跑阶段还要避免同一篇内容被重复推送。
原创示意图：把生成产物、校验报告、受保护审批、环境密钥和 Halo 发布动作拆成独立链路。 来源：Codex image generation
问题背景
GitHub Actions 的安全使用文档提醒，secret 的自动脱敏不能被当成绝对保证，工作流还要遵守最小权限，并收紧 GITHUB_TOKEN 的权限。部署环境文档也说明，deployment protection rules 可以在 job 进入目标环境前要求审批、等待或分支限制，environment secrets 会在满足环境条件后才对 job 可用。
这对 AI 自动发布很关键。Agent 生成的 JSON、封面图和正文配图属于待确认产物，CMS token 属于高风险发布权限，二者生命周期完全不同。如果生成 job 提前拿到发布密钥，日志里会多出一层没必要的敏感面。
踩坑和关键难点
第一个坑是复跑语义不清。重跑图片后，文章 slug 可能沿用旧值，说不清哪组产物被发布。第二个坑是人工审批太靠后，发布人只能看到日志，难以快速确认正文、图片、来源链接和 hash 是否一致。第三个坑是产物被改动后没有证据，JSON 通过校验，图片文件却可能已经换过。
解决思路
我把链路拆成三段。generate job 只负责生成文章 JSON、封面图、正文图和 manifest.json，manifest 记录标题、slug、图片路径、文件大小、sha256 和来源域名。validate job 只读产物，检查正文长度、分类标签、图片字段、来源链接、标题重复开头和禁用主题。publish job 单独绑定 production-cms 环境，只有人工确认后才读取 CMS secret。
GitHub 的 artifact attestations 文档强调，证明材料可以提供构建来源和完整性线索，但它不等于安全保证。因此我更倾向于给 manifest 和对外分发的构建物做签名或证明，普通正文图片至少保留 hash、上传记录和 run id。
关键步骤
第一步，生成脚本输出固定目录，禁止在生成阶段访问 Halo token。第二步，给每篇文章写稳定 slug，并在 publish 前调用最近文章检查，避免重名或重复选题。第三步，校验器把失败原因写成结构化报告，例如 missing_cover、source_domain_blocked 和 duplicate_heading。第四步，发布 job 使用受保护环境，审批通过后再读取 HALO_BASE_URL 和 HALO_TOKEN。第五步，发布完成后把 Halo 链接、图片数量和 manifest hash 写回 run summary。
可复用经验
这套拆法适合任何会产生外部副作用的 Agent 自动化。我的固定问题是：哪一步产生内容，哪一步验证内容，哪一步需要 secret，哪一步能重试，哪一步会影响外部系统。答案清楚后，CI 配置会自然分层，日志更干净。后续接邮件、知识库同步或桌面端内置发布，我也会沿用同一条边界：生成产物可复查，校验报告可追踪，发布密钥按环境释放，外部副作用带幂等键。
主要来源
GitHub Docs: Secure use reference