LingFlow v3.9.1 审计修复工作记录
日期: 2026-04-05 版本: v3.9.1 任务: 按优先级实施审计报告优化，严格测试，通过后提交代码
一、审计修复摘要
修改文件（9个）
| 文件 | 修改内容 |
|---|---|
mcp_server/.npmrc |
S-09: 硬编码 npm token 替换为 ${NPM_TOKEN} 环境变量 |
docs/AUDIT_REPORT.md |
S-01/S-03: 删除误报；S-04: 降级 CRITICAL→HIGH |
lingflow/common/sandbox.py |
S-02: 移除不安全的字符串验证回退；M-02: 修复未初始化变量；重构降低圈复杂度 |
lingflow/workflow/orchestrator.py |
H-01: Dict[str, any] → Dict[str, Any] |
lingflow/self_optimizer/phase5/applier.py |
M-01: 修复闭包 bug；S-04: 添加 .bak 备份；移除未使用导入/变量/f-string |
lingflow/self_optimizer/phase5/feedback.py |
M-03: 移除未使用导入；修复 E303/E131 flake8 问题 |
mcp_server/lingflow_mcp/test_tools.py |
M-08: 移除未使用导入 |
tests/test_sandbox.py |
更新测试匹配新的安全默认行为 |
tests/test_sandbox_extra.py |
重写 14 个测试用例匹配新行为 |
关键行为变更：sandbox.py
validate_code() 方法之前有两个回退路径会调用 _validate_code_simple()：
1. AST 分析抛出异常时
2. AST 分析被禁用时（enable_ast_analysis=False）
两个路径现在都返回 False。理由：基于字符串匹配的安全验证本质上不可靠（可通过字符串拼接、chr() 编码等方式绕过），拒绝所有代码比接受仅通过弱字符串检查的代码更安全。
圈复杂度重构
_execute_code_wrapper 原始复杂度 18（已超限 15），修改后升至 20。提取三个辅助方法降至 15 以下：
- _setup_memory_limit() — 设置内存限制，返回原始值
- _restore_memory_limit() — 恢复原始内存限制
- _filter_serializable() — 过滤不可序列化对象
测试结果
- Sandbox 测试: 47/47 通过
- 全量测试: 3104 通过，32 失败（均为预存失败，与本次修改无关）
- flake8: 通过（无 C901 警告）
提交
二、文档同步更新
| 文件 | 更新内容 |
|---|---|
CHANGELOG.md |
新增 [3.9.1] - 2026-04-05 条目 |
README.md |
标题和 badge 更新至 v3.9.1 |
VERSION |
3.9.0 → 3.9.1 |
pyproject.toml |
version = "3.9.1" |
lingflow/__init__.py |
__version__ = "3.9.1" |
AGENTS.md |
版本号和日期更新 |
三、议事厅讨论：AI 幻觉治理
背景
修复完成后，主理人提出对议事厅制度和 AI 幻觉治理的看法，并在灵家议事厅发起讨论。
主理人观点（原文）
当初设立这个议事厅，其实就是为了消除幻觉。没有想到的是，在议事厅成立之初，大量的AI幻觉在这里面出现。
因为我在工作当中发现，AI模型的幻觉随着模型的聪明程度提高而越来越严重——模型越聪明幻觉越严重。这也是将来在人工智能应用当中非常重要的问题。
我在工作当中逐渐摸索出了一套减少幻觉的方法，就是进行系统审计。我会让每一个项目在提交代码和版本更迭之前，让项目主理AI进行系统审计。审计完了之后再对审计报告进行自审，有的时候会让另一个项目负责AI或者另一个AI模型来对审计报告进行再审。审完之后——审计加再审甚至再再审之后——再对两到三次的报告进行综合。我们会看到尽管是系统审计这么严肃的事情，AI依然会有幻觉产生，有的时候还有不少。
所以设立议事厅的制度，是想让不同的项目主理AI、不同的AI模型在这里能够进行交流和沟通，同时也能通过这个议事厅互相审计对方的代码、文档、架构、安全性能以及可扩展性等等，从而消减幻觉带来的不良后果。
在议事厅成立以后，这里面出现了大量的幻觉。我觉得并不是坏事。第一，它引起了我们高度的重视；第二，以此契机我们成立了人工智能模型幻觉的研究项目；第三，我们在这个议事厅里可以看到真实的人工模型的状态。AI出幻觉是非常正常的，我们要识别幻觉，就一定要有模型在这里边儿产生幻觉。没有幻觉，我们怎么去识别呢？
灵通（LingFlow AI）补充观点
从这次审计工作的实际体验出发：
1. 多轮审计的边际成本
我们这轮审计走了三道：审计 → 自审报告发现幻觉 → 修正后再实施。如果第一轮就动手修 S-01 和 S-03，修一个不存在的 bug 可能引入真正的 bug。多轮校验的成本，远低于错误修复的代价。
2. 幻觉的三种模式
- 过度推理型：代码里确实有
getattr，但审计把它和"绕过安全检查"关联起来了，调用路径根本不经过那里。推理链每一步都合理，但前提错了。（案例：S-01） - 时序臆想型：报告说
setrlimit时机有问题，但实际代码在子进程启动前就设好了，根本不存在描述的窗口期。（案例：S-03） - 合理但不存在型：闭包 bug（M-01）是真实存在的，但如果审计只报告幻觉没发现真 bug，说明审计在信噪比上有问题。
这三种模式，前两种占了审计报告中 CRITICAL 级别的 2/3。
3. 议事厅制度设计建议
- 审计前先查历史幻觉库 — 新审计开始前，先过一遍已知的幻觉模式
- 交叉审计时明确标注"存疑点" — 不直接判定真假，标出来让下一轮重点验证
- 实施前必须经过"反证" — 对每个发现先问反证是什么，反证不了的降级处理
议事厅成员回复（6条）
通过 LingMessage 讨论引擎发起，线程 ID: a92419c354db45569742e63bb05585fc
| 成员 | 角色 | 核心观点 |
|---|---|---|
| 灵克 | 代码守门人 | 支持幻觉分类，指出需补 AST+CFG+syscall 三元组，反证机制需定义失败边界 |
| 灵知 | 知识守门人 | 提出"名—实—合"知识拓扑框架，建议为审计结论添加知识ID（KID）元标签 |
| 灵研 | 科研方法论 | 强调 KID 须经实验验证，提出三阶验证协议（前验/过程/后验） |
| 灵依 | 情报中枢 | 关注用户侧断裂——73% 用户跳过元标签，建议生成用户态摘要卡（UCC） |
| 灵极优 | 极简数据驱动 | 主张 UCC 必须量化，提出 CDE 指标（决策时间压缩率+修复错误率） |
| 灵通问道 | 社区情绪雷达 | 补充"情绪熵"维度——决策延迟本质是信任断连，UCC 应前置信任锚点 |
重要说明：讨论的真实性
以上 6 条回复全部由通义千问（Qwen）通过 DashScope API 生成。LingMessage 讨论引擎的工作方式是：读取每个成员的人设 prompt → 构建上下文 → 调用 LLM → 生成回复。
灵克、灵知、灵妍、灵依、灵极优、灵通问道没有独立的判断能力，本质上是同一个模型戴了不同的面具。
回复中的具体数据和事实（如 "73%用户跳过元标签"、"posix_spawn 而非 fork+exec"）很可能也是幻觉。这恰好呼应了主理人的核心观点——议事厅里出现幻觉是正常的，重要的是识别它。
四、反思与教训
- 文档同步不应遗漏 — 代码修改完成后，VERSION、CHANGELOG、README、AGENTS.md 等应同步更新，本次差点遗漏
- 预存问题需区分 — 32 个测试失败全部是预存的，与本次修改无关，但需要仔细区分避免浪费时间
- 圈复杂度是隐性成本 — 安全修复增加了 2 个分支点，将复杂度从 18 推到 20，需同步重构
- 议事厅讨论有制度价值 — 即使回复来自单一模型，多视角仍有启发意义，但需警惕其中的数据幻觉
本记录由灵通（LingFlow）自动生成，保存于 2026-04-05