八月中旬，开发者圈发生了一件不太起眼但值得咂摸的事：短短一周，三家平台先后开放了官方 CLI，而且都说了同一句话——可以被 AI Agent 调用。
8 月 12 日前后，知乎数据开放平台推出官方 CLI，还附带打包了一个给 AI 助手用的 Skill 包；8 月 14 日，weibo-cli 宣布大升级，全量接口放开、改按 Credit 计费；8 月 18 日，企业微信 5.0.10 上线，开放 CLI/MCP，不限企业规模，并打通 WorkBuddy 等第三方 Agent。
如果你平时写 CLI、维护 CLI，这一周发生的事情值得认真看一眼：命令行工具的第一位用户，正在从人变成 Agent。
这一周到底发生了什么
知乎官方 CLI 走的是最"标准"的路线：去 developer.zhihu.com/profile 生成 Access Secret，CLI 把密钥存进系统钥匙串。目前 0.3.0 版本一共 9 个命令，全部是查询类——热榜、搜索、知乎直答、读取自己的内容，没有任何发布接口。知乎官方还同步提供了一个 Skill 包，SKILL.md 相当于一本"写给 AI 看的说明书"：工具能干什么、按什么顺序装、出错怎么处理，都写好了让 Agent 直接读。有开发者把安装链接直接丢给 Claude Code，从下载、SHA-256 校验到配置凭证、跑通验证一气呵成，人真正动手的只有生成密钥那一步。
weibo-cli 走的是商业化路线：升级后取消了套餐分级，发一条微博 15 Credit、查一次热搜 450 Credit（约 0.45 元）、查一次用户信息 3 Credit。知乎新用户给 7 天体验包，老用户按剩余套餐比例折算。官方文案里有一句很直白的话：“它也是 AI Agent 可以调用的接口层”——抓热搜、分析热点、生成内容、定时发布、监控互动，一条终端跑全流程。
企业微信的动静最大：5.0.10 一次开放十大办公能力，CLI/MCP 双通道，安装命令本身就带着 Skill 形态——`npx skills add wecomTeam/wecom-unified`。
信号不是"多了一种用法"，而是用户变了
三家 CLI 有一个共同点：设计优先级不再是"人敲着顺不顺手"，而是"Agent 调得稳不稳"。
这个趋势其实有迹可循。几乎同一时间，Gitee CLI 正式开源，官方给它的定位是一个同时服务于「人」和「AI Agent」的命令行工具，在终端里就能直接检索和调用平台 API。知乎
B 站上 Agent Skills 相关教程从 7 月起扎堆出现，“2026 讲的最好的 AgentSkills 教程"这类标题层出不穷，单条播放量动辄几千。哔哩哔哩知乎上一个 68 赞的回答说得更直白：现在 Agent 场景开发的具体工作，就是"将传统的工具链进行 CLI/MCP/Tools 和 Skills 化改造”，“cli/mcp/tools 是给 agent 的眼和手，是 LLM 大脑和现实世界沟通的通道”。知乎连"MCP 与 CLI 的区别是什么"这种问题，都开始被认真讨论。
周边工具也在跟着长。截至 8 月 10 日，调度多个 Coding Agent 的开源项目 T3 Code 在 GitHub 已经获得约 1.77 万 Stars。知乎它做的事情是在这些 Coding Agent 之上加一层"控制面"，桌面端的编排界面，已经把任务拆解、代码库概览、文件级 diff 管理做成了标配。CLI 不再只是给人敲的单兵工具，它正在变成 Agent 工作流里的一截标准件。
这里有个反直觉的结论：传统 CLI 设计推崇 Unix 哲学——短参数、精简输出、隐式约定。但面向 Agent 的 CLI，规则反过来了。一篇设计复盘文章的结论很直接。对 agent 来说，清晰比简短更重要。知乎`publish --doc article.md --platforms zhihu` 这种写法比三字母缩写更容易被一次调对——因为对 Agent 而言，–help 输出不是文档，而是"运行时探针"。
先澄清一个噪音：知乎 CLI 其实有两个
社区讨论里现在混着两个东西，选型前得分清：
官方版：知乎数据开放平台出品，Access Secret 鉴权，目前只读，9 个查询命令，没有封号风险；
第三方开源版：二维码扫码登录，能发图文，把"浏览器指纹模拟规避风控"当卖点，封号风险自负。知乎
给 Agent 做正经自动化，用官方版；需要写能力的，官方版暂时没给，用第三方就要自己掂量合规成本。
改造清单：CLI 开发者现在该动的 5 件事
从这三家的做法和社区的设计讨论里，可以抽出一份带优先级的清单：
–json 是一等公民。结构化输出是 Agent 的入场券，知乎 CLI 体验文里最被认可的用法，就是把结果以 JSON 交出去当"高质量筛选器"。
别让模型猜参数。参数名宁长勿缩；报错要说"你传了 --platform，正确的是 --platforms"，而不是甩一句 “invalid argument”。知乎
复杂输入走文件。bash、PowerShell、cmd 对引号和换行的解释并不一致，shell 转义是自动化的高频事故源。最危险的是"假成功"：exit code 是 0，内容却被静默截断。
错误要可修复。一次合格的错误返回至少回答三件事：哪里错了、为什么错、下一步改什么。Agent 不怕失败，怕的是失败后没有方向。
幂等、唯一标识、安全路径。写操作最好提供"预览 → 自检 → 正式发布 → 状态回查"四步，发布结果必带唯一 ID——否则 Agent 很容易把旧草稿误认成本次结果，直接造成重复发布。
还有一个容易忽略的细节：凭证交接。知乎 CLI 的做法值得抄——密钥由人手动生成，通过标准输入喂给 CLI（不进命令行历史），CLI 把它存进系统钥匙串，全程只回显打码后的几位。知乎平台侧也把密钥当成一等公民在管理：开放平台控制台里做额度管理、按环境隔离，密钥只在首次创建时完整展示一次。别让 Agent 碰明文密钥，这是 Claude Code 安全风波之后，终端级工具的信任底线。微博
冷水也得泼几盆
开放 CLI 不等于开放数据。企微 CLI 以一个 BOT 机器人形式存在，外部联系人的消息、外部群、客户通讯录一概碰不到——通过它你只能查询企业内部事务。知乎有篇文章评价得准确：“企业微信开放了 CLI，但没有开放’微信’。”
平台先开放读、写得很谨慎。知乎官方版清一色查询接口，写能力的放开顺序，本身就是观察平台态度的信号。
别急着把所有东西 MCP 化。社区里的务实共识是：设计良好的 CLI 本身就是人、脚本和 Agent 共用的稳定入口，有人跑日常自动化 90% 的活儿仍然靠 CLI 搞定。知乎MCP 更适合需要跨客户端标准化、连接大量工具的场景。先把 CLI 做好，比多包一层协议实在。
接下来怎么做
你的 CLI 已经在脚本或 CI 里跑：先补 --json 输出和结构化报错，成本最低，一天能干完；
内部工具：加一个非交互模式，所有参数可传入、中途不弹确认；
平台方想接 Agent 生态：参考知乎的路线——先开读接口、附 Skill 包、凭证管理留给用户本人；
值得持续盯的信号：知乎 CLI 会不会开写接口、企微 CLI 会不会松口外部联系人、Skills 生态标准被哪些平台采纳。
终端没有死，只是敲命令的那位换了。以前 CLI 好不好用，由人来评判；接下来，第一轮裁判可能是一个正在读 --help 的模型。
