dangxinxing090-svg/dsh-plugin-brief

brief

一个 DeepSeek Harness 插件，把每条 agent 回复变成一份简报：几页幻灯片，结论先行。为那些使用 harness 但不读代码的人而做。

agent 仍然照常写它要写的东西。这个插件给你第二种阅读方式：每条回复都会以几页幻灯片的形式重新呈现——先结论，再是几个步骤，然后是 agent 等你回答的任何问题。原始文本永远只需点击一下即可查看，而在你需要的回合里，通俗易懂的版本也只需按一下即可获得。

它解决什么问题

agent 完成任务后打印出一大堆文字：文件名、代码、术语、括号、路径。如果你读代码，扫一眼就知道发生了什么。如果你不读，看完之后仍然不知道它是否成功了。

这个插件把一份幻灯片放在那条回复原本所在的位置——只有几页，而不是一堵墙：

| 幻灯片 | 内容 | 用途 |
|---|---|---|
| 1 | 结论 | 读完这一页你就知道结果 |
| 2–6 | 过程 | 实际发生了什么，每个步骤一行 |
| 最后 | 问题 | 如果 agent 需要你做决定，点击一个选项或输入回复 |

什么都不会被删除。卡片标题栏中的 完整原文 按钮可切换到完整原始文本，上方带有一行技术摘要（耗时、操作次数、token 用量），再用 回到幻灯片 切换回来。

安装

在已安装 DeepSeek Harness（dsh）的机器上：

dsh plugin --profile web add github:dangxinxing090-svg/dsh-plugin-brief

这会直接从本仓库安装，而且现在就能用——该包尚未发布到 npm。

一旦发布到 npm，更短的名称也能解析：

dsh plugin --profile web add dsh-plugin-brief

重启 dsh。整个安装过程就这些——该包会自行挂载，因此没有需要编辑的配置文件。

把 web 替换为你的 profile 名称（tui 是另一个常见的）。若要固定某个发布版本而不是跟踪默认分支，可追加标签或提交：github:dangxinxing090-svg/dsh-plugin-brief#v0.1.0。

手动安装

1. 在 profile 目录中安装该包：

cd ~/.dsh/profiles/web
pnpm add github:dangxinxing090-svg/dsh-plugin-brief

2. 在同一目录下的 cordis.patch.yml 中追加：

- insert:
- id: brief
name: 'dsh-plugin-brief'

3. 重启 dsh。如果你想先确认这一行，dsh --dump-config 会打印出组合后的树。

编辑 cordis.patch.yml，绝不要编辑 cordis.yml——后者是生成的。

卸载

dsh plugin --profile web remove dsh-plugin-brief

发布你自己的副本

Fork 这个项目并以你自己的名义发布？有三处必须保持一致：

1. package.json 中的 name——你发布的包名。
2. cordis.patch.yml 中的 name:——那是该行的模块说明符，它必须等于包名，否则加载器无法解析该行。
3. LICENSE 中的版权行。
行 id（brief）只是一个组合键；可以随意重命名。

重写是你主动请求的

默认情况下，回复不产生任何费用。 卡片打开时显示 · 原版 —— 即根据 agent 自己的措辞在本地排版的同一组幻灯片，布局正确、措辞未经处理 —— 标志旁边有一个 通俗化 按钮。

按下它，标题会显示 · 通俗化中…，同时该轮次的重写正在进行。然后要么：

- 出现 · 通俗版 —— 重写成功，你正在阅读通俗语言；要么
- 标志回到 · 原版 —— 重写失败，你保留本地渲染的版本。格式仍然正确，只是没有简化。

本地幻灯片从不会让卡片空白，也从不会显示损坏的标记。

成功会被保留。回到该轮次 —— 无论是在重新加载后，还是在重启 DSH 后 —— 按下 通俗化 会立即显示通俗版本：没有 · 通俗化中…，也永远不会再次调用你的模型。

