一个向社交媒体发布内容的智能体，和一个人来做这件事，需求是不一样的，而这些不同大多来自同一个事实：它动作发生的那一刻，没有人在盯着。
这篇文章是评判一个供智能体使用的发布 API 的检查清单，每一项背后都附有对应的失败模式。如果你想看如何接入智能体并安全设置的实操步骤，请看 如何让 AI 智能体发布社交媒体内容。API 本身的产品页面是 面向 AI 智能体的社交媒体 API。
智能体需要而人不需要的东西
一个真正有用的草稿状态。 不是一个隐藏的队列，而是人能看到、能审阅、能亲手发布的帖子。这是智能体发布场景里最重要的功能，也是最常被当作事后补充的功能。
在创建帖子时就校验。 一个人会注意到文案太长。智能体不会，而如果校验发生在发布那一刻，失败会在几个小时后才浮现，那时智能体早已不在了。错误必须在创建调用时就返回，智能体才能做出反应。
限定范围、可撤销的凭证。 和你其他的 key 分开。出问题时，你想要的是精准撤销这一个智能体，而不是去轮换你的生产管道共用的那个凭证。
能阻止循环失控的配额。 一个重试循环能在很短时间里产生大量帖子。这里的硬性上限是一个安全功能，而不只是一个计费档位。
结构化的错误信息。 智能体能针对“在 x 平台上文案超过了 280 个字符”这样的信息采取行动。但它无法针对一个笼统的 400 错误采取任何行动。
需要针对性设计防范的失败模式
自信地编造。 模型会生成一个看似合理的统计数字、价格或功能声明，而不是承认自己不知道。任何事实性内容都不应该由模型生成。事实应该来自你的代码所控制的某个来源。
重试风暴。 一个把超时当作失败并去重试的智能体，可能会产生重复的帖子，因为一次超时的创建请求也许其实已经成功了。重试必须是安全的或经过核对的，绝不能盲目进行。
在错误的时机发布。 智能体不知道今天是不是不适合发一条轻松愉快的内容。任何涉及新闻或争议的内容都需要有人来把关。
语气漂移。 放任不管的话，生成的帖子会趋于同一种腔调，而受众会比你更早注意到这一点。
可以向任何发布 API 提出的问题
| 问题 | 好的回答是什么样 |
|---|---|
| 帖子能保存而不发布吗？ | 能，通过同一个接口保存为草稿 |
| 限制在什么时候检查？ | 在创建时，并且错误信息里会点明是哪个平台 |
| 能限制 key 的权限吗？ | 可以按权限范围限制，并且可以单独撤销 |
| 超时之后会怎样？ | 重试之前，你可以先查到这条帖子 |
| 什么能阻止循环失控？ | 每日请求数上限和每日发帖数上限 |
BulkPublish 提供了什么
- 连接方式： 面向助手的 MCP 服务器、面向你自己代码的 API key、用于代表他人账号行事的 OAuth 2.1
- API： 有完整文档的 REST API，覆盖帖子、排期、媒体、频道、标签、分析、RSS feed 和配额
- 校验： 字符数限制和各平台的媒体规则在创建帖子时检查，而不是在发布时
- 平台： 15 个
| Free | Pro | Business | |
|---|---|---|---|
| 每日 API 请求数 | 10 | 5,000 | 50,000 |
| API key 数量 | 1 | 5 | 10 |
| 帖子数量 | 每天 1 条 | 每天 30 条 | 无限 |
OAuth 的权限范围是精细化的（posts:read、posts:write、media:read、media:write、analytics:read、channels:read、inbox:read、inbox:write 和 full），所以一个只需要创建帖子的智能体不会同时获得收件箱的权限。
简而言之
一个智能体需要一个真正的草稿状态、在创建时进行的校验、丢失也不会牵连其他系统的限定范围凭证，以及能阻止循环失控的配额。永远不要让它生成事实性内容，并在生成和发布之间保留一个人，直到你有充分的理由不这么做。
