模型输出截断主因是max_tokens超限，需先查finish_reason字段确认；再调高节点级最大回复长度，注意不超过模型context_length；对JSON等结构化输出启用Schema引导或终止符；最后用json_repair容错解析。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
在函子Zion平台中，模型节点运行后返回内容不完整、末尾突然中断、字段为空或提示“输出截断”，说明生成过程被强制终止，核心原因是模型输出长度超出了当前配置的硬性上限。
确认是否真为截断而非其他失败
先查看节点执行日志右侧的原始响应体（Raw Response），定位finish_reason字段值：若为length，即确认是max_tokens触顶导致；若为stop，则属正常结束；若为空或content_filter，则需另查安全策略或输入合规性。
这一步不能跳过——误把content_filter当成截断去调大max_tokens，只会让敏感内容更频繁地被拦截。
调高模型最大输出长度
函子Zion中，每个大模型节点都独立控制输出上限，该参数不继承全局设置。
方法一：图形界面调整
1. 点击目标节点→右上角「设置」图标→进入「模型配置」页签；
2. 找到「最大回复长度」滑块或输入框；
3. 将数值从默认的【4096】提升至至少8192（若输出含长列表或嵌套JSON，建议设为12288）；
4. 保存后重新试运行，观察原始响应中finish_reason是否变为stop且内容完整。
方法二：API方式覆盖（适用于批量部署）
在节点请求体（request body）中显式注入max_tokens字段，例如：{"max_tokens": 12288}。注意：此值不可超过所选模型文档标注的绝对上限（如Zion-GLM4上限为16384），否则请求会被平台静默截断并报400。
验证上下文总长度是否溢出
仅调大max_tokens还不够——如果输入prompt本身已占满大量token，剩余空间仍不足以容纳预期输出，截断照旧发生。
打开Zion控制台的「Token分析」面板（位于节点调试页右侧），粘贴当前完整输入文本，点击「估算」：
→ 查看「Input Tokens」数值；
→ 对照你设定的「max_tokens」，确认二者之和未超过模型标称的「context_length」（例如Zion-Qwen2-72B为131072）；
→ 若接近或超过90%，必须削减输入：删减示例、压缩历史对话、用摘要替代原文。
很多用户卡在这一步：猛调max_tokens到20000，结果发现输入已占125000 token，模型根本没机会开始生成就因context_length_exceeded直接拒绝。
启用结构化输出约束（防JSON类截断）
当输出目标是JSON、YAML等严格格式时，自由文本模式极易在截断点留下半截括号或引号，导致下游解析器崩溃。
方法一：开启JSON Schema引导
在节点「高级设置」中勾选「结构化输出」→ 选择「JSON Schema」→ 粘贴你的schema定义（必须是合法JSON格式）。Zion后台会自动启用guided decoding，强制模型逐字符生成合规JSON，显著降低中途断在逗号、引号、括号内的概率。
方法二：添加硬性终止符
在System Prompt末尾追加一句：请严格只输出JSON对象，结尾必须包含一个完整的}，不要任何额外说明文字。。这虽不如Schema可靠，但对轻量级结构有效，且不依赖平台功能开关。
注意：若schema中定义了required字段，而模型因截断未能生成全部字段，即使语法完整，业务校验仍会失败——此时需配合策略三的容错解析。
添加客户端容错解析（最后一道防线）
即便完成上述所有配置，网络抖动、流式传输中断或模型推理异常仍可能导致前端收到不完整字符串。此时不应让整个流程因json.loads报错而中断。
在调用Zion API的业务代码中，替换原始JSON解析逻辑：
→ 不再使用json.loads(response_text)；
→ 改用json_repair.loads(response_text)（需pip install json-repair）；
→ 或用正则提取首个{.*?}或\[.*?\]最外层结构（配合re.DOTALL标志）。
这一步操作起来很简单，直接把解析函数替掉就行，但能避免90%因截断引发的500错误和空数据入库。
