MCP和CLI到底怎么选？一家做了十几年HR SaaS的企业，把算薪、排班能力拆成原子化接口后，才发现客户要的是"说得动"而非"点得顺手"。换班操作从7分钟缩到1分钟的实战，揭开两条协议各自的适用边界。

最近我们遇到两件事，挺有代表性的。

一件是客户打来电话问：“你们系统支不支持MCP或者CLI？我们公司自己做了个Agent，想直接调用你们的算薪能力，不想让HR每次都进系统点来点去。”

另一件是销售跑过来问：“WorkBuddy那个平台，咱们现在能接进去吗？竞品已经支持了，客户对比的时候老拿这个说事儿，咱们再不跟上，单子真要丢。”

你看，同一个问题，从两个方向同时压过来了。一个来自客户的技术团队，一个来自前线的销售。

我们公司是一家做了十几年HR SaaS的企业，考勤、薪酬、排班这些事儿是看家本领。产品一直是GUI界面，人点人操作，挺好用。但AI Agent时代一来，客户预期变了——他们想要的不再是“点得顺手”，而是“说得动”。

于是我们被迫上了这条船。过程中遇到一个绕不开的选择：MCP和CLI，到底用哪个？

动手之前，我以为这俩是二选一的关系——“有了打车软件谁还坐公交”那种。结果扎进去才发现，根本不是这么回事。它俩更像螺丝刀和电钻——都能拧螺丝，但用法、场景、背后的逻辑，完全两码事。

下面是我们公司真实踩坑经历，希望能让你少走点弯路。

第一步：不管MCP还是CLI，先搞定”原子化接口能力”

我们定了三步走战略，第一步就是把系统能力拆成一组细粒度的、独立可调用的基础接口。内部管这叫“原子化接口能力”。

说白了，原来人通过GUI点点点才能干的事，比如算考勤报表，背后涉及校验、计算、状态查询好几个步骤。现在要把这些步骤一个一个拆成独立接口，让Agent像搭积木一样按需调用。

但有个认知转折很关键，值得记下来：

我们一开始想得美——把现有Open API封装一下不就行了？结果被现实啪啪打脸。

原因特简单：现有接口是给人操作GUI设计的，不是给Agent用的。

具体卡在哪？两个地方：

一个是鉴权。 现有Open API走的是OAuth 2.0那套，带着用户session、权限上下文，是针对“人”的。但Agent调用得用API Key、Token，甚至设备指纹，这是针对“机器”的。俩体系根本不通用，硬要复用的话，要么鉴权过不去，要么权限模型全乱套。

另一个是上下文窗口。 人调用接口返回1000条数据，人看着没问题。但Agent的上下文窗口（哪怕128K）也经不起这么造。你返回一坨数据，Agent还没来得及处理，窗口先爆了。所以入参得精简，出参更得精简，只传必要字段，分页逻辑都得重新设计。

所以结论特直接：别想着复用现有Open API，老老实实单独建一套基础接口能力层，专门给机器和Agent用。颗粒度要细，入参出参要克制。这是地基，地基不牢后面全白搭。

光说理论没感觉，上两个我们踩过的坑：

案例1：换班操作，从7分钟缩到1分钟

HR说：“帮我把张三6月7日跟李四6月25日换班。”

我们原接口只能按“员工+月份”查全月排班。Agent得这么干：

1. 先查张三6月全月排班（返回30多条）
2. 再查李四6月全月排班（又30多条）
3. 从两堆数据里筛出6月7日和6月25日的班次
4. 最后调换班接口

跑下来5到7分钟，还经常失败——数据量太大，上下文窗口直接爆了。

根儿在哪儿？没有“按人+按天”查排班的细接口。 Agent只能用大炮打蚊子。

解决方案特简单：加个接口，支持“单人单天”或“单人多年”查排班。改造后Agent精准拿数据，全程缩到1-2分钟，稳稳的。

案例2：批量改考勤状态，从”干不了”到”轻松搞定”

HR说：“把产研部、营销部全部员工6月10日出勤状态改成正常，当天团建。”

业务上完全合理，但接口体系撑不住：

• 改状态接口只支持”员工ID+日期”，不支持批量
• 没有”按部门查员工列表”的接口
• 没有”批量查某日期员工状态”的接口

Agent拿到指令根本不知道怎么拆，硬跑4-6分钟，要么超时，要么只改了第一个人就停了。

怎么办？加三个细接口：

1. 按部门/方案查员工列表
2. 批量查员工某日期的考勤状态
3. 批量改员工考勤状态

Agent逻辑立马清晰：查两个部门所有员工 → 批量查这些人6月10日状态 → 统一改成“正常”。行云流水。

这两个案例说明：原子化接口拆解，别对着文档画脑图，得拿着真实场景一个一个走查改造。 只有这样Agent才顺手。

