前言¶
在 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
