别让 Agent 只会写脚本：用 Producer 模式编排内容生产

一个内容 Agent 能生成脚本，不等于它能负责内容生产。

脚本之后还有事实核验、素材依赖、视觉交付、平台版本、页面字段、人工审批和结果回读。把这些全塞进一条超长 Prompt，最后通常得到的不是自动化，而是一段很难判断停在哪一步的聊天记录。

最近一个很有意思的信号来自 MrBeast。Google 9 月 2 日宣布与 Beast Industries 展开多年合作，并写明 9 月 5 日视频里的团队会在丛林、沙漠和北极环境使用 Gemini 识别危险、应对天气变化。公告还预告，后续广告会展示 Gemini 协助大型项目的后勤协调。

我更在意"后勤协调"这四个字。对内容系统而言，Agent 最实用的位置可能不是总导演，而是 Producer：人决定为什么做、对谁说、承诺什么；Agent 负责把工作拆开、衔接和交付。

先定义 Human Gate

不少 Agent 工作流先考虑哪些步骤可以自动化，最后才补人工确认。Producer 模式更适合反过来：先标出不可下放的决策，再设计自动化范围。

一条内容链至少有三个 Human Gate：

ts 复制代码

type HumanGate =
  | "FACTS_APPROVED"
  | "BRAND_APPROVED"
  | "PUBLISH_APPROVED";

FACTS_APPROVED：动态数据、产品承诺和引用范围已核对；
BRAND_APPROVED：立场、语气和受众判断符合业务目标；
PUBLISH_APPROVED：当前页面上的最终版本可以公开。

它们不是为了给流程增加三个弹窗，而是把责任边界固化进系统。内容可以自动生成，公开承诺的责任不会因此自动转移给模型。

Producer 管的是依赖图

"写一篇文章"在聊天框里是一项任务，在生产系统里却是一张 DAG：

text 复制代码

             ┌─> CSDN draft ─> metadata ─┐
brief -> facts ─> Juejin draft ─> metadata ├─> review -> prefill -> verify
             └─> Toutiao draft -> metadata┘
                  └────> visual brief -> assets ────────┘

事实清单是三个平台稿的共同依赖，视觉 brief 同时依赖核心观点与平台比例，发布动作又依赖正文、封面、摘要和审批状态。只要把它们当成一段顺序文本，某一步变化就很容易产生隐蔽的旧版本。

因此，每个节点至少应返回四项信息：

json 复制代码

{
  "artifact": "platforms/juejin.md",
  "status": "ready_for_review",
  "dependsOn": ["facts@sha256:...", "cover@sha256:..."],
  "nextGate": "BRAND_APPROVED"
}

artifact 让结果可回读，dependsOn 让版本可追踪，nextGate 则告诉编排器下一步能否继续。相比"已为你完成"，这几个字段更像真正的交付。

六个状态比一个 done 更可靠

Producer 不应该只维护任务列表，还要维护状态：

ts 复制代码

type ProductionState =
  | "BRIEFED"
  | "RESEARCHED"
  | "PRODUCED"
  | "REVIEWED"
  | "PREFILLED"
  | "VERIFIED";

两个边界尤其重要。

第一，RESEARCHED 不等于"搜过网页"。它应该有来源、核验时间、官方事实、合理推断和禁写断言。平台编辑可以改变表达，不能越过这一层创造新事实。

第二，PREFILLED 不等于"发布成功"。标题、正文和图片进入页面后，系统还要回读分类、标签、封面与声明；点击发布后，再从成功页、文章链接或作品管理记录确认。网络超时也不能靠连续点击解决。

垂类 Agent 的价值在验收函数

为什么不让一个通用 Agent 装上所有工具？可以，但工具数量并不会自动产生岗位经验。真正影响结果的是每个环节有没有对应的验收函数。

ts 复制代码

const gates = {
  researcher: hasSourceForEveryDynamicClaim,
  editor: hasNoUnverifiedClaim,
  designer: hasReadableTextAndCorrectRatio,
  publisher: hasVerifiedPlatformState,
};

研究 Agent 的完成标准不是写得顺，而是动态事实有来源；视觉 Agent 的完成标准不是"生成了图片"，而是文字清楚、比例正确、没有水印；发布 Agent 的完成标准不是调用工具成功，而是页面状态可确认。

上下文也应该按岗位最小化。编辑需要品牌与事实，未必需要浏览器登录态；发布岗位需要最终产物和平台规则，不应该重新改写核心观点。这能同时降低上下文噪声和权限暴露。

从一份生产清单开始

如果不准备搭复杂编排器，先用一个目录也够：

text 复制代码

topic/
├── brief.md
├── facts.md
├── assets/
├── platforms/
│   ├── csdn.md
│   ├── juejin.md
│   └── toutiao.md
└── delivery.md

brief.md 保存目标、受众、核心信息和人工 Gate；facts.md 只保存可核验内容；delivery.md 记录各平台时间、状态、链接与失败原因。下一次迭代时，不必重新从整段会话中拼凑发生过什么。

这也是我们做 Tipkay 时采用岗位化 AI 的原因之一。官网目前写明，不同 AI 员工围绕同一业务目标按岗位分工，结合业务资料完成流程并互相协作；本地素材与平台登录态留在用户电脑，发布等关键操作仍由用户确认。这个实现不是 Producer 模式的唯一答案，但它试图把"岗位经验、工具和验收"一起装进员工，而不是只增加一个聊天入口。

内容生产需要的从来不只是一个更会写的模型。让人掌握导演权，让 Agent 管好依赖、状态和交接，才有机会把一次生成变成稳定交付。

参考资料：

Google 官方公告：blog.google/company-new...
Tipkay 官网：www.tipkay.com/