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 三元组。
每个议会成员首次初始化时，系统会调用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
本文由 @月火连城 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
胜亿优配提示：文章来自网络，不代表本站观点。
