当工具越来越多，Prompt 需要分层管理
QVeris · 产品思考
当一个系统开始接入大量外部工具时，Prompt 很快会遇到一个现实问题：工具虽然都以 API 的形式暴露出来，但它们背后的语义并不相同。
最典型的是字段含义。同样是 symbol，在行情工具里可能代表证券、指数、期货或外汇；在财报工具里可能代表公司主体；到了新闻搜索工具里，真正决定查询意图的字段又可能变成 q、country、timeframe 或 category。如果所有工具都共用一份通用 Prompt，很快会造成信息量失控的问题：不同工具的字段规则、provider 约定、异常处理方式都会被塞进同一段上下文里。很多规则只适用于某一类工具，放到全局 Prompt 里不仅增加噪声，还可能和其他工具的规则发生冲突。
通用 Prompt 可以处理一些基础问题，比如字段名拼错、参数类型不匹配、枚举值格式不合法。但一旦继续往里面追加工具细节，就会遇到几个维护问题：
-
信息量膨胀：工具越多，Prompt 越长，真正相关的规则反而被埋掉。
-
适用范围不清：某条规则可能只适用于某个 provider，却被模型误用于其他工具。
-
规则互相冲突：同一个字段在不同工具里含义不同，全局规则很容易给出相反约束。
-
经验难以沉淀：历史案例如果全部塞进一份 Prompt，很难按当前 tool 精准复用。
所以，当工具数量不断增加时，Prompt 本身也需要从"一段固定说明"变成"按工具场景组织起来的上下文"。它要能根据当前 provider 和具体 tool，加载对应的规则、样例和历史经验。
这就引出了一个更合理的方向：分层 Prompt。
分层 Prompt：让模型知道自己正在修什么工具
我们可以把工具修复和评测所需的上下文拆成三层。
第一层是全局规则。
这一层适用于所有工具，比如：
-
不要用示例参数冒充修复成功。
-
不要替换用户指定的核心对象。
-
修复应优先做字段名、格式、类型、枚举值等低风险调整。
-
如果必须改变核心查询条件，应给出info提示或拒绝自动修复。
第二层是 provider 规则。
这一层根据 provider 前缀加载。例如：
-
工具 A 里，某些市场代码后缀转换可能只是 provider 约定差异。
-
工具 B 里，去掉不兼容的符号前缀可能是格式修正，但把核心查询对象替换成另一个对象就是意图偏移。
-
工具 C 里，
q、timeframe、country、language都会影响搜索范围，不能只按字段合法性判断。 -
工具 D 里，文档示例值本身不一定有问题；只有当它替换了用户原始核心对象、导致查询意图明显偏离时，才应该被标记为高风险。
第三层是 tool 精确规则。
这一层根据完整 tool_id 加载。例如：
-
quote 类工具：
symbol是核心实体字段。 -
balance sheet 类工具：
symbol表示财报查询对象，limit可能只是结果数量限制。 -
news search 类工具：
q是核心查询语义，删关键词会影响意图。 -
company overview 类工具：把无效 symbol 替换成示例 symbol，通常不能算真正修复。
这三层规则的优先级应该是：
tool 精确规则 > provider 规则 > 全局规则
这样模型不再是拿一份大而泛的 Prompt 去处理所有工具，而是针对当前工具加载合适的上下文。
RAG：让规则和历史经验动态进入上下文
分层 Prompt 解决的是规则组织的问题，但实际系统里，规则不会一次写完。
随着工具数量增加，我们会不断遇到新的 provider、新的参数约定、新的误修复模式。如果所有规则都硬编码在 Prompt 里，Prompt 会越来越长，也越来越难维护。
更好的方式是引入 RAG。
在工具修复或评测前，系统先根据当前 provider_id、tool_id、错误类型、参数字段，检索相关上下文：
-
当前工具的参数定义
-
provider 的特殊规则
-
历史修复样例
-
文档中的 sample parameter 及其风险标记
然后把检索到的内容拼进本次 Prompt，让模型基于这些上下文做判断。
这套设计解决什么问题
分层 Prompt + RAG 的目标，不只是提高自动修复成功率。
它更重要的价值在于：
-
让不同 provider 的特殊规则可以被显式表达。
-
让工具级别的风险字段可以被重点约束。
-
让历史误修复案例反过来约束未来修复。
最终，工具调用系统不应该只追求"能跑通"，而应该追求"可信地跑通"。
小结
当工具数量还少时，把规则写进一份 Prompt 里是可行的；但当工具开始成规模增长，Prompt 就不再只是"提示词"，而会变成一套需要维护的知识组织方式。
分层 Prompt 解决的是规则放在哪里的问题：通用原则放在全局层，provider 相关约定放在 provider 层，具体工具的特殊判断放在 tool 层。RAG 解决的是规则如何持续更新的问题：新的文档、样例、和人工经验，不必全部塞进固定 Prompt，而是按当前调用场景检索进来。
Prompt 不再随着工具数量线性膨胀，规则之间的冲突也更容易被隔离和管理。对于一个长期演进的工具调用系统来说，这比单纯写一份更长的 Prompt 更可持续。