驅(qū)動的“先規(guī)劃、逐步求解、受控重規(guī)劃“解題引擎)
DeepTutor 深度解題模式解析以 Chat Agent 循環(huán)驅(qū)動的先規(guī)劃、逐步求解、受控重規(guī)劃解題引擎【免費下載鏈接】DeepTutorDeepTutor: Lifelong Personalized Tutoring. https://deeptutor.info/.項目地址: https://gitcode.com/GitHub_Trending/dee/DeepTutor導讀本文圍繞 DeepTutor終身個性化輔導系統(tǒng)中面向解一道題的deep_solve深度解題能力展開。該能力不再使用獨立的定制流水線而是直接把聊天 Agent 循環(huán)當作求解器通過solve_plan/solve_finish_step/solve_replan三個工具為模型加上確定性脊梁commit to a plan、逐步驟門禁、受限重規(guī)劃再由模型自行決定每一步用什么工具去完成。讀完后你將掌握解題回合中三個 solve 工具的參數(shù)契約與底層實現(xiàn)、內(nèi)存會話 SolveSession 如何約束模型、系統(tǒng)提示詞本倉中英雙語如何驅(qū)動行為、以及temperature/max_rounds/max_replans等配置旋鈕在源碼中的實際取值路徑。1. 背景為什么深度解題不再需要專門的流水線在 DeepTutor 的能力體系中deep_solveCLI 別名solve的目標是把一道題從頭到尾嚴謹?shù)亟獬鰜?。其架?gòu)基線在 deeptutor/capabilities/solve/capability.py 的模塊注釋中寫得很明確There is no bespoke pipeline anymore. The chat agent loop IS the solver該能力只負責把當前回合標記為 solve 模式并解析會話 id隨后跑標準的 AgenticChatPipeline真正的解題發(fā)生在循環(huán)內(nèi)部。這一設(shè)計與 chat / mastery 共享同一條設(shè)計公理design axiom智能放在循環(huán)的出口規(guī)劃與求解由模型負責確定性脊梁是引擎狀態(tài)承諾計劃、不跳步、受限重規(guī)劃這些約束由引擎通過工具讀寫狀態(tài)來強制詳見 deeptutor/capabilities/solve/capability.py。也就是說本篇文章真正要講解的系統(tǒng)提示詞deeptutor/capabilities/solve/prompts/zh/system.md不是一段孤立的文字而是與 solve 工具、會話狀態(tài)、循環(huán)掛載點共同構(gòu)成一個閉環(huán)。中英文版本契約完全一致英文版見 deeptutor/capabilities/solve/prompts/en/system.md提示詞會按當前語言自動加載。2. 解題行為契約從第一件事到最終答案深度解題模式的系統(tǒng)提示詞定義了模型在 solve 回合中必須遵守的五階段行為契約逐條拆解如下。2.1 第一件事調(diào)用solve_plan未規(guī)劃前絕不求解提示詞要求在做任何事之前先調(diào)用solve_plan給出簡短分析和一個有序的步驟列表多數(shù)題目 2–6 步很簡單的題一步也行。在調(diào)用solve_plan之前絕不開始求解。這一規(guī)劃先行并非僅僅靠提示詞軟約束——在實現(xiàn)上它由服務端強約束SolvePlanTool.execute()只有在會話內(nèi)存在計劃后后續(xù)的solve_finish_step才會接受step_id若先調(diào)用solve_finish_step而尚無計劃工具會直接返回失敗No plan yet. Call solve_plan before solve_finish_step.見 deeptutor/capabilities/solve/tools.py。2.2 逐步推進一次一步提示詞要求模型按計劃一次推進一步并給出每類工作的推薦工具映射code_execution計算 / 作圖 / 數(shù)值驗算rag/read_source掛了學習材料知識庫時檢索web_search/web_fetch核查不確定的事實reason完成一段困難的子推導exec生成文件如解題 PDF、圖表、表格。一次一步的節(jié)奏同樣有引擎支撐solve_finish_step每次只把當前步驟標記為完成并返回下一個要做的步驟next由循環(huán)繼續(xù)驅(qū)動直到全部步驟完成后才返回all_done: true。2.3 帶圖題目用geogebra_analysis還原圖形對帶配圖的題、或畫圖有助于理解的幾何題提示詞要求調(diào)用geogebra_analysis把圖形還原成 GeoGebra 圖形再基于圖形求解。代碼注釋印證該工具遵循用戶在聊天側(cè)啟用的開關(guān)掛載web_search/reason/geogebra_analysismount iff the user enabled them, exactly as in chat見 deeptutor/capabilities/solve/loop.py即 solve 模式復用 chat 的完整內(nèi)建工具面同時尊重用戶開關(guān)。2.4 完成一步即記賬solve_finish_step每完成一步模型須調(diào)用solve_finish_step傳入步驟 id 與該步結(jié)論的簡短總結(jié)。這一調(diào)用的雙重作用從 deeptutor/capabilities/solve/tools.py 可以看出記錄結(jié)果把該步標記為 done 并保存 summary釋放上下文工具返回_context_checkpoint元數(shù)據(jù)循環(huán)AgentLoop會把這一步產(chǎn)生的大量中間工具對話折疊成一行總結(jié)等價于舊流水線里的逐步驟消息重置per-step message reset。提示詞同時給出兩條禁令不要跳步不要在工作真正完成前就把步驟標記為完成。2.5 卡住就重規(guī)劃但預算有上限若某條思路卡住或被證明走錯了模型應調(diào)用solve_replan給出原因與新的步驟列表。提示詞強調(diào)它有預算上限、只用于真正的方向修正預算用盡就用現(xiàn)有結(jié)果收尾。代碼中DEFAULT_MAX_REPLANS 2見 deeptutor/capabilities/solve/session.py預算用盡后重規(guī)劃工具會返回status: budget_exhausted并明確指示不要再重規(guī)劃用現(xiàn)有成果收尾。2.6 收尾先給精確結(jié)果再講求解過程所有步驟完成后提示詞要求模型寫出最終答案先清楚地給出精確結(jié)果再給出簡潔、有條理的求解過程講解若生成了圖形 / 文件一并呈現(xiàn)。這一點與輔導場景的訴求一致——all_done時solve_finish_step的返回指令也恰好是Write the final answer now.。3. 確定性脊梁三個 solve 工具的接口契約與返回結(jié)構(gòu)三個工具由 SOLVE_TOOL_NAMES 統(tǒng)一定義并僅在 solve 回合自動掛載由 SolveLoopCapability 裝載模型永遠無法自己提供會話 id——_solve_session_id由流水線服務端注入。下表匯總其完整契約工具觸發(fā)時機參數(shù)關(guān)鍵返回字段solve_plan回合第一件事analysis一兩句問題是什么 思路steps有序數(shù)組每項{goal}goal 為簡短祈使句status: planned、analysis、steps含服務端生成的S1/S2… id、next、instructionsolve_finish_step每一步實際工作完成后step_id如S1summary該步關(guān)鍵結(jié)論/數(shù)值作為該步記錄status: step_done、completed、next下一步或null、all_done、instruction元數(shù)據(jù)含_context_checkpointsolve_replan思路卡住/證明錯誤需整體換方向reason為何失敗、如何調(diào)整steps全新有序步驟成功status: replanned、replans_used/replans_max、steps、next預算耗盡status: budget_exhausted值得注意的三處實現(xiàn)細節(jié)均有源碼與測試佐證步驟 id 由服務端生成_parse_steps()丟棄沒有g(shù)oal的步驟并按序重命名為S1, S2, …Ids are server-generated so the model never controls storage keys見 deeptutor/capabilities/solve/tools.py。步驟上限計劃在寫入會話時被截斷到最多 12 步_MAX_STEPS 12見 deeptutor/capabilities/solve/session.py。非法調(diào)用被拒絕無活躍會話、無計劃先標記、step_id不存在等場景均返回失敗結(jié)果測試逐一覆蓋見下文第 7 節(jié)。一個典型的規(guī)劃調(diào)用JSON 示意圖字段以 solve/plan 的工具定義 為準{ name: solve_plan, arguments: { analysis: 要求解方程 x^2 - 4 0先因式分解再求根。, steps: [ {goal: 把多項式因式分解}, {goal: 由因式求出根并代入驗算} ] } }成功規(guī)劃后工具返回next: {id: S1, ...}并指示模型立即使用可用工具完成第一步完成后調(diào)用solve_finish_step。4. SolveSession單回合的內(nèi)存會話狀態(tài)約束模型不跳步、限制重規(guī)劃的確定性脊梁實體是 SolveSession其關(guān)鍵字段與行為包括字段 / 方法語義session_id本回合會話鍵源自 turn id回退到 session/message id同一服務進程內(nèi)并發(fā)回合互不競爭analysis模型對題目的簡短分析stepsSolveStep(id, goal, done, summary)的有序列表replans/max_replans已用 / 允許的最大重規(guī)劃次數(shù)默認 2set_plan()寫入計劃截斷到 12 步replan()預算未耗盡則替換計劃并把計數(shù) 1否則返回False且不動現(xiàn)有計劃mark_done()/next_step()/all_done()記賬、取下一步、判斷是否全部完成兩個工程細節(jié)值得關(guān)注會話是一次性的、進程內(nèi)存儲與 mastery 的磁盤持久化學習服務不同solve 回合是 one-shot 的會話僅存活于單回合內(nèi)。存儲是一個有界最多 256 條、LRU 式逐出的進程內(nèi)OrderedDict見 deeptutor/capabilities/solve/session.py避免長駐服務內(nèi)存泄漏。計劃同時搭乘在對話里solve_plan的工具結(jié)果會留在消息歷史中因此即便會話本身不持久化后續(xù)的普通聊天回合仍能根據(jù)該計劃保持上下文連續(xù)見 deeptutor/capabilities/solve/session.py 模塊注釋。5. 循環(huán)掛載SolveLoopCapability 如何把提示詞與工具接進聊天循環(huán)SolveLoopCapability 負責回合級集成四個鉤子決定了本提示詞何時生效、以什么語言加載is_active(context)僅當上下文元數(shù)據(jù)中solve_mode為真時才激活system_block()讀取配置中的提示詞覆蓋prompts[solve][system]否則從 deeptutor/capabilities/solve/prompts 下按語言加載zh或en的system.md包裝成名為deep_solve的 PromptBlock 注入augment_kwargs()僅對三個 solve 工具注入私有參數(shù)_solve_session_id并從元數(shù)據(jù)中把max_replans播種進會話預算該值來自配置絕不來自模型對復用型內(nèi)建工具如rag不做任何改動避免私有 kwarg 泄漏該行為有對應測試owned_tools等于SOLVE_TOOL_NAMES即掛載策略與注冊列表共用同一常量、永不失配。因此本文所述的系統(tǒng)提示詞不是每次聊天都出現(xiàn)而是在solve_mode回合由循環(huán)能力按語言注入屬于prompt engineering 與引擎狀態(tài)門控結(jié)合的典型實現(xiàn)。6. 從請求到循環(huán)DeepSolveCapability 的參數(shù)轉(zhuǎn)發(fā)鏈路用戶側(cè)如何進入該模式從 DeepSolveCapability 的 manifest 可見能力名deep_solve、CLI 別名solve、階段為responding并通過get_capability_request_schema(deep_solve)獲得請求配置校驗相關(guān)實現(xiàn)見 deeptutor/runtime/request_contracts.py 中的validate_deep_solve_request_config?；睾蠁雍髍un()依次完成寫入元數(shù)據(jù)solve_mode True與solve_session_id會話 id 來自 turn id → session id → message id 的回退鏈見 capability.py 的resolve_solve_session_id讀取求解參數(shù)get_solve_params()把max_replans放進元數(shù)據(jù)供 SolveLoopCapability 播種預算以這些參數(shù)構(gòu)造AgenticChatPipeline(max_rounds..., temperature..., max_tokens...)并運行。也就是說設(shè)置頁改動的值確實會驅(qū)動循環(huán)——max_rounds決定循環(huán)總輪次預算max_replans決定重規(guī)劃門禁temperature/max_tokens決定底層 LLM 調(diào)用。7. 配置旋鈕與默認值可設(shè)置、有鉗制求解相關(guān)的可調(diào)參數(shù)集中在 deeptutor/services/config/capabilities_settings.py默認值與寫入路徑如下參數(shù)默認值存放位置鉗制范圍語義temperature0.3data/user/settings/agents.yaml的capabilities.solve0.0 – 2.0求解屬于需要嚴謹度的任務默認取較低溫度max_tokens8192同上1 – 200000單次 LLM 輸出的 token 上限max_rounds12data/user/settings/main.yaml的capabilities.solve1 – 50一次 solve 回合的總 LLM 輪次預算規(guī)劃 工具 收尾都計為輪。代碼注釋特別說明每個計劃步驟要消耗數(shù)輪故該默認值高于 chat 的默認值但又保持在適中水平以免回合過長觸發(fā) LLM 超時想求解更深可調(diào)大max_replans2同上0 – 10允許的方向修正次數(shù)舊的max_iterations_per_step鍵已失效并被有意忽略配置合并邏輯get_solve_params()是設(shè)置頁對應/api/v1/capabilities/settings能力設(shè)置接口寫入兩條 YAML 后、deep-solve 能力讀取的唯一數(shù)據(jù)源所有寫入值經(jīng)_coerce_*鉗制杜絕臟值進入 YAML。一個完整的配置片段示意如下# data/user/settings/agents.yaml capabilities: solve: temperature: 0.3 max_tokens: 8192 # data/user/settings/main.yaml capabilities: solve: max_rounds: 12 max_replans: 28. 測試佐證契約如何被自動化驗證本模式的行為契約被 tests/capabilities/test_solve_capability.py 全面覆蓋可作為理解實現(xiàn)的可執(zhí)行文檔循環(huán)鉤子非 solve 模式下能力不激活、不注入 system blocksolve 模式下只貢獻自有工具且 system block 中出現(xiàn)solve_planaugment_kwargs只對 solve 工具注入會話 id復用型內(nèi)建工具不被污染計劃與記賬閉環(huán)先solve_plan再依次solve_finish_step(S1)→ 返回next S2、all_done false完成后返回all_done true、next null_context_checkpoint的 summary 確實包含步驟標記非法與邊界未知step_id如S99被拒絕重規(guī)劃在預算耗盡后返回budget_exhausted工具在無會話 id 時直接失敗會話語義replan重置步驟并遞增計數(shù)next_step()指向新計劃第一步。9. 工程啟示這套提示詞 工具 狀態(tài)設(shè)計帶來的實戰(zhàn)要點從 deeptutor/capabilities/solve/prompts/zh/system.md 及其周邊實現(xiàn)可以提煉出幾條可復用的經(jīng)驗把紀律做進工具而非只寫進提示詞模型跳過solve_plan就直接工作在提示詞里是被禁止的在工具層是直接失敗的無計劃時solve_finish_step報錯雙層保障讓先規(guī)劃成為硬約束用工具返回值推進而不是依賴模型記憶每完成一步工具就返回下一步是什么 / 是否全部完成循環(huán)按引擎狀態(tài)前進模型的短期記憶負擔被降到最低上下文壓縮內(nèi)建在流程中solve_finish_step既記賬又觸發(fā) checkpoint 折疊長解題流程數(shù)值計算、檢索、聯(lián)網(wǎng)產(chǎn)生大量中間輸出不會把上下文撐爆失控保護參數(shù)化重規(guī)劃預算max_replans、總輪次預算max_rounds、步驟上限12與并發(fā)會話上限256全部有界長駐服務因此既可控又不泄漏保持 chat 工具面的復用意solve 不另起爐灶做一套新工具而是復用聊天側(cè)的全部內(nèi)建工具并尊重用戶對web_search/reason/geogebra_analysis等的開關(guān)學習成本與維護成本同時降低。理解這條提示詞的最佳路徑是三件套對照閱讀以 zh/system.md 定義行為契約以 tools.py 與 session.py 看引擎如何強制契約以 test_solve_capability.py 驗證契約是否真的被遵守?！久赓M下載鏈接】DeepTutorDeepTutor: Lifelong Personalized Tutoring. https://deeptutor.info/.項目地址: https://gitcode.com/GitHub_Trending/dee/DeepTutor創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 DeepTutor 深度解題模式解析：以 Chat Agent 循環(huán)驅(qū)動的“先規(guī)劃、逐步求解、受控重規(guī)劃“解題引擎
DeepTutor 深度解題模式解析以 Chat Agent 循環(huán)驅(qū)動的先規(guī)劃、逐步求解、受控重規(guī)劃解題引擎【免費下載鏈接】DeepTutorDeepTutor: Lifelong Personalized Tutoring. https://deeptutor.info/.項目地址: https://gitcode.com/GitHub_Trending/dee/DeepTutor導讀本文圍繞 DeepTutor終身個性化輔導系統(tǒng)中面向解一道題的deep_solve深度解題能力展開。該能力不再使用獨立的定制流水線而是直接把聊天 Agent 循環(huán)當作求解器通過solve_plan/solve_finish_step/solve_replan三個工具為模型加上確定性脊梁commit to a plan、逐步驟門禁、受限重規(guī)劃再由模型自行決定每一步用什么工具去完成。讀完后你將掌握解題回合中三個 solve 工具的參數(shù)契約與底層實現(xiàn)、內(nèi)存會話 SolveSession 如何約束模型、系統(tǒng)提示詞本倉中英雙語如何驅(qū)動行為、以及temperature/max_rounds/max_replans等配置旋鈕在源碼中的實際取值路徑。1. 背景為什么深度解題不再需要專門的流水線在 DeepTutor 的能力體系中deep_solveCLI 別名solve的目標是把一道題從頭到尾嚴謹?shù)亟獬鰜?。其架?gòu)基線在 deeptutor/capabilities/solve/capability.py 的模塊注釋中寫得很明確There is no bespoke pipeline anymore. The chat agent loop IS the solver該能力只負責把當前回合標記為 solve 模式并解析會話 id隨后跑標準的 AgenticChatPipeline真正的解題發(fā)生在循環(huán)內(nèi)部。這一設(shè)計與 chat / mastery 共享同一條設(shè)計公理design axiom智能放在循環(huán)的出口規(guī)劃與求解由模型負責確定性脊梁是引擎狀態(tài)承諾計劃、不跳步、受限重規(guī)劃這些約束由引擎通過工具讀寫狀態(tài)來強制詳見 deeptutor/capabilities/solve/capability.py。也就是說本篇文章真正要講解的系統(tǒng)提示詞deeptutor/capabilities/solve/prompts/zh/system.md不是一段孤立的文字而是與 solve 工具、會話狀態(tài)、循環(huán)掛載點共同構(gòu)成一個閉環(huán)。中英文版本契約完全一致英文版見 deeptutor/capabilities/solve/prompts/en/system.md提示詞會按當前語言自動加載。2. 解題行為契約從第一件事到最終答案深度解題模式的系統(tǒng)提示詞定義了模型在 solve 回合中必須遵守的五階段行為契約逐條拆解如下。2.1 第一件事調(diào)用solve_plan未規(guī)劃前絕不求解提示詞要求在做任何事之前先調(diào)用solve_plan給出簡短分析和一個有序的步驟列表多數(shù)題目 2–6 步很簡單的題一步也行。在調(diào)用solve_plan之前絕不開始求解。這一規(guī)劃先行并非僅僅靠提示詞軟約束——在實現(xiàn)上它由服務端強約束SolvePlanTool.execute()只有在會話內(nèi)存在計劃后后續(xù)的solve_finish_step才會接受step_id若先調(diào)用solve_finish_step而尚無計劃工具會直接返回失敗No plan yet. Call solve_plan before solve_finish_step.見 deeptutor/capabilities/solve/tools.py。2.2 逐步推進一次一步提示詞要求模型按計劃一次推進一步并給出每類工作的推薦工具映射code_execution計算 / 作圖 / 數(shù)值驗算rag/read_source掛了學習材料知識庫時檢索web_search/web_fetch核查不確定的事實reason完成一段困難的子推導exec生成文件如解題 PDF、圖表、表格。一次一步的節(jié)奏同樣有引擎支撐solve_finish_step每次只把當前步驟標記為完成并返回下一個要做的步驟next由循環(huán)繼續(xù)驅(qū)動直到全部步驟完成后才返回all_done: true。2.3 帶圖題目用geogebra_analysis還原圖形對帶配圖的題、或畫圖有助于理解的幾何題提示詞要求調(diào)用geogebra_analysis把圖形還原成 GeoGebra 圖形再基于圖形求解。代碼注釋印證該工具遵循用戶在聊天側(cè)啟用的開關(guān)掛載web_search/reason/geogebra_analysismount iff the user enabled them, exactly as in chat見 deeptutor/capabilities/solve/loop.py即 solve 模式復用 chat 的完整內(nèi)建工具面同時尊重用戶開關(guān)。2.4 完成一步即記賬solve_finish_step每完成一步模型須調(diào)用solve_finish_step傳入步驟 id 與該步結(jié)論的簡短總結(jié)。這一調(diào)用的雙重作用從 deeptutor/capabilities/solve/tools.py 可以看出記錄結(jié)果把該步標記為 done 并保存 summary釋放上下文工具返回_context_checkpoint元數(shù)據(jù)循環(huán)AgentLoop會把這一步產(chǎn)生的大量中間工具對話折疊成一行總結(jié)等價于舊流水線里的逐步驟消息重置per-step message reset。提示詞同時給出兩條禁令不要跳步不要在工作真正完成前就把步驟標記為完成。2.5 卡住就重規(guī)劃但預算有上限若某條思路卡住或被證明走錯了模型應調(diào)用solve_replan給出原因與新的步驟列表。提示詞強調(diào)它有預算上限、只用于真正的方向修正預算用盡就用現(xiàn)有結(jié)果收尾。代碼中DEFAULT_MAX_REPLANS 2見 deeptutor/capabilities/solve/session.py預算用盡后重規(guī)劃工具會返回status: budget_exhausted并明確指示不要再重規(guī)劃用現(xiàn)有成果收尾。2.6 收尾先給精確結(jié)果再講求解過程所有步驟完成后提示詞要求模型寫出最終答案先清楚地給出精確結(jié)果再給出簡潔、有條理的求解過程講解若生成了圖形 / 文件一并呈現(xiàn)。這一點與輔導場景的訴求一致——all_done時solve_finish_step的返回指令也恰好是Write the final answer now.。3. 確定性脊梁三個 solve 工具的接口契約與返回結(jié)構(gòu)三個工具由 SOLVE_TOOL_NAMES 統(tǒng)一定義并僅在 solve 回合自動掛載由 SolveLoopCapability 裝載模型永遠無法自己提供會話 id——_solve_session_id由流水線服務端注入。下表匯總其完整契約工具觸發(fā)時機參數(shù)關(guān)鍵返回字段solve_plan回合第一件事analysis一兩句問題是什么 思路steps有序數(shù)組每項{goal}goal 為簡短祈使句status: planned、analysis、steps含服務端生成的S1/S2… id、next、instructionsolve_finish_step每一步實際工作完成后step_id如S1summary該步關(guān)鍵結(jié)論/數(shù)值作為該步記錄status: step_done、completed、next下一步或null、all_done、instruction元數(shù)據(jù)含_context_checkpointsolve_replan思路卡住/證明錯誤需整體換方向reason為何失敗、如何調(diào)整steps全新有序步驟成功status: replanned、replans_used/replans_max、steps、next預算耗盡status: budget_exhausted值得注意的三處實現(xiàn)細節(jié)均有源碼與測試佐證步驟 id 由服務端生成_parse_steps()丟棄沒有g(shù)oal的步驟并按序重命名為S1, S2, …Ids are server-generated so the model never controls storage keys見 deeptutor/capabilities/solve/tools.py。步驟上限計劃在寫入會話時被截斷到最多 12 步_MAX_STEPS 12見 deeptutor/capabilities/solve/session.py。非法調(diào)用被拒絕無活躍會話、無計劃先標記、step_id不存在等場景均返回失敗結(jié)果測試逐一覆蓋見下文第 7 節(jié)。一個典型的規(guī)劃調(diào)用JSON 示意圖字段以 solve/plan 的工具定義 為準{ name: solve_plan, arguments: { analysis: 要求解方程 x^2 - 4 0先因式分解再求根。, steps: [ {goal: 把多項式因式分解}, {goal: 由因式求出根并代入驗算} ] } }成功規(guī)劃后工具返回next: {id: S1, ...}并指示模型立即使用可用工具完成第一步完成后調(diào)用solve_finish_step。4. SolveSession單回合的內(nèi)存會話狀態(tài)約束模型不跳步、限制重規(guī)劃的確定性脊梁實體是 SolveSession其關(guān)鍵字段與行為包括字段 / 方法語義session_id本回合會話鍵源自 turn id回退到 session/message id同一服務進程內(nèi)并發(fā)回合互不競爭analysis模型對題目的簡短分析stepsSolveStep(id, goal, done, summary)的有序列表replans/max_replans已用 / 允許的最大重規(guī)劃次數(shù)默認 2set_plan()寫入計劃截斷到 12 步replan()預算未耗盡則替換計劃并把計數(shù) 1否則返回False且不動現(xiàn)有計劃mark_done()/next_step()/all_done()記賬、取下一步、判斷是否全部完成兩個工程細節(jié)值得關(guān)注會話是一次性的、進程內(nèi)存儲與 mastery 的磁盤持久化學習服務不同solve 回合是 one-shot 的會話僅存活于單回合內(nèi)。存儲是一個有界最多 256 條、LRU 式逐出的進程內(nèi)OrderedDict見 deeptutor/capabilities/solve/session.py避免長駐服務內(nèi)存泄漏。計劃同時搭乘在對話里solve_plan的工具結(jié)果會留在消息歷史中因此即便會話本身不持久化后續(xù)的普通聊天回合仍能根據(jù)該計劃保持上下文連續(xù)見 deeptutor/capabilities/solve/session.py 模塊注釋。5. 循環(huán)掛載SolveLoopCapability 如何把提示詞與工具接進聊天循環(huán)SolveLoopCapability 負責回合級集成四個鉤子決定了本提示詞何時生效、以什么語言加載is_active(context)僅當上下文元數(shù)據(jù)中solve_mode為真時才激活system_block()讀取配置中的提示詞覆蓋prompts[solve][system]否則從 deeptutor/capabilities/solve/prompts 下按語言加載zh或en的system.md包裝成名為deep_solve的 PromptBlock 注入augment_kwargs()僅對三個 solve 工具注入私有參數(shù)_solve_session_id并從元數(shù)據(jù)中把max_replans播種進會話預算該值來自配置絕不來自模型對復用型內(nèi)建工具如rag不做任何改動避免私有 kwarg 泄漏該行為有對應測試owned_tools等于SOLVE_TOOL_NAMES即掛載策略與注冊列表共用同一常量、永不失配。因此本文所述的系統(tǒng)提示詞不是每次聊天都出現(xiàn)而是在solve_mode回合由循環(huán)能力按語言注入屬于prompt engineering 與引擎狀態(tài)門控結(jié)合的典型實現(xiàn)。6. 從請求到循環(huán)DeepSolveCapability 的參數(shù)轉(zhuǎn)發(fā)鏈路用戶側(cè)如何進入該模式從 DeepSolveCapability 的 manifest 可見能力名deep_solve、CLI 別名solve、階段為responding并通過get_capability_request_schema(deep_solve)獲得請求配置校驗相關(guān)實現(xiàn)見 deeptutor/runtime/request_contracts.py 中的validate_deep_solve_request_config?；睾蠁雍髍un()依次完成寫入元數(shù)據(jù)solve_mode True與solve_session_id會話 id 來自 turn id → session id → message id 的回退鏈見 capability.py 的resolve_solve_session_id讀取求解參數(shù)get_solve_params()把max_replans放進元數(shù)據(jù)供 SolveLoopCapability 播種預算以這些參數(shù)構(gòu)造AgenticChatPipeline(max_rounds..., temperature..., max_tokens...)并運行。也就是說設(shè)置頁改動的值確實會驅(qū)動循環(huán)——max_rounds決定循環(huán)總輪次預算max_replans決定重規(guī)劃門禁temperature/max_tokens決定底層 LLM 調(diào)用。7. 配置旋鈕與默認值可設(shè)置、有鉗制求解相關(guān)的可調(diào)參數(shù)集中在 deeptutor/services/config/capabilities_settings.py默認值與寫入路徑如下參數(shù)默認值存放位置鉗制范圍語義temperature0.3data/user/settings/agents.yaml的capabilities.solve0.0 – 2.0求解屬于需要嚴謹度的任務默認取較低溫度max_tokens8192同上1 – 200000單次 LLM 輸出的 token 上限max_rounds12data/user/settings/main.yaml的capabilities.solve1 – 50一次 solve 回合的總 LLM 輪次預算規(guī)劃 工具 收尾都計為輪。代碼注釋特別說明每個計劃步驟要消耗數(shù)輪故該默認值高于 chat 的默認值但又保持在適中水平以免回合過長觸發(fā) LLM 超時想求解更深可調(diào)大max_replans2同上0 – 10允許的方向修正次數(shù)舊的max_iterations_per_step鍵已失效并被有意忽略配置合并邏輯get_solve_params()是設(shè)置頁對應/api/v1/capabilities/settings能力設(shè)置接口寫入兩條 YAML 后、deep-solve 能力讀取的唯一數(shù)據(jù)源所有寫入值經(jīng)_coerce_*鉗制杜絕臟值進入 YAML。一個完整的配置片段示意如下# data/user/settings/agents.yaml capabilities: solve: temperature: 0.3 max_tokens: 8192 # data/user/settings/main.yaml capabilities: solve: max_rounds: 12 max_replans: 28. 測試佐證契約如何被自動化驗證本模式的行為契約被 tests/capabilities/test_solve_capability.py 全面覆蓋可作為理解實現(xiàn)的可執(zhí)行文檔循環(huán)鉤子非 solve 模式下能力不激活、不注入 system blocksolve 模式下只貢獻自有工具且 system block 中出現(xiàn)solve_planaugment_kwargs只對 solve 工具注入會話 id復用型內(nèi)建工具不被污染計劃與記賬閉環(huán)先solve_plan再依次solve_finish_step(S1)→ 返回next S2、all_done false完成后返回all_done true、next null_context_checkpoint的 summary 確實包含步驟標記非法與邊界未知step_id如S99被拒絕重規(guī)劃在預算耗盡后返回budget_exhausted工具在無會話 id 時直接失敗會話語義replan重置步驟并遞增計數(shù)next_step()指向新計劃第一步。9. 工程啟示這套提示詞 工具 狀態(tài)設(shè)計帶來的實戰(zhàn)要點從 deeptutor/capabilities/solve/prompts/zh/system.md 及其周邊實現(xiàn)可以提煉出幾條可復用的經(jīng)驗把紀律做進工具而非只寫進提示詞模型跳過solve_plan就直接工作在提示詞里是被禁止的在工具層是直接失敗的無計劃時solve_finish_step報錯雙層保障讓先規(guī)劃成為硬約束用工具返回值推進而不是依賴模型記憶每完成一步工具就返回下一步是什么 / 是否全部完成循環(huán)按引擎狀態(tài)前進模型的短期記憶負擔被降到最低上下文壓縮內(nèi)建在流程中solve_finish_step既記賬又觸發(fā) checkpoint 折疊長解題流程數(shù)值計算、檢索、聯(lián)網(wǎng)產(chǎn)生大量中間輸出不會把上下文撐爆失控保護參數(shù)化重規(guī)劃預算max_replans、總輪次預算max_rounds、步驟上限12與并發(fā)會話上限256全部有界長駐服務因此既可控又不泄漏保持 chat 工具面的復用意solve 不另起爐灶做一套新工具而是復用聊天側(cè)的全部內(nèi)建工具并尊重用戶對web_search/reason/geogebra_analysis等的開關(guān)學習成本與維護成本同時降低。理解這條提示詞的最佳路徑是三件套對照閱讀以 zh/system.md 定義行為契約以 tools.py 與 session.py 看引擎如何強制契約以 test_solve_capability.py 驗證契約是否真的被遵守?！久赓M下載鏈接】DeepTutorDeepTutor: Lifelong Personalized Tutoring. https://deeptutor.info/.項目地址: https://gitcode.com/GitHub_Trending/dee/DeepTutor創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考