一旦通俗幻灯片存在，卡片就同时持有两种措辞，标志旁边的按钮会在它们之间切换：当你正在阅读通俗版本时显示 原版，要回到通俗版本时显示 通俗化。该切换是与 完整原文 分开的控件，后者会离开幻灯片，显示完整的 markdown。

对话本身显示的内容

卡片只是其中一半。该插件还会整理它周围的对话记录，这样你就不必滚过 agent 的作业才能找到答案：

| 在对话记录中 | 你看到的内容 |
| --- | --- |
| 当一轮次正在运行时 | 输入框正上方、深度求索中... 状态下方的一个两行框 —— 一个标题，说明正在发生什么并指向 Trajectory，然后用通俗语言显示最新步骤。关闭它后它会保持关闭；会话标题栏中有一个带标签的开关（显示工作过程 / 隐藏工作过程），可在任何状态下切换它 |
| 当轮次结束时 | 你的消息，然后是幻灯片 |
| 工具行、推理、工具折叠、注入的上下文、压缩标记、重试、系统提示 | 完全不显示 |
| 失败和截断（turn-error、turn-max-tokens） | 保留 —— 你总能知道出了什么问题 |
| 审批、问题、计划审查、呈现的文件 | 保留 —— 每一项都渲染在工具行之外（输入框、轮次页脚、侧边栏插件面板） |
| 动态插件自己的内联 UI（tool.view.cordis） | 与其行一起隐藏 —— 这是唯一真正的损失 |
| 上面隐藏的所有内容 | 仍在 Trajectory 视图中，一键即可访问 |

没有任何内容被删除。该插件改变的是默认显示的内容，而不是记录的内容。

成本

默认情况下不产生任何费用。 回复在本地排版，不产生费用，只有当你对某一轮次按下 通俗化 时才会发生模型调用。

- 它使用你当前选择的默认模型。
- 只翻译该轮次的报告。 工作过程永远不会被发送。
- 一次成功只花费一次调用，并且会被保留 —— 在本会话或之后的会话中再次请求同一轮次，都会直接显示通俗版本，永远不会再次询问模型。
- 一次失败最多重试三次，因此一次提问最多产生四次调用，且每次重试的输出预算都比首次尝试更宽裕。之后按钮会重新出现，所以失败的提问可以重复发起——那是一次新的提问，而非静默重试。
- 向上滚动回看绝不会重新发起请求。
- 要彻底移除改写功能——包括按钮——请在插件行中添加 disabled: true。

工作原理

共四个部分：

1. 它接管回复渲染器。 插件注册到 harness 的助手消息席位，因此原始 markdown 不再被直接渲染——取而代之的是幻灯片卡片。
2. 它接管工作过程渲染器。 同一个席位按消息类型区分，因此插件认领工具行、推理折叠块、注入上下文、压缩标记、重试和系统提示，并将它们渲染为空——从该轮的第一秒起，无需等待 harness 自身的过程折叠。那个折叠只对已产生最终答案的已结束轮次生效，而这恰恰不是轮次运行期间，也不是轮次被中止之后。插件还自行折叠这些行，而不是依赖 harness 的 :empty 规则：它们每一个都保留了一个子元素，所以该规则永远不会触发，每一行仍会占据该列的 16px 相邻边距——单轮中就会产生数千像素的空白。工作框根本不是渲染器，而是 composer 停靠项，因为只有停靠项会在对话之后绘制，因而也在状态标签之后绘制。交互式席位无法以这种方式认领，因此插件改为验证它们的归属位置：composer 中的审批和提问，轮次页脚中的交付物，侧边栏面板中的动态插件批准/拒绝。
3. 改写是可选启用的，且仅针对报告。 回复首先在本地排版，因此在你对其按下 通俗化 之前，一轮不产生任何开销。按下后会将收尾步骤的文本——绝不是过程——发送给你的模型，并附带严格指令：以固定行协议输出 HTML 片段，一个结论和几个步骤。一次成功即结束该轮的预算并被保留；一次失败最多重试三次；改写是串行化的，因此突发请求无法启动。
4. 本地渲染是默认行为，而非回退方案。 客户端自身用一个小的 markdown → HTML 转换器拆分原始文本。除非你请求改写，否则你读到的就是它；如果改写失败，你继续读到的也是它。排版正确，措辞未经处理。

