最近我用一个真实技术选题跑了一遍多平台内容工作流：同一组核心材料，分别生成 CSDN、知乎、今日头条和掘金版本，再通过 MCP 进入各平台编辑器，填入标题、正文、封面和标签，最终停在人工发布之前。

这次实践最大的体会是：多平台分发的核心难点不是 LLM 生成文本，而是平台适配、浏览器执行、状态验证和副作用控制。

1. 需求不是“一篇文章发四次”

如果把任务定义成：

generate_article(topic) -> copy_to_four_platforms()

得到的通常只是四份格式相似、语气相同的内容。

更合理的抽象应该是：

source_material
  -> extract_invariants
  -> adapt(platform_profile)
  -> validate(platform_constraints)
  -> prefill(platform_editor)
  -> verify(editor_state)
  -> human_approve()

其中 extract_invariants 保存不能被平台改写破坏的事实、结论和引用；platform_profile 则决定标题、篇幅、信息密度和组织方式。

本次实践中，我采用了下面的适配规则：

平台	内容重点	结构倾向
CSDN	可实现性、代码和架构	问题 → 数据结构 → 方案 → 伪代码
知乎	原因、边界和推理	问题 → 反直觉点 → 论证 → 结论
今日头条	可读性、场景和节奏	现象 → 案例 → 方法 → 互动
掘金	工程实践和技术判断	Runtime 问题 → 设计模式 → 落地建议

平台适配不是替换几个近义词，而是重新组织信息优先级。

2. 母稿和平台稿应该分层

我把内容数据拆成两层。

第一层是平台无关的 Content Brief：

type ContentBrief = {
  topic: string
  audience: string
  coreClaims: string[]
  evidence: Source[]
  examples: Example[]
  forbiddenClaims: string[]
  callToAction?: string
}

第二层是平台产物：

type PlatformDraft = {
  platform: 'csdn' | 'zhihu' | 'toutiao' | 'juejin'
  title: string
  markdown: string
  summary?: string
  tags: string[]
  cover: string
}

这样做有两个好处：事实与引用只维护一份；某个平台的标题或结构发生变化时，不会反向污染其他平台版本。

3. MCP 解决的是“把能力接进来”

这次我用 Tipkay 作为 Agent 客户端，通过博客发布助手暴露的 MCP 工具完成登录检查和编辑器预填。

从 Agent 视角看，平台操作被抽象成类似下面的工具：

check_login(platform)
prefill_draft(platform, title, content, tags, cover, summary)
continue_prefill(platform, changed_fields)

这层抽象的价值不是让模型知道某个按钮的坐标，而是给模型一个结构化的业务动作。至于底层使用 API、WebView 还是浏览器自动化，可以由工具实现自行处理。

2026 年 7 月发布的新版 MCP 规范继续向可靠 Agent 基础设施演进，引入无状态协议核心、Multi Round-Trip Requests、基于请求头的路由、授权强化以及支持长任务的 Tasks 扩展。这类能力使 MCP 不再只是“给模型接几个工具”，而开始承担更完整的执行协议角色。

4. 实际执行中遇到的三个问题

4.1 登录状态不是常量

首次检查时，CSDN、知乎和掘金在线，今日头条显示未登录。再次进入登录流程后，工具识别到已有会话并恢复正常。

因此登录应该是每次任务的前置状态，而不是安装时检查一次：

const session = await checkLogin(platform)

if (!session.authenticated) {
  await requestInteractiveLogin(platform)
  await verifyLogin(platform)
}

4.2 语义正确不等于平台可接受

初始标签使用“人工智能”“AI Agent”“大模型”“架构”，但平台自动补全并不总能返回精确候选。

CSDN 后续根据真实候选匹配到 ai 和“人工智能”；掘金只匹配到“人工智能”。正确做法是保留 unmatched 状态，基于候选继续填写，而不是让 Agent 随便点击第一个结果。

type TagResult = {
  added: string[]
  unmatched: Array<{
    requested: string
    candidates: string[]
  }>
}

4.3 工具返回成功不等于页面正确

预填完成后，我又读取四个编辑器的页面状态，检查标题值、正文长度、图片数量和 selection。

验证逻辑可以简化成：

const expected = {
  title,
  minBodyLength: 1000,
  minImageCount: 1,
  selection: ''
}

const observed = await inspectEditor(platform)
assertDraft(expected, observed)

最后一项 selection === '' 看似不起眼，却能避免浏览器自动化结束后留下全选状态，导致用户下一次输入直接覆盖全文。

5. 为什么 autoSubmit 固定为 false？

发布会产生对外副作用，且各平台的校验、声明、活动选项和审核规则不同。自动化最适合完成确定性强、重复度高的部分；最终发布则需要人检查语义、排版和合规性。

await prefillDraft({
  platform,
  title,
  content,
  tags,
  cover,
  autoSubmit: false
})

这也是 Human-in-the-loop 的典型应用。人不是从头手动操作，而是在系统已经准备好完整草稿和执行证据后，只负责高价值判断。

6. 推荐的生产化闭环

Brief
  -> Platform Adapter
  -> Constraint Validator
  -> MCP Tool Call
  -> Editor Inspector
      -> failed: repair / continue_prefill
      -> passed: waiting_for_human
  -> Human Publish

每个平台至少记录这些字段：

type DistributionState = {
  taskId: string
  platform: string
  loginVerified: boolean
  draftId?: string
  filledFields: Record<string, 'ok' | 'failed' | 'unsupported'>
  unmatchedTags: string[]
  verificationEvidence: unknown
  status: 'prefilling' | 'needs_repair' | 'waiting_for_human'
}

如果进一步生产化，还应补充幂等键、超时重试、截图证据、DOM 变化检测和发布后的反查机制。

结论

Agent + MCP 能明显降低多平台运营里的机械成本，但它不应该被理解成“一键复制四遍”。好的内容工作流要同时解决三件事：平台定制、可靠执行和人工控制。

这次使用的是 Tipkay，不过产品本身不是重点。真正可复用的是下面这条边界：让 Agent 生成四个不同版本并填好页面，让人掌握最后的发布权。

当这条边界设计清楚以后，AI 才不是一个更快的复制粘贴工具，而是一个可审阅、可修复的内容工作流执行者。

参考资料：

• MCP 2026-07-28 Specification：https://blog.modelcontextprotocol.io/posts/2026-07-28/
• Chrome Agent Security：https://developer.chrome.com/docs/agents/security
• Cloudflare Human-in-the-loop：https://developers.cloudflare.com/agents/concepts/agentic-patterns/human-in-the-loop/