华盛顿邮报为何拆分多个AI Agent：内容运营的岗位化架构设计

xierui123123

413人浏览 · 2026-08-29 20:46:15

xierui123123 · 2026-08-29 20:46:15 发布

摘要：华盛顿邮报和 Tech in Asia 最新公开的 AI 实践，都没有把内容工作简化成“自动写稿”。本文从目标、上下文、权限、交接和验收五条边界出发，给出适合小团队的岗位化 Agent 架构与落地方式。

做内容 Agent 时，最容易写出的 Demo 是：输入一个主题，生成一篇文章。

但 8 月 28 日 OpenAI Academy 公布的两个新闻机构案例，给出了另一种答案。Tech in Asia 的 Duc Tran 用 Codex 辅助制作每周刷新招聘数据、生成追踪链接、集中保存公司知识、次日在 Slack 推送文章数据等内部工具，案例同时明确写道：数据自动更新，文章由他本人完成。

华盛顿邮报走得更远，却也没有做一个“万能 Agent”。它按内容、广告、订阅等业务问题拆分 Agent，让它们使用不同的数据、指标定义和权限逻辑。

这两个案例值得开发者关注的不是媒体行业本身，而是一个通用架构问题：当 AI 从生成文本走向执行真实工作，应该按什么边界拆分？

别招一只万能章鱼

为什么一个 Agent 不该同时拿走所有上下文

把全部能力塞进一个 Agent，看起来最省工程量：

const agent = new Agent({
  instructions: allPrompts,
  knowledge: allBusinessFiles,
  tools: allTools,
  permissions: ['read', 'write', 'publish', 'analytics']
});

问题是，内容运营的各个步骤拥有完全不同的失败模式。

调研失败，通常是来源过期、事实混淆；
写作失败，可能是口径漂移、结构平庸；
发布失败，可能是标题超限、图片缺失、账号掉线；
复盘失败，可能是指标定义不一致，把短期波动当成结论。

一个大 Agent 把它们放进同一个上下文和权限域，错误会互相放大。更具体地说，它会遇到四类耦合：上下文污染、权限膨胀、状态混杂和验收模糊。

岗位化架构要拆五条边界

岗位不是角色扮演提示词，而是一份可执行合同。

type RoleContract = {
  goal: string;
  inputs: ArtifactRef[];
  allowedContext: ContextRef[];
  allowedActions: Action[];
  outputSchema: JsonSchema;
  acceptance: Check[];
  humanConfirm?: Action[];
};

1. 目标边界

研究 Agent 的目标是交付带日期和来源的事实清单，而不是顺手写一篇“听起来像真的”文章。发布 Agent 的目标是完成平台字段并取得回执，不应该临时改动中心观点。

2. 上下文边界

给岗位最小充分上下文。品牌语气和禁忌词属于平台编辑；平台登录态属于发布执行；广告指标定义属于复盘。所有资料长期常驻一个大 Prompt，不仅成本高，也让模型难以判断什么才是当前任务的权威信息。

3. 权限边界

研究只读公开网页，编辑写本地文件，发布只预填平台，最终提交由人确认。权限应随岗位和步骤收窄，而不是因为 Agent “可能有用”就提前授予。

4. 交接边界

Agent 之间传递结构化产物，而不是整段聊天记录。

{
  "topic": "AI 编辑部岗位化",
  "verified_facts": ["..."],
  "sources": [{"url": "...", "checked_at": "2026-08-29"}],
  "platform": "juejin",
  "assets": ["cover.png", "explainer.png"],
  "pending_steps": ["prefill", "dom_verify", "submit"]
}

这会让版本管理、失败恢复和模型替换都更简单。

5. 验收边界

每个岗位都要有可观测的完成条件。研究检查来源；写作检查事实、差异度和图片；发布回读标题、正文、封面、标签，再到成功页或作品管理确认作品 ID。Agent 自己说“完成了”不是验收证据。

一人公司也要分岗位

适合小团队的四岗位最小架构

不需要复制华盛顿邮报的数据系统。一人公司可以从四个岗位开始。

岗位	主要输入	核心输出	权限建议	验收
选题研究	官方资料、历史选题	事实清单、来源、风险点	只读网络	来源日期与事实一致
平台编辑	事实清单、品牌包、平台规则	差异稿、摘要、标签、图片需求	写本地文件	事实、风格、平台差异
发布助手	稿件、图片、本机登录态	平台预填、提交回执	平台写入；关键动作确认	成功页、作品 ID、审核状态
复盘助手	作品 ID、平台数据、历史基线	下一轮单变量建议	只读数据	指标口径一致、不过度归因

调用链也不用复杂：

Research Brief
  → Platform Drafts
  → Publish Package
  → Platform Receipt
  → Review Note

关键是每一步都有持久化产物。任务中断后，下一次从 pending_steps 继续，而不是让 Agent 凭聊天记忆猜已经做到了哪里。

多 Agent 的成本不能忽略

岗位拆分会增加路由、交接和状态管理。如果任务只做一次、权限风险低、几分钟就能人工验收，一个 Agent 从头做到尾更合适。

通常出现下面三个信号，才值得拆：

同一流程反复运行，已经形成稳定步骤；
不同步骤需要明显不同的数据或权限；
一次失败会影响真实账号、多个平台或后续业务。

先把流程跑通，再把稳定环节岗位化。否则“多 Agent 架构”很可能只是把一次调用变成四次转述。

Tipkay 的取舍：岗位先于统一入口

这也是我们做 Tipkay 时的一项架构取舍。官网当前把博客发布、公众号编辑、小红书运营、视频制作等定义为不同 AI 员工。岗位带着自己的业务上下文、流程、Skill 和 MCP，也可以把结构化产物交给下一位员工。

以发布岗位为例，它的任务不是发明观点，而是按平台改写、处理图片和字段、使用本机已有登录态预填、在关键操作前交还确认，再记录成功页和状态。用户还可以从官方员工复制专属版本，把稳定流程设成定时任务。

这不代表 Agent 越多越好，也不代表跨岗位协作天然没有沟通成本。真正有价值的是把目标、资料、权限和验收留在岗位里，而不是都绑在一个越来越长的聊天框里。

如果你的内容 Agent 同时拥有全部资料、全部工具和全部发布权限，不妨先问一句：这是一个员工，还是一只握着所有钥匙的“万能章鱼”？

参考资料

Tech in Asia 编辑部案例：https://academy.openai.com/public/blogs/how-a-journalist-uses-openai-to-build-tools-for-his-singapore-newsroom-2026-08-28
华盛顿邮报分析 Agent 案例：https://academy.openai.com/public/clubs/news-organizations-b9osl/resources/how-the-washington-posts-builds-ai-agents
Tipkay：https://www.tipkay.com/