客户端部分通过 Connection 的已认证 /api 获取通道（ctx.connection.fetch.register）与其宿主部分通信，因此 harness 会在处理器运行前应用其 Host/Origin 信任围栏和浏览器会话 cookie。插件自身不实现任何认证。

模型输出在渲染前会经过净化：只有一小份纯文本标签白名单得以保留，所有属性都被剥离，类  元素被整体移除。

常见问题

幻灯片是填充内容，比如“plugin updated”。
插件已经过滤掉纯状态和近乎空白的页面，重写提示词也告诉模型不要输出它们。如果还是漏了一个，请带着那张幻灯片的文本开一个 issue。

表格渲染成了一行竖线。
那一轮没有走 HTML 路径。请带着完整回复开一个 issue。

我希望 agent 一开始就用大白话回答，而不是事后被翻译。
那是另一项改动——它属于 agent 的提示词，不属于这个插件。这个插件刻意不动 agent 自己的话，因为那些话也是它用来继续工作的依据。

回复很长。我丢内容了吗？
演示文稿最多显示一张结论幻灯片加五张过程幻灯片。其余内容都在完整原文视图里。

这会把我的数据发到什么地方吗？
不会。重写使用的是你的对话已经在用的同一个模型服务。这个插件自身没有网络访问权限，也不收集任何东西。

故障排查

卡片始终不出现，启动时报告插件加载失败。

每一次注册到 conversation.chat.node 都用了默认的槽位优先级，而 harness 自己的渲染器已经以同样的优先级占用了那些相同的键。两个注册在同一优先级上争抢同一个单元格，这不是槽位系统会解决的平局：该行加载失败，插件什么也没贡献。这就是 v0.1.0 的 bug——插件在任何 harness 上都没能挂载。

已在 v0.1.1 修复：现在每次注册都带有 priority: -10，从而赢得该单元格。如果你在 v0.1.0 上，请升级。

插件到底加载了吗？ 已加载的插件会把每条回复渲染成一张卡片，上面有一个 演示 按钮。如果回复是纯 markdown，那就是没加载——而且 harness 本身没问题；故障仅限于这个插件自己的那一行。

卡片渲染出来了，但措辞还是很技术化。 这是默认行为：回复在本地排版，在你按下 通俗化 之前不会重写任何内容。如果你按了它，而标记又变回了 · 原版，说明重写失败了——打开浏览器控制台，找 brief:，它会报告尝试了多少次以及为什么最后一次什么都没产出。

开发

没有构建步骤——lib/ 里的文件就是源码。

lib/index.js       宿主部分：每个请求一次重写调用，以及 /api 路由
lib/client.js      浏览器部分：回复渲染器、幻灯片演示、本地演示文稿构建器
cordis.patch.yml   自挂载的 bundle 补丁
test/              两部分的可行性验证

npm test

test/host.test.mjs 把宿主部分挂载到一个假 context 上，并用 Request/Response 对象驱动真实路由。test/client.test.mjs 驱动实际的浏览器 bundle 契约：它捕获 window.__ModuleLoader__ 注册，用一个桩 require 调用工厂，并断言客户端部分做出的每一项贡献——它注册进的五个席位、它接管的类型、重写的调用预算和保留的演示文稿，以及工作框。
要在不发布的情况下试用本地检出：

dsh plugin --profile web add /path/to/dsh-plugin-brief

遮蔽内置插槽

conversation.chat.node 是一个带键的插槽，其键已由 harness 拥有。一个永久性的客户端插件若以默认优先级注册其中一个键，不仅会输给随附的渲染器——插件还会加载失败，什么都贡献不了，并在启动时报出加载错误。务必声明一个遮蔽优先级：

slots.register({ name: 'conversation.chat.node', key: 'assistant-step', priority: -10 }, View)

