最近我用一个真实技术选题跑了一遍多平台内容工作流同一组核心材料分别生成 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 BrieftypeContentBrief{topic:stringaudience:stringcoreClaims:string[]evidence:Source[]examples:Example[]forbiddenClaims:string[]callToAction?:string}第二层是平台产物typePlatformDraft{platform:csdn|zhihu|toutiao|juejintitle: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、知乎和掘金在线今日头条显示未登录。再次进入登录流程后工具识别到已有会话并恢复正常。因此登录应该是每次任务的前置状态而不是安装时检查一次constsessionawaitcheckLogin(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:}constobservedawaitinspectEditor(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:Recordstring,ok|failed|unsupportedunmatchedTags:string[]verificationEvidence:unknownstatus:prefilling|needs_repair|waiting_for_human}如果进一步生产化还应补充幂等键、超时重试、截图证据、DOM 变化检测和发布后的反查机制。结论Agent MCP 能明显降低多平台运营里的机械成本但它不应该被理解成“一键复制四遍”。好的内容工作流要同时解决三件事平台定制、可靠执行和人工控制。这次使用的是 Tipkay不过产品本身不是重点。真正可复用的是下面这条边界让 Agent 生成四个不同版本并填好页面让人掌握最后的发布权。当这条边界设计清楚以后AI 才不是一个更快的复制粘贴工具而是一个可审阅、可修复的内容工作流执行者。参考资料MCP 2026-07-28 Specificationhttps://blog.modelcontextprotocol.io/posts/2026-07-28/Chrome Agent Securityhttps://developer.chrome.com/docs/agents/securityCloudflare Human-in-the-loophttps://developers.cloudflare.com/agents/concepts/agentic-patterns/human-in-the-loop/