DeepTutor v1.3.7 深度解读思考型模型兼容、知识库索引追踪与 Co-Writer 编辑安全【免费下载链接】DeepTutorDeepTutor: Lifelong Personalized Tutoring. https://deeptutor.info/.项目地址: https://gitcode.com/GitHub_Trending/dee/DeepTutor本文以 DeepTutor 官方发布的 v1.3.7 Release Notes发布日期 2026.05.04为主线围绕“思考型模型与网关兼容性、知识库索引可见性、Co-Writer 编辑安全”三大主题展开并结合仓库内对应的源码与测试进行验证帮助开发者理解该版本的能力边界、升级影响以及如何在自有环境中落地配置。本版本并非新增功能的大版本而是面向工程健壮性与可观测性的一次打磨它一方面解决思考型reasoning模型在接入网关时常见的“推理过程混入正文”“思考强度无法全局控制”“自定义请求头丢失”等痛点另一方面让知识库的“索引是否真的更新过”这件事在后端元数据与前端界面中变得可追溯同时对 Co-Writer 编辑器的破坏性操作与撤销链路做了安全加固。读完本文你将掌握LLM_REASONING_EFFORT的配置方法、知识库索引元数据字段的读写语义以及 Co-Writer 编辑安全的行为约定。一、版本总览v1.3.7 解决了什么问题v1.3.7 的核心定位可以用一句话概括把 provider 特有的推理输出控制住、把索引行为看清楚、把编辑器误操作兜住。三个主线分别是Thinking-Model 与网关兼容性—— 推理过程scratchpad与最终可见回答在协议与服务层彻底分离DeepSeek 等模型的思考强度可从.env全局配置自定义网关如要求覆盖User-Agent的网关所需的请求头得以保留。知识库索引可见性—— create、upload、re-index 三类流程都会把索引时间、索引文档数与索引动作写入知识库元数据UI 的详情/设置/索引版本面板据此展示“最近一次索引”信息。Co-Writer 编辑安全—— 清空草稿与模板覆盖前必须先确认撤销功能在工具栏编辑前会先提交未定型的输入快照破坏性操作按钮具备更清晰的语义化样式与无障碍提示。从升级角度看这是一次向后兼容的修订除新增可选环境变量与若干元数据字段外未引入破坏性配置变更具体见文末“升级注意事项”。二、Thinking-Model 与网关兼容性2.1 推理内容与可见回答彻底分离“思考型模型”在生成正式回答前会先输出一段内部推理OpenAI 兼容协议中通常承载于reasoning_content字段Anthropic 风格的实现则可能是reasoning对象。若这段草稿被当作正文拼进最终回答会严重破坏用户体验与下游解析。在 v1.3.7 中服务层通过两条路径保证分离非流式路径在 deeptutor/services/llm/provider_core/openai_compat_provider.py 中从消息对象上优先读取reasoning_content若不存在则回退读取reasoning并单独存入LLMResponse.reasoning_content字段与content可见正文分离返回。流式路径在_parse_chunks中每个 chunk 的 delta 若携带reasoning_content或reasoning会被累积进独立的reasoning_parts列表而不是混入content_parts最终同样以独立字段返回见同文件 L588-L626。更进一步在 deeptutor/services/llm/factory.py 的 LLM 工厂层还有一道“防线”注释明确写着Do not replay reasoning_content as user-visible answer text即当response.content与response.reasoning_content恰好相等时也不会把推理草稿当作最终回答重放。这意味着 OpenAI-compatible 供应商与 TutorBot 两条路径下的推理输出都被隔离在正文之外。2.2 用LLM_REASONING_EFFORT全局控制思考强度针对 DeepSeek 等把思考默认开启、且可能烧光max_tokens预算的模型v1.3.7 将LLM_REASONING_EFFORT作为一等公民暴露给用户。官方约定如下留空默认让 DeepTutor 依据当前激活的模型自动推断是否需要思考、思考强度取多少minimal显式关闭思考型模型的 thinkingDeepSeek 场景下即关闭思考只做直接回答同时节省 tokenhigh/max显式开启较高强度的思考。写入.env的示例# 全局关闭 DeepSeek 思考节省 token / 快速问答场景 LLM_REASONING_EFFORTminimal # 全局开启高强度思考复杂推理场景 # LLM_REASONING_EFFORThigh需要说明的是该环境变量经由resolver 路径生效在 deeptutor/services/config/provider_runtime.py 中激活模型配置里的reasoning_effort会被解析进ResolvedLLMConfig随后在 deeptutor/services/llm/factory.py 等调用方中逐级继承并透传给 provider 层。因此它既能影响显式 LLM 调用也覆盖 chat / TutorBot 等默认走同一解析管线的场景。2.3 不同供应商的“思考开关”语义差异由统一模块处理不同 OpenAI-compatible 供应商对“思考开关”的协议表达并不一致。从源码看DeepTutor 在 deeptutor/services/llm/reasoning_params.py 中集中维护了一张映射表_PROVIDER_THINKING_STYLES供应商thinking 控制样式协议表达deepseek / volcengine / byteplusthinking_typeextra_body{thinking: {type: enabled/disabled}}dashscope通义enable_thinkingextra_body{enable_thinking: bool}minimaxreasoning_splitextra_body{reasoning_split: bool}而build_openai_compatible_reasoning_kwargs()会做三件事按模型族推断默认强度对匹配deepseek-v4-pro、deepseek-reasoner的模型族默认给high见_PROVIDER_REASONING_PATTERNS按需抑制顶层字段当某样式走extra_body时为避免协议冲突会抑制顶层reasoning_effort字段minimum会被归一化为minimal对“默认开思考会烧光预算”的模型显式关闭_PROVIDER_DEFAULT_OFF_PATTERNS记录了如gemini-2.5、gemini-3这类默认开启思考的模型若用户未显式指定强度default_reasoning_effort_for()会返回none使这些模型不再把整个max_tokens预算消耗在推理上。也就是说“auto-detect”并非黑盒它由 deeptutor/services/llm/reasoning_params.py 中的模式表驱动且同一份逻辑同时服务于 openai-SDK、aiohttp 回退等三条执行路径保证行为一致。对于自定义custom绑定则依赖模型名中的qwen3/qwen-3/qwq/deepseek-v4-pro等关键子串推断样式见_CUSTOM_MODEL_THINKING_STYLES。2.4 自定义网关请求头extra_headers被完整保留部分网关尤其要求覆盖User-Agent、加签或携带内部认证头的代理网关依赖自定义请求头才能放行请求。此前若这些头在 chat / 显式 LLM 调用链路上丢失会导致这类网关调用失败。v1.3.7 修复了该问题profile 中的extra_headers会经由 resolver 进入ResolvedLLMConfig.extra_headers见 deeptutor/services/config/provider_runtime.py 与 L664并在 deeptutor/services/llm/factory.py 的配置合并逻辑中以“调用方传入头覆盖既有头”的语义合并且逐级继承。因此只要 profile 中配置了extra_headerschat 与显式 LLM 调用都能把它带到 HTTP 请求上。2.5 结构化生成的 JSON 容错增强v1.3.7 还提到 book blocks 与题目头脑风暴question ideation对“带围栏代码块、被修复过的、列表形状或其他不完美 JSON”的解析更加宽容。这意味着这类生成路径在拿到json ... 包裹、前后附带解释文字、或经过程序化修复的 JSON 时也能更稳定地提取出有效结构降低因输出格式瑕疵导致的整轮失败。三、知识库索引可见性3.1 三类索引流程现在都会写入索引元数据v1.3.7 为知识库Knowledge Base新增了三个可查询的元数据字段字段含义last_indexed_at最近一次真实索引发生的时间ISO 时间戳last_indexed_count最近一次索引涉及的文档数量last_indexed_action触发索引的动作create/upload/link/ re-index 等从源码看各写入点与流程一一对应创建create在 deeptutor/knowledge/initializer.py 中KB 初始化完成后写入last_indexed_at、last_indexed_count取本次收录文档数与last_indexed_action create上传upload在 deeptutor/knowledge/add_documents.py 中DocumentAdder增量添加文档后写入last_indexed_at、last_indexed_count added_count与last_indexed_action upload重索引 / 状态流转re-index在 deeptutor/knowledge/manager.py 的update_kb_status中只有当 progress 里的index_changed为真或indexed_count 0时才更新last_indexed_at/last_indexed_count/last_indexed_action否则仅更新last_completed_at二者由此得以区分。last_indexed_action还有一个link取值用于“链接型 KB”的收录统计见 deeptutor/knowledge/manager.py。上述规则也被沉淀进文档字符串见 deeptutor/knowledge/manifest.py 对last_indexed_count语义指“最近一次批次大小”而非累计总量的说明。3.2 “进度完成”不等于“索引变更”后端如何区分这是 v1.3.7 在可观测性上最有价值的一点元数据完成metadata-only completion与真正的向量索引更新actual vector-index update被区分开。在update_kb_status()的实现中若状态为ready而index_changed为假KB 记录只更新last_completed_at并清理旧的 progress banner 与错误字段只有当index_changed为真时才落盘上述三个last_indexed_*字段。因此一次“只是改了描述、没动文档”的保存不会伪造一次索引一次真正触发向量重建/增量的操作才会把时间戳、文档数、动作记录进元数据。3.3 Knowledge UI 展示索引历史后端在对外输出 KB 信息时统一携带这三项注册/扫描时的元数据迁移deeptutor/knowledge/manager.py兼容旧metadata.json缺少last_indexed_at时回退到last_updated、信息聚合L1070-L1072与配置回写L1193-L1198都会透传。前端 Knowledge 模块的详情detail、设置settings与索引版本index-version面板据此在可用时展示“最近索引时间 索引文档数”让用户无需翻日志即可判断某个知识库是否真的把新增文档纳入过向量索引。四、Co-Writer 编辑安全4.1 破坏性动作必须二次确认在 v1.3.7 之前“清空草稿clear”与“套用模板template”若作用于一个非空草稿会直接覆盖用户内容误点成本很高。新版本规定当目标草稿非空时clear 与 template 动作都会先弹出确认对话框用户明确确认后编辑器才会被清空或覆盖在对话框被确认前原有草稿内容保持原样不会进入任何写路径。4.2 Undo 更可靠快捷键体系完整撤销依赖的是“编辑前的快照”因此快照时机决定了撤销能否覆盖到一次操作。v1.3.7 的改动是工具栏编辑动作执行前先把尚未定型的输入pending typing snapshots提交commit避免用户正在输入的内容被当成编辑动作的一部分、或快照缺失导致撤销范围错乱编辑器快捷键补全了跨平台习惯Ctrl/CmdZ撤销、ShiftCmdZ重做、Ctrl/CmdY重做均受支持。对用户而言clear / template 造成的覆盖在“离开当前草稿”之前都是可恢复的见本文“升级注意事项”。4.3 工具栏控件的语义与可达性破坏性动作clear与模板动作template在视觉与交互上被进一步区分使用**不同的色调tones**让用户一眼区分“危险操作”与“普通操作”具备独立的focus 状态键盘导航时能清晰看到当前焦点提供明确的标签labels与可访问的 tooltips对屏幕阅读器等辅助技术友好。五、配套测试三个主线的验证证据v1.3.7 的测试同样围绕三条主线展开说明上述行为是被测试锁定的、而非临时补丁OpenAI-compatible provider 测试覆盖 service 与 TutorBot 两条路径下reasoning_content与可见响应内容的分离防止推理草稿泄漏进正文的回归。LLM 工厂测试扩展覆盖extra_headers的继承、reasoning_effort的继承以及“仅推理不输出正文”reasoning-only streaming的流式行为。知识库管理器测试覆盖last_indexed_*元数据仅在索引真实变更时才被记录与 3.2 的判定逻辑对应。仓库内可参考的既有测试布局包括 tests/knowledge/、tests/services/llm/、tests/book/ 等目录可作为进一步阅读与二次开发的起点。六、升级注意事项从 v1.3.6 升级到 v1.3.7 时请关注以下三点环境变量可选若你需要全局控制思考型模型的思考行为在.env中设置LLM_REASONING_EFFORTminimal关闭 /high、max开启留空则交由 DeepTutor 依据激活模型自动探测。该变量经 resolver 路径作用于 chat 与显式 LLM 调用。知识库元数据新增字段兼容KB 元数据可能新增last_indexed_at、last_indexed_count、last_indexed_action三个字段。旧 KB 若缺少last_indexed_at会在注册/扫描时回退使用last_updated填充见 deeptutor/knowledge/manager.py因此无需额外迁移脚本若下游消费方按固定 schema 读取需容忍这些新字段存在。Co-Writer 可恢复窗口clear / template 造成的覆盖可通过 undo 恢复直到用户离开当前草稿。也就是说恢复窗口与“草稿会话”绑定离开草稿后该覆盖将不可逆请在编辑中善用确认对话框与撤销快捷键。结语v1.3.7 是 DeepTutor 在“把既有能力做扎实”方向上的一次集中交付推理输出隔离让思考型模型可以安全接入各类网关LLM_REASONING_EFFORT让思考强度从“.env 到 provider 协议”形成完整闭环last_indexed_*元数据让知识库索引变得可观测、可审计Co-Writer 的确认与撤销体系则显著降低了误操作成本。对于自托管与二次开发用户而言本版本值得平滑跟进且无需担心破坏性变更。【免费下载链接】DeepTutorDeepTutor: Lifelong Personalized Tutoring. https://deeptutor.info/.项目地址: https://gitcode.com/GitHub_Trending/dee/DeepTutor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DeepTutor v1.3.7 深度解读：思考型模型兼容、知识库索引追踪与 Co-Writer 编辑安全
DeepTutor v1.3.7 深度解读思考型模型兼容、知识库索引追踪与 Co-Writer 编辑安全【免费下载链接】DeepTutorDeepTutor: Lifelong Personalized Tutoring. https://deeptutor.info/.项目地址: https://gitcode.com/GitHub_Trending/dee/DeepTutor本文以 DeepTutor 官方发布的 v1.3.7 Release Notes发布日期 2026.05.04为主线围绕“思考型模型与网关兼容性、知识库索引可见性、Co-Writer 编辑安全”三大主题展开并结合仓库内对应的源码与测试进行验证帮助开发者理解该版本的能力边界、升级影响以及如何在自有环境中落地配置。本版本并非新增功能的大版本而是面向工程健壮性与可观测性的一次打磨它一方面解决思考型reasoning模型在接入网关时常见的“推理过程混入正文”“思考强度无法全局控制”“自定义请求头丢失”等痛点另一方面让知识库的“索引是否真的更新过”这件事在后端元数据与前端界面中变得可追溯同时对 Co-Writer 编辑器的破坏性操作与撤销链路做了安全加固。读完本文你将掌握LLM_REASONING_EFFORT的配置方法、知识库索引元数据字段的读写语义以及 Co-Writer 编辑安全的行为约定。一、版本总览v1.3.7 解决了什么问题v1.3.7 的核心定位可以用一句话概括把 provider 特有的推理输出控制住、把索引行为看清楚、把编辑器误操作兜住。三个主线分别是Thinking-Model 与网关兼容性—— 推理过程scratchpad与最终可见回答在协议与服务层彻底分离DeepSeek 等模型的思考强度可从.env全局配置自定义网关如要求覆盖User-Agent的网关所需的请求头得以保留。知识库索引可见性—— create、upload、re-index 三类流程都会把索引时间、索引文档数与索引动作写入知识库元数据UI 的详情/设置/索引版本面板据此展示“最近一次索引”信息。Co-Writer 编辑安全—— 清空草稿与模板覆盖前必须先确认撤销功能在工具栏编辑前会先提交未定型的输入快照破坏性操作按钮具备更清晰的语义化样式与无障碍提示。从升级角度看这是一次向后兼容的修订除新增可选环境变量与若干元数据字段外未引入破坏性配置变更具体见文末“升级注意事项”。二、Thinking-Model 与网关兼容性2.1 推理内容与可见回答彻底分离“思考型模型”在生成正式回答前会先输出一段内部推理OpenAI 兼容协议中通常承载于reasoning_content字段Anthropic 风格的实现则可能是reasoning对象。若这段草稿被当作正文拼进最终回答会严重破坏用户体验与下游解析。在 v1.3.7 中服务层通过两条路径保证分离非流式路径在 deeptutor/services/llm/provider_core/openai_compat_provider.py 中从消息对象上优先读取reasoning_content若不存在则回退读取reasoning并单独存入LLMResponse.reasoning_content字段与content可见正文分离返回。流式路径在_parse_chunks中每个 chunk 的 delta 若携带reasoning_content或reasoning会被累积进独立的reasoning_parts列表而不是混入content_parts最终同样以独立字段返回见同文件 L588-L626。更进一步在 deeptutor/services/llm/factory.py 的 LLM 工厂层还有一道“防线”注释明确写着Do not replay reasoning_content as user-visible answer text即当response.content与response.reasoning_content恰好相等时也不会把推理草稿当作最终回答重放。这意味着 OpenAI-compatible 供应商与 TutorBot 两条路径下的推理输出都被隔离在正文之外。2.2 用LLM_REASONING_EFFORT全局控制思考强度针对 DeepSeek 等把思考默认开启、且可能烧光max_tokens预算的模型v1.3.7 将LLM_REASONING_EFFORT作为一等公民暴露给用户。官方约定如下留空默认让 DeepTutor 依据当前激活的模型自动推断是否需要思考、思考强度取多少minimal显式关闭思考型模型的 thinkingDeepSeek 场景下即关闭思考只做直接回答同时节省 tokenhigh/max显式开启较高强度的思考。写入.env的示例# 全局关闭 DeepSeek 思考节省 token / 快速问答场景 LLM_REASONING_EFFORTminimal # 全局开启高强度思考复杂推理场景 # LLM_REASONING_EFFORThigh需要说明的是该环境变量经由resolver 路径生效在 deeptutor/services/config/provider_runtime.py 中激活模型配置里的reasoning_effort会被解析进ResolvedLLMConfig随后在 deeptutor/services/llm/factory.py 等调用方中逐级继承并透传给 provider 层。因此它既能影响显式 LLM 调用也覆盖 chat / TutorBot 等默认走同一解析管线的场景。2.3 不同供应商的“思考开关”语义差异由统一模块处理不同 OpenAI-compatible 供应商对“思考开关”的协议表达并不一致。从源码看DeepTutor 在 deeptutor/services/llm/reasoning_params.py 中集中维护了一张映射表_PROVIDER_THINKING_STYLES供应商thinking 控制样式协议表达deepseek / volcengine / byteplusthinking_typeextra_body{thinking: {type: enabled/disabled}}dashscope通义enable_thinkingextra_body{enable_thinking: bool}minimaxreasoning_splitextra_body{reasoning_split: bool}而build_openai_compatible_reasoning_kwargs()会做三件事按模型族推断默认强度对匹配deepseek-v4-pro、deepseek-reasoner的模型族默认给high见_PROVIDER_REASONING_PATTERNS按需抑制顶层字段当某样式走extra_body时为避免协议冲突会抑制顶层reasoning_effort字段minimum会被归一化为minimal对“默认开思考会烧光预算”的模型显式关闭_PROVIDER_DEFAULT_OFF_PATTERNS记录了如gemini-2.5、gemini-3这类默认开启思考的模型若用户未显式指定强度default_reasoning_effort_for()会返回none使这些模型不再把整个max_tokens预算消耗在推理上。也就是说“auto-detect”并非黑盒它由 deeptutor/services/llm/reasoning_params.py 中的模式表驱动且同一份逻辑同时服务于 openai-SDK、aiohttp 回退等三条执行路径保证行为一致。对于自定义custom绑定则依赖模型名中的qwen3/qwen-3/qwq/deepseek-v4-pro等关键子串推断样式见_CUSTOM_MODEL_THINKING_STYLES。2.4 自定义网关请求头extra_headers被完整保留部分网关尤其要求覆盖User-Agent、加签或携带内部认证头的代理网关依赖自定义请求头才能放行请求。此前若这些头在 chat / 显式 LLM 调用链路上丢失会导致这类网关调用失败。v1.3.7 修复了该问题profile 中的extra_headers会经由 resolver 进入ResolvedLLMConfig.extra_headers见 deeptutor/services/config/provider_runtime.py 与 L664并在 deeptutor/services/llm/factory.py 的配置合并逻辑中以“调用方传入头覆盖既有头”的语义合并且逐级继承。因此只要 profile 中配置了extra_headerschat 与显式 LLM 调用都能把它带到 HTTP 请求上。2.5 结构化生成的 JSON 容错增强v1.3.7 还提到 book blocks 与题目头脑风暴question ideation对“带围栏代码块、被修复过的、列表形状或其他不完美 JSON”的解析更加宽容。这意味着这类生成路径在拿到json ... 包裹、前后附带解释文字、或经过程序化修复的 JSON 时也能更稳定地提取出有效结构降低因输出格式瑕疵导致的整轮失败。三、知识库索引可见性3.1 三类索引流程现在都会写入索引元数据v1.3.7 为知识库Knowledge Base新增了三个可查询的元数据字段字段含义last_indexed_at最近一次真实索引发生的时间ISO 时间戳last_indexed_count最近一次索引涉及的文档数量last_indexed_action触发索引的动作create/upload/link/ re-index 等从源码看各写入点与流程一一对应创建create在 deeptutor/knowledge/initializer.py 中KB 初始化完成后写入last_indexed_at、last_indexed_count取本次收录文档数与last_indexed_action create上传upload在 deeptutor/knowledge/add_documents.py 中DocumentAdder增量添加文档后写入last_indexed_at、last_indexed_count added_count与last_indexed_action upload重索引 / 状态流转re-index在 deeptutor/knowledge/manager.py 的update_kb_status中只有当 progress 里的index_changed为真或indexed_count 0时才更新last_indexed_at/last_indexed_count/last_indexed_action否则仅更新last_completed_at二者由此得以区分。last_indexed_action还有一个link取值用于“链接型 KB”的收录统计见 deeptutor/knowledge/manager.py。上述规则也被沉淀进文档字符串见 deeptutor/knowledge/manifest.py 对last_indexed_count语义指“最近一次批次大小”而非累计总量的说明。3.2 “进度完成”不等于“索引变更”后端如何区分这是 v1.3.7 在可观测性上最有价值的一点元数据完成metadata-only completion与真正的向量索引更新actual vector-index update被区分开。在update_kb_status()的实现中若状态为ready而index_changed为假KB 记录只更新last_completed_at并清理旧的 progress banner 与错误字段只有当index_changed为真时才落盘上述三个last_indexed_*字段。因此一次“只是改了描述、没动文档”的保存不会伪造一次索引一次真正触发向量重建/增量的操作才会把时间戳、文档数、动作记录进元数据。3.3 Knowledge UI 展示索引历史后端在对外输出 KB 信息时统一携带这三项注册/扫描时的元数据迁移deeptutor/knowledge/manager.py兼容旧metadata.json缺少last_indexed_at时回退到last_updated、信息聚合L1070-L1072与配置回写L1193-L1198都会透传。前端 Knowledge 模块的详情detail、设置settings与索引版本index-version面板据此在可用时展示“最近索引时间 索引文档数”让用户无需翻日志即可判断某个知识库是否真的把新增文档纳入过向量索引。四、Co-Writer 编辑安全4.1 破坏性动作必须二次确认在 v1.3.7 之前“清空草稿clear”与“套用模板template”若作用于一个非空草稿会直接覆盖用户内容误点成本很高。新版本规定当目标草稿非空时clear 与 template 动作都会先弹出确认对话框用户明确确认后编辑器才会被清空或覆盖在对话框被确认前原有草稿内容保持原样不会进入任何写路径。4.2 Undo 更可靠快捷键体系完整撤销依赖的是“编辑前的快照”因此快照时机决定了撤销能否覆盖到一次操作。v1.3.7 的改动是工具栏编辑动作执行前先把尚未定型的输入pending typing snapshots提交commit避免用户正在输入的内容被当成编辑动作的一部分、或快照缺失导致撤销范围错乱编辑器快捷键补全了跨平台习惯Ctrl/CmdZ撤销、ShiftCmdZ重做、Ctrl/CmdY重做均受支持。对用户而言clear / template 造成的覆盖在“离开当前草稿”之前都是可恢复的见本文“升级注意事项”。4.3 工具栏控件的语义与可达性破坏性动作clear与模板动作template在视觉与交互上被进一步区分使用**不同的色调tones**让用户一眼区分“危险操作”与“普通操作”具备独立的focus 状态键盘导航时能清晰看到当前焦点提供明确的标签labels与可访问的 tooltips对屏幕阅读器等辅助技术友好。五、配套测试三个主线的验证证据v1.3.7 的测试同样围绕三条主线展开说明上述行为是被测试锁定的、而非临时补丁OpenAI-compatible provider 测试覆盖 service 与 TutorBot 两条路径下reasoning_content与可见响应内容的分离防止推理草稿泄漏进正文的回归。LLM 工厂测试扩展覆盖extra_headers的继承、reasoning_effort的继承以及“仅推理不输出正文”reasoning-only streaming的流式行为。知识库管理器测试覆盖last_indexed_*元数据仅在索引真实变更时才被记录与 3.2 的判定逻辑对应。仓库内可参考的既有测试布局包括 tests/knowledge/、tests/services/llm/、tests/book/ 等目录可作为进一步阅读与二次开发的起点。六、升级注意事项从 v1.3.6 升级到 v1.3.7 时请关注以下三点环境变量可选若你需要全局控制思考型模型的思考行为在.env中设置LLM_REASONING_EFFORTminimal关闭 /high、max开启留空则交由 DeepTutor 依据激活模型自动探测。该变量经 resolver 路径作用于 chat 与显式 LLM 调用。知识库元数据新增字段兼容KB 元数据可能新增last_indexed_at、last_indexed_count、last_indexed_action三个字段。旧 KB 若缺少last_indexed_at会在注册/扫描时回退使用last_updated填充见 deeptutor/knowledge/manager.py因此无需额外迁移脚本若下游消费方按固定 schema 读取需容忍这些新字段存在。Co-Writer 可恢复窗口clear / template 造成的覆盖可通过 undo 恢复直到用户离开当前草稿。也就是说恢复窗口与“草稿会话”绑定离开草稿后该覆盖将不可逆请在编辑中善用确认对话框与撤销快捷键。结语v1.3.7 是 DeepTutor 在“把既有能力做扎实”方向上的一次集中交付推理输出隔离让思考型模型可以安全接入各类网关LLM_REASONING_EFFORT让思考强度从“.env 到 provider 协议”形成完整闭环last_indexed_*元数据让知识库索引变得可观测、可审计Co-Writer 的确认与撤销体系则显著降低了误操作成本。对于自托管与二次开发用户而言本版本值得平滑跟进且无需担心破坏性变更。【免费下载链接】DeepTutorDeepTutor: Lifelong Personalized Tutoring. https://deeptutor.info/.项目地址: https://gitcode.com/GitHub_Trending/dee/DeepTutor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考