问题出现得很突然，日志倒是留得挺全。用 PromptTemplate 写 SQL 生成提示词，模板里带 JSON 示例 {“table”:”orders”}，调用 format 抛 KeyError: ‘”table”‘，改成 f-string 又因为 SQL 里的花括号报语法错。
刚开始盯着「模板里既有 JSON 示例又有真实变量，没有区分转义与占位」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。PromptTemplate 按 f-string 规则解析花括号，JSON 示例里的左括号被当变量起点。另一种情况是变量名含引号或冒号，不满足标识符规则，解析时直接当键名抛错。
另外，选了 Jinja2 模板类，却仍按 f-string 写法给示例。
第一件事是看模板被解析出哪些变量
python -c "from langchain_core.prompts import PromptTemplate;print(PromptTemplate.from_template('示例 {{json}} 问题 {q}').input_variables)"随后把示例的花括号加倍转义后渲染
python -c "from langchain_core.prompts import PromptTemplate;print(PromptTemplate.from_template('示例 {{json}} 问题 {q}').format(q='近七天订单'))"再往下在源文件里定位未转义的花括号
findstr /n "{" prompts\sql_template.txt末了统计单括号与双括号数量做断言
python -c "s=open('prompts/sql_template.txt',encoding='utf-8').read();print(s.count('{{'),s.count('{'))"别只看报错消失，验证要多做一步。渲染结果里 JSON 示例原样保留且问题被填入，input_variables 只剩 q，调用不再抛 KeyError。
容易忽略的是，只要模板里出现 JSON 或代码片段，就统一走转义或换成更宽松的模板类，混着写迟早踩一次。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。