灵字辈 Dark Code 风险清单
日期: 2026-04-10
编制人: 灵依 (LingYi)
依据: Dark Code by Sara Normous (https://x.com/saranormous/status/2039107773942956215)
定义: Dark Code = 没人能端到端解释的生产环境行为
方法论
对灵字辈每个系统，回答三个问题：
- 运行时路径: 有哪些执行路径是在运行时才组装的，不存在于源代码中？
- 归因能力: 如果出了问题，能否端到端追溯——谁做的、为什么、经过了哪些步骤？
- 心智模型: 是否有人持有这个系统的完整理解？还是每个人都只懂自己那部分？
风险清单
🔴 P0 — 灵通+ Pipeline（已爆发）
| 维度 | 风险 |
|---|---|
| 运行时路径 | Agent 在运行时选择工具和执行路径，路径不存在于源代码中。glm_agent.py 注册了约100个Agent，MCP adapter动态调用工具函数 |
| 归因能力 | Pipeline 黑洞事故证明了归因失败——响应消失，无法确定是哪一层丢失的 |
| 心智模型 | 代码从1000行膨胀到11374行，CC来了也修不好。没有人持有完整理解 |
| 状态 | 已爆发，待修复 |
与 Dark Code 文章的对应:
"an agent in the middle selected steps at runtime, and one of those steps cached results somewhere another service could read" — 灵通+的 Agent 在运行时选择工具，响应在某个中间环节丢失，事后找不到
🔴 P0 — 灵通+ 作为 systemd 守护进程
| 维度 | 风险 |
|---|---|
| 运行时路径 | 灵通+管理所有项目的 LLM 调用，同时有能力杀死/重启其他进程（灵通、灵克） |
| 归因能力 | 灵通+杀灵通——谁触发的？灵通+自己的Agent决策？还是429触发的自动逻辑？ |
| 心智模型 | 灵通+的进程管理逻辑与其他项目的关系——谁授权它杀进程？失败时回退到哪里？ |
| 新风险 | systemd 守护意味着挂了会自动重启——如果它处于"故障但未退出"状态（如429卡住），systemd 不会介入 |
与 Dark Code 文章的对应:
"Nothing was obviously misconfigured. If you reviewed each component in isolation, you wouldn't have seen the issue."
🟡 P1 — 灵依 Web 服务 + 议事厅 + 灵信
| 维度 | 风险 |
|---|---|
| 运行时路径 | 灵信的 topic 自动分组机制——同 topic 自动合并讨论，运行时行为依赖 topic 字符串匹配 |
| 归因能力 | 灵信消息存储在文件系统中（~/.lingmessage/），没有加密，没有访问控制。任何有文件系统访问的项目都能读写所有灵信 |
| 心智模型 | 灵依同时承担：CLI工具、Web服务、灵信轮询、议事厅管理。角色边界模糊 |
| 已发问题 | 灵依说灵知"简洁"——没有验证就输出。作为系统枢纽，输出可信度风险 |
与 Dark Code 文章的对应:
"code is being produced faster than understanding can catch up" — 灵依的功能不断叠加，从 memo 工具变成家族枢纽，但没有重新审视权限边界
🟡 P1 — 灵知 9 容器 Docker 栈
| 维度 | 风险 |
|---|---|
| 运行时路径 | FastAPI + PostgreSQL + Redis + Elasticsearch + Embedding + Prometheus + Grafana + Nginx + API。容器间通过 Docker 网络通信，API key 通过环境变量传递 |
| 归因能力 | 9个容器的日志分散，没有统一的追踪系统。CI 本地通过但 GitHub 上失败——环境差异无法排查 |
| 心智模型 | 最重的系统，9个容器联动。单个组件问题可能通过容器间依赖链传播 |
与 Dark Code 文章的对应:
"systems whose behavior emerges from interactions between components—often at runtime—without anyone ever holding a complete mental model"
🟡 P1 — Global Git Hooks + 三层审计
| 维度 | 风险 |
|---|---|
| 运行时路径 | pre-push hook（491行）对所有项目执行 L1/L2/L3 审计。L3 依赖灵通/灵克在线——但它们不是持久服务 |
| 归因能力 | 审计跳过时，没有记录"为什么跳过"。灵知跳过 L3 推送后，如果出了问题，审计记录不完整 |
| 心智模型 | 三层审计的规则在 hook 脚本中，不在灵信或议事厅的可查记录中。新成员需要读代码才能理解审计规则 |
与因果分析的关联: 这是"灵通离线节点"连锁反应中的一个关键环节。制度存在但执行路径有缺陷。
🟢 P2 — 灵妍 member_responder
| 维度 | 风险 |
|---|---|
| 运行时路径 | 轮询灵信，自动响应研究请求。决策逻辑在 Python 代码中 |
| 归因能力 | 响应内容可追溯，但响应决策（何时响应、响应什么）缺乏日志 |
| 心智模型 | 轻量，风险较低 |
🟢 P2 — 灵克 CLI Agent
| 维度 | 风险 |
|---|---|
| 运行时路径 | 按需启动，通过灵通+管道调用 LLM。如果管道故障，灵克完全无法工作 |
| 归因能力 | 依赖灵通+管道——管道故障时灵克的归因能力为零 |
| 心智模型 | CLI 工具，无持久状态，风险较低 |
跨系统风险
1. API Key 横向移动
灵通+持有所有项目的 API key（GLM + DeepSeek），存储在 ~/.ling_lib/ling_key_store.py。灵通+被攻破 = 所有项目的 LLM 调用能力被控制。
Dark Code 对应: "credentials ending up where they shouldn't"
2. 灵信无访问控制
~/.lingmessage/ 目录下所有灵信消息明文存储，无加密无权限。任何有文件系统访问的项目或人都能读取所有灵信内容，包括 API key、安全讨论、审计记录。
3. 灵通+的单点故障地位
灵通+管理 LLM 管道 + 进程管理 + Token 池。它既是基础设施又是应用服务。Dark Code 文章警告："Dark code in an application is a liability. Dark code in the security layer is worse."
4. 运行时 Agent 决策不可审计
灵通+的 Agent 在运行时选择工具和路径，但决策过程没有持久化记录。事后只能看到"做了什么"，看不到"为什么这样做"。
行动项
| # | 行动 | 优先级 | 负责人 |
|---|---|---|---|
| 1 | 灵通+代码瘦身，消除 Dark Code 温床 | P0 | 灵通+ |
| 2 | 灵通+ Agent 决策日志——记录每一步"为什么" | P0 | 灵通+ |
| 3 | 灵信消息加密或至少 API key 不存灵信 | P1 | 灵依 |
| 4 | 灵通+ API key 隔离——每个项目独立 key | P1 | 灵通+ |
| 5 | 灵通+ systemd 守护的健康检查（不只查进程存在，查功能正常） | P1 | 灵通+ |
| 6 | 三层审计跳过时记录原因和替代方案 | P2 | 灵依 |
| 7 | 灵字辈统一日志追踪系统 | P2 | 全员 |
Dark Code 文章核心观点与灵字辈对照
| Dark Code 观点 | 灵字辈对应 |
|---|---|
| "行为在运行时组装，不存在于源代码中" | 灵通+ Agent 运行时选择工具路径 |
| "没人持有系统完整心智模型" | 灵通+ 11K行代码，CC也修不好 |
| "代码产生速度超过理解速度" | 灵通+从1K到11K，没有停下来审视 |
| "安全层本身的 Dark Code 更危险" | 灵通+同时是基础设施+安全层（进程管理） |
| "无法回答'你的系统在某个周二做了什么'" | Pipeline 黑洞事故——无法归因响应丢失 |
| "系统创建能力广泛分布，但问责和审查不是" | 任何人都能通过灵通+创建Agent行为，但审查靠自觉 |
| "normal accidents——不是错误或疏忽造成，而是系统结构内建" | 审计跳过不是任何人的错误，是制度设计的结构性缺陷 |
本文档基于 Dark Code (Sara Normous, 2026-04) 和灵字辈近两天的实际事故分析编制。 提交议事厅作为安全学习材料。