当工具越来越多，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，通常不能算真正修复。
这三层规则的优先级应该是：
CODE
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 更可持续。