一句话回答：AI 不支持 MCP 也能自动发布内容，用命令行外壳
npx publishport就行——它跟 MCP 服务走的是同一条中转，鉴权、设备路由、用量计量都一样，不是绕过去的备用方案。CI 里跑的定时任务、暂时配不好 MCP 的客户端，都能直接用命令行接。
GitHub Actions 里跑着一个每天定时选题的 agent，稿子写完想顺手发到知乎和公众号，翻了几家发布工具的文档，几乎都要求先配好 MCP。可这个 agent 是 cron 触发的一次性脚本，跑完直接退出进程，根本没有一个常驻的客户端能装 MCP server。配置文档写得再细也没用，场景本身就用不上。
这不是个例。MCP 这两年确实成了 AI 工具调用的主流协议，但“主流”不等于“到处都能用”，接下来这几段拆开说。
为什么不是所有 AI 场景都配得上 MCP
第一种情况：客户端本身支持 MCP，但配置起来不稳定。有开发者在论坛上吐槽过，Codex 升级之后配置好的 MCP 工具全部失联，同一套配置在 Claude 里照常能用，问题出在客户端这一层，跟服务端有没有提供 MCP 无关。排查这类问题要核对客户端版本、配置文件路径、服务进程有没有正常起来，折腾一圈是常有的事。
第二种情况：有的工具压根没打算走 MCP。社区里比较活跃的开源编程 agent 工具 OpenClaw 就是这样，官方给出的理由是数据共享带来的隐私风险、不想被协议锁死迭代节奏、以及减少预加载 schema 带来的上下文开销。它用自己的 Skills 机制替代，靠命令行 --help 让 agent 现场发现能力，而不是提前塞给模型一整套工具定义。这跟本文开头那种“想用但配不上”不一样，是设计上就没走这条路。
第三种情况，也是最容易被忽略的一种：运行形态决定的。MCP 会话需要一个持续在线的客户端进程去维持连接，GitHub Actions 里的定时 agent、cron 触发的脚本、CI 里跑一次就退出的编码任务，这类场景没有“常驻”这个前提，不是支不支持的问题，是压根没有地方去装。
命令行不是备用方案，是同一条中转的另一个外壳
PublishPort 给 AI 的原语很薄：list_capabilities() 告诉 AI 这台设备当前登录了哪些账号、支持哪些操作，local_bash(cmd) 把具体命令下发到本机执行，由驱动真实浏览器登录态的开源命令行工具跑。会说 MCP 的 AI 直接接 MCP 端点用这套原语，不会说 MCP 的 AI 用官方远程 CLI npx publishport，它是同一套服务的命令行外壳，同样经过中转。
这一点值得说清楚：不是因为不支持 MCP 就退而求其次，直接拿本机 ppcli 摸索着来。那样做会丢掉三件事：设备路由（AI 怎么知道该发到哪台机器）、登录态校验（怎么确认账号真的在线）、用量计量（超没超出配额）。命令行外壳这条路走的还是那条中转，鉴权、设备路由、登录态校验、用量计量一个都不少，区别只在于外壳形态从“MCP 工具调用”换成了“敲一条命令”。具体接入方式见 PublishPort 文档。
具体怎么接：五步跑通
从装完到能发出第一条内容，通常用不了五分钟。
- 装 desktop app 并登录账号：正常打开浏览器登录一次要发布的平台，不做登录态迁移，用的就是你自己这台设备的真实会话。
- 拿到访问凭证：交互环境里跑
npx publishport login，凭证会存在~/.publishport/config.json（权限 600）；CI 或容器里没法交互登录，直接把凭证塞进环境变量PUBLISHPORT_TOKEN。 - 确认设备和账号状态：
npx publishport capabilities能看到当前在线的设备、每个平台的登录情况、剩余配额，先跑这条心里有数。 - 查这个平台该怎么写命令：
npx publishport guide <平台> --device <设备>会给出这个平台发布的必填参数和常见坑，比自己猜参数靠谱。 - 真正执行：
npx publishport run --device <设备> -- <具体命令>，退出码会原样透传回来，方便接进正常的 shell 错误处理逻辑。
一个真实场景：GitHub Actions 里的定时发布 agent
回到开头那个场景。这类“CI 里跑 agent CLI”的模式本身不是什么偏门用法，GitHub 官方也在推 Agentic Workflows：用 Markdown 写意图，由编码 agent 在标准 GitHub Actions YAML 里执行，是官方认可的一种自动化路径。落到发布这一步，做法是把 PUBLISHPORT_TOKEN 存成仓库 secret，agent 生成完稿子之后直接调用命令行：
export PUBLISHPORT_TOKEN=${{ secrets.PUBLISHPORT_TOKEN }}
npx publishport run --device my-desktop -- ppcli zhihu article --file draft.md --execute没有交互式界面、没有常驻客户端，agent 跑完这一步照样正常退出，和它跑其他任何一步 shell 命令没有区别。
边界与注意
凭证要当密码保管，它能驱动对应设备上的实际操作，CI 里务必存成 secret 而不是明文写进配置文件。命令报错不代表内容真的没发出去，网络超时、连接中断这类问题可能是命令没拿到返回值，但发布动作已经在平台那边完成了，重试前先用查询命令确认一遍状态，避免重复发布。发布行为始终是这台设备、这个真实账号在做，内容本身还是要符合平台规则，命令行只是换了个调用方式，不代表可以不管这些规则。
接入前检查清单
- 先确认这个场景到底有没有常驻客户端进程，没有就直接走命令行，不用死磕 MCP 配置
- 交互环境用
login，CI/容器环境用PUBLISHPORT_TOKEN环境变量，别混着来 - 执行发布类命令前先跑一遍
capabilities和guide，别对着旧文档猜参数 - CI 里把凭证存成 secret，别明文写进 workflow 文件
- 命令报错先查状态再决定要不要重试，避免同一条内容发两遍
常见问题 / FAQ
Codex 配置 MCP 总是报错，是不是就用不了 PublishPort 了？
不是。MCP 客户端配置有问题时，直接换成命令行外壳 npx publishport 就行，两条路走的是同一条中转，功能上没有缺失，只是调用方式从“MCP 工具”变成了“敲命令”。
GitHub Actions 里跑的一次性任务也能用吗，它没有交互式界面？
可以。这类场景本来就不适合装 MCP 客户端，凭证放进环境变量 PUBLISHPORT_TOKEN，agent 跑完生成内容之后直接调用 publishport run 就是一条普通的 shell 命令。
CLI 和 MCP 是不是不一样，会不会某边功能少一块？
不会。两者都是同一套服务的外壳，鉴权、设备路由、登录态校验、用量计量都走同一条中转，publishport tools 列出的是权威的完整工具清单，服务端新增能力两边都能立刻用上，不存在只在其中一边开放的功能。
PUBLISHPORT_TOKEN 泄露了会怎样？
它能驱动你账号绑定设备上的实际操作，等同于一把能远程执行命令的钥匙，泄露后需要立刻在账号里撤销并重新生成。CI 环境务必用 secret 管理，不要明文写进代码仓库。
以后这个 AI 支持了 MCP，是不是要把现在的 CLI 配置换掉？
不需要，两者可以一直并存。哪种调用方式更顺手就用哪种，没有谁是过渡方案、谁是正式方案的区别。
命令行接入的原理和背后的安全模型，跟 ppcli 本地怎么用 与 MCP 内容发布服务器的工作方式 是同一套东西的不同侧面，配着看会更清楚。