---
status: live
type: prd
module: dsh-round-table
last_updated: 2026-10-06
---

# 圆桌骑士：当前产品需求与行为

> 当前源码1.0.0仅调整版本编号，产品形态沿用已验收的0.1.18；1.0.0尚未公开发布。维护入口见[CLAUDE](../CLAUDE.md)、[ENGINEERING](ENGINEERING.md)及[API](产品实现速查.md)；内部验收和业务数据不公开。

## 1. 文档作用与版本

本文是接手 Agent 了解**当前产品形态**的首读文档，当前源码为 `dsh-round-table 1.0.0`，功能与验收基线为0.1.18，宿主仍为桌面 DSH `0.2.0-rc.2`。本次仅调整版本编号，未改变业务功能；下文原验收与模型测试仍归属其记录版本。

本仓库根目录的[package.json](../package.json)、src和lib对应当前桌面版本。体验清单（内部维护记录）记录 UX-001—022 的历史反馈、曾经的建议及验收过程；其中旧章节的“尚未实现”“待细化”描述是当时状态，不代表当前需求。阅读当前行为以本文和清单最新完成结论为准，判断测试范围以 QA（内部维护记录） 的版本记录为准。

其他阅读入口：设计规范（内部维护记录）、产品变更记录（内部维护记录）。本文不替代磁盘会议账本、已发布任务卡或当前宿主会话实况。

### 状态口径

- **已实现：** 下文明确说明的 0.1.18 功能，能从生产源码和记录的验收范围找到依据。
- **已确认原则：** 用户指定的产品边界，后续修改必须遵守；不能凭 Agent 的建议恢复旧设计。
- **体验观察：** 已登记但没有实施的改进线索，不能当作新需求或宣布完成。
- **实测边界：** 区分真实模型、真实生产组件、隔离 Host 与正式桌面观察，不将某一种通过扩大为全场景保证。

## 2. 产品定位与信息结构

圆桌把多个**原有成员 Agent 会话**组织到同一场会议，让用户讨论、准备工作、明确授权、跟踪结果与整理会议进展。它同时服务临时问答和项目工作会，用户决定什么时候只讨论，什么时候生成并发布任务卡，什么时候使用可重复的协作流程。

主要导航为 **讨论、进程、资料、纪要、设置**。成员从右侧边栏查看；“任务卡”打开本插件内的生成与修改窗口。细粒度执行跟进归入成员工作日志，不恢复独立的成员页或独立任务跟进页。

会议头部显示会议名称、概况、成员数量、待验收／故障等状态及可点击的下一步。运行结束、下一轮草稿和历史记录是不同状态；会议进行中不意味着所有成员正在执行。等待投递、送达、正式提交、人工验收也分别记录。

依据：[MeetingPanel](../src/client/MeetingPanel.tsx)、[会议计数](../src/meeting-counts.ts)、[体验状态投影](../src/meeting-ux.ts)。

## 3. 讨论：自然输入与明确接收人

### 3.1 普通消息与仅记录

普通消息由用户在讨论输入框撰写，并通过 `@` 明确选择一个或多个成员。选择以实际接收人标签为准，正文中的 `@名字` 字符串不等于已选成员。普通发送进入原成员有序接收队列，不创建工作任务卡，也不由 LLM 判断用户是否“真正想派任务”。

没有接收成员时，“记录到会议”把内容保存到本会，不唤醒成员。有接收成员时，主操作显示发送对象。普通问答可以关联已有工作，作为澄清或补充交流；这不另建工作任务，也不冒充正式成果提交。

**已确认原则：** 保留普通讨论与结构化任务两种机制。切换依据是用户操作“任务卡生成”和之后的发布确认，禁止加入 LLM 自动意图分类来替用户切换。

### 3.2 输入与附件

- 讨论区是资料的直接输入入口：图片、文档可拖入，截图可粘贴，正文与附件作为同一条内容提交。
- Enter 提交当前内容；Ctrl／⌘+Enter 换行。当前实现也保留 Shift+Enter 换行，中文输入法候选确认不误发送。
- 上传、图片能力核对或原请求结果待核实时，不把半条图文消息先发出去。失败／不确定的操作保留原请求身份，支持核对及原请求重试。
- 输入框不再常驻底部“@成员”“资料”“加入会议环节”按钮；键入 `@` 仍可打开选人菜单。选人菜单脱离裁切容器，窄栏也能查看和操作。
- 删除当前草稿里的附件选择，不等于删除已上传到本会的资料归档。