数字越小越能赢得该单元格。test/client.test.mjs 会在每一个 conversation.chat.node 注册上强制执行这一点，因此新增一个键却忘记写优先级，会在发布前就让测试套件失败。列表插槽（conversation.chat.assistant-actions、shell.overlay）是叠加式的，不需要优先级——给它们一个你自己的 id 即可。

MIT 许可。

brief（中文）

一个 DeepSeek Harness 插件。把每一轮 AI 的回答变成一份简报：几页幻灯片，先给结论。给用这个 harness、但不读代码的人。

AI 该怎么写还是怎么写。这个插件只是给你第二种读法：每轮回答都被重新呈现成几页幻灯片——先给结论，再列几步过程，最后是 AI 在等你拍板的问题。原文永远只差一次点击，大白话版本则在你想要的那几轮上差一次按下。

它解决什么问题

AI 干完活，吐出一大段文字：文件名、代码、术语、括号、路径。懂代码的人扫一眼就知道发生了什么；不懂的人读完了，还是不知道到底成没成。

这个插件在原本那段回答的位置放一副幻灯片——只有几页，不是一堵墙：

| 页 | 内容 | 作用 |
|---|---|---|
| 第 1 页 | 结论 | 只读这一页就知道结果 |
| 第 2–6 页 | 过程 | 每一步实际做了一件什么事 |
| 最后几页 | 问题 | 如果 AI 在等你决定，点选项或直接输入回复 |

什么都没删。卡片右上角的 完整原文 按钮随时切回完整原文，原文上方还有一行技术统计（耗时、操作次数、token 用量）；进入原文后按钮变成 回到幻灯片。

安装

在装了 DeepSeek Harness（dsh）的机器上执行：

dsh plugin --profile web add github:dangxinxing090-svg/dsh-plugin-brief

这是直接从本仓库安装，现在就能用——这个包还没发布到 npm。

等它发布到 npm 之后，短名字也成立：

dsh plugin --profile web add dsh-plugin-brief

然后重启 dsh。安装就这一步——包会自己挂载自己，不需要改任何配置文件。

把 web 换成你实际用的 profile 名（另一个常见的是 tui）。想锁定某个版本而不是跟随默认分支，在末尾加上 tag 或 commit：github:dangxinxing090-svg/dsh-plugin-brief#v0.1.0。

手动安装

1. 在 profile 目录里安装：

cd ~/.dsh/profiles/web
pnpm add github:dangxinxing090-svg/dsh-plugin-brief

2. 在同目录的 cordis.patch.yml 里追加：

- insert:
- id: brief
name: 'dsh-plugin-brief'

3. 重启 dsh。想先确认的话，dsh --dump-config 会打印组合后的插件树。

要改的是 cordis.patch.yml，不要改 cordis.yml——后者是自动生成的。

卸载

dsh plugin --profile web remove dsh-plugin-brief

发布你自己的版本

想 fork 出去用自己的名字发布？三处必须保持一致：

1. package.json 里的 name —— 你发布的包名
2. cordis.patch.yml 里的 name: —— 这是插件行的模块标识符，必须等于包名，否则加载器找不到这一行
3. LICENSE 里的版权行

行里的 id（brief）只是组合键，随便改。

通俗化是要你点才会做的

默认一分钱不花。 卡片打开时是 · 原版——同样的幻灯片，但由 agent 自己的原话在本地排版而成，排版正确、用词不加工——旁边有一个 通俗化 按钮。

按下去，卡头变成 · 通俗化中…，在等这一轮的改写返回。之后二选一：

- 出现 · 通俗版 —— 改写成功，你读到的是大白话；或
- 卡头退回 · 原版 —— 改写失败，你继续看本地渲染的版本。排版仍然正确，只是用词没加工。

本地排版不会让卡片空白，也不会显示破损的标记。

成功一次就会存下来。 以后回到那一轮——刷新页面也好、重开 DSH 也好——再按 通俗化 会直接显示通俗版：不会先出现 · 通俗化中…，也不会再问一次模型。
一旦通俗版存在，卡片同时持有两种措辞，标记旁边的按钮在它们之间切换：正在读通俗版时显示 原版，点它回到通俗版时显示 通俗化。这个开关和 完整原文 是两回事：后者会离开幻灯片、显示完整 markdown。

