平台技能 — 每个智能体都已具备的能力

原则 —— 平台技能是方法，租户技能是你的业务。 共享库保存通用的工作方式（调研竞争对手、阅读法规、评估潜在客户）。任何特定于你的行业或你的数据的内容都应放在你自己的技能中。更多详情请参见 设计原则。

每个代理都拥有一组平台技能，无需分配即可使用。它们是通用的工作方法，按需加载，就像任何其他技能一样，你无需逐个附加它们。

为什么它们不仅仅是“代理上的更多技能”

一个包含数百种方法的库无法放入提示词中。完整列出它们会显著影响选择效果：当列出全部 207 个技能时，模型选对正确技能的概率仅为 30%；当列表首先缩小到最相关的 15 个时，该概率为 51%。因此，平台在列出之前会先进行检索。

检索针对当前消息运行，同时覆盖两个库——共享库和你的库。你的技能不会因与通用技能共享空间而处于劣势：在将 18 个真正的行业特定技能混合到 193 个通用技能中进行的测量中，行业技能被识别的可靠性更高（86% 对比 79%），因为行业词汇与通用方法词汇相距甚远。

在大约八个技能以下，不会进行检索——直接显示完整列表。 在这个规模下，列表已经准确，检索反而可能引入新的失败：正确技能未出现在短列表中，模型随后根据其自身知识作答，且日志中无任何迹象。

你控制什么，不控制什么

用英文编写

平台技能是用英文编写的——description、instructions、menu_label 以及生成的触发短语。

这不仅是为了演示。在相同的 193 个中文技能库上测量，将三个平台技能从中文切换为英文提高了每个技能被识别的可靠性：竞争对手调研 75% → 83%，政策阅读 83% → 100%，潜在客户资格验证 50% → 62%。英文技能在向量空间中距离一堆中文技能更远，因此更容易被挑选出来。（这种优势来自于不同，而非英语本身——在全部为英文的库中，这种优势会消失。）

语言不会影响模型调用技能的能力：自托管的 35B 模型和托管模型均从中文和英文描述中发出了正确、格式良好的 load_skill 调用。选择英语是一个产品决策，而非技术变通方案。

你自己的技能则是另一回事——用你的客户使用的任何语言编写它们。

让平台在技能开工前先去调研

技能可以要求平台先把材料备好再开工。在 instructions 的最上面写这一行：

PREFETCH: web x4

平台会把访客那句话变成这么多条检索式、跑一遍，再把一张编号的事实表交给技能去引用。只写 PREFETCH: web 表示用默认的两条；不写这一行就什么都不搜。

只在问题有好几个面的时候才要更宽的。 一次产品调研——价格、限制、导出——用窄的那一版实测是 2957 字配 5 条出处，里面每个价格都是任何来源里都找不到的具体数字；改成四条检索式之后，同一个问题带回 17 条出处。起草、改写、算账的技能则应该什么都不声明：一次它不需要的检索，就是白花的时间和钱。

这替代不了把规则写下来，但它是真正起作用的那一半。同一个技能的指南里本来就写着绝不写出材料里没有的价格，它照写不误。改变答案的是材料，不是那句话。

编写真正被使用的技能

遵循与任何技能相同的规则，外加一个仅在大规模下显现的规则：

• description 说明何时使用，使用客户会用的词汇。 这是检索匹配的依据。
• instructions 以技能不涵盖的内容结尾。 拥有数百个技能时，近邻情况不可避免；这行结尾说明是模型注意到打开错误技能的唯一方式。
• 触发短语由系统生成——八种普通人可能会请求它的通俗方式——你可以编辑它们。它们用于匹配，从不向访客显示，且你的编辑不会被重新生成覆盖。

编写后有一个值得运行的检查：询问库中每个触发短语检索到哪个技能。如果一个技能自己的触发短语总是返回为其他技能，则该技能虽然在库中但无法被访问——将其与始终胜出的技能合并，或明确说明两者的区别。