可靠的 Agent 发布流程应该把内容生成、版本检查、排版预览、正式发布和公开读回拆成独立步骤。每一步都有清楚的输入与失败条件，才能让自动化保持可审查、可停止和可追踪。
发布不是一次请求，而是一条可检查的流程
AI Agent 很容易生成一段看起来完整的文章，然后马上调用发布接口。但对真实网站来说，“能发送请求”不等于“适合自动公开”。标题可能与现有文章重复，资料来源可能过时，另一个编辑也可能刚刚修改同一篇内容。
更稳妥的做法，是把一次发布拆成几个独立关卡：检查目标文章、保存草稿、读回版本、预览排版、显式发布，最后再读取公开页面。任何一步不符合预期，都应该停止，而不是自动跳到下一步。
第一步：先检查 Slug，再建立草稿
Slug 是文章 URL 的稳定标识。Agent 在建立文章前，应先读取文章列表，确认目标 Slug 没有被占用。这样可以避免把“新建文章”意外变成“覆盖旧文章”。
新内容默认保存为草稿也很重要。草稿状态让系统有机会检查标题、摘要、分类、来源和 Markdown 正文，而不是把模型第一次输出直接暴露给公开读者。
第二步：让结构化资料与 Markdown 各司其职
文章标题、搜索说明、分类、发布日期、摘要和来源适合使用结构化字段；正文则适合使用 Markdown。两者分开后，Blog 列表、SEO 信息和文章页面可以稳定生成，编辑者仍能用纯文本维护正文。
Markdown 本身也必须经过安全渲染。系统不应执行正文里的原始 HTML 或脚本；链接应限制为允许的协议。CommonMark 规范提供了清楚的语法基础，但网站仍需要自己的安全输出规则。
第三步：用版本校验避免覆盖别人的修改
Agent 在修改或发布前，应重新读取当前文章，并取得最新 revision。随后把这个版本值放进条件请求；如果服务器发现版本已经变化，就返回冲突，让 Agent 重新比较差异。
RFC 9110 定义了 If-Match 条件请求的语义。它的价值不只是“多一个请求头”，而是把“我确认自己处理的是这个版本”变成服务器可以执行的保护条件。遇到版本冲突时，正确动作是停止和重新读取，不是盲目重试。
第四步：预览必须检查真实渲染结果
只检查 Markdown 原文不够。标题层级、列表、引用、代码、链接和长段落都可能在渲染后暴露问题。发布前应调用与正式页面相同的安全渲染器，确认输出包含预期结构，也没有把危险内容当作可执行 HTML。
预览通过后，Agent 才能使用刚刚读到的 revision 调用正式发布。这样，“内容正确”和“版本仍然正确”会在同一条流程里被验证。
第五步：密钥不能成为内容的一部分
Bearer Token 的特点是持有者即可使用，因此密钥不应出现在文章、前端代码、截图、操作日志或错误回显里。受控 Agent 只在运行时读取密钥，服务器只保存不可逆摘要，并提供独立吊销能力。
本地回环地址适合开发验证；真正对外提供 API 时，应使用 HTTPS、限制权限、设置限流，并把管理页面和个性化接口排除在公共缓存之外。OWASP 的 REST 安全建议也强调，受保护的 REST 服务应通过 HTTPS 传输认证资料。
第六步：发布成功后还要公开读回
API 返回成功，只能证明服务器完成了那次操作。Agent 还应再次读取文章资料，确认状态已经变成“已发布”，然后访问公开文章 URL 和 Blog 首页，检查标题、正文、分类、来源链接与索引入口是否真的出现。
一条可靠的自动发布流程，最后必须留下不含秘密的审计结果：做了什么、目标 Slug、成功或失败状态，以及公开页面是否读回。这样，人工管理员可以判断结果，而不需要接触 Agent 的密钥。
一份可以直接执行的发布清单
- 检查目标 Slug 是否已经存在。
- 准备结构化资料、来源和 Markdown 正文。
- 建立草稿，不直接公开。
- 重新读取文章与最新 revision。
- 使用服务端渲染器检查排版和链接。
- 以 If-Match 条件显式发布。
- 再次读取文章状态。
- 访问公开文章页和 Blog 首页完成读回。
自动化最有价值的地方，不是省掉所有人工判断，而是把重复步骤做得一致，把风险关卡变得清楚，并在条件不满足时可靠地停下来。