依据：[HostingComposer](../src/client/HostingComposer.tsx)、[ChatDiscussion](../src/client/ChatDiscussion.tsx)、[普通讨论协议](../src/discussion.ts)、[聊天与资料暂存](../src/chat.ts)、[附件输入](../src/client/ComposerAttachments.tsx)。

### 3.3 导入成员回复

旧“公开原回复”已改为“导入成员回复”，在讨论中直接打开。主持人明确选择来源成员、读取和预览后，可以把原回复选入本会，或补交关联任务的结果；导入保留来源与原回复信息。导入不是通知其他成员，补交也不自动完成验收。

不能未经操作批量公开原成员的其他私聊。选择、取消和确认是独立动作，重复请求不重复创建已接受内容。

依据：[PublishPanel](../src/client/PublishPanel.tsx)、[发布与正式结果](../src/meeting-flow.ts)。

## 4. 任务卡：原成员起草，用户修改并选择发布

### 4.1 生成者与触发

用户先在讨论输入区 `@` 选原成员，再点击“任务卡生成”。**正文可以为空**；若有正文、引用或附件，则作为生成约束与资料。没有选择成员时不能擅自决定生成者。选中的原成员依据自己实际收到的会议上下文提出后续工作，插件不默认另建起草助手或让秘书代写。

一项待办对应一张卡，多事项返回逐项清单。生成者与确认责任成员分别显示，不能把生成者直接当作用户已确认的执行者。多成员回应分别记录；失败项重试不要求成功项重新生成。

### 4.2 修改与采纳

用户可打开卡片全文，编辑名称、Markdown 正文及责任成员，再保存新版本。也可针对某一张卡写自然语言修改意见，交给该卡的**原生成者**调整。建议独立保留，用户明确采纳后才形成新版本；晚返回的 AI 建议不能覆盖用户的新编辑。

当前编辑、旧版本、生成来源与调整建议均可追踪。存在未保存编辑时，先保存再调整或发布。当前卡片正文以原始 Markdown 编辑展示，不宣称已有排版阅读视图。

### 4.3 发布与执行

用户选择具体卡片，并核对**精确版本及责任成员**，点击“确认发布并通知执行”。先将批准版本写入本会工作文件夹，再建立责任成员通知队列。未选中的卡不发布、不执行；生成、编辑、让原成员调整、采纳建议都属于准备工作。

成员读取已批准文件，认领并通过正式结果工具提交。插件区分等待、送达、处理中、提交、验收和要求修改；普通回应不能替代工作结果。发布同一请求不会变成重复工作，写盘或送达不确定时保留可恢复状态。

旧手工发任务／模板发送入口已从当前用户主流程替换。历史任务、结果及旧模板名称保留，不因界面简化而删除；资料中的历史模板只读显示。

依据：[TaskCardsPanel](../src/client/TaskCardsPanel.tsx)、[生成控制器](../src/client/use-card-generation.ts)、[任务卡状态与发布](../src/task-cards.ts)、[任务版本协议](../src/task-card-types.ts)、[正式提交工具](../src/tools-meeting.ts)、[修改关系](../src/task-revision.ts)。

## 5. 成员：右侧详情与会议工作日志

### 5.1 边栏归属

“成员”在当前会议右侧展开成员边栏，讨论和未发送输入保持原位。成员详情显示原窗口状态、工作区、职责及成员管理；工作日志汇总该成员在本会的参会、要求、所选资料、普通讨论、投递、回应、正式结果、修改与验收事实。

日志由已有会议事件和结构化状态投影，不由 LLM 每次重写成员历史，也不持续抓取原窗口全部私聊。它帮助用户持续跟进某位成员，粒度比秘书的全会纪要更细。成员离会后保留历史日志和已有结果。

### 5.2 原窗口恢复与不可用状态

用户已授权的入会简报、讨论或工作投递需要原成员时，插件检查并按需恢复**同一个原会话**，包括原身份、预设、上下文和工作区，用户不必离开插件手动唤醒。浏览名册或日志本身不等于唤醒所有成员。

