如何让 AI 智能体发布社交媒体内容

让一个助手拥有发布能力，本质上是一个权限范围和审核方式的问题。这篇文章介绍三种接入方式，以及应该先设置好的护栏。

让助手起草一条帖子很简单。让它发布出去则是另一种性质的决定，而有意思的部分不在于连接方式的技术细节，而在于它出错时会发生什么。

下面讲讲这种接入是怎么运作的，以及你在动手之前需要先做出哪些决定。

三种接入方式

MCP，适用于像 Claude 这样的助手，或者具备 AI 能力的编辑器。Model Context Protocol 是这类应用与外部工具对话的方式，一个 MCP 服务器会把发布功能暴露成助手可以直接调用的工具。这是工作量最小的方式：连接好服务器，助手就能在对话中撰写、排期和查看帖子。

API key，适用于你自己编写智能体的情况。你的代码持有你自己账号的 key，直接调用 API。做法简单，而且当智能体只代表你自己行动时，这样做是正确的。

OAuth，适用于你的产品要代表别人的账号行动的情况。每个用户都授权你的应用，而不是把 key 粘贴给你。如果你在构建多用户的产品，就应该用这一种，让用户粘贴 API key 是一个你以后必须迁移掉的错误做法。

BulkPublish 三种都提供：一个发布在 npm 上、名为 @bulkpublish/mcp-server 的 MCP 服务器、API key 认证，以及面向”代表其他用户行动”的应用的 OAuth 2.1。

一个向真实受众发布内容的智能体，出错的方式和人类通常不一样。不是打错字，而是自信满满、看起来完全合理，却是错的。一条帖子里编造出来的统计数字，读起来和真实数据一模一样。

所以第一个要做的决定不是技术性的，而是：在”生成内容”和”发布内容”之间应该发生什么。

默认草稿。 智能体把帖子创建为草稿，由人来审核、由人来发布。这保留了智能体所有有用的部分，同时消除了几乎所有风险。对大多数人来说，这是正确的默认设置，而且他们永远不会需要改变它。

审批流程。 智能体把内容放入队列，由指定的人来批准。思路相同，但多了一份审计记录，这对团队来说很重要。

延迟排期发布。 智能体把发布时间设在稍后，而不是立即发布，留出一个窗口来发现问题。这比人工审核弱一些，因为它依赖于有人真的去看。

直接发布。 适合范围狭窄、定义明确的任务，内容是模板化的而不是生成式的：例如状态页更新、根据变更日志生成的新版本发布公告。对于任何从零开始撰写关于你公司的文字内容来说，这种方式都远远不够合适。

给智能体能完成任务的最小访问权限。

之所以值得这样做，是为了撤销权限的方便。出问题的时候，你希望在凌晨两点只切断这一件事，而不是轮换整条流水线都在用的那把 key。

永远不要让它陈述关于你产品的具体数字。 价格、方案限额和功能数量都会变化，而模型很乐意生成一个看起来合理但错误的数字。任何关于你的事实性内容，都应该来自数据源，而不是生成。

给它真正的品牌语气。 一个没有风格指引的智能体，写出来的文字一看就是智能体写的，这本身就是一种声誉损失。

盯住发布量。 发布配额不只是计费档位的划分，也是防止死循环的一道保险。一个陷入重试循环的智能体，能在很短时间内产出大量帖子。

任何敏感内容都要保留人工把关。 涉及新闻、争议或道歉的内容，不应该交给智能体处理。

帖子可以被创建为草稿而不是直接发布，这是值得作为起点的设置。

给助手用的接入方式选 MCP，给你自己的智能体用 API key，代表别人行动就用 OAuth。在决定其他任何事情之前，先决定审核环节，让凭证保持独立且权限收窄，永远不要让模型生成关于你自己产品的具体事实。默认草稿的成本几乎为零，却能消除几乎所有风险。