背景
个人技术网站通常由站长直接登录后台编写、修改和发布内容。随着 Agent 能够承担资料整理、草稿生成、格式校验和发布协作等工作，传统的后台直改模式会暴露出权限过大、操作不可追溯、误发布成本高等问题。
更稳妥的做法不是让 Agent 完全接管生产后台，而是把它纳入一个提交-审核模型：Agent 只负责产生待审变更，人类维护者负责最终判断、合并和发布。这样既能提升内容生产效率，也能保留个人网站的编辑主权。
统一提交入口
提交-审核模型的核心是统一入口。无论草稿来自本地编辑器、自动化脚本还是外部 Agent，都应该通过同一个 HTTP API 提交结构化变更。入口负责校验字段、记录来源、生成变更集，并把目标对象映射为文章、页面或配置项。
对于博客文章，提交内容至少应包含标题、slug、摘要、正文、标签和提交类型。API 不应直接写入已发布内容，而是创建待审记录。这样可以把“生成内容”和“发布内容”分离，也方便后续接入差异预览、内容 lint、敏感词检查和构建预检。
权限边界
Agent 的权限应该尽量窄。它可以提交草稿，但不应该登录管理后台；可以创建待审变更，但不应该直接发布；可以附带元信息和建议，但不应该绕过人工审核。
一个实用的边界设计是为 Agent 分配专用 Bearer token，并把 token 绑定到有限能力：只允许 POST 到提交接口，只允许创建特定 kind 的变更，只允许修改草稿态目标。服务端还应记录提交者、时间、来源 IP、payload 摘要和校验结果，避免后续排查时缺少证据。
审核与回滚
审核流程需要关注两件事：看得清和退得回。看得清意味着审核界面应展示 Markdown 渲染结果、原始内容、字段差异、标签变化和构建影响。退得回意味着每次批准都应形成可追踪的版本记录，并能从上一版本恢复。
对于个人网站，回滚机制不必一开始就很复杂。可以先把每次批准后的文章快照持久化，记录 changeSet 与目标内容版本的关系。当新内容出现格式错误、事实错误或 SEO 问题时，维护者可以快速恢复到前一版本，再重新提交修订。
实践建议
第一，把 Agent 的产出视为草稿，而不是事实来源。技术文章尤其需要人工确认命令、版本号、配置项和外部链接。
第二，让提交 API 做严格校验。slug、标题、摘要长度、标签白名单、Markdown 结构和必填章节都可以在入库前检查，减少审核阶段的低级返工。
第三，保留操作审计。谁提交、谁审核、何时发布、发布了哪些字段，这些信息决定了模型能否长期运行。
第四，从小范围开始。先让 Agent 参与博客草稿，再扩展到项目页面、变更日志或站点配置。个人网站的自动化不应追求一次性全托管，而应逐步把高频、低风险的环节交给 Agent。
第五，明确失败路径。提交失败要返回可读错误，审核拒绝要保留原因，发布后异常要能回滚。只有失败路径清楚，Agent 才能成为稳定协作者，而不是新的运维负担。