做个兜底？本身推理框架也是识别特定标签给你包装成toll_call调用，要是没给你检测出来，自己做个匹配是不是也行

有两个问题，一是模型输出如果比较混乱匹配规则可能会比较难写，二是这样是不是就不能真流式返回了？只能先缓冲完整输出再来解析之后伪流式输出？

不支持原生toolcall就只能让他输出结构json然后后端解析了，但稳定性很差。也可以参考ds2api的toolcall解析

如何处理模型把 tool_call 参数输出到正文中的问题？

佬的意思是模型本应通过协议层返回结构化的 tool_call，却把调用意图或参数当成普通文本输出到了 content 正文里了吧

做个兜底

楼上佬友说的是可以的，但只能作为最后一道保险，不能当主要方案，因为仅靠正则或文本匹配，很容易遇到参数不完整、格式漂移、转义错误、正文误判等问题

我觉得可以先用非流式请求直接查看模型服务的原始响应，再依次对比中转层和 Agent 框架收到的结果。如果模型直连时能正常返回 tool_calls，但经过代理后进入正文，大概率是中转层转换或流式拼接有问题；如果直连也进入正文，则需要检查模型是否真正支持 tool calling 以及推理框架的 tool-call parser 配置

提示词中也不要写“请输出工具名和参数”，而应明确要求必须使用结构化工具调用，不得在正文中模拟 JSON。然后做业务侧兜底，对工具名、参数 Schema 和权限进行严格校验，避免误执行或提示注入

本质上还是要保证模型、模板、推理服务、中转层和 Agent 框架之间的协议一致

是这个意思，tool_call是支持的，就是偶尔会出错，不是必现。想知道生产级产品是怎么处理这种模型的不稳定表现的，感觉总得牺牲流式输出性能

工具调用一般就没必要使用流式输出，最后的结果输出使用流式就好吧

流式可以啊，就是遇到正文里面工具调用的时候卡一下，其他时候都是正常流式返回，比较难受的点其实就是在于匹配规则了，但是都到这一步了，只能说尽量的规则写满了

我之前也遇到过好多次，你用的是啥模型呀？小模型特别容易这样，实在不行只能在代码里加正则兜底解析了^-^