👁 76 次阅读
Semantic Kernel .NET 流式对话为何丢失推理内容？
来源链接：https://github.com/microsoft/semantic-kernel/issues/13860现象描述
microsoft/semantic-kernel 仓库的 issue #13860 记录了一个 .NET 侧的流式输出问题。报告者在使用 Semantic Kernel（下文简称 SK）连接大模型进行对话时，模型输出过程中包含思考内容（reasoning/thinking content），但在 SK 的流式输出过程里看不到这部分内容。 报告者的原始描述是：连接大模型进行对话，大模型输出过程中存在思考内容，但在 SK 流式输出过程中没有输出思考内容。思考阶段的第一部分接收到的是空信息，一直持续到思考过程结束，之后才开始输出正式内容。 报告者随后补充说明，OpenAI 注册的模型也存在同样情况，同样无法接收思考内容的输出。报告者的判断是，不是大模型没有思考，而是思考内容没有被 SK 正确捕获。 该 issue 当前状态为 open，标签为bug、.NET、triage，创建于 2026-04-13，最后更新 2026-04-29，共 10 条评论，其中 2 条为机器人或无效留言，实质讨论来自 8 条评论。反应合计为 0。
背景原因
从 issue 讨论的排查过程看，问题定位经历了几个阶段。 维护者 PrathamAditya 最初表示无法完全理解报告内容，原因是 issue 模板中的复现步骤仍保留了占位符文本（Go to '...'、Click on '....'），没有实际信息。在报告者补充说明后，维护者确认了问题现象：模型确实在产生思考内容，但 SK 没有正确捕获或流式传输这部分内容，只输出了最终结果。
维护者对根因给出了两层判断。第一层判断停留在流式管道层面，认为问题可能出在流式更新如何被映射到 ChatMessageContent 的过程中。第二层判断则指向更深的抽象层面：维护者表示，当前抽象并没有原生支持 reasoning/thinking 内容，这正是这部分内容在最初就被丢弃的原因。
维护者提到已经实现了一个修复，让思考内容可以传递到 ChatMessageContent，并补充了针对该场景的测试。但由于根因涉及抽象层不支持推理内容，维护者另外开了一个 feature request 来讨论这个方面，编号为 #13889，链接为 https://github.com/microsoft/semantic-kernel/issues/13889。
需要说明的是，issue 当前仍为 open 状态，官方尚未合入最终方案。上述修复属于维护者在讨论中描述的实现进展，代码是否进入主干尚无合并记录可核实，可通过 GitHub API 查询相关 PR 状态来确认。
排查或量化方法
该 issue 的有效定位信息来自讨论而非代码复现，可归纳为以下几条观察：- 使用大模型进行对话时，模型输出过程含思考内容，SK 流式输出中没有对应内容。
- 思考阶段的第一部分接收到空信息，空信息持续到思考过程结束，随后才开始输出正式内容。
- 同样的现象在 OpenAI 注册模型上复现，报告者认为这表明问题不在单一模型提供商侧。
- 维护者尝试在本地复现，并追踪思考内容在流式管道中丢失的位置。
- 维护者初步怀疑方向是流式更新映射到
ChatMessageContent的环节。
完整解决方案
官方当前未合入最终方案，本节只归纳 issue 中已经出现过的处理路径与其局限。 维护者在讨论中描述的动作包含两部分： 1. 实现让思考内容传递到ChatMessageContent 的修改，并补充覆盖该场景的测试。
2. 针对抽象层原生不支持 reasoning/thinking 内容的问题，另开 feature request #13889 进行讨论。
对于使用方而言，issue 中并未给出可直接落地的配置项或调用方式。该功能的具体实现尚未公开，因此无法在正文中提供可靠的代码示例。
可确认的一点是，维护者将问题拆成了两个层次：可以在现有抽象内打通的传递路径，以及需要在抽象层新增支持的推理内容承载能力。前者属于缺陷修复范畴，后者属于能力扩展范畴，两者推进节奏不同。
若需要在项目中跟踪进展，建议通过 GitHub API 查询 #13860 的状态字段与关联 PR 的合并状态，而不是依赖讨论中的口头描述判断是否已修复。
| 维度 | 现状 |
| issue 状态 | open |
| 标签 | bug、.NET、triage |
| 创建时间 | 2026-04-13 |
| 最后更新 | 2026-04-29 |
| 评论数 | 10（含 2 条无效，实质讨论 8 条） |
| 反应合计 | 0 |
| 官方是否合入修复 | 尚未合入 |
| 关联条目 | #13889（feature request，讨论抽象层支持） |
| 涉及的类 | ChatMessageContent |
| 影响范围 | 大模型、OpenAI 注册模型均复现 |
常见错误排查
官方尚无最终修复，以下条目只归纳 issue 讨论中出现过的定位信息，不引入未出现的排查手段。- 流式回调中思考阶段持续返回空内容：与该 issue 描述一致，说明思考内容在管道中被丢弃。
- 思考结束后才出现正式内容：这是报告者观察到的时序特征，可用于与其它流式问题区分。
- 更换模型提供商后现象依旧：报告者在 OpenAI 注册模型上同样复现，因此排除单一提供商侧原因。
- 复现步骤缺失导致无法定位：issue 模板保留了占位符文本，维护者最初因此无法理解问题，补充自然语言描述后才推进。
- 抽象层不支持推理内容：维护者认为这是内容被丢弃的深层原因，单靠流式管道映射的修改无法覆盖全部场景。
实践建议
在官方合入方案之前，依赖 SK 流式获取思考内容的场景存在明确限制。可以采取的做法包括：- 在应用中单独保留原始流式响应，绕开 SK 的
ChatMessageContent映射做二次解析，用于展示思考过程。 - 关注 #13889 的讨论，因为抽象层是否新增推理内容承载能力，决定了后续是否需要修改调用侧代码。
- 在 issue 中补充可复现的模型信息与流式回调日志，帮助维护者缩小定位范围。
- 不要依赖讨论中的实现描述作为版本升级依据，以 GitHub API 返回的 PR 合并状态和发布说明为准。
- 若同时使用 .NET 与 Python 侧，需分别确认各自管道对该现象的表现，本 issue 标签为
.NET。
FAQ
这个 bug 会导致什么后果？ SK 的 .NET 流式输出会丢失模型的思考内容，思考阶段表现为持续收到空信息，直到思考结束才开始输出正式内容。模型本身仍在推理，只是内容未被捕获。 哪些模型会受影响？ 据 issue 讨论，大模型和 OpenAI 注册模型均出现该现象。报告者据此认为不是单一模型提供商侧的问题。 根因是什么？ 维护者给出两层判断：流式更新映射到ChatMessageContent 时可能丢失内容；更深层的原因是当前抽象没有原生支持 reasoning/thinking 内容。
官方修好了吗？
issue 当前仍为 open。维护者描述了一个让思考内容传递到 ChatMessageContent 的修复并补充了测试，但代码是否进入主干缺乏合并记录支撑，可通过 GitHub API 查询 PR 状态确认。
有没有相关的后续讨论？
维护者另开了一个 feature request #13889，用于讨论抽象层原生支持推理内容的问题。该编号与链接均在 issue 讨论中被给出。
临时有没有办法拿到思考内容？
issue 中未给出可直接使用的配置或调用方式，该功能的具体实现尚未公开。应用侧若需展示思考过程，可考虑在 SK 之外解析原始流式响应，但这属于绕行方案，不在官方讨论范围内。
🔗 相关阅读（你可能还想看）
📄 Outlook 节点创建草稿添加附件为何报 UnableToDeserializePostBody？
📄 Flowise 点击市场或聊天页为何整页白屏？
📄 如何解决 Azure AI Search 向量存储的 $filter 递归深度超限错误？
📄 如何解决 shadcn/ui Sidebar 与 Header 重叠的问题？
📄 Next.js 开发服务器为何会 JavaScript heap out of memory？
📄 Nuxt 偶发 Cannot read properties of undefined 报错是怎么回事
📄 如何解决「Visual Studio Code for ipad」相关的问题？
📄 如何在AutoGen中实现企业级代理治理的加密行动收据（AAR）？
📄 记忆内容未清洗直接注入系统提示词，如何防范间接提示注入？
crewAI LiteAgent 将记忆内容直接拼接到系统提示词，存在间接提示注入风险。社区提出分层防御方案，但 iss