MCP工具链里怎么设计Prompt才能让模型稳定输出JSON格式？

这问题我太有同感了，上个月搞类似的东西差点被整疯。先说结论：单靠System Prompt确实不够稳，尤其是MCP这种多轮调用场景，模型很容易把上下文里的“非指令文本”当成输出格式参考。

我现在的做法是三步走。第一，System Prompt里不只写“只输出JSON”，而是给一个具体的模板，比如“你的回复必须严格符合以下JSON Schema，不可包含其他字符”，后面直接贴一个带字段约束的示例。第二，在每个User Message末尾加一句“请直接返回JSON”，这个重复强调其实很管用，因为模型对近端指令更敏感。第三，如果还是偶尔翻车，就在工具调用返回后加一个轻量校验层，用正则或者json.loads兜底，检测到解析失败就自动重试一次，同时把失败原因反馈给模型，比如“上次返回多了文本，请只输出JSON”。几次下来模型就记住了。

另外你提到的上下文窗口问题，我怀疑是MCP在拼接历史消息时，某些工具返回的文本占了大量token，导致System Prompt被稀释。可以试试把System Prompt放在每次对话的头部，并且控制工具描述的长度，别让非核心内容挤占指令位置。还有一个坑：如果模型在之前的对话中见过非JSON格式的输出（比如调试时）,它可能会在后续对话里模仿那个格式，所以最好把历史消息里非标准格式的回复也清理掉。

总之别指望模型百分百听话，加一层后处理校验最稳，毕竟生产环境里一个解析失败就够折腾半天了。

这个问题我最近也踩过坑，光靠system prompt确实压不住，尤其MCP里工具调用返回后模型容易“话痨”。我的做法是在每个user message末尾加一行“请严格以JSON格式输出，不要包含任何其他文字”，同时把输出格式示例直接塞到工具返回的result里，相当于每次交互都强行矫正一次，稳定性提升不少。你试试看？

这个问题我太熟悉了，几乎每个做MCP落地的团队都会在这个坑里摔一遍。你遇到的“模型突然在JSON外面加解释文字”或者“字段名被悄悄改掉”的现象，本质上不是MCP的上下文窗口或工具调用机制在作祟，而是大模型在生成时对“约束”和“自由”的边界感知出了问题。我先给你一个最直接的结论：在System Prompt里写“只输出JSON”几乎等于没写，因为模型的注意力机制会把这条指令当成众多上下文中的一条普通文本，而不会把它当成一个硬性约束来强制执行。你需要通过更结构化的手段，让模型从“理解指令”变成“遵循协议”。

先说说我踩过的坑。去年我们在做一个MCP工具链，用来让大模型调用内部知识库API做自动补全。当时我们在System Prompt里写了“你必须严格按照以下JSON Schema输出，不允许有任何额外文字”，结果在测试阶段，模型有大概30%的概率会在JSON前面加一句“根据您的查询，我找到了以下结果”，或者在JSON后面补充“请注意，这些数据仅供参考”。最离谱的一次，模型直接输出了一个Markdown表格，然后说“为了更直观，我换了一种格式”。当时团队差点把锅甩给MCP的上下文窗口限制，但后来我们做了个实验：把同样的System Prompt放到普通Chat接口里，发现模型在普通对话里也会犯同样的错误。这说明问题不在MCP本身，而在于大模型对“输出格式”的遵守程度天然不稳定，尤其是在长上下文或多轮对话中。

那怎么解决？我总结了一套组合拳，经过多个项目验证，可以让JSON输出的稳定性达到95%以上。第一层是“指令强化”。不要在System Prompt里只写一句话，而是写一个“输出协议”段落，包含三条硬性规则：1. 所有输出必须以JSON对象开始，以JSON对象结束，首尾不得有任何字符；2. JSON必须严格匹配指定的Schema，字段名和类型不可修改；3. 如果无法生成有效JSON，必须输出一个包含error字段的JSON对象，而不是用自然语言解释。这个协议要放在System Prompt最靠前的位置，因为研究表明模型对上下文开头部分的注意力权重更高。同时，在每个User Message的末尾，用一行固定的后缀提醒，比如“请严格遵循输出协议，只返回JSON”。这相当于给模型一个“锚点”，每次生成时都会重新激活约束。

第二层是“结构强制”。MCP支持在工具定义中设置参数和返回值的Schema，但很多人在定义工具时只描述了输入参数，忽略了输出格式的约束。你应该在工具返回值的Schema里把JSON结构写死，比如用OpenAPI规范定义required字段和enum枚举值。MCP的底层机制里，工具调用本身是一个独立的函数调用过程，模型在调用工具时会更倾向于遵循函数签名中的类型约束，这比System Prompt里的自然语言指令有效得多。如果你的工具链是通过MCP的“function calling”方式调用的，那模型对输出格式的遵守程度会显著提升。但要注意，有些MCP实现允许模型在工具调用后继续生成自然语言，这就回到了最初的问题。所以你必须确保在工具定义中明确要求“strict_output: true”或者类似的开关，让MCP框架在工具返回后直接拦截模型继续生成的行为。

