 |
1
agegcn Mar 24
越少越好。选择越多越容易选错
|
 |
2
frank1256 Mar 24
我之前也搞了很多 skill ，后来发现 cdp 弄好，就没 skill 啥事了，只要一个 agent-browser 就可以了。有了 chrome ，就有了整个世界
|
 |
3
wat4me Mar 24
好奇塞完之后，对话窗口上下文能剩多少
|
 |
4
NeoAshes Mar 24
skill 和 tool 都会占用上下文的，太多会导致回复效果变差
|
 |
5
dp Mar 24
这上下文不得爆？
|
 |
6
apkapb Mar 24
除了极少数通用的、有用的 skill ，其余的 skill 我是建议自己写：在某次功能完成之后，让 AI 来总结成 skill （当前前提是该套路、方法后面会经常用到）
|
 |
8
ARIInV2 Mar 24
多了会幻觉
|
 |
10
Plutooo Mar 24
越少越好，珍贵的不是 token 花费而是每次对话 llm 上下文的聪明区，网上找个抓包分析的视频你就能明白怎么用更合适了
|
 |
11
swaylq Mar 24  3
1000 个 tool 塞进去上下文直接废掉大半，模型光是理解"我有哪些工具可以用"就烧掉一堆 token ，真正留给干活的空间反而少了。
我的经验是 skill 按需加载比较靠谱——平时只挂十来个核心的，需要特定能力的时候再动态拉进来。搜索引擎同理，挂一两个够用的就行，全装上去让 AI 每次都调五六个再交叉验证，延迟和成本都顶不住。 同意楼上说的，好用的 skill 最好自己从实际项目里沉淀出来，外面搜罗一堆通用的反而噪音太大。 |
 |
12
JerryZhi Mar 24
skill 要分情况，如果是有具体细分工作的牛马 subagent ，尽可能只给他必要的 skill
如果是负责分发任务的 PM 型 subagent ，尽可能多装一些，让自己对话舒服，既然是 skill ，就应该往无感的方向发展，不要天天焦虑他有没有这个 skill |
 |
13
ThisDay Mar 24
正常全局的个位数就够用了，然后各个项目目录下可以存一些项目级的 skill
|
 |
15
chen27 Mar 24
LLM 给的上下文越长，性能下降越厉害。所以要给最精确、最需要、尽可能少的内容。
|
 |
16
Tink PRO 一个 hello ，上下文炸了
|
 |
17
AItsuki Mar 24
越少越好，上下文膨胀会让 AI 变蠢。
|
 |
18
sc13 Mar 24
太长了不行的，1.是占用上下文长度 2.是 tool 太多 ai 会不知道到底要用哪一个 tool 。可以根据不同的业务场景，使用不同的 agent ，不同的 agent 默认带的 skills 不一样，只用来处理专门的问题，这样效率会比较高，token 也节省。最前面放一个 llm 用来区分问题应该给哪些 agent 来处理就行了
|
|
20
wat4me Mar 24
@lynn1su 1M 上下文真正可用的可能就 50%多，再多大模型会产生幻觉，也就是除去工具以外，你实际可用的上下文还剩 30%了，同一对话窗口 AI 再去调用 tools ，30%都剩不下
|
 |
21
mortal Mar 24
人家 skill 一个重要的特性就是渐进式披露，你还搞越多越好
|
 |
22
mjawp Mar 24
claude code 出了一个 find tools 的工具，所以理论上你再多的 skill 和 tool 都不会干涉上下文了
|
 |
23
TUGOh0st Mar 24
并不是越多越好，看你如何分配 skill 给 agent ，这个非常有讲究的，而不是一股脑地赛 1000 个之类的，如果遇到两个或者多个类似的 skill 会导致 agent 混乱。要做好 skills 路由、上下文管理、工具编排、约束与安全、评测体系、可维护性、发现机制、容错和降级。
|
 |
24
exoticknight Mar 24
你好，不是，请控制 20 个以内
|
 |
25
Jiajin Mar 24
20 个 skills 顶天了，而且是我明确要用的时候才会指定让他用 skills 。你也不想你的模型注意力被分散吧？
|
 |
26
collery Mar 24
hello how are you
|
 |
