AI Agent 可以飞快地起草、改写、翻译和排版内容。但分发是另一个问题。把同一篇内容发到多个平台，需要账号会话、草稿行为、平台特定的校验、定时、失败记录，以及当自动化该停下时安全的回退路径。
把这一切都堆到那个写内容的 Agent 身上，团队最终会得到一堆脆弱的脚本——平台每改一次按钮，它就坏一次。
把「写」和「发」分开
OmniPost 把分发当作一个独立的、本地的桌面层。Agent 负责准备内容；OmniPost 负责平台账号、浏览器会话、MCP 工具、CLI 命令、HTTP 端点和发布记录。这条边界是刻意划出来的：
- 写作方 负责语气、结构与 Markdown 正文。
- 发布方 负责会话、能力探测、格式化、记录与时机。
让这两件事各司其职，意味着你可以随意更换模型、提示词或编辑器，而不影响分发的可靠性——反之亦然。
分发层到底该负责什么
一个真正的分发层，负责的是那些不光鲜、却有状态的脏活：
- 账号登录与持久的会话隔离。
- 针对每个平台的草稿与发布能力探测。
- Markdown 预览与平台特定的格式化。
- 多账号的目标选择。
- 定时与重试。
- 发布记录、编辑器链接与失败原因。
为什么本地优先在这里很重要
平台会话很敏感。它们代表着对真实账号的真实登录。把它们运行在一个真正的本地浏览器环境里——而不是交给一个替你保管 Cookie 的云服务——就把这条信任边界，留在了它该在的地方：你的机器上。
这正是 OmniPost 的核心判断。生成正在快速变成大路货；而可靠、可审计、本地优先的分发不是。
#分发#Agent#架构