我让三个大模型互相当红队一个多模型圆桌插件的架构、踩坑与一次被否掉的方案先说结论免得你翻到最后多模型协作 ≠ 多问几个模型。并列回答解决的是覆盖率会议解决的是收敛——后者需要主持人、需要持久的专家会话、需要结构化归并。真正难的不是让模型说话是控制权、上下文、成本口径以及审查者的输出格式。本文有 4 个来自真实翻车的工程细节、2 个诚实故事、1 个被红队否掉的产品方向。项目是dsh-plugin-roundtableDeepSeek Harness 插件MITv1.0.0-rc.1。下面所有数字和坑都是真的。一、起点一次真实的多模型评审我写了一份方案草案然后做了一件事把三个不同厂商的模型拉进同一个会议室只给一条规矩——只准挑毛病不准给方案。克劳德 · 架构视角gpt · 产品视角qwen · 实现成本视角它们交回来9 条缺陷。我逐条表态9 条全部认定为真问题。其中最值钱的一条是方案自己前后矛盾一处要求画布可拖拽编辑另一处写着不另做独立编辑器。这个矛盾我在写方案时完全没意识到而它是纯文本层面就能当场核实的——不需要任何领域知识。这件事让我确认了一个判断让模型互相拆台比让它给我答案有用得多。二、为什么多问几个 AI不等于开会同时问三个模型你得到三份并列的回答。听起来很美实际有四个问题问题表现没有收敛三份答案都摆在那谁对谁错、哪里冲突还是你自己判断上下文爆炸三个模型各写 2000 字你读完已经累了再多两个模型直接放弃没有责任主体没人负责综合于是你成了唯一的整合器分歧无处安放模型 A 说该做、模型 B 说不该做这个分歧本身是有价值的信息却被并列排版抹平了所以这个插件要造的不是多路调用而是三件东西主持人谁负责收敛、持久会话专家能被追问不是一次性问答、结构化归并不让上下文被十份报告淹没。三、架构主持人 持久子代理 汇聚网关拓扑是一张环形图主持人DeepSeek / | \ 专家A ←——→ 专家B ←——→ 专家C ← 双向通道 可互辩 \ | / 汇聚网关结构化归并三件事值得说1. 每位专家是一个持久子代理durable subagent不是一个 API 调用。它带着一份《全局协作总纲》入会会议目标、自己的角色边界、协作协议、安全红线。跑完一轮它回到空闲状态但还能被再次唤醒——所以节点已完成这种状态在语义上是不存在的这一点后来成了我改界面的依据见第八节。2. 两种发言通道用错就是烧钱。roundtable_speak写进会议记录不唤醒任何人。日常汇报走这条。roundtable_send_message唤醒收件人让它立刻开始干活。只有必须现在动手才用它。这个区分不是洁癖把日常汇报走成唤醒专家会被无意义地拉起来烧 token。3. 状态全落盘且 UI 不直接改会议状态。工作区/.roundtable/会议id/ ├── meeting.json 议题、专家、连线、预算、决策 ├── transcript.jsonl 逐条发言追加写 ├── review.json 针锋相对的评审记录与表态 ├── user-actions.jsonl UI 上的改动等主持人执行 └── kb-digest.json 知识库摘要缓存UI 改动走队列是刻意的设计。你在界面上加一个专家插件不会去偷偷改会议状态而是往user-actions.jsonl追加一条记录主持人下一轮读到它、再用roundtable_add_node执行。好处是只有主持人一个写者不存在两个写者互相覆盖主持人唯一对用户负责的语义没有被 UI 绕过去队列落盘重启不丢。代价是有延迟下一轮才生效界面上必须如实告知已排入队列——这是产品诚实问题不是技术问题。四、成本为什么必须区分说了多少和花了多少这是我踩过的最有教育意义的坑。插件界面上有一个 Token 数字超预算会自动闭麦。它统计的是发言文本量中文约 0.6 token/字。一直相安无事直到我把它和 provider 上报的真实用量摆在一起口径数值界面上显示的发言量粗估5,289provider 上报的真实用量127,230差 24 倍。差额来自哪里system prompt、每位专家的 persona、历史上下文、工具调用的请求与返回——这些都不在发言文本里但都是真金白银。所以现在界面上两个数字并列显示并且我把这段说明直接写进了 README它是说了多少的刻度不是成本表。工程教训任何自己算出来的成本指标只要它不是 provider 账单就必须明确标注口径否则它迟早会误导你自己。预算熔断可以基于粗估它只需要单调、可控但成本判断不行。五、针锋相对把只挑毛病做成协议红队模式的核心不是多问一遍而是约束审查者的输出规则 1只找缺陷禁止提替代方案。不禁止会怎样审查者会逃到我觉得应该这样做——听起来像建议实际上是把论证降级成了另一种主张你反而更难判断原方案是否成立。规则 2每条观点只聚焦一个缺陷必须附证据。证据分两级C1repro代码/bug 类附可复现步骤1. 2. 3.argument设计类附论证链。并且明令禁止给设计类缺陷编造伪复现步骤。这条很关键——否则模型会为了让证据看起来硬写出运行这条命令即可复现这种假东西。规则 3逐条三态表态驳回必须写理由。每个观点独立一张卡支持 / 驳回 / 取消三态可互切。驳回必填理由——这不是找麻烦而是因为一键驳回是逃避思考的最短路径。理由会进 user-action 记录供主持人修订时对照。规则 4闭环复审最多 3 轮首轮 2 次复审超过需显式批准。复审时只核对上一轮已认定的缺陷是否修复禁止引入全新打分项——否则评审会变成无限循环的每次都有新意见。六、四个来自真实翻车的工程细节这一节是我最想写给掘金读者的部分都是真事都有具体症状。6.1inject是加载门禁不是可选依赖插件曾把可选能力写进了 cordis 的inject列表。结果是宿主少提供任何一个服务整个插件不加载——工具、数据路由、GUI 页签、设置页一起消失而且不报错。用户看到的现象是页签不见了没有任何线索指向根因。修法必需能力才走inject可选能力skill 目录、用户问答、connection 兜底传输改成运行时ctx.get(...)可选读取。铁律两条探测绝不成为新的加载门禁降级必须留痕。6.2 宿主会静默摘掉抛错的 UI 条目DSH 对渲染抛错的 slot 条目会静默移除——隔离本身是正确的但用户只看到页签消失了。修法两个界面入口都包进错误边界把崩溃渲染成可读的报错面板 控制台完整堆栈用户可以直接贴 issue。6.3 自建 Web 路由不会自动带安全栅栏插件有两条自己的路由快照 RPC。原因是宿主的通用 connection 通道在某些组合下没挂载只靠它会导致无法连接会议服务。但自建路由有个陷阱宿主不会自动施加 Host/Origin 与浏览器认证检查。不接的后果是真实的——本机任意网页DNS rebinding 后同源或者text/plain简单 POST 免预检都能命中插件路由删会议、改连线、读走全部评审内容。修法路由自己调宿主的connection.requestRejection()。官方文档原话就是Apply Connection’s Host/Origin checks and browser authentication to another Web route。另外补了 1 MiB 请求体上限——无上限的请求体等于让任何本机页面把整包塞进内存。6.4 rc 线上类型全红不一定是 API 破坏对齐宿主版本后第一次跑tsc60 处报错Property subagents does not exist on type Context看起来像宿主改了 API。实际根因是同一个deepseek-ai/cordis存在两份物理副本宿主一份、插件一份。TypeScript 视为两个不同模块于是declare module deepseek-ai/cordis { interface Context { ... } }的声明合并失效。把插件指向宿主那一份之后tsc0 错误。教训版本升级后类型全红先查混装再怀疑 API。这个坑现在被写进了插件的只读诊断脚本doctor它会主动比对两条路径不一致时直接把上面这段解释打给你。七、两个诚实故事7.1 数字口径上面第四节已讲此处不重复7.2 评审工具自己在评审中暴露的归集缺陷它确实是插件的已知短板。针锋相对评审有一个观点自动拆分专家一条发言里往往写了 3 条缺陷系统要把它们拆成 3 张独立观点卡用户才能逐条表态。拆分优先走 LLM失败则降级到本地零 token 的标记切分。在一次真实评审里出现了这样的结果观测数值拆分请求4 次产出的观点数5 条其中最短的那条发言被成功拆成 2 条三条长发言各被压成 1 条也就是说三位专家各写 3 条缺陷最后只形成了 3 张大卡每张里塞着 3 条缺陷表态粒度被悄悄变粗了。根因在降级路径本地兜底识别的标记格式是观点 N指向 X维度Y而专家实际写出的是**缺陷 1……**主路径LLM与兜底路径本地标记对什么算一条观点的定义不一致。当 LLM 路径失败时系统并没有降级到同等结构而是静默改变了输出语义。教训我认为这是本文最值得抄走的一条降级路径必须产出与主路径同构的结果。否则兜底不是保底而是悄悄换了一套语义——而用户只会看到观点变少了永远不会知道为什么。我最后的处理是按发言原文手工重排成 9 条独立观点并逐条校验原文引用确实是发言原文的子串拆分器的第三道防线本来就在做这件事。未来的修法还没做如实记在这里让本地兜底同时识别缺陷 N这类常见写法或者在降级发生时在界面上明确标注本条未拆分——宁可让用户看到粗糙也不要让他看到被悄悄合并的结果。八、一个被红队否掉的方向把拓扑图升级成流程图这部分我想单独讲因为**决定不做什么比做了什么更能体现设计判断**。想法现在的拓扑图是会议状态的投影——先开会图跟着变。它很好看但读完你说不出谁把什么交给了谁、下一步去哪。于是我想把它升级成流程图开会前先画蓝图会议按图执行节点升级成带输入/处理/输出的步骤连线升级成带数据标注和条件分支的流转蓝图可存成模板分享。听起来很顺对吧我把它交给三位专家做红队评审架构 / 产品 / 成本三个攻击面交回9 条缺陷全部认定为真。挑三条最致命的状态机与持久子代理的生命周期冲突草案定义pending/running/done/failed但专家是持久子代理做完一轮回到空闲、还能被再次唤醒——done在这个系统里根本不存在。要么把专家降级成一次性子代理丢掉多轮追问能力要么引入步骤实例 / 专家会话双层抽象复杂度暴涨。连线的流转语义与平等模式互斥上游哪段产出 → 下游哪个输入是确定性数据流而平等模式下专家之间是点对点自由辩论消息内容由发送方推理动态决定、接收方自主解读不存在预定义输入槽位。要按蓝图校验消息就得拦截、阻断或改写——要么破坏专家自治要么让流程大量卡在校验失败上。成本被严重低估草案用一行话带过节点状态扩展为 pending/running/done/failed失败按节点配置重试或走兜底分支。但当时没有执行引擎、没有节点级重试/超时/兜底会议推进靠主持人手动派发。要实现那行字需要新建主动调度器、每节点超时与重试循环、三种兜底路由继续/跳过/交给人、条件分支判定模块——这是一个迷你工作流引擎保守 2~3 周全职后端再加上编辑器前端端口吸附、贝塞尔拖拽、数据映射可视化配置3~4 周。而这个草案在同一页里写着不另做独立编辑器——自相矛盾。决定不做。但这次评审不是白做因为它逼我把图到底该怎么读想清楚了。最后落地的是三件不涉及流程图的事画布图例把这张图在当前模式下怎么读直接写在画布上统筹主持人逐次派发 / 平等专家直达互辩 / 红队只挑毛病并标注虚线是系统补的骨架通道、不是真实流转。起因正是缺陷 1、2 的共同内核同一张通道图在三种模式下含义完全不同不写清楚用户就会把它读成一张控制流程的路径图。节点状态如实显示直接显示持久子代理的真实状态——工作中 / 空闲可续聊/ 就绪可唤醒/ 未唤醒 / 已退出。刻意不发明已完成 / 已失败因为子代理跑完一轮回到空闲、仍可被再次唤醒说它结束了是错的。这是缺陷 1 反过来给的启示既然不引入执行状态机界面就该更贴真相。阵容预设一次套用多位专家“方案评审三人组这类固定组合。它只回答谁来开会——没有节点顺序、没有连线、没有分支。缺陷 2 指出模板与角色预设边界不清”所以这次我把边界同时写进类型注释、设置页提示文案和 README从三个地方堵死它演化成又一个会议模板的可能。方法论一个方案被否掉的时候别急着扔掉整份文档。把为什么它不成立拆出来里面往往有几条与方案无关的、独立成立的改进。九、装起来插件不发布到 npm作者拿不到 npm 账户registry 上不存在这个包只能从源码装gitclone https://github.com/9931666/dsh-plugin-roundtablecddsh-plugin-roundtablepnpminstallpnpmbuild dsh plugin--profilewebadd.装完重启 DSH → 刷新 Web UI → 设置里能看到「圆桌会议」即可。宿主基线DeepSeek Harness 0.1.5-rc.3MIT 许可。它是什么把一个 DSH 会话变成一场可视化、可辩论、可拍板的圆桌会议。三种模式主持人统筹 / 多模型平等 / 针锋相对、汇聚网关、人类决策卡片、知识库中转与摘要缓存、预算熔断与闭麦、整场 Markdown 导出、匿名反馈只记模式/模型/轮数/时间戳 你主动填的一句话绝不记对话内容。十、已知欠账诚实清单写文章最容易犯的错是只讲优点所以我先把欠账列出来前端零测试RoundTableView.tsx有 1700 行没有测试覆盖——因为需要先把纯逻辑从组件里抽出来。纯函数层预算、状态、净化、拆分有测试界面没有。只验证过一个宿主版本0.1.5-rc.3。兼容矩阵是单一来源、有脚本强制一致但矩阵里目前只有一条。不发 npm升级靠git pull pnpm build。观点拆分对长发言不稳见 7.2这是当前最该修的一条。结语用 AI 评审 AI最容易走偏的地方是把它做成多问几遍。真正让结果可用的是三个约束审查者只输出缺陷、每条缺陷必须带证据、由人逐条拍板并把理由落盘。剩下的都是工程让状态落盘、让写者唯一、让降级同构、让成本口径诚实。你只负责抛出议题。
我让三个大模型互相当红队一个多模型圆桌插件的架构、踩坑与一次被否掉的方案先说结论免得你翻到最后多模型协作 ≠ 多问几个模型。并列回答解决的是覆盖率会议解决的是收敛——后者需要主持人、需要持久的专家会话、需要结构化归并。真正难的不是让模型说话是控制权、上下文、成本口径以及审查者的输出格式。本文有 4 个来自真实翻车的工程细节、2 个诚实故事、1 个被红队否掉的产品方向。项目是dsh-plugin-roundtableDeepSeek Harness 插件MITv1.0.0-rc.1。下面所有数字和坑都是真的。一、起点一次真实的多模型评审我写了一份方案草案然后做了一件事把三个不同厂商的模型拉进同一个会议室只给一条规矩——只准挑毛病不准给方案。克劳德 · 架构视角gpt · 产品视角qwen · 实现成本视角它们交回来9 条缺陷。我逐条表态9 条全部认定为真问题。其中最值钱的一条是方案自己前后矛盾一处要求画布可拖拽编辑另一处写着不另做独立编辑器。这个矛盾我在写方案时完全没意识到而它是纯文本层面就能当场核实的——不需要任何领域知识。这件事让我确认了一个判断让模型互相拆台比让它给我答案有用得多。二、为什么多问几个 AI不等于开会同时问三个模型你得到三份并列的回答。听起来很美实际有四个问题问题表现没有收敛三份答案都摆在那谁对谁错、哪里冲突还是你自己判断上下文爆炸三个模型各写 2000 字你读完已经累了再多两个模型直接放弃没有责任主体没人负责综合于是你成了唯一的整合器分歧无处安放模型 A 说该做、模型 B 说不该做这个分歧本身是有价值的信息却被并列排版抹平了所以这个插件要造的不是多路调用而是三件东西主持人谁负责收敛、持久会话专家能被追问不是一次性问答、结构化归并不让上下文被十份报告淹没。三、架构主持人 持久子代理 汇聚网关拓扑是一张环形图主持人DeepSeek / | \ 专家A ←——→ 专家B ←——→ 专家C ← 双向通道 可互辩 \ | / 汇聚网关结构化归并三件事值得说1. 每位专家是一个持久子代理durable subagent不是一个 API 调用。它带着一份《全局协作总纲》入会会议目标、自己的角色边界、协作协议、安全红线。跑完一轮它回到空闲状态但还能被再次唤醒——所以节点已完成这种状态在语义上是不存在的这一点后来成了我改界面的依据见第八节。2. 两种发言通道用错就是烧钱。roundtable_speak写进会议记录不唤醒任何人。日常汇报走这条。roundtable_send_message唤醒收件人让它立刻开始干活。只有必须现在动手才用它。这个区分不是洁癖把日常汇报走成唤醒专家会被无意义地拉起来烧 token。3. 状态全落盘且 UI 不直接改会议状态。工作区/.roundtable/会议id/ ├── meeting.json 议题、专家、连线、预算、决策 ├── transcript.jsonl 逐条发言追加写 ├── review.json 针锋相对的评审记录与表态 ├── user-actions.jsonl UI 上的改动等主持人执行 └── kb-digest.json 知识库摘要缓存UI 改动走队列是刻意的设计。你在界面上加一个专家插件不会去偷偷改会议状态而是往user-actions.jsonl追加一条记录主持人下一轮读到它、再用roundtable_add_node执行。好处是只有主持人一个写者不存在两个写者互相覆盖主持人唯一对用户负责的语义没有被 UI 绕过去队列落盘重启不丢。代价是有延迟下一轮才生效界面上必须如实告知已排入队列——这是产品诚实问题不是技术问题。四、成本为什么必须区分说了多少和花了多少这是我踩过的最有教育意义的坑。插件界面上有一个 Token 数字超预算会自动闭麦。它统计的是发言文本量中文约 0.6 token/字。一直相安无事直到我把它和 provider 上报的真实用量摆在一起口径数值界面上显示的发言量粗估5,289provider 上报的真实用量127,230差 24 倍。差额来自哪里system prompt、每位专家的 persona、历史上下文、工具调用的请求与返回——这些都不在发言文本里但都是真金白银。所以现在界面上两个数字并列显示并且我把这段说明直接写进了 README它是说了多少的刻度不是成本表。工程教训任何自己算出来的成本指标只要它不是 provider 账单就必须明确标注口径否则它迟早会误导你自己。预算熔断可以基于粗估它只需要单调、可控但成本判断不行。五、针锋相对把只挑毛病做成协议红队模式的核心不是多问一遍而是约束审查者的输出规则 1只找缺陷禁止提替代方案。不禁止会怎样审查者会逃到我觉得应该这样做——听起来像建议实际上是把论证降级成了另一种主张你反而更难判断原方案是否成立。规则 2每条观点只聚焦一个缺陷必须附证据。证据分两级C1repro代码/bug 类附可复现步骤1. 2. 3.argument设计类附论证链。并且明令禁止给设计类缺陷编造伪复现步骤。这条很关键——否则模型会为了让证据看起来硬写出运行这条命令即可复现这种假东西。规则 3逐条三态表态驳回必须写理由。每个观点独立一张卡支持 / 驳回 / 取消三态可互切。驳回必填理由——这不是找麻烦而是因为一键驳回是逃避思考的最短路径。理由会进 user-action 记录供主持人修订时对照。规则 4闭环复审最多 3 轮首轮 2 次复审超过需显式批准。复审时只核对上一轮已认定的缺陷是否修复禁止引入全新打分项——否则评审会变成无限循环的每次都有新意见。六、四个来自真实翻车的工程细节这一节是我最想写给掘金读者的部分都是真事都有具体症状。6.1inject是加载门禁不是可选依赖插件曾把可选能力写进了 cordis 的inject列表。结果是宿主少提供任何一个服务整个插件不加载——工具、数据路由、GUI 页签、设置页一起消失而且不报错。用户看到的现象是页签不见了没有任何线索指向根因。修法必需能力才走inject可选能力skill 目录、用户问答、connection 兜底传输改成运行时ctx.get(...)可选读取。铁律两条探测绝不成为新的加载门禁降级必须留痕。6.2 宿主会静默摘掉抛错的 UI 条目DSH 对渲染抛错的 slot 条目会静默移除——隔离本身是正确的但用户只看到页签消失了。修法两个界面入口都包进错误边界把崩溃渲染成可读的报错面板 控制台完整堆栈用户可以直接贴 issue。6.3 自建 Web 路由不会自动带安全栅栏插件有两条自己的路由快照 RPC。原因是宿主的通用 connection 通道在某些组合下没挂载只靠它会导致无法连接会议服务。但自建路由有个陷阱宿主不会自动施加 Host/Origin 与浏览器认证检查。不接的后果是真实的——本机任意网页DNS rebinding 后同源或者text/plain简单 POST 免预检都能命中插件路由删会议、改连线、读走全部评审内容。修法路由自己调宿主的connection.requestRejection()。官方文档原话就是Apply Connection’s Host/Origin checks and browser authentication to another Web route。另外补了 1 MiB 请求体上限——无上限的请求体等于让任何本机页面把整包塞进内存。6.4 rc 线上类型全红不一定是 API 破坏对齐宿主版本后第一次跑tsc60 处报错Property subagents does not exist on type Context看起来像宿主改了 API。实际根因是同一个deepseek-ai/cordis存在两份物理副本宿主一份、插件一份。TypeScript 视为两个不同模块于是declare module deepseek-ai/cordis { interface Context { ... } }的声明合并失效。把插件指向宿主那一份之后tsc0 错误。教训版本升级后类型全红先查混装再怀疑 API。这个坑现在被写进了插件的只读诊断脚本doctor它会主动比对两条路径不一致时直接把上面这段解释打给你。七、两个诚实故事7.1 数字口径上面第四节已讲此处不重复7.2 评审工具自己在评审中暴露的归集缺陷它确实是插件的已知短板。针锋相对评审有一个观点自动拆分专家一条发言里往往写了 3 条缺陷系统要把它们拆成 3 张独立观点卡用户才能逐条表态。拆分优先走 LLM失败则降级到本地零 token 的标记切分。在一次真实评审里出现了这样的结果观测数值拆分请求4 次产出的观点数5 条其中最短的那条发言被成功拆成 2 条三条长发言各被压成 1 条也就是说三位专家各写 3 条缺陷最后只形成了 3 张大卡每张里塞着 3 条缺陷表态粒度被悄悄变粗了。根因在降级路径本地兜底识别的标记格式是观点 N指向 X维度Y而专家实际写出的是**缺陷 1……**主路径LLM与兜底路径本地标记对什么算一条观点的定义不一致。当 LLM 路径失败时系统并没有降级到同等结构而是静默改变了输出语义。教训我认为这是本文最值得抄走的一条降级路径必须产出与主路径同构的结果。否则兜底不是保底而是悄悄换了一套语义——而用户只会看到观点变少了永远不会知道为什么。我最后的处理是按发言原文手工重排成 9 条独立观点并逐条校验原文引用确实是发言原文的子串拆分器的第三道防线本来就在做这件事。未来的修法还没做如实记在这里让本地兜底同时识别缺陷 N这类常见写法或者在降级发生时在界面上明确标注本条未拆分——宁可让用户看到粗糙也不要让他看到被悄悄合并的结果。八、一个被红队否掉的方向把拓扑图升级成流程图这部分我想单独讲因为**决定不做什么比做了什么更能体现设计判断**。想法现在的拓扑图是会议状态的投影——先开会图跟着变。它很好看但读完你说不出谁把什么交给了谁、下一步去哪。于是我想把它升级成流程图开会前先画蓝图会议按图执行节点升级成带输入/处理/输出的步骤连线升级成带数据标注和条件分支的流转蓝图可存成模板分享。听起来很顺对吧我把它交给三位专家做红队评审架构 / 产品 / 成本三个攻击面交回9 条缺陷全部认定为真。挑三条最致命的状态机与持久子代理的生命周期冲突草案定义pending/running/done/failed但专家是持久子代理做完一轮回到空闲、还能被再次唤醒——done在这个系统里根本不存在。要么把专家降级成一次性子代理丢掉多轮追问能力要么引入步骤实例 / 专家会话双层抽象复杂度暴涨。连线的流转语义与平等模式互斥上游哪段产出 → 下游哪个输入是确定性数据流而平等模式下专家之间是点对点自由辩论消息内容由发送方推理动态决定、接收方自主解读不存在预定义输入槽位。要按蓝图校验消息就得拦截、阻断或改写——要么破坏专家自治要么让流程大量卡在校验失败上。成本被严重低估草案用一行话带过节点状态扩展为 pending/running/done/failed失败按节点配置重试或走兜底分支。但当时没有执行引擎、没有节点级重试/超时/兜底会议推进靠主持人手动派发。要实现那行字需要新建主动调度器、每节点超时与重试循环、三种兜底路由继续/跳过/交给人、条件分支判定模块——这是一个迷你工作流引擎保守 2~3 周全职后端再加上编辑器前端端口吸附、贝塞尔拖拽、数据映射可视化配置3~4 周。而这个草案在同一页里写着不另做独立编辑器——自相矛盾。决定不做。但这次评审不是白做因为它逼我把图到底该怎么读想清楚了。最后落地的是三件不涉及流程图的事画布图例把这张图在当前模式下怎么读直接写在画布上统筹主持人逐次派发 / 平等专家直达互辩 / 红队只挑毛病并标注虚线是系统补的骨架通道、不是真实流转。起因正是缺陷 1、2 的共同内核同一张通道图在三种模式下含义完全不同不写清楚用户就会把它读成一张控制流程的路径图。节点状态如实显示直接显示持久子代理的真实状态——工作中 / 空闲可续聊/ 就绪可唤醒/ 未唤醒 / 已退出。刻意不发明已完成 / 已失败因为子代理跑完一轮回到空闲、仍可被再次唤醒说它结束了是错的。这是缺陷 1 反过来给的启示既然不引入执行状态机界面就该更贴真相。阵容预设一次套用多位专家“方案评审三人组这类固定组合。它只回答谁来开会——没有节点顺序、没有连线、没有分支。缺陷 2 指出模板与角色预设边界不清”所以这次我把边界同时写进类型注释、设置页提示文案和 README从三个地方堵死它演化成又一个会议模板的可能。方法论一个方案被否掉的时候别急着扔掉整份文档。把为什么它不成立拆出来里面往往有几条与方案无关的、独立成立的改进。九、装起来插件不发布到 npm作者拿不到 npm 账户registry 上不存在这个包只能从源码装gitclone https://github.com/9931666/dsh-plugin-roundtablecddsh-plugin-roundtablepnpminstallpnpmbuild dsh plugin--profilewebadd.装完重启 DSH → 刷新 Web UI → 设置里能看到「圆桌会议」即可。宿主基线DeepSeek Harness 0.1.5-rc.3MIT 许可。它是什么把一个 DSH 会话变成一场可视化、可辩论、可拍板的圆桌会议。三种模式主持人统筹 / 多模型平等 / 针锋相对、汇聚网关、人类决策卡片、知识库中转与摘要缓存、预算熔断与闭麦、整场 Markdown 导出、匿名反馈只记模式/模型/轮数/时间戳 你主动填的一句话绝不记对话内容。十、已知欠账诚实清单写文章最容易犯的错是只讲优点所以我先把欠账列出来前端零测试RoundTableView.tsx有 1700 行没有测试覆盖——因为需要先把纯逻辑从组件里抽出来。纯函数层预算、状态、净化、拆分有测试界面没有。只验证过一个宿主版本0.1.5-rc.3。兼容矩阵是单一来源、有脚本强制一致但矩阵里目前只有一条。不发 npm升级靠git pull pnpm build。观点拆分对长发言不稳见 7.2这是当前最该修的一条。结语用 AI 评审 AI最容易走偏的地方是把它做成多问几遍。真正让结果可用的是三个约束审查者只输出缺陷、每条缺陷必须带证据、由人逐条拍板并把理由落盘。剩下的都是工程让状态落盘、让写者唯一、让降级同构、让成本口径诚实。你只负责抛出议题。
