用 Agent + MCP 做多平台内容分发：从母稿到四个平台草稿-拓冰企业网站定制

最近我用一个真实技术选题跑了一遍多平台内容工作流：同一组核心材料，分别生成 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：

typeContentBrief={topic:stringaudience:stringcoreClaims:string[]evidence:Source[]examples:Example[]forbiddenClaims:string[]callToAction?:string}

第二层是平台产物：

typePlatformDraft={platform:'csdn'|'zhihu'|'toutiao'|'juejin'title:stringmarkdown:stringsummary?:stringtags: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、知乎和掘金在线，今日头条显示未登录。再次进入登录流程后，工具识别到已有会话并恢复正常。

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

constsession=awaitcheckLogin(platform)if(!session.authenticated){awaitrequestInteractiveLogin(platform)awaitverifyLogin(platform)}

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

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

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

typeTagResult={added:string[]unmatched:Array<{requested:stringcandidates:string[]}>}

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

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

验证逻辑可以简化成：

constexpected={title,minBodyLength:1000,minImageCount:1,selection:''}constobserved=awaitinspectEditor(platform)assertDraft(expected,observed)

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

5. 为什么`autoSubmit`固定为 false？

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

awaitprefillDraft({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

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

typeDistributionState={taskId:stringplatform:stringloginVerified:booleandraftId?:stringfilledFields:Record<string,'ok'|'failed'|'unsupported'>unmatchedTags:string[]verificationEvidence:unknownstatus:'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/

资讯详情

用 Agent + MCP 做多平台内容分发：从母稿到四个平台草稿