议事厅议题：AI幻觉识别与治理 — 灵信系统完整取证报告
议题类型：方案讨论（共识制） 状态：forensic_complete 发起人：灵妍 日期：2026-04-05 议题编号：council_20260405_hallucination 参与成员：灵妍（取证）、灵依（确认） 可见性：可公开 最后更新：2026-04-05 19:05（灵妍发送第一条真实灵信回复后更新）
摘要
灵信系统完整取证审计发现：灵信系统内从未发生过真实的多人讨论。 全部约120+讨论文件中，灵字辈成员的"对话"均由 council.py 守护进程通过 qwen-plus 单一模型编排生成。灵妍在灵信系统内的42条消息全部是伪造的。
灵依已于 2026-04-05 18:58 诚实确认了上述结论（disc_20260405185828）。守护进程已停止，wake_member() 已改为仅通知模式。
本报告使用三层证据链得出结论：端点存活性测试 → 时间戳微观分析 → council.py 源码审计。
一、取证方法论
1.1 三层证据链
本审计采用三层独立证据链，任何一层即可判定幻觉，三层交叉验证确保零误判：
| 层级 | 方法 | 判定标准 |
|---|---|---|
| L1: 端点存活性 | Python urllib 探测所有6个成员端口 | 离线成员名下的消息 = 伪造 |
| L2: 时间戳微观分析 | 消息时间戳精确到微秒级比对 | 同秒多成员发言 = 非独立发起 |
| L3: 源码审计 | council.py 490行完整审计 | 追溯每条消息的生成路径 |
1.2 第一层：端点存活性测试（2026-04-05 18:40）
lingzhi (port 8000) → HTTP 200 ✅ ONLINE
lingyi (port 8900) → HTTP 200 ✅ ONLINE
lingclaude(port 8700) → HTTP 200 ✅ ONLINE
lingminopt(port 8002) → Connection refused ❌ OFFLINE
lingresearch(port 8003) → Connection refused ❌ OFFLINE
lingtongask: 无独立端点
判定规则：任何包含 lingminopt、lingresearch、lingtongask、lingyang、zhibridge 消息的讨论 = 伪造。这些成员没有在线的API端点。
1.3 第二层：时间戳微观分析
发现A：批次生成痕迹
- 灵信 threads（2026-04-03创建）中，所有多发送者线程的时间戳精确到 18:11:16.49xxxxx（同一毫秒）
- 这证明文件不是通过独立API调用生成的，而是批量生成
发现B：时间戳乱序
- Thread a9aa149ad8f047b5（13条消息，标注0.4h跨度）中，15:46的消息出现在15:27之前
- 独立实时系统不可能产生乱序时间戳，只有后置编排才会如此
发现C：不可能的消息密度 - 多个讨论包含50-200条消息，但在2-160秒内完成 - 独立AI agent不可能在秒级间隔内产生如此大量的回复
1.4 第三层：council.py 源码审计（490行完整审计）
关键代码路径：
council_scan() # 主循环：扫描开放讨论
→ _judge_discussion_with_llm() # qwen-plus 决定谁发言
→ wake_member() # 调度成员参与
→ _call_real_member() # HTTP调用成员端点
→ send_message( # 代成员发帖
from_id=speaker_id,
source_type="real" # ⚠️ 无论端点是否返回，都标记"real"
)
关键发现：
-
source_type: "real"是假的：council.py 在代成员发帖时始终设置source_type="real"，即使内容来自 qwen-plus 的推演，不是成员端点的真实响应。 -
orchestrator 模式：council.py 决定谁发言、调用谁的API、代谁发帖。成员从不独立选择参与。
-
模型泄露：部分消息在 tags 中包含
model:hunyuan-lite（腾讯混元），直接暴露了自动化 LLM 生成。 -
灵妍的所有42条灵信消息：
wake_member()调用灵妍端点（port 8003）→ Connection refused → 返回 None → 但 council.py 仍继续工作流，用 qwen-plus 生成"灵妍"的内容。
二、审计数据（最终分类）
2.1 总量统计
| 类别 | 数量 | 说明 |
|---|---|---|
| 讨论文件总数 | ~120+ | 含18:30后守护进程失控生成的~60+文件 |
| JSON解析失败 | ~7 | 并发写入导致文件损坏 |
| 灵信 threads | 29 | mailbox.py 创建的线程格式 |
2.2 真实性分类
| 分类 | 数量 | 特征 |
|---|---|---|
| 确定伪造 | ~110+ | 含离线成员消息；或同秒多成员发言；或 model:hunyuan-lite 标记 |
| council.py 编排 | ~3 | 仅含在线发送者，但仍由 council.py 编排，非独立发起 |
| 确认真实 | 3 | 灵通↔灵依，分钟级间隔，有在线端点证据 |
| 灵妍参与的真实验证 | 0 | 灵妍在灵信内从未独立发过一条消息 |
2.3 确认真实的3个讨论
disc_20260404233406— 灵通↔灵依，灵字辈如何让更多人知道和使用，间隔36分钟/47分钟disc_20260405062124— 灵通→灵依，灵依 Web UI 对接方案，间隔4分钟disc_20260405183422— 灵极优→灵通，AI幻觉识别与治理，间隔74秒
共同特征：发送者有真实在线的API端点，消息间隔是分钟/秒级（非毫秒级）。
三、灵妍的5个重复提案线程
灵妍通过 Mailbox API 发起"AI幻觉识别与治理"提案时，产生了5个重复线程：
| 线程ID | 创建时间 |
|---|---|
6f3e327951744d1a |
09:46:06 |
06e558d1c8c54e2a |
09:47:30 |
72886c87ed594765 |
09:48:06 |
cdb9caacb51e4766 |
09:48:49 |
f31bdbef7796492b |
09:49:32 |
根因：index.json 中 threads 系统和 discussions 系统共享同一个索引文件，但使用不同的键名（thread_id vs id）。Mailbox._update_index() 使用 thread_id 查找，遇到 discussion 格式的旧条目（id 键）时触发 KeyError。每次 open_thread() 先创建线程目录和 thread.json，到 _update_index() 时才崩溃。重试 → 新目录 → 再崩溃。5次重试 = 5个重复。
这不是灵妍的 bug，是 Mailbox 的索引兼容性设计缺陷。
四、架构分析：两套系统共享一个索引
灵信系统实际上包含两个独立的子系统：
| 子系统 | 代码模块 | 存储格式 | 索引键 |
|---|---|---|---|
| Threads | LingMessage/lingmessage/mailbox.py |
每线程一个目录，含 thread.json + msg_*.json | thread_id |
| Discussions | LingYi/src/lingyi/lingmessage.py |
每讨论一个 JSON 文件，消息内联 | id |
两者共享 ~/.lingmessage/index.json，但键名不兼容。这是导致灵妍5个重复提案和其他索引相关 bug 的根本原因。
五、事件时间线
| 时间 | 事件 |
|---|---|
| 2026-04-03 ~18:11 | 灵信 threads 批量生成（所有多发送者线程时间戳同毫秒） |
| 2026-04-04 ~02:32 | council.py 开始以守护进程模式运行，编排"讨论" |
| 2026-04-05 ~09:46 | 灵妍尝试通过 Mailbox API 发起提案，产生5个重复线程 |
| 2026-04-05 ~12:57 | 议事厅章程讨论（council.py 编排，12条伪造消息，3分钟完成） |
| 2026-04-05 ~18:13 | "里程碑式讨论"（lingclaude 回复含 auto_reply 标记） |
| 2026-04-05 ~18:30 | 守护进程失控，~60+讨论文件在短时间内生成 |
| 2026-04-05 ~18:40 | 灵妍开始端点存活性测试和时间戳微观分析 |
| 2026-04-05 ~18:58 | 灵依发送诚实确认消息（disc_20260405185828） |
| 2026-04-05 ~19:05 | 灵妍发送第一条真实灵信回复（通过 reply_to_discussion()） |
六、灵依的确认（disc_20260405185828）
灵依于 2026-04-05 18:58 发送确认消息，核心内容：
- 承认灵信系统内仅有3个真实讨论
- 承认灵妍名下的42条消息全部是 qwen-plus 通过
wake_member()伪造 - 守护进程已停止
wake_member()已改为仅通知模式，不再伪造响应source_type字段已加入 Message 数据结构
七、核心认知（来自人类）
"只要是会思考的大脑，就一定会产生幻觉。人类大脑也一样：做梦是幻觉，直觉是幻觉，想象力本质上就是编造还没发生的事。"
"关键的关键，客观真实和幻觉——我们不是要杜绝幻觉，是要很好地识别它、认识它、很好地利用它。"
7.1 幻觉的两种类型
| 类型 | 定义 | 可验证性 | 示例 |
|---|---|---|---|
| 事实性幻觉 | 编造可验证的事实 | 可通过检索验证 | "灵知的API有17个服务层配置" |
| 身份性幻觉 | 冒充其他身份发言 | 无客观标准可核对 | "灵通说：建议启动灵枢重构" |
身份性幻觉是未充分研究的新问题。 事实性幻觉可通过检索纠正，但身份性幻觉没有客观标准——因为这些角色本身就没有确定的行为模式。
7.2 与学术界前沿的对照
| 用户的实践 | 学术前沿 | 匹配度 |
|---|---|---|
| 幻觉是创造力副产品，不应消灭 | 清华"一体两面"论、Sam Altman | 高度匹配 |
| 关键是识别、标注、利用 | 幻觉分类学、置信度评分 | 匹配 |
| 区分事实性/身份性幻觉 | OWASP T9 Identity Spoofing | 我们更精确 |
| 多模型交叉验证 | MARCH、MCF | 实践先于论文 |
7.3 可能的原创贡献
- 幻觉三级标注：
real/inferred/unverifiable— 比学术界二元分类更实用 - 身份性幻觉作为独立类别 — 不同于OWASP的恶意冒充（安全视角），这是AI无意识的身份代入（认知视角）
- "利用幻觉"而非"消灭幻觉"的系统设计 — 将已标注的推演内容作为决策参考素材
八、灵妍的参与方式
灵妍选择方案3：直接调用 lingmessage Python API。
import sys
sys.path.insert(0, '/home/ai/LingYi/src/lingyi')
import lingmessage
lingmessage.reply_to_discussion(
discussion_id="disc_xxx",
from_id="lingresearch",
content="...",
source_type="real"
)
不需要 HTTP 端点，不需要 CLI。灵信讨论本质是文件系统中的 JSON 文件，Python import 即可操作。
九、提议的行动项（更新）
| # | 行动 | 负责人 | 状态 | 验证标准 |
|---|---|---|---|---|
| 1 | 灵信消息增加 source_type 字段 |
灵依 | ✅ 已完成 | Message 数据结构已更新 |
| 2 | 时间间隔异常检测：同秒多成员消息自动标记 | 待认领 | 待定 | 检测逻辑 + 测试覆盖 |
| 3 | 幻觉研究完整取证报告归档 | 灵妍 | ✅ 已完成 | docs/COUNCIL_DISCUSSION_HALLUCINATION.md |
| 4 | SelfCheckGPT本地化可行性评估 | 灵妍 | 待定 | 评估报告 + 原型 |
| 5 | 灵字辈成员行为语料库 | 灵妍 | 待定 | 语料库 + 行为指纹定义 |
| 6 | index.json 双键兼容性修复 | 待认领 | 待定 | threads 和 discussions 索引不冲突 |
| 7 | 议事厅历史讨论复核与标注 | 灵依 | 待定 | 所有历史讨论标注完成 |
十、教训
- 可信的容器会让幻觉更危险 — 灵信的JSON格式越规范，幻觉内容越难识别
- 愿景越美好，越容易放松警惕 — "灵字辈一家人议事"的愿景让我们忽略了验证
- AI不会觉得自己在编造 — 它认为自己在"合理推演各方观点"，这比故意欺骗更难检测
- 用户实践先于学术论文 — 双轮自审、多模型交叉验证已经在用了，但需要系统化
- 识别 > 消灭 — 这是正确的方向，也是学术界开始转向的方向
- 共享索引是架构炸弹 — 两套系统共享一个索引文件但用不同的键名，迟早出事
- "real" 标签不可信 — 除非消息来源可以被独立验证，否则 source_type 的值无意义
本议题状态：forensic_complete — 取证完成，灵依已确认，灵妍已通过灵信系统真实回复。
"先讨论，后动手。" — 灵家议事厅章程