发布日期上午推迟了，运营助手已经改好说明，设计助手下午还在输出旧日期海报。两边都遵循自己聊天里的最后要求，却没有共同的当前版本。逐个补发通知可以救一次，助手多起来后就总有漏掉的一处。
先在共享文档或项目工具里确定当前要求，通常比增加系统更重要。原平台已经支持项目知识和更新通知，就直接用。跨工具执行时，可以让 EasyNet 接入读取这份确认稿的操作，而不是复制出另一份独立真相。
查询函数接受项目标识，返回批准版本、明确的生效要求和变化摘要。原项目系统负责保存及批准内容，Context 只保留入口。助手实际取得的是获准片段与版本，不需要把全部讨论历史搬到每个会话。
生成海报时保存所依据的版本，提交发布时再检查当前确认稿是否仍相同。版本变了就请负责人决定重做或继续，不能只靠助手承诺已看通知。这个提交检查、通知订阅和版本警告需要业务服务实现，链接可访问不等于自动同步。
查询与发布使用不同的权限，读取当前要求不同时授予对外发送。已发布材料也不会因为更改文档自动撤回，必须单独处理更正；输出文件应能追到对应版本和实际发布决定。
用两个助手分别生成同一任务，中途修改确认稿，再观察旧稿是否会在提交时被拦住。工作变得清楚之后，用户改一次批准来源，后续执行有共同的检查点，而不是相信每个会话都恰好收到了同一条消息。
- 01
读取 v3
取得当前批准的发布日期
- 02
生成海报
产物记录所用版本
- 03
提交前核对
发现 v4 则请求再确认
拦住旧稿提交
本地版本检查示例。真实提交服务必须原子核验当前批准版本，不能只在浏览器检查。
本地示例 · python
artifact = {"name": "launch-poster.png", "brief_version": 3}
approved_version = 4
status = "ready" if artifact["brief_version"] == approved_version else "needs-review"
assert status == "needs-review"
print(status)预期结果：输出 needs-review，不发布旧日期海报。
接入时的检查项
- 两个助手是否能读取同一份确认稿。
- 旧版本产物是否清楚标记而非混入当前交付。
- 提交前版本变化是否触发重新确认。