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

[lynn1su]

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

[agegcn]

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

[frank1256]

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

[wat4me]

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

[Grooveys]

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

[dp]

这上下文不得爆？

[apkapb]

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

[Fdoit]

@frank1256 这个 cdp 是啥

[ARIInV2]

多了会幻觉

[frank1256]

@Fdoit Chrome DevTools Protocol

[Plutooo]

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

[swaylq]

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

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

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

[JerryZhi]

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

[ThisDay]

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

[lynn1su]

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

[chen27]

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

[Tink]

一个 hello ，上下文炸了

[AItsuki]

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

[sc13]

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

[Tearth]

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

[wat4me]

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

[mortal]

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

[mjawp]

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

[TUGOh0st]

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

[exoticknight]

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

[Jiajin]

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

[collery]

hello how are you

[thevita]

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

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

[gam2046]

显然不是越多越好。

打个比方就是，让你写个命题作文，然后从康熙词典到故事会的文献都给你来参考，还是只给你一本和命题相关的书籍，让你来参考写作，哪个更容易一些呢。

前一种，都没开始写作，光挑选参考文献的时候，就已经懵逼了。

[YanSeven]

上下文+注意力限制了你。

[Muniesa]

上下文过长会导致模型性能断崖式下滑

[Lanayaaa]

@frank1256 哈哈 如果没有 token 焦虑的话，好像确实可以这样。

[cheng6563]

别说 1M 了，上下文超过 20K 都能感到性能明细下降。

[ufan0]

请问“免费的 gpt-5.4”怎么获得的？

[musi]

我一直认为使用 AI 代指 LLM 是个错误的方式，这会使人们看不到 LLM 的问题

[lynn1su]

@ufan0 #33 反代 condex ，可以转换成 api 的模式

[7gugu]

现在依旧会有注意力涣散的问题，如果注意力问题可以解决的话，肯定是越多越好的，但现在因为存在注意力涣散的问题，你给 AI 越多选择，他就越容易选错工具。

[chtcrack]

越多浪费的上下文越多,生成的代码越是不符合.

[COW]

@frank1256 可以展开说说吗，为什么说用了 cdp 就不需要 skill 了呢？你的意思是让 cdp 自己去浏览器里搜索自己想要的 skill ？

[xuwen]

mcp 不是越多越好，skill 是用来解决 mcp 过多导致 token 太多，注意力分散，意图分类不精确等问题的

[frank1256]

@COW 我寻思 cdp 打通后，大部分的 skill 都能覆盖了。新闻，搜索，小红书？ gogs 的，也能代替把，但是费很大 token ，而且没有 api 来的快。比如，我闲鱼想盯着有没有低价的某个东西，这个 cdp 就直接去做了。我的意思是你能用 chrome 做的事情，它蛮多都能做了。

[frank1256]

@COW 最重要的是 cdp 是拟人，不会被拦截。

[sharpy]

1000 多个 tool 和 200 多个 mcp 起怕是有点儿多哦

[bond020]

@frank1256 agent-browser 与 CDP 可以配合使用吗？我配置了 CDP ，卸载了 agent-brower

[frank1256]

@bond020 官方 browser 也可以，还有一个 browser-use ，我试下了 agent-browser 最好用，最准，耗时最短 token 最少。用的 snapshot 啥技术

[cxd8190102]

别挂太多，而且你也可以指定它用哪个，别让它自己一个个试，成本下不来。

[viking602]

太多会影响上下文的 选对的就行了 没必要这么多 ..

[hailaz]

给你举个例子

我一次性给你讲这里有 100 本不同领域的书，每本书大概能做什么（一两句话的长度介绍），你不能用任何人脑以外的方式记住这些介绍。

过后我问你，说一下第 19 本和 50 本书的介绍，估计你就懵逼。

这就大模型的上下文，容量有限，塞的内容越多他就不知道自己要干嘛该怎么做。

[goodboy95]

mcp 是会全部加载到上下文的，开多了上下文会爆炸

[turi]

看看 Harness Engineering