面向 AI 智能体的社交媒体 API

相比人工驱动的集成，一个智能体对发布 API 的需求有何不同，以及值得针对性设计防范的失败模式。

一个向社交媒体发布内容的智能体，和一个人来做这件事，需求是不一样的，而这些不同大多来自同一个事实：它动作发生的那一刻，没有人在盯着。

智能体需要而人不需要的东西

一个真正有用的草稿状态。 不是一个隐藏的队列，而是人能看到、能审阅、能亲手发布的帖子。这是智能体发布场景里最重要的单一功能，也是最常被当作事后补充的功能。

在创建时校验，而不是在发布时校验。 一个人会注意到文案太长。智能体不会，而如果校验发生在发布那一刻，失败会在几个小时后才浮现，那时智能体早已不在了。错误必须在创建调用时就返回，智能体才能做出反应。

限定范围、可撤销的凭证。 和你其他的 key 分开。出问题时，你想要的是精准撤销这一个智能体的权限，而不是去轮换你生产管道共用的那个凭证。

能阻止循环失控的配额。 一个重试循环能在很短时间里产生大量帖子。这里的硬性上限是一个安全功能，而不只是一个计费档位。

结构化的错误信息。 智能体能针对”在 x 平台上文案超过了 280 个字符”这样的信息采取行动。但它无法针对一个笼统的 400 错误采取任何行动。

自信地编造。 模型会生成一个看似合理的统计数字、价格或功能声明，而不是承认自己不知道。任何事实性内容都不应该由模型生成。事实应该来自你代码所控制的某个来源。

重试风暴。 一个把超时当作失败并去重试的智能体，可能会产生重复的帖子，因为一次超时的创建请求也许其实已经成功了。重试必须是安全的或经过核对的，绝不能盲目进行。

在错误的时机发布。 智能体不知道今天是不是不适合发一条轻松愉快内容的日子。任何涉及新闻或争议的内容都需要一个人来把关。

语气漂移。 放任不管的话，生成的帖子会趋于同一种腔调，而受众会比你更早注意到这一点。

连接一个智能体有两种方式，适用于不同的场景。

MCP，适用于智能体本身就是一个助手，比如 Claude 或者具备 AI 能力的编辑器。服务器暴露出命名的工具，由助手来决定调用哪一个。工作量最小，也是让人以对话方式工作时的正确选择。

API key，适用于你自己编写、无人值守运行的智能体。直接调用，自己的控制流，自己的错误处理。

OAuth，适用于你的智能体代表别人的账号行事，而不是代表你自己的账号。由每个用户自行授权，而不是粘贴一个凭证。

帖子可以创建为草稿，这是应该起步时使用的设置，而且对大多数用途来说，也应该一直保持这个设置。

OAuth 的权限范围是精细化的（posts:read、posts:write、media:read、media:write、analytics:read、channels:read、full），所以一个只需要创建草稿的智能体不会同时获得删除的能力。

一个智能体需要一个真正的草稿状态、在创建时而非发布时进行的校验、丢失也不会牵连其他系统的限定范围凭证，以及能阻止循环失控的配额。给它完成任务所需的最小权限范围，永远不要让它生成事实性内容，并在生成和发布之间保留一个人，直到你有充分的理由不这么做。