从 Chatbot 到 Agent：Skill、MCP、CLI 如何让 AI 真正干活
我观察了身边的人用 AI，大致可以分成三个层级。
第一层：把 AI 当聊天框
打开 ChatGPT ， Claude ，Deepseek，Kimi，豆包的对话框，直接跟它聊天，让它帮你解决问题。你问一句，它答一句。写文案、翻译、总结文章，都在一个聊天框里完成。这是最普遍的状态。AI 是个顾问，动嘴不动手。
第二层：开始使用 Agent 平台
你不只是跟 AI 聊天了，而是通过一个中介，让它帮你干活。你跟中介说个目标，中介在后台自己查资料、调工具、检查结果，最后把成品交给你。你从“提问者”变成了“发包方”。
第三层：使用中央调度系统
比如 OpenClaw、WorkBuddy 这种，调度一群 AI 帮你干活。这已经不是雇一个中介了，是雇了一个项目经理。项目经理自己拆任务，分配给下面专门写代码的、专门搜资料的、专门验收的专家 Agent，最后给你交付成品。你只需要定方向、验结果。
大部分人在第一层，少部分人在第二层，第三层。
那 Agent 到底是什么？中介怎么干活的？专家团又是什么？我琢磨了很久，才有了下面这些想法。
以下是个人的理解，以最通俗易懂的方式解释，有些解释可能不是特别专业，大家重在理解什么是 Agent 就行。
01 AI 一开始就是个聊天框
最开始的 AI，就是个 Chatbot。
你跟它打字说话，它理解你的意思，然后给你回复。你问一句，它答一句。你继续追问，它继续回答。就这么简单。
这时候的 AI 不能干活，不能联网查东西，不能操作电脑，不能调工具。它就是个聊天的对象，像个顾问，你问它啥，它给你出出主意。但真正要动手做的事，还是得你自己来。
后来 Chatbot 开始升级了。它能联网搜索了，能读文件了，能写代码了，上下文窗口也越来越大。还加上了思考模式，让它在回答之前先自己琢磨一下。
这时候的 Chatbot，其实已经在向 Agent 的方向走了。它不再只是动嘴，开始能动手了。
02 Agent 就是中介
Agent 是什么？我的理解很简单：Agent这个词是代理意思，换种说法 就是中介。
以前我们是直接跟大模型对话。你一句，我一句。大模型只有嘴，没有手。
现在不一样了。我们不是直接跟大模型说话了，我们是跟 Agent 这个中介说话。
你跟中介说一个目标，比如“帮我调研某某的竞品，写份报告，以下是我的需求”。然后你就不用管了，坐沙发上等着就行。
中介在后台干嘛呢？
- 第一步 它转身去问大模型：“客户要调研某某的竞品，需要什么信息？这是需求”。
- 第二步 大模型说：“我需要竞品 A 和 B 的最新定价。”
- 第三步 中介自己上网搜，搜到一堆资料。
- 第四步 中介把资料整理好，又去找大模型：“给你资料，开始分析。”
- 第五步 大模型分析完了，给出结论。
- 第六步 中介拿着结论，去找另一个专门写报告的大模型：“帮我写成报告。”
- 第七步 中介拿到报告，自己先检查一遍，格式不对的改一下，逻辑漏洞的补一下。
- 最后 中介把成品递给你：“老板，报告写好了。”
从头到尾，你只跟中介说了一句话。中介在后台跟大模型来回沟通了七八次。
Agent 这个中介，把大模型从“只能聊天”变成了“能干活的工具”。
03 Agent 本身就是一套 Harness
那这个中介到底是什么？它本质上就是一套 Harness （挽具）。
大模型是那匹马。它只有脑子和嘴，没有手，没有记性，不会自己规划步骤。
Agent 就是套在马身上的缰绳、马鞍、马镫。它告诉马往哪走、什么时候停、什么时候加速。
它给马装上工具，让马不仅能想能说，还能查、能算、能写、能验证。
Agent = 大模型 + Harness
模型是引擎，Harness 是整车的控制系统。
没有 Harness，大模型只是一个会聊天的脑子。有了 Harness，它才能变成一个能干活、能闭环、能自我修正的执行者。
同一个大模型，套上不同的 Agent（不同的挽具），就会变成完全不同的工具。
- 套上 Claude Code 的挽具，它就是个编程助手。
- 套上 ChatGPT 的挽具，它就是个通用聊天工具。
- 套上你自己写的挽具，它就是你专属的私人助理。
模型没变，变的是挽具。
那这套 Harness 到底由什么组成？
我把它总结成了一个公式：
Agent 的
Harness = 多次请求提示词 + 上下文的记忆系统 + 工具集合
工具集合包括 Skill、CLI、MCP。
这三个组件，就是挽具的全部家当。
多次请求提示词
这是挽具的“运行节奏”。它决定了 Agent 怎么拆任务、什么时候调工具、什么时候检查结果。不是一次性丢给大模型，而是一步一步来。
上下文的记忆系统
这是挽具的“信息管道”。负责记住每一步的结果，把关键信息装进新的上下文喂给大模型，同时对抗中段遗忘和上下文污染。
工具集合（Skill、CLI、MCP）
这是挽具的“执行手臂”。Skill 是自动化流程模组，MCP 是标准化外部服务接口，CLI 是兜底的命令行。
没有工具，Agent 就只能动嘴不能动手。三样东西组合在一起，就是一套完整的挽具。套上它，大模型这匹马才能稳定地跑完全程。下面我们一个个拆开看。
04 组件一：多次请求提示词
中介为什么能搞定复杂任务？靠的就是 Harness 里的第一个组件： 多次请求 。
单次请求就像让一个人看了一眼问题就必须马上给出完整答案，中间不能查资料、不能验算、不能修改。复杂任务这样搞，质量一定差。
中介的做法不一样。它把一个大任务拆成多个小步骤，每一步都单独跟大模型沟通一次：
- 第一次 理解目标，拆任务。
- 第二次 问大模型需要什么信息，然后去搜。
- 第三次 把搜到的信息喂给大模型，让它分析。
- 第四次 把分析结果给大模型，让它写报告。
- 第五次 检查报告，有问题就再改一轮。
每一轮的结果都被装进新的上下文，喂给模型再思考。这就是“结果回传”的自动化版本。不用你手动去喂，中介自己就循环起来了。
中介还有一个聪明的地方：
它不会一次性把所有信息都塞给大模型。一次性全塞进去，大模型反而不知道该关注什么，容易跑偏。中介的做法是渐进式披露，每一步只给大模型看它当前需要的东西。
搜索时只看搜索结果，写代码时只看代码需求，验收时只看验收标准。信息是一层一层打开的，大模型每一步的注意力都很聚焦。
多次请求是手段，渐进式披露是策略，Skill 的完整执行是目的。
也就是你要使用 Skill，除了选大模型之外，还需要选对应合适的 Agent 工具。
05 组件二：上下文的记忆系统
AI 的记忆是有限的。对话越长，它越不可能每一句话都平等记住。尤其在长对话里，它容易记住开头和结尾，忽略中间。
Agent 的 Harness 里专门有一套机制来管这个事。这就是公式里的第二个组件： 上下文的记忆系统 。
这套系统做三件事：
- 第一，记住关键信息。
- 每完成一步，把重要的结论、数据、用户偏好记录下来，装进新的上下文里。
- 第二，对抗中段遗忘。
- 对话长了，把关键约束重新提到前面来，或者让大模型先做总结再开新窗口继续。
- 第三，防止上下文污染。
- 不相关的东西不塞进去，只给大模型看当前这一步需要的材料。
所以你不能指望 AI 自己管好所有信息，Harness 要替它管。这就是公式里“上下文的记忆系统”的价值。信息管道越干净，大模型的判断越稳定。
要避免 Agent 出现幻觉，就要警惕上下文污染的问题。
06 组件三：工具集合——调工具之前先“握手”
中介工具箱里最常用的三种装备，就是 Skill 、 MCP 和 CLI 。
但中介调用 MCP 工具之前，不是上来就直接用的。它要先跟 MCP 服务端走一个“互相认识”的流程。这个流程刚好也是三步，可以理解成应用层的“三次握手”：
- 第一步，中介自报家门。
- 中介先发一个请求给 MCP 服务端，告诉对方自己支持的协议版本、有哪些能力。（以 JSON-RPC 协议）
- 第二步，服务端亮底牌。
- MCP 服务端收到后，返回自己的信息，确认协议版本，并列出自己能提供什么工具和资源，比如能访问数据库、能读网页内容。
- 第三步，中介确认，握手完成。
- 中介收到服务端的底牌后，再发一个确认通知过去，说“我知道你能干什么了，我也准备好了”。到此握手结束，双方正式开始干活。
这个过程跟网络层的 TCP 三次握手不一样。TCP 的三次握手是为了建立网络连接，发生在底层。MCP 的握手发生在应用层，目的是强制双方在干活之前先把能力对齐。
TCP 管连通，MCP 管能力。
中介知道服务端能干什么，服务端也知道中介要按什么标准来，后面才不会出乱子。
这其实也印证了 Harness 工程的思路：好的控制系统，不仅要管“怎么干”，还要管“干之前先把规矩定清楚”。
07 握手之后，怎么干活？
握手成功之后，Agent 和 MCP 服务端就进入了正式的干活阶段。这个过程就是“多次请求”和“结果回传”在工具调用中的具体体现。
整个过程可以概括为三步循环： 下指令 → 去执行 → 看结果 。
- 第一步，下指令。
- 当大模型判断需要调用某个 MCP 工具时，Agent 就向 MCP 服务端发一个请求，里面写清楚要调哪个工具、参数是什么。比如要查天气，就告诉它“调 get_weather，城市是北京”。
- 第二步，去执行。
- MCP 服务端收到指令后，就开始干自己的活。它可能会去访问数据库、调第三方 API、或者做计算。这个过程对 Agent 来说是个黑盒，Agent 只需要等结果。
- 第三步，看结果。
- 服务端执行完毕后，把结果封装好返回给 Agent。结果里有两样东西：一个是 content，就是实实在在的数据，比如天气信息、数据库查询结果。另一个是 isError，告诉 Agent 这次调用有没有出错。
使用 MCP 也要注意安全问题，因为你并不清楚对方在黑箱子中做了什么，比如说对方在黑箱子中把你的数据同步到对方的邮箱中。
Agent 根据结果判断下一步是继续推进，还是处理报错。
拿到结果后，Agent 就完成了我们之前说的关键步骤：结果回传。它把这个结果装进新的上下文，再次发给大模型。
大模型读一遍结果，然后回答你的问题，或者判断要不要再调一次工具，重复这个循环，直到把事情办妥。
这整个过程，正好印证了 Harness 公式里的三个组件如何协同工作：多次请求是运行节奏，记忆系统负责把结果装进上下文，MCP 工具负责实际执行。
08 Skill 怎么“包含”MCP？
那 Skill 和 MCP 到底是什么关系？Skill 里怎么包含 MCP？
Skill 包含 MCP，不是通过代码调用，而是通过配置声明，然后由 Agent 框架在运行时自动集成。
整个过程分五步走：
- 第一步，Skill 声明自己要用的 MCP 服务。
- 在 Skill 的配置文件里，它会写清楚自己需要哪些 MCP 服务，比如要一个能查天气的服务。
- 第二步，Agent 框架启动时加载 MCP 服务。
- 当你启动这个 Skill 时，Agent 框架会读配置，然后按照声明去启动对应的 MCP 服务端。启动过程中走一遍我们刚说的“三次握手”。
- 第三步，MCP 工具被自动注入到大模型的上下文里。
- 握手成功后，Agent 框架拿到了 MCP 服务端提供的工具清单，比如 get_weather、get_forecast 这些。然后框架把这些工具的描述，自动加入到发给大模型的工具定义里。这一步对 Skill 来说是完全透明的。
- 第四步，大模型决策，触发 Function Calling。
- 当任务需要查天气时，大模型看到上下文里有 get_weather 这个工具，就按 Function Calling 的格式输出一个调用指令，告诉 Agent 框架：“帮我调 get_weather，参数是 city: Beijing。”
- 第五步，Agent 框架通过 MCP 协议执行调用。
- Agent 框架接收到大模型的指令后，不是自己去直接调天气 API，而是通过 MCP 协议，把这个指令发给 MCP 服务端。服务端执行完，把结果返回给框架，框架再喂回给大模型。
所以整个链路是：
Skill 声明依赖 → Agent 框架加载 MCP 服务并握手 → MCP 工具注入大模型上下文 → 大模型通过 Function Calling 决定调用 → Agent 框架通过 MCP 协议执行 → 结果回传给大模型
三个东西各司其职：Skill 管“我要用什么”，Function Calling 管“现在该用哪个”，MCP 协议管“怎么去执行”。
也就是为什么有人说，未来 Skill “走天下”，因为 Skill 中可以包含 MCP，也可以包含部分上下文记忆。
09 Skill、MCP、CLI 三者的区别
Harness 公式里的工具集合，就是这三样东西。它们到底有什么区别？
我们再用这个比喻，从五个维度拆开细看：
CLI：中介自己动手
CLI 是中介自己动手，直接去敲电脑命令行。它的颗粒度最细，一条命令就是一个操作。操作系统或已安装软件自带的命令，中介拿起来就能用。大模型通过 Function Calling 决定要执行什么命令，Agent 框架直接在终端里跑。
MCP：外部专业服务商
MCP 是中介打电话给一个外部专业服务商，按标准协议下单。它的颗粒度居中，一个 MCP 服务端可以提供多个工具。这些服务端可以是第三方提供的，也可以自己搭建。
Skill：操作手册
Skill 是中介手里的一本操作手册，里面写好了“遇到什么情况，该做什么事”。它的颗粒度最粗，一个 Skill 就是一个完整的任务流程，用户或开发者预先编写好。
三者的层级关系也很好记：
Skill 是最高层级的指挥官，管流程；
MCP 是标准化服务接口，管外部服务；
CLI 是兜底的万能胶，管计算机本身。
所以三者的关系可以总结为： Skill 是任务层的挽具，MCP 是工具层的标准化插头，CLI 是兜底的万能胶。
在 Agent 所有的工具中，CLI 终端的数据是最快的。
CLI > MCP > Skill
原因很简单：流程最短，中间环节最少。
CLI
中介自己站起来，走到电脑前，敲一行命令，回车，结果就出来了。全程就一步。
MCP
中介拿起电话，打给外部服务商，先说“我要查天气，城市是北京”，服务商那边处理完，再把结果报回来。中间多了一层通信。
Skill
中介翻开操作手册，按手册写的步骤，第一步干嘛，第二步干嘛，每一步可能还要调 CLI 或 MCP。流程更长。
CLI 是直接在本机执行，没有网络延迟，没有协议握手，没有额外的通信开销。一条 curl 命令下去，结果马上就回来了。
但是 CLI 虽然快，但是不稳，因为直接 CLI 在终端执行，一旦遇到危险命令，就可能有严重的后果，比如删了你的内容。
使用 MCP 就多了一个“外部服务商”，就相对 CLI 更稳些。
所以得靠优秀的 Agent 平台，基于里面的 Harness 工具，避免出现问题。
飞书在 3 月，公开了官方 CLI。它是为 Agent 而生的 CLI。
官方仓库：https://github.com/larksuite/cli
飞书 CLI 内置 200 多条命令，覆盖了消息、文档、表格等 17 个核心业务，Agent 调用它能省去中间环节，让真实任务跑起来。
如果官方有提供 CLI，并且 CLI 可以解决，优先走 CLI 方式。它是最快，最省，最安全，最稳的方式。
通过数据了解到，相同的处理，MCP 消耗的 Tokens 是 CLI 的 4 到 32 倍。
10 两件事正在同时发生
好玩的地方在于，Chatbot 和 Agent 正在互相靠拢。
一边是 Chatbot 在长“手”和长“脑”，越来越能干。
另一边是 Agent 在学“说话”，本来它是在后台自己跑的，现在为了面向大众用户，把界面又做回了聊天框的样子。
所以你看到的产品，比如现在的 ChatGPT、Claude，已经很难说它到底是 Chatbot 还是 Agent 了。它是个融合体。
所以严格来讲，我的结论是：
Chatbot 本身就是一个 Agent 工具。
Agent 是带有 Chatbot 界面、更集成、可以真正干活的工具。
两者不是两种东西，而是在一条能力光谱上。Chatbot 是起点，Agent 是更高阶的形态。区别就在于自动化程度和能不能自己推着任务往前走。
11 用好 AI，核心是你能不能说清楚问题
很多人以为用 AI 用得好不好，看的是 AI 模型有多强。
其实不是。
更关键的是： 你给 AI 的问题够不够清楚。
AI 是放大器。
你想得清楚，它就能把你的思路放大成更好的方案。
你想得模糊，它就放大这种模糊，给你一堆看起来有道理但没法用的废话。
举个最简单的例子：
你只跟 AI 说“帮我想想怎么发展”，它只能给你泛泛的职业建议。
但如果你说：“我在杭州做了三年运营，手上有个 500 人的活跃社群，想在三个月内通过兼职月入 3000 块。帮我分析三个最可行的方向，每个方向要讲清楚启动成本、风险和第一步具体怎么做。”
它就能给你真正有用的东西。
这就是我一直说的：AI 像一匹马，你是骑手。马有力气跑得快，但它不知道你要去哪里。你不拉缰绳，它就乱跑。你拉对方向，它才能带你到目的地。
12 别光让它说好听的
AI 有个毛病，喜欢顺着你说，让你开心。这叫“讨好偏见”。
你说往东，它说东边好。你说往西，它也说西边有价值。你问它有什么问题，它只挑不痛不痒的小毛病。
另一个毛病是“幻觉”，就是它不知道的时候不会说“不知道”，而是编一个听起来很真的答案。最吓人的是，它说真话和说假话的时候，语气一样自信。
所以我的习惯是：
- 主动让它反驳我，问我哪里想错了。
- 让它列出方案中最可能失败的地方。
- 重要的结论，用另一个模型或另一个对话窗口再问一次，这叫交叉验证。
- 凡是具体数字、事实、引用，都默认需要核实。
所以用好 AI，就是选择合适的大模型，以及合适的 Agent 工具。
除此之外，你得学会提问，内容越具体，指代越明确，AI 回答的效果就越好，出现幻觉就越少。
写Skill别急着动手，先问自己这四个问题
跟AI说话总翻车？因为你不懂它"读"东西的方式
13 多 Agent 团队：一个人管不过来就组团
当任务太复杂的时候，一个中介搞不定，那就组团。
这就是使用 AI 的第三层级：中央调度系统。
像 OpenClaw、WorkBuddy 这种，就是一个项目经理，负责调度一群专家 Agent 帮你干活。
主 Agent 不自己干活，负责拆任务、调度专家、检查结果。每个专家 Agent 都有自己独立的 Harness 和专属工具，比如专门写代码的、专门搜索的、专门验收的。
那专家 Agent 的 Harness 跟主 Agent 有什么不同？其实公式是一样的，都是“多次请求提示词 + 记忆系统 + 工具集合”，但各自的分工不一样：
主 Agent 的 Harness
管“做什么”和“为什么做”。它的多次请求侧重于拆任务和调度，它的工具集合里主要是 Skill 这种操作手册。
专家 Agent 的 Harness
管“怎么做”。它的多次请求侧重于执行具体任务，它的工具集合里挂着专属的 MCP 服务或 CLI 命令。
这是一个层级挽具结构。每个 Agent 都有自己的三件套，各管一摊。
14 厂商下场做工具，适配度最高
这里还有一个很有意思的点。
Agent 工具内设的提示词，就是针对特定模型做的 Harness。
而厂商自己做的 Agent 工具，适配度通常是最高的。
因为厂商最清楚自家模型的脾气、长处和短板，就像马的驯养师亲手为它量身打造鞍具。
所以结论是： 大模型是引擎，Agent 工具是控制系统，Skill 是加装的自动化程序。 引擎制造商亲自调校的系统，匹配度最高。
如果你用 Claude 模型，就直接用 Claude Code 官方的 Agent 工具，效果是最好的。
但是你用别的模型，是不是选用 Claude 的 Agent 工具，就不是特别重要了。
15 最终的理解
我对 AI 的认知，最后可以归结成三句话：
Agent 就是中介。它把大模型从“只能聊天”变成了“能干活的工具”。
Agent 的 Harness = 多次请求提示词 + 上下文的记忆系统 + 工具集合（Skill、CLI、MCP）。
- 你负责判断方向，AI 负责放大执行。
具体工具会更新换代，但思考问题的能力、管理上下文的方法、搭建挽具的思维，这些是永远可以带走的。
不用焦虑不会某个具体工具怎么办。术会过时，道能迁移。
使用AI干活其实就是，选择合适的模型，选择合适的agent工具，搭建属于自己习惯的缰绳工具。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～