GUI 之后，SaaS 该如何为 Agent 重写自己

从 CLI-Anything 现象看 bsin-paas 四块系统的 Agent 化设计CLI-Anything 在 GitHub 上拿到 15000 颗星的速度让很多人感到意外。它做的事情说起来并不复杂给任意桌面软件自动生成一套命令行接口让 AI Agent 能直接用 CLI 操控 GIMP、Blender、LibreOffice……几乎你能想到的软件它都能包一层。但它火起来的原因不是技术有多新而是它把一个正在发生的趋势挑明了——Agent 操控软件的方式正在从「看屏幕点鼠标」转向「读文档敲命令」。Claude Code 是 CLICodex 是 CLIOpenClaw 也是 CLI。这不是巧合这是 Agent 的天性使然。GUI 本质上是一个翻译层人类花了四十年给计算机套上图形界面是因为人类不擅长记命令。但 Agent 天生就说命令行语言强迫它点按钮、拖滑块是在逼一个会说 API 的实体去学一门它根本不需要的语言。这件事对 SaaS 产品经理意味着什么意味着你正在服务的用户群正在悄悄多出一类——不是人而是 Agent。而你的产品还没准备好接待它。一、SaaS 面临的真正挑战不是「被替代」而是「被绕过」过去两年SaaS 圈最流行的焦虑是AI 会不会取代我们的产品这个问题问错了。更现实的威胁是当 Agent 成为用户的操作入口它会优先调用那些「好调用」的软件。你的产品如果只有 GUI没有 Agent 可以直接对话的接口Agent 就会绕过你去找有 API、有 CLI、有 Skill 的替代品。不是被替代而是被绕过。这个判断背后有一个简单的逻辑Agent 在执行任务时会自动寻找阻力最小的路径。GUI 自动化截图点击是最后的选择因为它脆弱、慢、不可靠。结构化的 CLI 或 API 调用才是 Agent 的首选因为它确定、快、可追溯。所以问题变成了你的 SaaS有没有给 Agent 准备一条「好走的路」二、Skill 化SaaS 为 Agent 开门的标准姿势CLI-Anything 给桌面软件自动生成 CLI解决的是「原本没有命令行接口」的软件问题。但对于 SaaS 来说路径更直接——你本来就有 API你需要做的是在 API 之上封装一层Agent 友好的 Skill。什么是 SkillSkill 是一份「使用说明」加上「标准化接口」的组合。它告诉 Agent这个能力叫什么名字、什么场景该用、参数怎么传、结果怎么解析、出错了怎么处理。Agent 读完 SKILL.md就能像工程师读完接口文档一样独立完成任务。Skill 化和 API 化的区别在于API 是给人类开发者看的Skill 是给 Agent 直接执行的。前者需要人来理解和编排后者 Agent 自己就能上手。Skill 化的三层结构┌─────────────────────────────────────┐ │ SKILL.md语义层 │ │ · 能力描述 · 使用场景 · 注意事项 │ ├─────────────────────────────────────┤ │ CLI / MCP Tool接口层 │ │ · 标准化命令 · 结构化输出 · 鉴权 │ ├─────────────────────────────────────┤ │ 业务 API执行层 │ │ · 原有 SaaS 核心逻辑不变 │ └─────────────────────────────────────┘最下面一层是你已经有的东西——业务逻辑、数据库、核心功能一行代码都不需要动。中间一层是新增的 Agent 接口——规范化的命令结构固定的 JSON 输出格式AppKey 鉴权。最上面一层是 Agent 的「导航地图」——一份写给 Agent 看的说明文件告诉它这个 Skill 能干什么、怎么干。这三层加在一起就是 SaaS Skill 化的完整形态。三、bsin-paas 四块系统的 Skill 化设计以 bsin-paas 为例它包含四个核心业务模块商品推荐、客户管理、门店管理、优惠券营销。这四块各有特点Agent 化的设计思路也各有侧重。1. 商品推荐系统——Agent 的「货架」商品推荐是 Agent 最高频调用的能力之一。用户对 Agent 说「推荐一款 5000 元以内的华为手机」Agent 需要能直接拿到结构化的商品列表而不是让用户去页面上自己筛选。核心 Skill 能力goods.search按关键词 过滤条件查询商品goods.recommend按用户画像 场景返回推荐列表goods.detail查询单品详情设计重点输出必须结构化。商品名、价格、品牌、核心卖点、库存状态每个字段都要有固定的 key 名称。Agent 拿到的不是一段描述文字而是可以直接渲染、可以和其他 Skill 联动的数据对象。产品经理的决策点推荐算法的权重是否对 Agent 调用和人类浏览保持一致还是给 Agent 单独的排序逻辑这个问题值得提前想清楚。2. 客户管理系统CRM——Agent 的「记忆」CRM 是四块系统里风险最高的一块因为它涉及写操作——创建记录、更新标签、添加跟进。Agent 如果判断错误可能造成数据污染。核心 Skill 能力crm.customer.get查询客户基本信息与标签crm.order.list查询消费历史crm.followup.create创建跟进记录crm.customer.tag更新客户标签设计重点写操作必须分级。读操作用普通 AppKey 即可写操作需要scopewrite授权涉及手机号、身份证等敏感字段需要单独申请scopepii权限。更关键的是引入「预览模式」Agent 在执行写操作之前先调用--dry-run拿到操作预览确认无误后再执行。这一步让人类对 Agent 的行为保有最后的确认权也是在 Agent 能力边界尚未完全清晰时最稳健的设计。产品经理的决策点哪些字段允许 Agent 修改哪些字段只读这个权限边界的设计直接决定了 CRM Skill 的安全性上限。3. 门店管理系统——Agent 的「地图」门店管理的核心场景是用户问「附近哪家店有货」Agent 需要同时拿到位置信息、营业状态和实时库存然后给出一个整合后的答案。核心 Skill 能力store.search按坐标 半径查询附近门店store.status查询门店营业状态与当前人流store.inventory查询门店指定商品库存store.appointment创建到店预约设计重点门店 Skill 的价值在于「组合调用」。单独查门店没意义单独查库存也没意义但「附近 3 公里 这款手机有货 今天营业中」组合在一起Agent 就能直接给出「南山旗舰店距你 1.2 公里库存 3 台营业至 22:00」的答案。这要求 Skill 的输出字段设计要有前瞻性——每个能力的返回值需要能和其他 Skill 的输入字段自然对接。产品经理的决策点库存数据的实时性要求是什么如果库存更新有延迟需要在 Skill 的输出里标注数据时效避免 Agent 给出错误承诺。4. 优惠券 / 营销系统——Agent 的「算盘」营销系统是最容易被低估的一块。用户问「这款手机最便宜多少钱」Agent 需要能自动完成「查原价 → 查可用券 → 算最优组合 → 返回最终价」这一整套逻辑。核心 Skill 能力coupon.list查询用户可用优惠券支持按商品过滤coupon.calculate计算指定商品 指定优惠券的最终价格coupon.bestdeal自动返回当前用户的最优优惠方案coupon.issue按活动规则发放优惠券设计重点coupon.bestdeal是这里最重要的一个 Skill 设计决策——是让 Agent 自己遍历所有券做计算还是在服务端直接封装「最优解」接口后者更聪明。Agent 不需要知道优惠券的叠加规则和互斥逻辑它只需要调一个接口拿到「用这张券最终 6499 元」的答案。复杂的业务规则留在服务端Skill 保持简洁。产品经理的决策点营销活动的实时性如何保证大促期间规则频繁变更Skill 层需要有版本管理机制避免 Agent 用了过期的优惠规则。四、Skill、MCP 与 CLI——三者是什么关系很多人在接触这些概念时会混淆这里做一个清晰的区分。CLI 是形态。命令行接口文本输入结构化输出这是 Agent 最喜欢的交互方式。CLI-Anything 把桌面软件变成 CLIbsin-paas 把业务能力包装成可命令行调用的接口本质都是在给 Agent 创造「好走的路」。MCP 是协议。Model Context ProtocolAnthropic 提出的标准定义了 AI Agent 和外部工具之间的通信规范。你可以把 MCP 理解成一套「插头标准」——Agent 支持 MCP你的 Skill 实现了 MCP两者就能直接对接不需要定制集成。Skill 是知识。SKILL.md 是写给 Agent 看的使用说明告诉它什么场景调什么接口、参数怎么填、结果怎么用。Skill 不是代码是语义——它是 CLI/MCP 接口之上的一层「操作手册」。三者的关系Agent │ ├── 读 SKILL.md知道能干什么、怎么干 │ ├── 通过 MCP 协议标准化通信 │ └── 调用 CLI 接口实际执行 │ └── bsin-paas HTTP API业务逻辑对 SaaS 产品经理来说这三层各有负责方CLI 是工程师的活MCP 是架构师的活而SKILL.md 是产品经理的活。你需要想清楚这个 Skill 叫什么名字它能干什么不能干什么什么情况下 Agent 该用它什么情况下不该用这些判断技术同学给不出来只有懂业务的人才能写好。五、商业模式从「卖座位」到「按调用收费」Skill 化不只是技术架构的变化它也在重塑 SaaS 的商业模式。传统 SaaS 的收费逻辑是「卖座位」——按用户数、按月付费。这个模式在人类用户时代是合理的但当 Agent 成为主要用户「座位」的概念就失效了。一个 Agent 可以代替十个人操作但它只需要一个账号。新的商业模式正在形成按 Skill 调用次数计费。每次 Agent 调用goods.recommend计一次费。这个模式对高频场景商品推荐、优惠计算天然友好也让 SaaS 的收入和实际使用量直接挂钩。按能力层级收费。基础 Skill查询类免费或低价高价值 Skill智能推荐、数据分析、自动化执行高价。这和 API 经济的分层定价逻辑一脉相承。AppKey 作为商业控制点。每个 AppKey 绑定权限范围、调用配额、数据边界。企业采购的本质从「买软件使用权」变成「买 Agent 操作权」。这个转变让 SaaS 的续费和扩费逻辑更加清晰用得越多调用越多付费越多。六、落地路径不要推倒重来要分层叠加最后谈落地。很多团队看到「Agent 化」就想重构这是最常见的错误。正确的姿势是分层叠加不是推倒重来。第一步梳理核心能力定义 Skill 清单。把现有产品的核心操作梳理成 20-30 个原子能力每个能力对应一个 Skill。不要贪多先把最高频、最有价值的场景覆盖掉。以 bsin-paas 为例商品搜索、客户查询、门店查找、优惠计算这四个场景先跑通就覆盖了 80% 的 Agent 使用需求。第二步封装标准化接口统一输出格式。现有 API 大概率已经有了要做的是在上面加一层「Agent 友好」的封装固定 JSON 结构、统一错误码、加上 AppKey 鉴权。这一步工程量不大但收益极高。第三步写 SKILL.md告诉 Agent 怎么用。这是产品经理最直接的产出物。一份好的 SKILL.md需要描述清楚能力名称、适用场景、参数说明、输出字段、常见错误处理。写 SKILL.md 的过程也是倒逼产品把接口设计做清晰的过程。第四步接入 OpenClaw 或 Claude Code跑通端到端。选一个真实业务场景让 Agent 从头到尾走一遍。哪里卡住了哪里的 Skill 描述不清楚哪里的输出字段让 Agent 困惑在这一步全部暴露。第五步灰度上线监控调用数据。把 Agent 调用和人工操作并行运行一段时间对比结果准确率、任务完成率、用户满意度。用数据说话决定哪些场景可以让 Agent 独立执行哪些场景需要保留人工确认。结语CLI-Anything 的走红是一个信号不是一个终点。它说明的是软件行业正在进行一场悄无声息的界面革命。不是界面变得更好看而是界面正在变得「对 Agent 可见」。GUI 不会消失它仍然是人类用户的窗口。但在 GUI 之下每一个 SaaS 都需要长出一层新的神经末梢——让 Agent 能摸到、能调用、能信任。这层神经末梢就是 Skill。对 SaaS 产品经理来说下一个三年最重要的产品命题不是「我们的 AI 功能做得够不够好」而是「我们的产品够不够容易被 Agent 调用」。软件的用户正在从人类扩展到人类 Agent。先想清楚这件事的团队会在下一个平台迁移中占到先机。