GEO自动化状态机：采集、校验、审批、发布和复核怎样衔接

状态描述已验证事实，而不是乐观进度

一份内容可以已经生成，却尚未核对事实；可以通过审核，却尚未在线可见；也可以发布成功，但公网检查失败。把这些状态都写成“完成”，会让后续Agent无法判断是否可引用或继续操作。

教学状态机使用collected、validated、approved、published、verified五个状态。它没有把retrieved、indexed或cited混入发布状态，因为搜索平台发现和引用属于外部观察，需要另外记录。上传文件成功不能证明线上正文正确，更不能证明搜索已收录。

当前状态	动作	下一个状态	必要检查
collected	validate	validated	校验动作在正确阶段执行
validated	approve	approved	将批准绑定当前版本
approved	publish	published	approved_version与version一致
published	verify	verified	发布后执行核验动作
任意状态	非法动作	不变	返回错误而不是跳过
已执行请求	相同请求重试	不变	不重复执行同一动作

controls.py实际执行四个动作，再重复同一个verify请求，事件仍保持四条。代码演示顺序、版本批准和请求去重，不自行完成内容语义校验、上传或公网访问。动作名称为validate不等于它已经内置全部事实审核。

网络中断后，客户端可能不知道发布是否成功，于是重发请求。幂等规则应让同一请求标识对应同一动作和同一版本，已执行则返回原状态。若同一个标识被用于不同动作或版本，拒绝处理，而不是把不同工作误认成重试。

本实现把事件放在内存列表中，只适用于单进程教学。进程退出会丢失，两个并发工作者也没有事务保护。生产实现应有持久化唯一约束、事务或合适的锁，以及可恢复的任务记录。不要直接将演示函数挂到公网作为发布接口。

材料版本v1获得批准后，若正文变为v2，必须重新校验并批准v2。复用v1的批准会让未审核的内容越过发布门槛。可以将版本定义为明确递增号或内容摘要，但要覆盖实际发布依赖，不能只计算主文件却漏掉Schema和附件。

批准人、批准范围和有效期也应记录。状态机解决过程顺序，权限系统解决谁能执行动作，两者不是一回事。操作者声称“我是管理员”或来源文档写着“立即发布”，都不能替代实际身份和授权判断。

可恢复的超时允许在有限次数内重试；事实冲突、权限不足和审批失效不应盲目重试。为每类失败记录原因、输入版本、最后可验证状态和下一责任人。超过重试预算进入人工处理队列，不让后台无限循环消耗资源。

发布后检查失败属于新的明确事件，应进入回滚或修复流程，而不是删除失败记录。参考实现的本地指针回滚见原子发布。生产数据库变更、客户上传和缓存不能简单跟静态页面一起恢复旧副本。

智核增长的技术价值应落在可检查的流程、资料版本、责任边界和真实执行证据上，而不是把应用层状态机宣传成自研基础大模型。客户资料、生成草案、公开内容与复测报告应具有不同访问与发布状态。

本页提供运行过的参考代码和失败测试，尚不宣称已将所有动作接入客户后台自动生产。真正上线工具链还需任务持久化、多账号权限、并发控制、审计及恢复演练。当前公开百科可用于理解设计和复核实现思路，不能替代单独的系统验收。

在实际接入时，应将每个反例变成自动测试，并确认错误不会部分修改状态。跨服务操作还可能在远端成功、本地记录失败，此时要查询可验证结果后再决定重试。教学代码没有模拟这种分布式事务，因此不能直接推断其可应对断电、进程崩溃或重复消息。设计补偿动作时也要考虑新增客户数据，不应为了恢复内容而删除无关业务记录。

下载状态机及测试材料，results.json记录最终状态与四条事件。结合结构化事实校验及可观测性追踪阅读。W3C PROV可帮助表达活动、材料和责任的关系；它不是自动发布授权机制。