归档不自动解除；已删除、身份变化、工作区不可用或宿主证据不足时明确提示，保留会议内移除入口。恢复失败不能新建替代会话冒充原成员，未知状态不冒称删除或送达。成员忙碌时遵守宿主有序接收，不宣称即时中断当前工作。

移除成员应告知关联工作影响；已有工作、结果和历史成员记录不被静默清空。后续环节仍引用不可用原成员时，保留该身份并提示，不能自动分配给另一位成员。

依据：[MemberSidebar](../src/client/MemberSidebar.tsx)、[成员工作日志投影](../src/client/member-work-log.ts)、[成员任务操作](../src/client/MemberTaskActions.tsx)、[原会话检查与恢复](../src/member-session-state.ts)、[入会简报](../src/member-briefing.ts)。

## 6. 会议目录与资料归档

### 6.1 目录身份与内容

新会议在**会议选定工作区内由插件建立**专属目录，保留成员原有会话工作区。实际组织为：

```text
<会议选定工作区>/圆桌会议/<会议名-稳定标识>/
├── .会议身份.json
├── 会议说明.md
├── 说明版本/会议说明-vN.md
├── 文件索引.json
├── 材料/
├── 任务卡/
├── 成果/
└── 纪要/
```

稳定标识来自会议 ID，名称不是唯一身份。会议改名不移动目录；目标、成员职责等明确管理修改产生新的说明版本，旧版不覆盖。会议归档或删除保留工作文件。旧会议由用户明确确认接入，复制其已批准材料／任务／成果／纪要，不自动迁移、不重放旧任务。

### 6.2 成员与秘书如何读取

原成员通过 `meeting_file_index` 获取本会批准的 fileId／版本，通过 `meeting_read_file(meetingId,fileId)` 读取；通知和入会说明提供目录位置及规则。跨工作区读取仍校验参会身份，不扩大原会话工程写权限。

文件由插件核验身份、路径、内容摘要和批准版本；成员不直接编辑已批准文件或系统账本。外部修改、缺失、损坏或索引冲突时报告问题，不把未知文件自动当作新批准材料。

秘书的生成 Agent 禁用工具，由插件先读取并核验指定批准文件，再把只读快照注入。**不能写成秘书只看路径就已自行读取所有文件，或仅凭文件名已看懂图片／压缩包。**

### 6.3 资料页的完整归档责任

资料页显示**当前会议所有已成功上传并保存的文档和图片及其版本**，包含未随消息发给任何成员的资料。它不只显示最新一条消息的附件，不要求用户先到资料页输入，也不因取消消息里的引用而丢失归档。上传失败或尚未批准的文件不冒充已保存资料。

每份资料可查看名称、版本、时间、大小和 SHA，下载指定版本；支持的图片可预览，可读取的文本可查看内容。直接读取的小文本／图片每份最大 2 MB，文本最多 10 万字符；普通文件可保留完整原件引用，最大 256 MB，不自动解压或解析。保留原件不等于模型已理解内容，图片发送还需核对实际接收模型能力。

依据：[会议目录与读取](../src/meeting-folder.ts)、[批准文件同步](../src/meeting-files-sync.ts)、[流式上传](../src/meeting-file-upload.ts)、[ResourcesPanel](../src/client/ResourcesPanel.tsx)、[MeetingFolderPanel](../src/client/MeetingFolderPanel.tsx)、[图片预检](../src/image-preflight.ts)。

## 7. 秘书与纪要：全会进展的按需整理

会议秘书是会议专属的只读整理角色，不是普通执行成员，不接受 `@全体` 的普通工作路由，不代成员完成任务或替主持人验收。当前实现保留会议专属秘书会话；一次纪要生成启动受限、无工具的生成子 Agent。因此“秘书是一次性 Agent”只适合描述单次生成过程，不能据此删除会议秘书身份或把秘书作为一般执行人。

用户在纪要页选择全量或“自上次以来”，可以预览读取范围，再按需生成。默认整理正式会议消息、结构化任务状态及已明确选入的资料；原会话来源是显式兼容设置，不能扩大成默认读取私聊。生成结果展示摘要、决策、任务进展与责任、未决事项，并附系统事实核对、缺失来源和生成证据。

纪要先作为草稿保留。事实核对不保证模型绝对正确；主持人核对后，公开到会议与发送通知给成员分别操作，也可以保留不发送。纪要按对应会议文件夹归档。失败或取消不冒充成功的增量基线。