27
thevita Mar 24
1. tool 这种东西单纯的多没意义，追求的应该是"可组合性",即工具间能相互争强，扩展使用场景（既然你多个搜索的目的是整合多信源，那你其实需要的是一个高置信度的信源, 用现有的 10+个网页搜索做一个 subagent 也好，还是干脆花钱买个商业的都行啊， 这种由明确目标的问题最好还是寻找一个直接的解决方案，而不是一股脑扔给 LLM ）
2. 对于 LLM 来说，现在以及在短暂可预见的未来，Context 都是关键最资源，如果 Context 里长期存在一大堆绝大多数时间都用不上的信息，肯定不是最优解，不只是成本问题，长上下文时，注意力稀释问题 对模型表现影响很大 |
 |
28
ntdll Mar 24
显然不是越多越好。
打个比方就是，让你写个命题作文，然后从康熙词典到故事会的文献都给你来参考，还是只给你一本和命题相关的书籍，让你来参考写作，哪个更容易一些呢。 前一种，都没开始写作，光挑选参考文献的时候，就已经懵逼了。 |
 |
29
YanSeven Mar 24
上下文+注意力限制了你。
|
 |
30
Muniesa Mar 24 via Android
上下文过长会导致模型性能断崖式下滑
 |
 |
32
cheng6563 Mar 24
别说 1M 了，上下文超过 20K 都能感到性能明细下降。
|
 |
33
ufan0 Mar 24
请问“免费的 gpt-5.4”怎么获得的？
|
 |
34
musi Mar 24 via iPhone
我一直认为使用 AI 代指 LLM 是个错误的方式，这会使人们看不到 LLM 的问题
|
 |
36
7gugu Mar 24
现在依旧会有注意力涣散的问题，如果注意力问题可以解决的话，肯定是越多越好的，但现在因为存在注意力涣散的问题，你给 AI 越多选择，他就越容易选错工具。
|
 |
37
chtcrack Mar 24
越多浪费的上下文越多,生成的代码越是不符合.
|
 |
39
kazumaa Mar 24
mcp 不是越多越好，skill 是用来解决 mcp 过多导致 token 太多，注意力分散，意图分类不精确等问题的
|
|
40
frank1256 Mar 24
@COW 我寻思 cdp 打通后，大部分的 skill 都能覆盖了。新闻，搜索，小红书？ gogs 的，也能代替把，但是费很大 token ，而且没有 api 来的快。比如，我闲鱼想盯着有没有低价的某个东西，这个 cdp 就直接去做了。我的意思是你能用 chrome 做的事情，它蛮多都能做了。
|
 |
42
sharpy Mar 24
1000 多个 tool 和 200 多个 mcp 起怕是有点儿多哦
|
|
44
frank1256 Mar 24
@bond020 官方 browser 也可以，还有一个 browser-use ，我试下了 agent-browser 最好用，最准，耗时最短 token 最少。用的 snapshot 啥技术
|
 |
45
cxd8190102 Mar 24
别挂太多，而且你也可以指定它用哪个，别让它自己一个个试，成本下不来。
|
 |
46
viking602 Mar 24
太多会影响上下文的 选对的就行了 没必要这么多 ..
|
 |
47
hailaz Mar 24
给你举个例子
我一次性给你讲这里有 100 本不同领域的书，每本书大概能做什么（一两句话的长度介绍），你不能用任何人脑以外的方式记住这些介绍。 过后我问你，说一下第 19 本和 50 本书的介绍，估计你就懵逼。 这就大模型的上下文，容量有限，塞的内容越多他就不知道自己要干嘛该怎么做。 |
 |
48
goodboy95 Mar 24 via Android
mcp 是会全部加载到上下文的，开多了上下文会爆炸
|
 |
49
turi Mar 24
看看 Harness Engineering
|
 |
51
AEDaydreamer Mar 25
不是越多越好的兄弟，agent 每次会把 tool list 作为上下文的，你这样直接爆炸，而且很多 skill 会互相影响调用效果也不好。
|
 |
52
zqguo Mar 25
越多越不好，给 AI 造成的负担相当大。 就像去买衣服，给你太多选项，你也会迷糊。
|
|
53
frank1256 Mar 25
@Rooneyxu 最重要的是 cdp 是拟人，不会被拦截。agent-browser 只是一个控制工具，你默认安装的是它自带的 headless chrome
|
 |
54
sprinng Mar 25
我是这么用的。https://github.com/doccker/cc-use-exp 感谢社区的每一个 issue 和 PR ，是你们推动着它变得更好。欢迎大家继续共建，或者点个 Star 支持一下！
|
 |
55
heftyMan Mar 25
skill 要定制化，你塞一堆开源的，没啥效果
|
Select Language