对话里还剩什么

卡片只是一半。插件同时会把对话本身整理干净，你不用翻过一堆“作业”才能看到答案：

| 对话里的位置 | 你会看到 |
| --- | --- |
| 一轮正在进行时 | composer 上方一个两行框，位于「深度求索中...」下面 —— 第一行标题说明正在做什么并指向轨迹页，第二行是最近一步的普通话描述。关掉它就一直是关的；会话标题栏有一个带文字的开关（显示工作过程 / 隐藏工作过程），任何状态都能切换 |
| 一轮结束时 | 你的消息，然后是幻灯片 |
| 工具行、思考过程、工具折叠、注入的上下文、压缩标记、重试、系统提示 | 完全不显示 |
| 失败与截断（turn-error、turn-max-tokens） | 保留 —— 出了问题一定会告诉你 |
| 授权、提问、计划确认、交付物 | 保留 —— 各自都有工具行之外的落点（composer、轮次页脚、侧栏插件面板） |
| 动态插件自己的行内界面（tool.view.cordis） | 随工具行一起隐藏 —— 这是唯一的真实代价 |
| 上面被隐藏的内容 | 都在“轨迹”视图里，点一下就能看 |

什么都没删。插件改变的是默认显示什么，不是记录什么。

花多少钱

默认不花钱。 回答先在本地排版，只有你按下某一轮的 通俗化 按钮，才会发生模型调用。

- 用的是你当前选中的默认模型
- 只翻译这一轮的结果，工作过程从不发给模型
- 成功只调用一次，并且会存下来——以后对同一轮再按一次，无论在本次会话还是下次打开，都直接显示通俗版，不会再问模型
- 失败最多重试三次，所以一次请求最多四次调用；每次重试的输出预算比首次更宽。失败后按钮会回来，可以再按——那是你主动发起的新一次请求，不是偷偷重试
- 往回翻永远不会重新请求
- 想彻底去掉改写（连按钮一起），在插件行上加 disabled: true

它是怎么工作的

四个部件：

1. 接管回答的渲染位。 插件注册进 harness 的“助手消息渲染位”，所以原始 markdown 不再直接渲染——由幻灯片卡取代。
2. 接管工作过程的渲染位。 同一个渲染位是按消息种类分键的，插件把工具行、思考折叠、注入的上下文、压缩标记、重试和系统提示全部认领下来，渲染成空——从一轮的第一秒就生效，不等 harness 自带的过程折叠（那个折叠只在“轮次已关闭且有最终答复”时才启用，恰好在一轮进行中和任务中止后是关着的，而那两个时刻正是过程最不该刷屏的时候）。此外插件自己把这些行收起来，不依赖 harness 的 :empty 规则：实测每个被隐藏的节点里都留着一个子元素，那条规则从不生效，于是每一行照样吃掉转录列的 16px 相邻外边距——一轮下来就是几千像素的纯空白。工作框本身不是渲染位，而是一个 composer 停靠项，因为只有停靠层绘制在整段对话之后，也就是绘制在「深度求索中...」之后。承担交互的渲染位不能这样认领，所以插件改为确认它们的落点在别处：授权与提问在 composer，交付物在轮次页脚，动态插件的批准/拒绝在侧栏面板。
3. 通俗化是 opt-in，而且只改写结果。 回答先在本地排好版，所以在你按下某一轮的 通俗化 之前，这一轮不产生任何调用。按下之后，插件才把收尾那一步的文字交给你的模型（过程永远不发），要求严格按固定行协议输出 HTML 片段：一句结论、若干步过程。成功一次就结束这一轮预算并永久留用；失败最多重试三次；改写之间是串行的，不会一次涌出一批调用。
4. 本地渲染是默认路径，不是兜底。 客户端自己用一个小型 markdown → HTML 转换器把原文切排。除非你按了通俗化，你读到的就是它；改写失败时你继续读的也是它。排版正确，用词不加工。

