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

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

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

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

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

这上下文不得爆？

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

@frank1256 这个 cdp 是啥

多了会幻觉

@Fdoit Chrome DevTools Protocol

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

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

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

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

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

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

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

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

一个 hello ，上下文炸了

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

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

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

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

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

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

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

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

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

hello how are you

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

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

显然不是越多越好。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

给你举个例子

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

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

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

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

看看 Harness Engineering

@frank1256 #44 是 cdp 和 agent browser 同时安装吗？这两者不是类似功能嘛

不是越多越好的兄弟，agent 每次会把 tool list 作为上下文的，你这样直接爆炸，而且很多 skill 会互相影响调用效果也不好。

越多越不好，给 AI 造成的负担相当大。 就像去买衣服，给你太多选项，你也会迷糊。

@Rooneyxu 最重要的是 cdp 是拟人，不会被拦截。agent-browser 只是一个控制工具，你默认安装的是它自带的 headless chrome

我是这么用的。https://github.com/doccker/cc-use-exp 感谢社区的每一个 issue 和 PR ，是你们推动着它变得更好。欢迎大家继续共建，或者点个 Star 支持一下！

skill 要定制化，你塞一堆开源的，没啥效果

@Tearth 对，互相打架是真的，之前遇到过两个 skill 对同一个操作给出相反的指令，模型直接懵了原地转圈。后来的做法是给每个 skill 加上明确的触发条件和优先级，冲突的时候至少知道该听谁的。