SKILL 和 mcp 这两个是不是对 ai 来说越多越好？目前我弄了 1000 多个 tool 和 200 多个 skill 一股脑塞给 ai

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

1.api 是免费的 gpt-5.4 ，所以不担心 token 的问题
但是弄了这么多后没感觉变强了
2.所有类型的工具和 skill 都有 10 个以上，比如网页搜索，我把百度必应 goole ，tavily ，duckduckgo ，博查啥的都装上去了，给他说好每次要全部使用交叉验证，还是只用三个，有点烦
3.大家都是怎么弄的？
4.工具调用模式是 full

SKILL

Tool

49 条回复 • 2026-03-24 19:07:20 +08:00

agegcn

12 小时 20 分钟前

越少越好。选择越多越容易选错

frank1256

12 小时 19 分钟前

我之前也搞了很多 skill ，后来发现 cdp 弄好，就没 skill 啥事了，只要一个 agent-browser 就可以了。有了 chrome ，就有了整个世界

wat4me

12 小时 15 分钟前

好奇塞完之后，对话窗口上下文能剩多少

Grooveys

12 小时 4 分钟前

skill 和 tool 都会占用上下文的，太多会导致回复效果变差

12 小时 1 分钟前

这上下文不得爆？

apkapb

11 小时 59 分钟前

除了极少数通用的、有用的 skill ，其余的 skill 我是建议自己写：在某次功能完成之后，让 AI 来总结成 skill （当前前提是该套路、方法后面会经常用到）

Fdoit

11 小时 58 分钟前 via Android

@frank1256 这个 cdp 是啥

ARIInV2

11 小时 53 分钟前

多了会幻觉

frank1256

11 小时 49 分钟前

@Fdoit Chrome DevTools Protocol

Plutooo

11 小时 47 分钟前

越少越好，珍贵的不是 token 花费而是每次对话 llm 上下文的聪明区，网上找个抓包分析的视频你就能明白怎么用更合适了

swaylq

11 小时 47 分钟前

1000 个 tool 塞进去上下文直接废掉大半，模型光是理解"我有哪些工具可以用"就烧掉一堆 token ，真正留给干活的空间反而少了。

我的经验是 skill 按需加载比较靠谱——平时只挂十来个核心的，需要特定能力的时候再动态拉进来。搜索引擎同理，挂一两个够用的就行，全装上去让 AI 每次都调五六个再交叉验证，延迟和成本都顶不住。

同意楼上说的，好用的 skill 最好自己从实际项目里沉淀出来，外面搜罗一堆通用的反而噪音太大。

JerryZhi

11 小时 46 分钟前

skill 要分情况，如果是有具体细分工作的牛马 subagent ，尽可能只给他必要的 skill
如果是负责分发任务的 PM 型 subagent ，尽可能多装一些，让自己对话舒服，既然是 skill ，就应该往无感的方向发展，不要天天焦虑他有没有这个 skill

ThisDay

11 小时 43 分钟前

正常全局的个位数就够用了，然后各个项目目录下可以存一些项目级的 skill

lynn1su

11 小时 41 分钟前

@wat4me #3 要用 210000 左右的上下文，模型是 1m 的上下文

chen27

11 小时 40 分钟前

LLM 给的上下文越长，性能下降越厉害。所以要给最精确、最需要、尽可能少的内容。

Tink

PRO

11 小时 22 分钟前

一个 hello ，上下文炸了

AItsuki

11 小时 21 分钟前

越少越好，上下文膨胀会让 AI 变蠢。

sc13

11 小时 21 分钟前

太长了不行的，1.是占用上下文长度 2.是 tool 太多 ai 会不知道到底要用哪一个 tool 。可以根据不同的业务场景，使用不同的 agent ，不同的 agent 默认带的 skills 不一样，只用来处理专门的问题，这样效率会比较高，token 也节省。最前面放一个 llm 用来区分问题应该给哪些 agent 来处理就行了

Tearth

11 小时 20 分钟前

@swaylq 而且技能也会互相打架

wat4me

11 小时 7 分钟前

@lynn1su 1M 上下文真正可用的可能就 50%多，再多大模型会产生幻觉，也就是除去工具以外，你实际可用的上下文还剩 30%了，同一对话窗口 AI 再去调用 tools ，30%都剩不下

mortal

11 小时 5 分钟前

人家 skill 一个重要的特性就是渐进式披露，你还搞越多越好

mjawp

11 小时 5 分钟前

claude code 出了一个 find tools 的工具，所以理论上你再多的 skill 和 tool 都不会干涉上下文了

TUGOh0st

11 小时 4 分钟前

并不是越多越好，看你如何分配 skill 给 agent ，这个非常有讲究的，而不是一股脑地赛 1000 个之类的，如果遇到两个或者多个类似的 skill 会导致 agent 混乱。要做好 skills 路由、上下文管理、工具编排、约束与安全、评测体系、可维护性、发现机制、容错和降级。

exoticknight

11 小时 2 分钟前

你好，不是，请控制 20 个以内

Jiajin

11 小时 0 分钟前

20 个 skills 顶天了，而且是我明确要用的时候才会指定让他用 skills 。你也不想你的模型注意力被分散吧？

collery

10 小时 55 分钟前

hello how are you

thevita

10 小时 50 分钟前

1. tool 这种东西单纯的多没意义，追求的应该是"可组合性",即工具间能相互争强，扩展使用场景（既然你多个搜索的目的是整合多信源，那你其实需要的是一个高置信度的信源, 用现有的 10+个网页搜索做一个 subagent 也好，还是干脆花钱买个商业的都行啊，这种由明确目标的问题最好还是寻找一个直接的解决方案，而不是一股脑扔给 LLM ）

2. 对于 LLM 来说，现在以及在短暂可预见的未来，Context 都是关键最资源，如果 Context 里长期存在一大堆绝大多数时间都用不上的信息，肯定不是最优解，不只是成本问题，长上下文时，注意力稀释问题对模型表现影响很大