秘书负责全会层面的汇总，成员日志负责某位成员的具体事实；二者不互相替代。新自由步骤不默认插入秘书环节，用户仍可在纪要页主动整理。

依据：[秘书身份与权限](../src/secretary.ts)、[生成及来源](../src/minutes.ts)、[系统事实核对](../src/minutes-facts.ts)、[MinutesPanel](../src/client/MinutesPanel.tsx)。

## 8. 进程：用户自行编排的步骤列表

### 8.1 用途与工具栏

进程用于较固定、可重复的多 Agent 协作安排，减少反复指定成员和传递成果的操作。普通问答不需要先进入进程，也不需要任务卡才能交流。

工具栏分为三层：

| 区域 | 用户决定什么 | 作用 |
|---|---|---|
| 正在查看／显示方式 | 看本轮、下一轮草稿或历史；步骤列表或流程图 | 切换查看，不唤醒成员 |
| 流程配置 | 保存修改、放弃修改 | 保存安排与版本，不开始工作 |
| 本轮运行 | 预览并启动逐环节规则、运行操作 | 核对实际输入、执行人、自动环节和手动停止点，再明确授权；暂停／恢复／停止是运行操作 |

配置、查看和运行分开，不通过“保存”暗中执行。新自由步骤不再提供全局“手动主持／自动接力”下拉，由每个环节的开关指定接力规则；仅非逐环节旧流程保留全局协作方式的兼容入口。原“加入会议环节”不再放在讨论主输入区；补充输入在实际环节内操作，暂存资料不等于马上投递或新建环节。

依据：[WorkflowToolbar](../src/client/WorkflowToolbar.tsx)、[WorkflowPanel](../src/client/WorkflowPanel.tsx)。

### 8.2 空白编排与每行内容

**新流程从空白开始。** 新增环节初始名称、成员、要求为空，自动运行默认关闭。没有预设“提出方案→技术评审／预算评审→人工决定→修改→秘书”的业务结构。

每个环节具备：

- **名称：** 在标题位置直接输入；没有展开后的重复“步骤名称”字段。
- **成员 Agent：** 每行常驻真实会议成员选择，一个环节一个 Agent；同一 Agent 可承担多个环节。同名环节按稳定 ID 区分，不用名字当唯一身份。
- **自动接收上游信息并运行：** 唯一此类复选框，默认不勾选；不再向步骤用户分别展示“接收上游”和“成果验收”两个开关。
- **展开详情：** 本环节要求、明确选择的会议消息／资料，以及已有结果、验收、修改、补充、重试等执行操作。
- **标题栏删除：** 0.1.18 每个普通环节和并行分支都常驻红色“删除”，不需要先展开。

“本环节要求”实际成为该环节工作投递中的 instruction，并与冻结的所选资料／上游正式结果一起发给负责成员。它不是只供人阅读的便签，也不自动替其他环节改写提示词。要求可留空；执行时使用通用的完成与正式提交要求，名称及成员仍须完整。

### 8.3 顺序、并行与删除

用户可添加环节、在任意阶段插入后续、整体上移／下移阶段；在任意环节旁“设置并行”新增独立分支。并行各项有自己的名称、成员、要求、资料和自动选项，全部真实分支完成并满足正式结果条件后才继续下游。同一 Agent 被安排到多个并行项时，宿主可能按队列顺序处理，不保证物理同时执行。

删除操作依据稳定节点 ID。删除未选中环节保留当前选中项；并行剩一项自动收缩为普通阶段；删至零回到空白；保存后持久记录。删除草稿环节不等于删除成员会话、资料或历史执行结果。

**已确认原则：** 新步骤列表不设独立返工／回路编辑器，不保留固定的通过／需要修改分支。需要修改或再评审时，由用户新增后续步骤，可以再次指定同一 Agent。不能把旧模板或自动默认结构重新塞入新流程。

### 8.4 草稿、启动与自动边界

空白或未配置完整的步骤可作为准备草稿保存；执行预览必须补齐实际名称、成员和可用输入。初次预览明确展示首阶段所有真实工作项，以及已保存的自动环节、手动停止点和额度。确认后立即启动首阶段全部工作项，并授权预览中明确勾选的后续逐环节规则；首阶段的本次明确启动不受开关是否勾选限制，未勾选的后续步骤不能自行开始。

