Custom Agent 和 Skill 到底啥区别？别再用大炮打蚊子了

前段时间我写了两篇关于 MCP 的文章，一篇讲怎么让 AI 爬网页存数据，另一篇讲怎么省 Token。评论区有人问了一句把我整不会了：“小哥，你那个爬虫工具算 Skill 还是 Agent？”

我当时回复的是“Skill，因为它只是一个功能点”。

结果这哥们追问：“那啥时候该用 Agent？我看着网上教程一会说 Skills 一会说 Agents，脑子都成浆糊了。”

得，今天就把这事儿单独拎出来唠清楚。Custom Agent 和 Skill 各自该用在啥场景，别再杀鸡用牛刀，也别让狗去耕地。

---

一、先别急，这俩到底是个啥

我用最土的话解释一遍。

Skill（技能）：就是 AI 能调用的一个单功能工具。比如“查天气”“翻译一段话”“爬一个网页”“往数据库里插一条记录”。你跟 AI 说“帮我查下南京天气”，它调一次 Skill，完事。

Custom Agent（自定义智能体）：是一个会自己规划的多面手。你跟 Agent 说“帮我分析一下最近一周南京的天气趋势，结合空气质量数据，写一份出行建议，存成文档发到我的邮箱”。它需要自己拆任务：先查天气、再查空气质量、再分析趋势、再生成文档、再调邮件发送——每一步可能涉及不同的 Skill，而且它得根据中间结果决定下一步干啥。

概括一句话：Skill 是螺丝刀，Agent 是拿着螺丝刀还知道拧哪个螺丝的师傅。

从技术实现看：

• Skill 对应大模型的 Function Calling 里的单个 function，或者 MCP Server 里注册的一个 tool。你定义好输入输出，模型决定什么时候用。
• Agent 则是一个带循环的执行引擎，通常有“思考（Plan）→ 行动（调用 Skill）→ 观察结果 → 再思考”的循环，还会带记忆和任务拆解能力。

---

二、核心区别：就三个维度，看完不迷糊

我画不了图，直接上表格。

维度	Skill	Custom Agent
任务复杂度	单步、确定性的任务	多步、需要动态调整的任务
决策能力	模型只决定“调不调这个 Skill”	模型决定“先干啥、再干啥、如果失败了怎么办”
记忆与状态	无状态，这次调用跟下次无关	有状态，记住之前做了啥，中间结果可以传递
典型实现	Function Calling / MCP Tool	Agent 框架（LangChain Agent、AutoGPT、CrewAI）
Token 消耗	每次 1 次 LLM 调用 + Skill 执行	多轮思考+多次 LLM 调用，容易烧钱

说白了，你要是就想让 AI 帮你“查个东西”或者“做个简单转换”，Skill 足够。你要是想让 AI “独立完成一个需要好几个步骤、还要根据情况变通的活儿”，那得上 Agent。

---

三、场景举例：看完就知道该用谁

场景 1：文本翻译

用户输入：“把这段话翻译成英文。”

这就是个单步任务。你定义一个 translate Skill，接收文本和目标语言，返回翻译结果。模型调用一次 Skill，完事。上 Agent 纯属浪费，多烧十倍的 Token 去做“规划”，最后还不是调同一个翻译 Skill。

场景 2：客服查询

用户问：“我的订单到哪了？”

典型的单步查询。定义一个 query_order Skill，输入订单号，返回物流状态。模型调一次 Skill 就能回。

场景 3：竞品分析助手

用户说：“帮我把 A 网站、B 网站、C 网站上关于‘智能手表’的产品参数抓下来，对比价格和功能，生成一个对比表，把有优势的标绿，最后存成 Excel。”

这事儿一个 Skill 搞不定。它需要：

• 爬取三个网站的网页内容（可能涉及多个 web_fetch Skill）；
• 从内容里提取产品参数（需要解析，可能还得调用一个提取 Skill）；
• 对比价格和功能（需要推理能力）；
• 生成对比表并标颜色（需要代码生成或特殊处理）；
• 存成 Excel（又是一个 Skill）。

