
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通常不能算真正修复。这三层规则的优先级应该是CODEtool 精确规则 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 更可持续。