自动接力依据结构化流程和授权状态，不做会话意图分析。**后续自动开始需要首轮预览确认已授权逐环节规则、该环节已勾选自动运行、输入与额度条件满足，且本轮未暂停或停止。** 新自由步骤无需再选择全局自动模式。未勾选的后续环节停在可开始状态，等待用户手动预览和开始；手动开始也会使用实际可用的上游信息，关闭自动开关不意味着屏蔽上游。

普通回复、生成草稿或文件存在不能代替正式任务结果；结果被要求修改、需要验收、成员失效、投递未知、失败或额度边界会阻止继续。默认自由步骤没有强制人工验收门，但显式要求验收或旧流程保留的验收条件仍有效。人工跳过须明确记录，不能冒称成功；自由并行的内部依赖不能以“部分继续”绕过未完成分支。

活动运行时顺序、并行结构、添加和删除冻结，**暂停也不解除结构冻结**；已开始环节的成员、要求及输入等字段冻结。尚未开始的字段可按现有规则更新；自动协作未来规则修改需额外确认，保存后暂停，核对并明确恢复才使用新规则。重启、异常停止和待核实状态不自动重放工作。

### 8.5 内部依赖与旧流程兼容

新步骤用有序阶段保存结构，并编译内部入口／并行汇合依赖。它们不是成员、秘书或人工决定环节：没有执行激活、没有模型任务、不占普通任务或秘书额度，不允许通过用户执行接口直接启动。新结构使用 workflow schema 3，schema 1／2 保持支持，更高未知版本只读。

旧会议图定义、选择／回路语义和全部运行历史保留，**不自动转平为自由步骤**。旧图在步骤列表按真实节点只读显示，原流程图入口保留；活动运行结束后可明确“新建空白步骤编排”，保存前不替换旧定义。新自由步骤的流程图只查看依赖，结构编辑回到步骤列表。

依据：[WorkflowSteps](../src/client/WorkflowSteps.tsx)、[纯步骤编排与内部依赖](../src/workflow-steps.ts)、[校验](../src/workflow-graph.ts)、[运行与冻结](../src/workflow-runtime.ts)、[正式结果投影](../src/workflow-projection.ts)、[自动接力](../src/workflow-auto.ts)、[版本协议](../src/workflow-types.ts)。

## 9. 桌面壳、缩放与草稿恢复

普通圆桌侧栏默认宽 380 px，可拖动调整；关闭后再打开恢复默认宽度，实际宽度受当前宿主可用空间约束。原 Agent 中心页面同步缩窄，与侧栏并排，避免输入区被插件直接覆盖。完整工作台是单独的展开模式，占用中心区域；不能把普通侧栏的并排保证扩大为完整工作台也永不覆盖。

流程图画布适应可用区域，并提供缩小、放大、适配按钮及 Ctrl＋滚轮锚点缩放。普通滚轮滚动画布，不改变整个宿主页面倍率；这不是为全部产品页面加浏览器缩放。

旧未分区草稿按内容、所属会议、接收成员和待核实状态呈现，而非要求用户理解技术存储键。用户明确确认归属后恢复，不覆盖已有当前草稿，不自动重发未知原请求。成功恢复后收起已处理提醒，原数据与设置入口保留；失败／冲突／未知请求仍提示实际状态。本地存储不可用时明示仅本窗口有效，不能显示虚假的“已保存”。

依据：[桌面入口](../src/client/index.tsx)、[侧栏尺寸](../src/client/panel-layout.ts)、[宿主并排](../src/client/host-dock.ts)、[画布](../src/client/WorkflowCanvas.tsx)、[缩放几何](../src/client/workflow-viewport.ts)、[旧草稿恢复](../src/client/LegacyDrafts.tsx)、[本地实例分区](../src/client/ui-state.ts)。


## 验证与发行状态

0.1.18内部交付已通过124套常规、225项真实浏览器检查和18包检查；公开仓库verify仅类型/包验证。生成卡片的旧真实模型单例与最新步骤的隔离Host/组件验证范围不同，不能据此保证任意模型起草或纪要事实质量。当前[npm包](https://www.npmjs.com/package/dsh-round-table)与[GitHub v0.1.18](https://github.com/whateverboy2333/dsh-round-table/releases/tag/v0.1.18)均已发行，桌面安装方式以仓库README的当前说明为准。已发行标签和资产不随后续main文档补全而替换。