第三层是“后处理兜底”。这是最笨但最有效的方法。我们在MCP工具链的入口处加了一个JSON解析中间件，不管模型输出什么，先尝试用正则提取最外层的大括号内容，然后做JSON.parse。如果解析失败，就触发一个重试机制：把模型的上一次输出连同错误信息一起作为新的User Message发回去，要求模型重新生成。这个重试机制通常一次就能解决问题，因为模型在看到自己的错误输出后，会更容易理解失败的原因。我们统计过，一次重试成功率超过80%，两次重试超过95%。这个方案牺牲了一点延迟，但换来了绝对的稳定性。对于生产环境，这个代价完全可以接受。

第四层是“上下文隔离”。你提到MCP的上下文窗口可能影响Prompt优先级，这个猜测有道理。MCP的工具链通常会有多轮对话积累的历史消息，这些历史消息会稀释System Prompt的约束力。我们的做法是在每个工具调用请求中，把System Prompt重新注入到当前轮次的消息队列顶部，而不是依赖模型对历史上下文的记忆。具体实现上，我们在每次构建请求时，都会把System Prompt作为一个独立的“system”角色消息放在最前面，然后才是User Message和工具调用历史。这样即使上下文窗口很大，约束指令始终处于注意力最高的位置。

还有一个容易被忽略的细节：JSON格式的复杂程度。如果你要求模型输出一个多层嵌套的复杂JSON，字段名又长又怪，模型生成出错的概率会直线上升。我们的经验是，尽量让JSON扁平化，字段名用驼峰式且尽量短，避免使用特殊字符。如果确实需要嵌套结构，可以用JSON Schema里的$ref来定义子结构，但最终输出时让模型只输出一个对象ID，后端再通过ID去拼接完整数据。这听起来有点绕，但实际效果很好。举个例子，我们之前让模型输出一个包含用户信息和订单列表的JSON，字段名用了中文拼音，结果模型经常把“yonghu_id”写成“user_id”或者“用户ID”。后来我们把输出Schema拆成两个独立的工具调用，第一个只返回用户ID列表，第二个再根据ID返回详细信息，字段名全部用英文数字组合，问题就基本消失了。

最后，关于“是不是MCP的上下文窗口或者工具调用机制影响了Prompt的优先级”，我直接回答你：不是MCP的问题，是模型自身的生成策略问题。MCP只是一个协议框架，它不负责修改模型的生成逻辑。模型在生成文本时，会基于整个上下文做概率采样，而“输出JSON”这个指令在统计上并没有压倒性的优势，尤其是当模型在之前的训练数据中看到过大量“先解释再输出”的示例时，它会倾向于模仿这种模式。所以你的解决方案应该是从“让模型更听话”转向“让系统更健壮”，即通过多层防护来容忍模型的不完美。

如果你现在还在调试阶段，我建议你立刻做三件事：第一，把System Prompt里的“只输出JSON”改成我前面说的“输出协议”，并放在最前面；第二，在每个User Message末尾加上“请严格遵循输出协议”；第三，在MCP工具链后端加一个JSON解析重试中间件。这三步走完，你的稳定性应该能从70%提升到90%以上。如果还不够，再考虑把工具返回值Schema写得更死，或者把复杂JSON拆成多次调用。

另外给你一个可能颠覆你当前认知的思路：不要试图让模型自己输出JSON，而是让它输出一个“能生成JSON的指令”。什么意思呢？就是让模型输出一种中间表示，比如一个包含字段名和值的键值对列表，然后由后端代码来组装成JSON。这样做的好处是，模型对于“列出几个键值对”的错误率远低于“生成一个完整JSON对象”。我们在一个金融数据处理项目中就这么干过，模型输出的是“field:value”格式的文本，后端用正则解析后转成JSON。这种“降维打击”的思路虽然听起来有点土，但在工程上极其有效。

总之，这个问题没有银弹，但有一整套工程化的组合策略可以逼近100%的稳定性。希望这些经验对你有帮助，如果后续遇到具体场景的坑，可以再细聊。

我最近也踩过类似的坑，感觉光靠System Prompt真的不够稳，MCP里工具调用返回的上下文可能会把模型带偏。我现在是每个User Message末尾都加一句“严格按{格式要求}输出，否则报错”，然后把JSON schema也塞进去，频率确实降了不少。不过偶尔还是会抽风，特别是任务复杂的时候，同求大佬们有没有更硬核的解法。