前言¶
在 DeepSeek Harness(DSH)裏跑 Agent,常見問題是:同類失誤會在不同任務裏重複出現;當前會話結束後,上下文不一定保留;換一個新會話,之前的修正也不一定被沿用。只靠加長 system prompt 能塞下靜態規則,卻很難自然記錄「這次具體出了什麼問題、怎麼改的、後來有沒有再驗證」。
下面介紹社區插件 dsh-lessons(維護者 duahciM,SkillHub 分類爲工作流)。它嘗試把「任務執行 → 結束復盤 → 結構化記憶 → 後續按作用域注入」串成閉環,讓一次任務裏形成的經驗有機會遷移到後續獨立任務。README 與目錄頁均標明這是實驗品,效果不保證;是否值得接入,需要結合自己的任務形態和合規要求自行判斷。
這是什麼¶
dsh-lessons 是 DSH 上的元認知類插件:用 task_start / task_end 劃定任務邊界,在任務結束時生成決策軌跡與復盤材料,經 task_reflect 把經驗寫成可治理的記憶,並按 global、session、reflection 三層作用域注入 system prompt 的 ## Accumulated Lessons 區段。
- 插件包名:
dsh-lessons,當前版本 0.2.2(MIT 許可證) - 運行環境:README 寫明 DeepSeek Harness
0.2.2-rc.1;package.json要求dsh>=0.2.1-rc.5,Node^22.19.0 || >=24.0.0 - 社區目錄:SkillHub - dsh-lessons(獨立社區站點,與 DeepSeek / 幻方無官方從屬關係)
- 源碼:github.com/duahciM/dsh-lessons
插件在分工上明確:程序負責記錄、結構校驗與注入流程;模型負責語義分類、衝突判斷和任務反思。
核心機制¶
閉環與四個工具¶
插件設想的閉環如下:
任務開始 → 決策 → 任務結束 → Agent反思 → 結構化記憶
↑ │
└──────────── 後續任務讀取並應用經驗 ────────┘
對外暴露四個工具(名稱與參數以 README 爲準):
| 工具 | 作用 |
|---|---|
task_start(goal, expected_result) |
聲明任務目標與預期結果,建立任務記錄 |
task_end(task_id, status, result) |
聲明任務結果,關閉任務並生成復盤材料 |
task_reflect(task_id, assessment, source, lessons[]) |
保存 Agent 對任務的反思和經驗 |
lessons_lookup(lesson_id) |
按需追溯一條經驗的完整來源(只讀) |
task_end 會在任務時間窗內整理決策軌跡(用戶請求與糾正、Agent 對外表述等),反思對象是 Agent 的工作決策,而不是完整的工具調用技巧清單。任務狀態包括 succeeded、failed、abandoned、aborted。
三層記憶與注入¶
| 層 | 主要用途 | 默認作用範圍 |
|---|---|---|
global |
跨任務通用的方法論 | 所有會話 |
session |
與特定會話/項目背景綁定的約束或經驗 | 指定會話 |
reflection |
從具體任務反思中產生的經驗 | 產生該經驗的會話 |
注入由作用域決定;經驗可晉升到 global 或指定 session,晉升是狀態遷移而非複製條目。三層目前渲染在同一 system prompt 區段,按層分組。
經驗字段與治理¶
單條經驗的核心字段包括:problem(現象)、attempted(當時做法)、correction(應當怎麼做)、applies_when(適用條件)、confidence(low/medium/high)。寫入時由模型聲明與已有經驗的關係:new / repeat / revise / none;生命週期含 active、superseded、deprecated、deleted 等。衝突關係可聲明爲 condition、goal、contradiction、apparent,渲染時並列呈現,不由程序自動裁決。
決策環境快照¶
task_start 會把當時實際生效的經驗凍結進 task_open 記錄,避免事後修改記憶庫改寫歷史任務「當時看到的約束」。反思材料裏可呈現 DECISION ENVIRONMENT 段;渲染是否簡略由配置項 environmentInBrief(默認 true)控制。記錄與渲染可分開取捨:快照始終落盤,關掉簡略渲染可減少復盤時的 token,但不影響按 id 反查。
默認開啓的 silentReflection 要求模型在思維鏈內完成復盤,直接調用 task_reflect,對外最多一行說明任務是否成功,以減少重複輸出 token 和決策軌跡污染(詳見 README 第 2.4 節實測說明)。
安裝與啓用¶
依賴方面:無外部服務,零 npm 依賴(僅 Node 內置模塊)。安裝前建議瀏覽倉庫源碼與 MIT 許可證;插件以當前 dsh 進程權限運行,數據目錄由你配置,需自行評估路徑與備份策略。
方式 A:DSH 界面(推薦)¶
- 打開 DSH,進入 插件 → 添加插件。
- 輸入
dsh-lessons(或倉庫地址https://github.com/duahciM/dsh-lessons),點擊 安裝。 - 安裝完成後點擊 立即啓用。
方式 B:命令行¶
Web 模式示例:
dsh plugin --profile web add dsh-lessons
命令行安裝後請重啓 dsh web。Headless 用戶請使用 --profile headless。
配置要點¶
插件通過 cordis.patch.yml 掛載;下列片段摘自官方文檔,安裝後可在對應配置中按需修改路徑與開關:
- insert:
- id: lessons
name: 'dsh-lessons'
config:
taskDir: '<你的數據目錄>/dsh-lessons-data'
fsyncEvery: 16
taskBoundaryHints: true
injectReflection: true
recordEvents: true
stateFromFile: true
silentReflection: true
lessons:
enabled: true
maxLessons: 0
diagnostics: true
scopes:
global: true
session: true
reflection: true
batching: true
instantNotice: true
commitEvery: 8
commitEveryTokens: 0
taskDir 決定任務記錄與經驗的存放位置。stateFromFile: true(默認)時,進程重啓可從 tasks.jsonl 重建進行中任務等狀態,避免 task_end 報 no open task。batching 與 instantNotice 用於在「system prompt 全量重算成本高」與「新反思儘快可見」之間折中:未達提交閾值時先發 plugin 通知,達到 commitEvery 等閾值後再更新 system prompt 區段。
典型用法¶
Agent 側流程¶
系統提示會引導 Agent:任務開始前調用 task_start(文檔要求其爲任務第一項動作);有明確結果後調用 task_end;根據復盤材料調用 task_reflect 寫入結構化經驗。若任務開始後才補開 task_start,插件無法補回此前未收錄的決策過程——這是 README 明確寫明的限制。
需要追溯某條經驗時,由 Agent 自行決定是否調用 lessons_lookup(lesson_id),以換取完整來源鏈(目標、結果、事件區間、任務開啓時的其他經驗等),而不是在每次反思時預塞全部來歷。
人工維護記憶¶
在插件目錄下,可用附帶的 CLI 做審計與治理(會話 id 等參數以你環境爲準):
node tools/lessons.mjs list --session <會話id>
node tools/lessons.mjs check
node tools/lessons.mjs add --scope global --pattern "…" --correction "…" \
--applies-when "…" --boundary "爲什麼屬於這一層"
node tools/lessons.mjs move <id> --to global
node tools/lessons.mjs remove <id>
node tools/lessons.mjs remove <id> --yes
node tools/deprecate.mjs <id> --reason "…"
node tools/deprecate.mjs --list
remove 默認只預覽、exit 3 等待確認;--yes 才寫入墓碑。這與 README 中「危險操作需審批」的設計一致。
適用場景與注意¶
更適合誰: 希望在 DSH 工作流裏顯式區分「任務邊界」、願意讓 Agent 在任務結束後做結構化復盤,並把經驗按會話/全局分層注入後續對話的團隊或個人。SkillHub 將其歸入工作流類插件,與「純工具封裝」型插件的定位不同。
務必留意的限制(摘自 README 第三節,此處只列要點):
- 任務邊界仍依賴模型是否調用
task_start/task_end,漏開會缺決策軌跡。 - 分層、衝突、重複等語義判斷由模型負責,結構檢查器無法識別「分錯層」或空泛
boundary。 - 三層共用一個 system prompt section,內容變化可能觸發較大範圍的提示詞緩存重算(README 給出過量級實測,因使用方式而異)。
- 插件自述爲實驗品,第四節實驗數據需在倉庫內查閱,不宜在未經復現的情況下當作生產 SLA。
經過上面的步驟,若你已在測試環境驗證安裝、數據目錄權限與復盤流程,再推廣到日常會話會更穩妥。
結尾¶
dsh-lessons 把 DSH「一切皆插件」的思路落到 Agent 元認知上:用工具劃定任務、用結構化字段沉澱經驗、用作用域與治理規則控制注入,並保留按需溯源能力。它不替代你自己的評測與合規流程,而是在 Harness 內多一層可審計的記憶閉環。