eino reasoning_content 字段速查三步看懂模型的推理过程【免费下载链接】einoThe ultimate LLM/AI application development framework in Go.项目地址: https://gitcode.com/GitHub_Trending/ei/eino调试 Agent 时常遇到这种情况模型答错了但说不清是推理环节错还是表述环节错。eino reasoning_content 是 Go 语言 LLM 应用开发框架 eino 消息结构里的一个字段用来存模型的思考过程模型一旦返回思考内容它就会被写进消息你可以打印它、存历史、计入 token。上图是 eino 的 ReAct Agent 循环模型调用与工具调用交替进行当你想看模型为什么选了某个工具、传了哪些参数reasoning_content 就是第一手材料。eino 思考内容字段里到底存了什么一张草稿纸定义在 schema/message.go 第 528 行Message结构体的直接成员ReasoningContent string json:reasoning_content,omitempty它就是个字符串取值状态只有两种模型返回了思考过程比如推理模型给出的思维链它有值普通模型或本轮没输出思考它是空字符串。omitempty的标注意味着序列化为 JSON 时空字段会被自动省略不会改变既有对接方的负载体积。可以把它和 Content 对照着理解Content 是卷面上的最终答案ReasoningContent 是旁边的草稿纸两者都挂在同一条消息上没有草稿纸时就不存在。顺带两个相关统计响应的CompletionTokensDetails里有ReasoningTokens计数思考消耗的 tokenschema/openai/extension.go 的 OpenAI 协议扩展用ReasoningExtension保留了分段思考内容的原始结构供需要更细粒度信息的实现使用。一次对话的时间线推理内容如何产生、流动、呈现按一次调用的时序走这个字段经过三个环节。产生。模型返回后对应的 provider 实现把响应里的 reasoning 部分解析进Message.ReasoningContent。流式输出时它分 chunk 到达每个 chunk 只带一小段文本首个 chunk 有时甚至只有 Role。流动。字段跟着消息原样传回模型中间处理环节也不丢它adk/middlewares/reduction/reduction.go 里 reduction 中间件的copyMessages逐字段复制它defaultTokenCounter直接把它的长度计入文本adk/middlewares/summarization/summarization.go 的 summarization 中间件统计消息长度时同样按len(msg.Content) len(msg.ReasoningContent)计算。呈现。流式 chunk 合并时schema/message.go 的ConcatMessages按顺序拼接每个非空 chunk 的ReasoningContent得到完整思考内容打印单条消息时String()会把这段内容以独立的 reasoning content: 小节输出。上图是 eino 的流式输出机制模型按 chunk 返回框架把各 chunk 合并成一条完整消息ReasoningContent 与 Content 走的是同一条合并路径。三步确认模型的思考过程最短路径就三步调用返回后判断有没有值。流式场景必须先合并全部 chunk交给ConcatMessages即可再判断msg.ReasoningContent单看某一个 chunk 没有意义。打印看内容。最短的做法是把整条消息打印出来字段非空时String()会输出 reasoning content: 小节fmt.Println(msg)想直接取文本就读msg.ReasoningContent。存历史时一并带上。消息落库或估算上下文长度时沿用框架口径与 Content 一起计入而不是忽略它。空值与流式拼接的三个坑坑一默认这个字段一定有值。空才是常态模型本轮没输出思考、或 provider 实现没解析 reasoning 部分都得到空字符串。从 JSON 反序列化时也不要假设 key 存在omitempty 会让空字段直接不出现在报文里判断统一写len(...) 0最稳。坑二流式只取最后一个 chunk。思考内容分散在多个 chunk 里最后一个 chunk 常常是空的或只剩片段直接取末尾 chunk 得到的是残缺内容。框架的ConcatMessages按序拼接OpenAI 扩展的ConcatReasoningExtensions则按每段的Index归位合并有索引和无索引的 chunk 混在一股流里会直接返回错误见到这个报错就说明流里的 chunk 是混流的。坑三思考过程也占上下文。defaultTokenCounter数 token 时包含 ReasoningContentsummarization 和 reduction 中间件也把它计入消息长度。自己写上下文统计如果只算 Content估算会系统性偏小窗口超限和自动摘要的触发点都会整体偏移。收尾reasoning_content 的价值在于链路上每一环都可验证它是消息结构里的一个字符串流式合并时框架替你拼好token 统计时它被计入。调试看它工程预算算它两边都有明确的落点。【免费下载链接】einoThe ultimate LLM/AI application development framework in Go.项目地址: https://gitcode.com/GitHub_Trending/ei/eino创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考