而且每一步的结果会影响下一步：爬下来发现某个网站反爬，Agent 得换策略；提取的参数格式不统一，Agent 得自己想办法归一化。

这时候就得用 Custom Agent，让它自己规划步骤、调用 Skill、处理异常。

场景 4：自动代码修复

用户说：“我的 Spring Boot 项目启动报错了，帮我修一下。”

如果只是一个固定的“粘贴错误日志，返回修改建议”，那一个 Skill 也能凑合。但真实场景往往是：

• Agent 要先读项目结构；
• 根据日志定位哪个文件；
• 查看相关代码；
• 分析可能的原因；
• 尝试修改；
• 如果修改后还有错，继续迭代。

这是典型的“多步推理+工具调用”，Agent 才能干。

场景 5：定时报告生成

用户说：“每天早上 8 点，帮我汇总 GitHub 上某项目的 issue 和 PR，总结进展，发到我的钉钉群。”

一个 Skill 做不了，因为涉及多个操作和时间触发。Agent 可以作为后台服务，定时触发，调用 fetch_issues、fetch_prs、summarize、send_dingtalk 等多个 Skill，中间还可能做格式转换。

---

四、我踩过的坑：用 Agent 查天气，Token 烧了一顿饭

不瞒你们说，我一开始学 Agent 框架的时候，特别兴奋。给一个 Agent 配了天气查询、网页抓取、数据库存储等一堆 Skill，然后让它“帮我查下明天杭州天气”。

你猜怎么着。

Agent 开始思考：“用户想要天气信息，我需要先确定城市。城市是杭州。我可以用天气查询 Skill 来获取数据。但在获取之前，我要确认用户是否想知道更详细的信息，比如湿度、紫外线指数。我先查天气，再根据结果决定是否需要更多信息。好的，我现在调用天气查询 Skill……”

它光“思考”就烧了我一千多 Token，最后调用的还是同一个天气 Skill。

而同样的需求，我一个 Skill 直接绑到 Function Calling 上，模型一次调用就结束了，Token 消耗差了将近 10 倍。

血的教训：能一步搞定的事情，千万别让 Agent 演内心戏。

---

五、实战建议：一个判断流程图帮你选

我给你一个土法判断流程，照着来就行：

1. 任务能不能用一次调用完成？（是 → Skill，否 → 往下看）
2. 任务需不需要多个步骤，而且步骤之间有依赖？（是 → 往下看，否 → Skill）
3. 任务执行过程中会不会出现意外情况，需要根据中间结果改策略？（会 → Agent，不会 → 多个 Skill 串起来也能用）
4. 任务需不需要长时间运行，或者跨多个会话？（需要 → Agent，不需要 → Skill + 简单编排）

举个例子：

• “把这段 JSON 转成 Java 对象” → Skill
• “根据需求文档生成全套 CRUD 代码，包括 Controller、Service、Mapper、测试，并自动修复编译错误” → Agent
• “每天定时抓新闻，分析情感，存库” → Agent（但也可以用简单的脚本加 Skill，灵活选择）

成本角度：

• Skill：每次任务 1-2 次 LLM 调用，Token 很少。
• Agent：每个子任务至少 1 次 LLM 调用，加上思考、反思、自我纠错，轻松上 10-20 次调用。用 GPT-5.4 的话，复杂任务一次几块钱很正常。

所以，别拿 Agent 当 Skill 用，你的账单会哭。

---

六、总结：别被概念忽悠，按需选型

最后说两句人话：

Skill 是 AI 的“手”，让它能干具体的活。Agent 是 AI 的“脑”，让它自己规划怎么干。

如果你就给 AI 装一只手，它只能做你指定的动作。如果你给它一个大脑加上一堆手，它就能自己搞一套组合拳。

但记住——不是所有的活都需要组合拳。拧个螺丝，一只手就够了，非得搭个机器人工厂，除了感动自己，没半点好处。

实际开发中，先从 Skill 开始。当你发现任务复杂到 Skill 搞不定、需要多步推理和动态决策的时候，再引入 Agent。别一上来就整 Agent 框架，不然你调半天参数，发现还不如一个 if-else 好使。