第二步：终于能聊CLI和MCP的区别了

有了基础接口，接下来才真正面对CLI和MCP的选择。

先给个我的理解公式，不严谨但好记：

CLI = 基础接口能力 + Skills（必须）

MCP = 基础接口能力 + Skills（可选）

区别在哪儿？拿HR实际场景掰开揉碎说。

场景： HR说“帮我重新算当前月考勤报表”。

用CLI方案：得写Skill（技能编排），把流程写死：

1. 先调”计算前检验”接口
2. 没问题再调”重算”接口
3. 轮询”查询计算状态”，每5秒问一次
4. 算完通知HR成功或失败，检验不通过就终止并告诉原因

CLI的核心是流程控制——Skill告诉Agent先干嘛后干嘛，出错了怎么办。Agent就是个执行者，按剧本走。

用MCP方案：部署MCP Server，提供标准化schema文件（定义好入参“月份”、出参“计算状态”）。Agent自己理解：“哦要算报表，我调’计算’工具，等结果就行。”

业务特别复杂的话也可以在MCP上加Skill，但大部分情况MCP不需要Skill，Agent靠工具描述就能自主完成。

另一个关键区别：

• CLI本地化，得安装卸载，跟装软件似的。
• MCP支持远程模式（SSE或HTTP），也支持本地（stdio）。也就是说MCP Server可以放云端，第三方Agent通过HTTP就能调，用户本地啥都不用装。

第三步：自建Agent，我们把它做成了”虚拟员工”

基础接口和CLI能力搭好后，我们开始琢磨：光有工具不行，得让它们“有人样”。

于是我们把每个业务场景封装成一个虚拟员工——比如“薪酬专员Agent”、“考勤专员Agent”、“排班专员Agent”。每个Agent背后是同一套CLI能力，但各自配了不同的Skill编排、知识库和性格设定。

举个例子，“薪酬专员Agent”的知识库里装了薪酬计算规则、个税政策、公司薪酬制度，你跟它说“帮我看下这个月薪酬有没有异常”，它会先调计算接口，再跟历史数据比对，最后给你一个带判断的答复——不是冷冰冰地甩一堆数字。

“考勤专员Agent”则完全不一样。它知道公司考勤制度、加班规则、调休政策，你说“帮我把这周迟到的人都列出来”，它会先理解“这周”的范围，再调考勤查询接口，最后按部门归类呈现给你。

这里有个细节：每个虚拟员工都有自己的“性格”。薪酬Agent偏严谨，涉及钱的事不能马虎；考勤Agent偏灵活，毕竟排班换班是常态。实际上就是调整了Prompt里的人物设定和语气风格。

技术上没啥大瓶颈（就是CLI+Skills+知识库+长期记忆那一套），但商业上确实走通了。我们按“虚拟员工座席+Token调用量”收费，客户算了一笔账：招一个HR助理月薪大几千，买个Agent座席每月几百块，还能7×24小时在线。划算。

第四步：对接第三方Agent，这才是真纠结的地方

自建Agent虽性感，但推广运营太累。就像互联网时代你做了个App，得去各市场买量。但上架到WorkBuddy、千问办公这些平台，人家自带流量啊！

问题来了：用啥方案对接？

实际对接后发现：

WorkBuddy： 一个连接器两种方案都支持——CLI+Skills或MCP+Skills，SSE、HTTP、stdio都行。

千问办公： 只支持MCP+Skills，且必须HTTP模式，SSE和stdio都不认。

怎么选？一鱼多吃。

我们最终策略：MCP+Skills的HTTP模式，一套代码同时适配WorkBuddy和千问办公。

麻烦的是——自建Agent用CLI+Skills，意味着必须同时维护两套方案。CLI给自建用，MCP给第三方渠道。成本确实高，但现阶段最优解。

最后一个血泪教训：接口权限一定要分级管控

假设自建Agent有全量200个接口，上架WorkBuddy时千万别全量上架。

为什么？保护自建Agent的售卖周期。

如果WorkBuddy里能用的功能和自建虚拟员工一模一样，客户凭啥还买你的Agent？

我们的做法：WorkBuddy渠道只上架100个基础接口，够用但不够爽。自建Agent保留全部200个，还带专属知识库和长期记忆。客户想用得爽，就得买虚拟员工。

同时也留了口子——哪天想冲量了，随时可以把全量接口上架，操作空间全在自己手里。

最后说几句实在话

MCP和CLI真不是谁替代谁，是不同阶段、不同场景的产物。

• 自建Agent，CLI+Skills更成熟可控。
• 对接第三方平台，MCP+HTTP是目前的”最大公约数”。

别想一步到位，先跑通一个场景再慢慢扩。AI Agent这事儿，落地的细节比概念的花哨重要得多。