多 Agent 微信内容创作流

要解决什么问题

公众号长文往往卡在「素材散、结构不稳、改稿没有标准」：一个人既要搜案例又要写稿，评审意见也常和打分混在一起，最后还要手工套微信 HTML。这个技能把多 Agent 协作收成一条固定流水线：你给出主题和约束，主编调度子 Agent，直到评审分数达到阈值再交付排版好的 HTML。

工作流怎么跑

触发方式包括「写文章」「创作内容」「多Agent协作」、/创作 [主题] 等。主编收到指令后，典型路径是：

1. 并行调研与评估 — 调研员按 references/content-data-sources.md 汇总三类素材（人→人、人→Agent、Agent↔Agent）；评估员给出受众、时机与结构建议。
2. 写手出稿 — 写手依据 references/agents.md 与结构要求写完整正文；子 Agent 不执行文件操作，内容直接回传主编。
3. 评审与迭代 — 评审从主题契合度、结构清晰度、案例质量、洞察深度、可读性与传播性五维打分（各 20 分，满分 100，目标 ≥90）。第 1–5 轮及格线 85，第 6–10 轮 90；未达标则改稿再评，达标即停，不为了 polish 继续改。
4. HTML 交付 — 按 references/wechat-html-guidelines.md 与 references/template.html 生成 {文章标题}.html，样式必须全内联 CSS（微信编辑器会剥 <style>）。

团队角色与模板集中在 references/：agents.md、templates.md、article-writing-principles.md 等，评审报告与交付报告也有固定模板。

适用边界与坑

• 适用：从零写一篇面向微信传播的长文，并需要可量化质量门槛。
• 不适用：「多Agent做项目」应走 delegate_task 或 kanban-orchestrator；建 Skill 用 skill-factory；用户说「深化/重新解读已有素材」时主编应直接深度写作，不要再派调研员。
• 硬约束：输出路径为 Windows 桌面 /mnt/c/Users/Administrator/Desktop/；评审只打分、修改建议由主编汇总给写手；若评审未真正调用，必须如实告知用户。
• 迭代卡点：分数长期停在 78–83 时，往往是「洞察深度」需要观点突破，而不是加字数。