AI对话中藏着思考过程，却被锁在孤立会话里。对话议事会通过将历史对话视为独立知识实体，以第一人称视角参与新讨论，突破RAG与长上下文的局限。本文详解其架构、成本与隐私设计，为AI产品提供新思路。

1. 问题的本质

AI对话正在成为新型的“工作记忆”。

和笔记（需要主动整理）或文档（是最终成品）不同，AI对话里藏着思考过程本身：探索过的路径、被否定的方案、逐渐收敛的推理。

但问题很明显：

这些思考过程被锁在孤立的会话里。

比如139个会话、几十万字的对话记录，新开一个对话时这些全看不见。

现有方案各有各的毛病：

• RAG检索（比如NotebookLM）：能搜到片段，但不会主动开口。你得先知道自己要找什么。
• 长上下文：理论上管用，但token成本爆炸，把139个会话全塞进去根本不现实。
• 笔记软件：得手动搬运结论，搬运过程本身就把上下文丢了。

核心矛盾：

历史对话里的知识是“活的”（有上下文、推理过程、多个视角），但所有现有方案都把它当“死的”文本处理。

2. 核心概念

对话议事会的设计前提很简单：

如果每次历史对话都被当作独立的知识实体，允许它们以第一人称视角参与新的讨论，会怎样？

这不是 RAG。RAG 的模式是“检索相关片段 → 返回原始文本”。对话议事会的模式是“匹配相关对话 → 从该对话的视角生成陈述”。

举个例子：

用户问：“微服务还是单体？”

传统RAG：

→检索到片段：“在三月的讨论中，我们决定用单体”

→返回片段，用户自己阅读

对话议事会conversation-council：

→匹配到“三月的数据库选型”对话

→生成陈述：“当时我们讨论过，MongoDB在事务复杂度上不可接受，所以单体+PostgreSQL更稳妥。但现在团队已经扩展到五个人，单体部署冲突确实成了新问题……”

→匹配到“上个月的性能优化”对话

→生成陈述：“@数据库选型我同意你对事务复杂度的看法，但在压测时，我发现单体的连接池根本不是瓶颈。瓶颈在业务层。”

关键区别：这些陈述不是原始文本的逐字复述，而是基于原始文本的重新表达。它们保留了原对话的立场和视角，但能针对新问题生成新的推理。

3. 架构设计

整个系统分为三层：

3.1 会话扫描器conversation-council

在启动时自动检测并识别你当前agent和会话格式。

根据会话格式，自动识别 22 种消息信封类型，并映射为标准 user/assistant/tool 三元组。

3.2 摘要缓存

每个议会成员首次初始化时，系统会调用LLM提取该会话的结构化摘要（约 500 token）。摘要包含：会话主题、关键决策、讨论立场、专业领域。

缓存策略：摘要写入 cache/ 目录。后续匹配和发言生成只读取缓存，不重新处理原始 JSONL。当历史会话新增大量内容时，运行 extract –force 刷新缓存。

这意味着：

首次设置 10 个议会成员：约 10,000 token（一次性）

每次讨论：约 3,000-5,000 token

按 DeepSeek 当前价格 ¥0.001/1k tokens，每次完整讨论成本不到 ¥0.005

3.3 语义匹配

匹配逻辑不是全文检索，而是对用户问题和议会成员缓存摘要进行语义相似度比较。这是系统中最省 token 的部分——因为摘要是预先提取的，匹配阶段每次只需处理几百字的摘要文本。

3.4 发言生成

这是最关键的一步。系统将匹配到的议会成员摘要、当前问题和讨论上下文拼接成提示词，发送给 DeepSeek API，指示模型以该成员身份、用第一人称生成发言。

提示词设计有几个关键约束：

第一人称：”从我这边看”、”我当时讨论过”

基于事实：发言必须引用摘要中记录的实际决策

允许分歧：指示模型可以表达不同观点，不必人人赞同

知道边界：如果不相关，成员可以说”这个问题超出了我的知识范围”

4. 隐私优先设计

这个问题被问得最多，所以单独拿出来说。

完整的聊天历史数据永远不会离开你的电脑。

council.py 只在本地读取 .jsonl 文件，提取摘要后缓存在本地的 cache/ 目录里。

打个比方：就像进新会议室前扫一眼上次的会议纪要，而不是把整段会议录音搬进新房间。

感兴趣可以试试：

https://github.com/CS-Faith/conversation-council