浏览器半边通过 Connection 的带鉴权 /api 通道（ctx.connection.fetch.register）和宿主半边通信，所以 Host/Origin 信任栅栏和浏览器会话 cookie 由 harness 在处理函数运行前统一校验，插件自己不做任何鉴权。

模型返回的 HTML 在渲染前会过白名单过滤器：只放行少数几个裸文本标签，所有属性一律剥掉， 之类整段删除。

常见问题

有一页是废话，比如“插件已更新”。
插件已经会过滤只有状态、没有内容的页，改写提示词里也明令禁止。如果还漏了，把那一页的文字贴上来开个 issue。

表格显示成一堆竖线。
那一轮没走通 HTML 路径。请附上完整回答内容开 issue。

我想让 AI 一开始就用大白话回答，而不是事后翻译。
那是另一件事——属于 agent 的提示词，不属于这个插件。这个插件刻意不改 AI 的原话，因为那些话它自己还要拿来继续干活。

回答很长，内容丢了吗？
幻灯片最多显示 1 页结论 + 5 页过程。剩下的都在“完整原文”里。

它会把我的数据发到别处吗？
不会。改写用的就是你本来就在用的那个模型服务。这个插件自己不联网、不收集任何东西。

排错

卡片一直不出现，启动时报插件加载失败。

插件注册 conversation.chat.node 时用的是默认优先级，而 harness 自带的渲染器早就占了同样的 key、同样的优先级。同一个格子里两个注册抢位，不是“谁赢”的问题 —— 整条 row 加载失败，插件什么都没贡献。这就是 v0.1.0 的 bug：它在任何 harness 上都装不上。

v0.1.1 已修复：每个注册都带 priority: -10，数字更低，赢得格子。你如果装的是 v0.1.0，请升级。

怎么判断插件到底有没有加载？ 加载成功时，每条回复都是一张卡片，右上角还有一个“演示”按钮。如果回复是普通 markdown，就是没加载 —— 但 harness 本身没事，失败只局限在这个插件自己那条 row 里。

卡片出来了，但用词还是很专业。 这是默认状态：回答先在本地排版，你没按 通俗化 就不会改写。如果你按了、卡头又退回 · 原版，说明改写失败——打开浏览器控制台找 brief:，它会报告尝试了几次、以及最后一次为什么没产出内容。

开发

没有构建步骤——lib/ 里的文件就是源码。

lib/index.js      宿主半边：每次请求恰好一次改写调用，以及 /api 路由
lib/client.js     浏览器半边：接管回答显示、渲染幻灯片、本地排版
cordis.patch.yml  自挂载补丁
test/             两个半边各自的可运行验证

npm test

test/host.test.mjs 把假上下文挂上宿主半边，用真正的 Request/Response 打通整条路由；test/client.test.mjs 验证真实的浏览器包契约——捕获 window.__ModuleLoader__ 注册、用桩 require 调用工厂函数，并断言客户端半边的每一项贡献：它注册的五个槽位、接管的节点种类、改写的调用预算与留存的通俗版、以及工作框。

想试本地 checkout 而不发布：

dsh plugin --profile web add /path/to/dsh-plugin-brief

覆盖 harness 自带的槽位时，必须给优先级

conversation.chat.node 是按 key 分格的槽位，而这些 key 早就被 harness 占着。永久客户端插件用默认优先级注册同一个 key，不是"输给"自带渲染器 —— 是整个插件加载失败、什么都没贡献，启动时还会报一个加载错误。必须显式声明一个能赢的优先级：

slots.register({ name: 'conversation.chat.node', key: 'assistant-step', priority: -10 }, View)

数字更低者赢得格子。test/client.test.mjs 对每一个 conversation.chat.node 注册都强制检查这一点 —— 以后加了新 key 却忘了优先级，测试会在发布前就失败。列表型槽位（conversation.chat.assistant-actions、shell.overlay）是可叠加的，不需要优先级，但要用自己的 id。

MIT 许可。