我做一期视频时，会先用 AI 剪辑、加字幕，最后再分别上传到小红书、抖音、B 站和视频号。剪辑完成后，重复填写标题、标签、声明和封面的工作仍然很多，所以我写了 video-publisher Skill，把发布前的准备交给 Codex 和四个子 Agent。
这套流程不会替我点击最终发布按钮。Agent 负责把各个平台的草稿准备好，我负责确认字段和发布结果。
在 Codex 里触发这个 Skill，再附上视频链接，任务就会开始。
从线性脚本改成 Agent 流程
我最早想把整个发布过程写成一个线性脚本，让 AI 调用脚本后直接执行到底。实际使用时，这条路并不稳定。不同平台的表单和状态经常变化，还会遇到登录、标签候选、封面裁切和风控提示。脚本遇到这些情况，只能不断增加特判，维护成本越来越高。
现在我保留固定的准备步骤，把需要判断页面状态的操作交给子 Agent：
- Codex 按照我在 Skill 里写好的规则，给视频生成标题和标签。标题通常和视频文件名对应，即便不对应，Skill 里也写清楚了我平时起标题的方式。
- Codex 让我选择要发布到哪些平台。新视频一般发全部平台，存量视频可能小红书已经发过，就单独选择剩下的平台。
- Codex 为每个平台写一份发布清单，每个平台对应一个 JSON 文件。
- 这些 JSON 文件会分发给不同的子 Agent，每个子 Agent 负责一个平台的实际发布。
先把平台差异拆开
同一个视频不能拿一份统一表单机械填写。不同平台的标题、标签和声明规则各不相同，所以我先把每个平台的要求分别写进规范：
- 标题风格不同。同一个视频，发到四个平台的标题写法不一样。
- 标签不同。比如抖音我有固定的四个标签，小红书也有平时固定带的标签。
- 表单不同。有的平台要开启原创声明，有的平台要开启内容声明，需要勾选的选项都不一样。
标签输入能说明为什么需要现场判断。输入文字后，还要从下方出现的候选中选中对应条目，平台才会把它识别成实体标签。匹配结果和预期不一致时，子 Agent 需要先读取当前页面，再决定下一步动作。
再把四个平台放到独立空间
实际操作在 Ego Lite 里完成。发布任务开始后，AI 会创建四个独立 Space，每个 Space 对应一个平台，在后台分别填写表单。四个平台可以并行处理，登录状态和页面操作也不会混在同一组标签页里。如果某个平台没有登录，Agent 会停下来提醒我处理。
Skill 只保存可以复用的流程
video-publisher 的 references 目录保存了四个平台各自的规范文档。它们记录每个平台要填写什么、如何判断状态和在哪里停下，本身不是可以直接执行的脚本。
这些规范来自我和 Agent 对平台后台的实际探测。我们先走通一次发布过程，再把可以重复的步骤和判断条件记录下来。下一次遇到相同状态时，子 Agent 有依据可查；页面出现意外情况时，它仍然需要根据现场信息处理。
Skill 里还有一份 Ego Browser 的 workflow，指导 AI 怎么用 Ego Browser 的命令完成自动化操作，比如怎么识别页面状态、怎么填字段、每步之间等多久、什么时候判定卡住并上报。
子 Agent 负责现场执行和反馈
每个平台由一个单独的子 Agent 负责。Codex 的 agents 目录下有四个平台的描述文件，里面写清楚了发布入口和需要读取的规范文件。主 Agent 只负责准备信息和调度，不在四个后台之间来回切换。
描述文件里还有一条规则：子 Agent 在发布时遇到问题，需要把确认过的解决办法写回 Skill。这样下一次执行可以直接使用新规则，不必重新摸索同一个问题。
最终结构是一位主 Agent 负责调度，四个子 Agent 分别处理一个平台。
需要选择实体标签、处理封面裁切或识别异常提示时，子 Agent 可以根据页面反馈调整操作。这也是它相对线性脚本的主要价值。
发布前由我本人确认
即便使用子 Agent，发布过程仍然不完全稳定。我给流程加了两个限制：点击最终发布前必须等我确认；无论 Agent 报告的结果是什么，稍后我都会再检查一遍每个平台。多数时候视频、标题和标签已经准备好，个别字段仍可能需要我手动纠正。
确认过的平台变化会由子 Agent 写回对应的 Skill 文件，下一次执行可以继续使用。人工确认没有被自动化取消，它变成了流程里明确的一道边界。
