我做公众号内容自动化时踩的三个坑：MCP 工具拆分的取舍

richardlau

最近把公众号内容生产做成了一套 MCP Server（叫 RedCao），Agent 直接调工具就能完成起草、排版、入草稿箱、发布。

分享三个当时纠结、后来想明白的点。

第一个坑是"一个工具干完所有事"。最直觉的设计是：给个主题，直接返回排好版的 HTML。demo 很漂亮，但一上线就发现改不动了——因为内容生成和排版规则被塞进了同一个函数，公众号编辑器一改样式，我就要重写生成逻辑去改一个 class。

后来拆成四个独立工具：起草、排版、入草稿箱、发布。每一环都是确定性转换——同样的输入永远同样的输出。公众号改样式时，只动转换层那一层，生成逻辑一点不碰。

第二个坑是"失败了要不要抛异常"。排版时遇到一张图挂了、或者某个 emoji 编码有问题，一开始我直接抛异常。但对 Agent 来说，异常栈基本等于"重试或者放弃"——它没法从中恢复。

改成降级处理并回报："这篇文章有 3 处降级，需要你确认"。这样 Agent 才知道下一步该干什么。

第三个坑是幂等。排版接口因为网络超时被重复调用，产生了重复草稿。修法很便宜：给请求内容算个哈希，命中相同哈希就直接返回上次的结果。这个坑在并发场景下才显形，但一旦显形就是线上事故。

顺便说个心态上的变化：这套流程跑通之后我回头看，人工介入点就剩两个——发布前扫一眼草稿，和按下群发按钮。中间的搬运活儿全是确定性的。

自动化不是要替人做判断，是别再让人做机械劳动。

工具和文档在 https://mcp.redcao.com/ ，有问题欢迎提 issue。