前言¶
在 DSH 裏跑領域智能體時，「好不好」往往靠會話裏的口頭約定或散落筆記，難以追溯，也談不上多會話一致。改一條寫作或評審標準，通常只能改提示詞或人工同步文檔，缺少可審計的提案、背書和爭議處理路徑。
下面介紹社區插件 dsh-taste-loop（維護者 NelsonLongxiang，分類：工作流）。它在 DSH host 側提供一套 taste protocol：記錄判斷、提出版本化規則修訂、由獨立會話達成法定人數共識，爭議由配置的人工仲裁會話處理。插件當前版本 0.2.1，許可證 MIT，GitHub 星標爲 0（以目錄頁統計爲準）。
這是什麼¶
dsh-taste-loop 是僅運行在 DSH host 上的品味閉環插件：自助版本化規則提案、獨立會話共識、人工仲裁。英文簡介爲：self-service versioned taste rules with independent-session quorum and human arbitration。
它不替你做業務決策，而是把「規則從哪來、何時生效、誰背書、誰仲裁」寫成可查詢、可追加的歷史（JSONL），並通過 MCP 工具與可選的 taste-mcp HTTP 面暴露給智能體與市場網關。
核心工具與能力¶
插件註冊一組 MCP 工具，職責如下（名稱與 README 一致）：
| 工具 | 用途 |
|---|---|
taste_rules |
已登記規則及提案狀態（effective / pending_review / needs_arbitration） |
taste_case |
確定性 case ID，同一判斷點始終映射到同一 ID |
taste_record |
將品味判斷寫入 verifier inbox |
taste_queue |
人工仲裁 / 結算隊列快照 |
taste_update |
自助規則生命週期：propose / list / blind / endorse / resolve |
自助規則生命週期¶
- 任意領域智能體可創建或修訂 版本化規則提案（
taste_update propose）。歷史爲只追加 JSONL，不會自動激活新版本。 - 兩個 彼此獨立的 DSH 會話（且不同於提案作者；
ctx=decision:上下文不計入）對同一修訂背書 → 該修訂成爲域內 effective 版本。共識得到的 effective 與人工 ratified 在報告中始終分開呈現。 - 兩個獨立 dissent 會話 → 狀態爲 needs_arbitration。爭議凍結期間，上一版 effective 規則繼續有效。
- 人工仲裁者（見配置項
arbiterSessionIds）處理爭議；每次 resolution 會追加 claim 與 resolution 行。
安全邊界¶
僅帶自報 X-Market-Client 頭的直連 HTTP 調用方可以寫入普通判斷，但 不能 提案共享規則、背書或 resolve。若 workbench-market 網關與插件配置了相同的 marketGatewayKey，攜帶匹配 X-Market-Gateway-Key 的請求會把網關會話身份從 mcp/<name> 升級爲已校驗的 market/<name>，方可 propose 與 endorse。人工仲裁（resolve）仍限制在配置的 DSH arbiterSessionIds。提案、背書與 resolution 賬本使用可崩潰恢復的文件鎖串行寫入。
安裝與啓用¶
官方 README 給出的安裝方式如下（推薦本地 checkout；未提供 dsh plugin add github:owner/repo 形式的一鍵命令）：
dsh plugin --profile web add /path/to/dsh-taste-loop
若從 GitHub 源碼安裝：prepare 會構建 lib/，但 @deepseek-ai/* 等 peer 僅在 DSH profile 內才能正確解析；在 profile 外單獨 pnpm add github:NelsonLongxiang/dsh-taste-loop 可能無法通過 typecheck（安裝路徑以你本地 checkout 爲準）。
在 cordis.patch.yml 中配置插件 id 爲 taste-loop，字段包括（註釋摘自 README）：
- id: taste-loop
config:
verifierRepo: '<your-verifier-repo-path>' # required
inboxHome: '<your-inbox-path>' # optional
host: 127.0.0.1 # taste-mcp HTTP face
port: 9810
arbiterSessionIds: [] # DSH session IDs allowed to resolve disputes
marketGatewayKey: '' # shared secret with the market gateway; set to enable trusted market sessions
說明：verifierRepo 爲必填，指向 verifier 倉庫；inboxHome 可選；host / port 爲 taste-mcp HTTP 監聽；arbiterSessionIds 列出允許 resolve 爭議的 DSH 會話 ID；marketGatewayKey 與市場網關共享密鑰，非空時啓用受信 market 會話。
插件開發自檢命令（維護者側）：
pnpm install && pnpm build && pnpm verify && pnpm drift
典型用法（工作流概覽）¶
下面是一條可對照 README 復現的邏輯鏈，不涉及虛構案例數據。
- 用
taste_case爲某個判斷點固定 case ID，避免同一點多次記錄時 ID 漂移。 - 用
taste_record把當前會話的品味判斷寫入 inbox，供後續 verifier 或人工流程使用。 - 用
taste_update propose提交或修訂版本化規則提案；用list/blind查看或盲審相關狀態（以工具 schema 爲準）。 - 由 非作者 的兩個獨立 DSH 會話分別
endorse同一修訂，使規則進入 effective；若出現雙 dissent，則進入 needs_arbitration，此時用taste_queue查看仲裁隊列。 - 配置在
arbiterSessionIds中的會話通過taste_update resolve結案；全程用taste_rules查詢 effective / pending / needs_arbitration 等狀態。
市場側若需 propose / endorse，須走帶正確 X-Market-Gateway-Key 的網關路徑，而不是僅自報 Client 頭的直連寫操作。
適用場景與注意¶
適合誰： 需要在多會話、多智能體之間對齊「領域品味 / 評審標準」，且希望規則變更有提案、背書、仲裁留痕的團隊；與工作流類 DSH 插件組合，把判斷與規則從聊天上下文中抽成 host 側協議。
務必注意：
- 插件以 當前 DSH 進程權限 運行，讀寫
verifierRepo、inbox 與賬本文件；安裝前應閱讀源碼與 MIT 許可證，確認路徑與密鑰配置符合你的安全策略。 - 社區目錄 SkillHub 插件頁 與 GitHub 倉庫由社區維護，與 DeepSeek / 幻方無官方從屬關係；DSH 生態理念是「一切皆插件」，本文不將其描述爲官方應用商店條目。
ctx=decision:會話不參與獨立背書計數；共識 effective 與人工 ratified 分報，避免把自動共識誤當成人工批准。
結尾¶
dsh-taste-loop 把品味判斷與版本化規則變更收斂到 host 側工具鏈：記錄、提案、獨立會話法定人數、人工仲裁，並劃清 market 網關與 arbiter 會話的寫權限邊界。若要進一步覈對工具參數與配置細節，請以倉庫 README 爲準。
- 目錄頁：https://www.skillhub.cn/plugins/NelsonLongxiang/dsh-taste-loop
- GitHub：https://github.com/NelsonLongxiang/dsh-taste-loop
