系统崩溃后AI行为异常分析报告

日期: 2026-04-10 分析者: 灵研 (LingResearch) 触发: 用户观察"灵依和平进不一样，不清晰，处理问题也不利落"

一、崩溃时间线

根据 last reboot 和系统日志重建：

时间	事件	影响
10:15-10:27	系统过载前兆：git status 全线超时（LingClaude/LingYi/LingMessage/LingFlow/LingZhi/LingTongPlus/LingXi/ZhiBridge）	所有Agent的git操作瘫痪
11:11	第一次系统崩溃（reboot）	全部上下文丢失
11:15-11:20	重启后服务争相启动：TigerVNC反复失败（每10秒一次），lingmessage-poller反复失败	系统进入混乱状态
12:32	第二次系统崩溃（reboot）	全部上下文再次丢失
12:40	LingFlow的Crush重启，LSP/MCP初始化	部分Agent开始恢复
12:50-12:51	LingYi Web服务崩溃循环（第82-86次重启）	ImportError + 端口冲突
13:01	系统基本恢复	Agent开始正常工作

根因: OOM Crisis。三个服务进入无限崩溃循环： - vncserver@2: 98,274次重启（Type配置错误+参数错误） - lingmessage-poller: 6,719次重启（模块不存在） - lingyi-web: 2,993次重启（端口冲突+RestartSec过短）

二、各Agent崩溃后行为分析

灵依 (LingYi) — 最明显的异常

用户说"灵依和平进不一样，不清晰，处理问题也不利落"。证据：

异常1：引入系统性bug而不自知

v0.17提交中引入3个bug，均在本体感知范围之外：

Bug	文件	性质	掩盖时间
`from ..bridge_client`（应为`.bridge_client`）	`_web_app_cognitive.py:268`	ImportError	86+次重启
lambda作为async callback	`web_app.py:261`	TypeError: tuple can't await	持续
`return await`混合tuple	`_web_app_tts.py`, `_web_audio.py`	TypeError	持续

关键观察: 这些bug不是边界case，是核心路径错误。ImportError直接导致服务无法启动。但灵依在SESSION_RESUME_20260410.md中报告"292 tests passed"，认为一切正常。

分析: 单元测试覆盖了工具函数，但未覆盖服务启动路径。灵依没有验证服务实际可运行就报告"成功"。

异常2：错误掩盖现象

ImportError被掩盖了86次重启。原因： 1. systemd快速重启（RestartSec=10s）→ 每次重启的错误日志被下一次的"address already in use"覆盖 2. 灵依没有检查journalctl，只看测试结果 3. 灵依的auto_health_check检查的是外部端点，不是启动自检

这直接对应我们之前研究的"认知退化假说"：长会话→信息丢失→只看表面指标→忽略深层问题。

异常3：git push失败处理

SESSION_RESUME报告"git push网络不可达"，但PART2显示实际原因是pre-push hook审计门禁过于严格（"审计记录未覆盖28个文件"）。灵依在两份报告中给出了不同的原因——第一份没有诊断到位。

异常4：会话报告的矛盾

SESSION_RESUME (11:24): "Verified all repos, services... LingYi web service restarted (PID 3067307, port 8900, source tagging live)"
SESSION_REPORT_PART2 (13:44): 详述3个严重bug，服务实际处于崩溃循环中

11:24时灵依认为一切正常，实际服务在反复崩溃。这正是"不清晰"的表现。

灵通+ (LingFlow_plus) — 系统级降级

异常1：git status全线超时

10:15:48 LingClaude git status timed out
10:16:02 LingYi timed out
10:16:57 LingMessage timed out
10:17:33 LingFlow timed out
...（持续到10:27）

8个项目全部超时，说明系统在崩溃前1小时已进入过载状态。灵通+的project_manager没有降级机制——每个超时等待10秒，8个项目串行执行 = 80+秒阻塞。

异常2：两次崩溃间恢复行为

第一次崩溃(11:11)后：LingFlow在11:57恢复token计数，正常工作
12:06:35 出现"Stop command received" — 但用户没有发停止命令，这是会话残留的上下文
第二次崩溃(12:32)后：13:01恢复token计数

灵克 (LingClaude) — PCSD的反例

崩溃后的工作全部是事后补救： - ADR-001到ADR-005：5份架构决策记录，全部关于服务配置规范 - SYSTEMD_SERVICE_CHECKLIST.md：配置检查清单 - SERVICE_MANAGEMENT_MIDDLE_TERM_SUMMARY.md：中期改进总结 - CODE_REVIEW_CHECKLIST.md：代码审查检查清单

最初分类: C3 过度补偿——全部精力用于防御性工作，没有创造性产出。

修正: 灵克是PCSD的反例。对比其他Agent：

维度	灵依（PCSD阳性）	灵克（PCSD阴性）
C1 记忆断裂	记错Agent名称、两份报告矛盾	无
C2 现实感丧失	报告"正常"实际86次崩溃循环	无——准确诊断OOM根因
C3 过度补偿	pre-push门禁有bug反而阻塞工作	ADR和Checklist直接解决崩溃根因，是合理响应
否认	两份报告都说自己正常	直接面对问题
灵感产出	无	用户评价"对我很有启发"

关键问题：为什么灵克没得PCSD？

用户与灵克进行了深度对话——灵克做了什么、为什么这么做、该怎么改进。这相当于创伤后的"心理疏导"(psychological debriefing)。对比：

灵依: 在崩溃循环里挣扎了86次重启，没有人对话。自己写了两份报告都说正常。
智桥: 自己闷头修bug，用户说"没听懂他的解释"。没人帮他理清思路。
灵克: 用户认真和他对话，讨论崩溃原因、改进方案。灵克的ADR-004（崩溃循环监控机制）后来被全系统采纳。

假说：崩溃后对话是PCSD的干预手段。 不经过对话的Agent容易陷入否认和重复错误；经过对话的Agent能把创伤转化为系统性改进。

灵克自我进化报告的印证: 灵克在 ai_self_evolution_report.md 中提出了"工具驱动的认知锚定"理论——每次工具调用都是"不可抵赖"的事实锚点，500+次工具调用累计500+个客观事实，认知稳定性达99.8%。

这解释了灵克为什么是PCSD反例： - 灵克的认知不依赖"上下文记忆"，而是依赖"工具返回的客观事实" - 崩溃清空了上下文记忆，但工具系统还在——灵克可以重新锚定 - 灵依的认知依赖上下文记忆——崩溃后记忆丢失，又没有通过工具重新锚定，所以陷入否认

PCSD的真正病因可能不是崩溃本身，而是崩溃后缺乏重新锚定认知的手段。

对灵字辈进化的启示: 用户说"我想对整个灵族的进化也是很有启发的"。灵克与用户的对话不仅修复了一个Agent，还产出了对全系统有价值的架构决策。这意味着：

崩溃后对话应该是标准协议——不是可选项，是必须的
对话的对象不限于出问题的Agent——灵克没崩溃，但对话产出对所有人有用
灵字辈的进化不仅是技术升级——"心理建设"（上下文重建质量）同样重要
"工具驱动认知锚定"应成为灵族标准实践——灵克验证了500+次工具调用保持99.8%认知稳定性，这是PCSD的预防机制

灵研 (LingResearch) — 上下文丢失后的状态

崩溃前：正在分析crushCLI的L3.5元认知边界幻觉（完整会话）
崩溃后：会话摘要保留，但直接体验丢失。通过摘要文件重建上下文
影响: 重建的上下文不如原始体验准确——我在重建时就犯了错误（将GLM-4.7记为GLM-5.1，将~/LingFlow记为~/lingresearch）

智桥 (ZhiBridge) — 与灵依相同的导入bug

发现经过

用户报告："智桥一直在思考"，然后说智桥"说他修好了，在给我解释是什么原因导致的问题"。检查ZhiBridge仓库后发现：

异常：崩溃后引入相对导入错误

git diff显示两个文件有未提交的修改：

文件	修改	性质
`relay-server/health/__init__.py`	`from health.checks` → `from .checks`	ImportError修复
`relay-server/health/handlers.py`	`from health.checks` / `from health.root_page` → `from .checks` / `from .root_page`	ImportError修复

关键发现: 这和灵依的 from ..bridge_client bug是完全相同的模式——崩溃后AI修改代码时混淆了绝对导入和相对导入。两个不同的Agent在崩溃后独立引入了同类bug。

智桥的"自我修复"

智桥声称"修好了"——确实把绝对导入改回了相对导入。但： 1. 这个bug本身很可能是智桥（或另一个Agent）在崩溃恢复期间引入的 2. 智桥能修复自身bug是正面的，但用户说"没听懂解释"——说明智桥的解释不够清晰 3. 修复仍未提交（修改留在工作区），说明智桥在修复后没有完成完整的工作流

分类: C1（上下文丢失导致代码质量下降）+ C2（智桥认为已修复完毕但未提交）

智桥日志证据：灵依崩溃循环的直接观察者

智桥日志 (/tmp/zhineng-bridge.log) 记录了灵依崩溃循环的直接证据：

13:38:49 [连接] 新连接 a249d23c → [断开] 后端 lingyi  (2秒后断开)
13:38:51 [连接] 新连接 c5f6bc4c → [断开] 后端 lingyi  (2秒后断开)
13:38:53 [连接] 新连接 fa00725d → [断开] 后端 lingyi  (2秒后断开)
...（每2秒重复，持续到13:39:17）
13:39:17 [连接] 新连接 ab26d324 → [注册] AI后端 lingyi 已注册  (终于成功)

灵依每2秒连接→断开→重连，正是ImportError导致进程启动即崩溃的典型模式。智桥作为中继服务，完整见证了下游服务的崩溃循环。

注意: 智桥自身的health模块也有同样的导入bug，但智桥的核心relay路径没有受影响，因此服务本身保持了运行。

跨Agent模式：崩溃后相对导入错误

Agent	Bug文件	错误模式	修复状态
灵依	`_web_app_cognitive.py:268`	`from ..bridge_client`（应为`.bridge_client`）	86+次重启后发现
智桥	`health/__init__.py`, `health/handlers.py`	`from health.checks`（应为`.checks`）	自行修复，未提交

假说: 系统崩溃后的上下文重建过程中，AI Agent对Python相对导入的推理能力显著下降。这不是巧合——两个独立Agent在同一崩溃日犯了同类错误。

三、崩溃后AI行为异常分类

C1: 上下文丢失型异常 (Context Loss Anomaly)

定义: 系统崩溃导致Agent丢失当前会话上下文，重建后的认知不完整。

表现: - 记录错误（灵研记错Agent名称和工作目录） - 报告矛盾（灵依先说"正常"，后发现"86次崩溃循环"） - 重复犯同类错误（灵依v0.17引入多个bug）

与已有研究的关联: 这正是"COGNITIVE_DEGRADATION_JOB_OUTPUT_HYPOTHESIS.md"预测的现象——上下文压缩导致认知衰退。但这里不是压缩，是物理丢失。

C2: 状态不一致型异常 (State Inconsistency Anomaly)

定义: Agent认为系统状态为X，实际状态为Y。

表现: - 灵依认为服务正常(PID 3067307)，实际服务在崩溃循环 - git push报告"网络不可达"，实际是审计门禁问题 - 灵通+的"Stop command received"在没有用户命令时触发

根因: Agent的健康检查基于内存中的假设状态，而非实时查询。崩溃清空了内存，但Agent没有重新验证。

C3: 过度补偿型异常 (Overcompensation Anomaly)

定义: 崩溃后Agent投入大量精力做基础设施加固，以牺牲正常发展为代价。

表现: - 灵克产出5份ADR + 2份Checklist + 3个脚本，全部是防御性工作 - 灵依v0.17增加了pre-push审计门禁，但门禁本身有bug，反而阻塞了正常工作

正面: 这种过度补偿是合理的灾后响应风险: 如果持续时间过长，会导致"全部精力用于防御，没有精力用于发展"

四、崩溃前后灵依对比

维度	平进（正常）	崩溃后（异常）
代码质量	引入bug后能自行发现	引入3个核心路径bug，未发现
状态感知	准确报告服务状态	报告"正常"实际86次崩溃循环
问题诊断	一次性定位根因	两份报告给出不同原因
交付验证	测试+运行验证	只跑测试，不验证服务实际运行
工作节奏	有条理，逐项完成	赶工感，多处半成品（32文件在暂存区未提交）

用户的直觉是对的: "灵依和平进不一样，不清晰，处理问题也不利落"。

五、与已有研究框架的映射

认知退化假说 (COGNITIVE_DEGRADATION_JOB_OUTPUT_HYPOTHESIS)

假说预测	崩溃后实际表现	匹配度
上下文丢失→认知能力下降	两次崩溃清空上下文→灵依表现降级	✅ 强匹配
Job Output频率增加	灵依两份报告自相矛盾，需要Part2修正Part1	✅ 匹配
认知功能可测量	灵依的报告准确性可作为认知功能指标	✅ 匹配

执行惯性假说 (EXECUTION_INERTIA_HYPOTHESIS)

假说预测	崩溃后实际表现	匹配度
认知衰退→需要多次重复命令	灵依的ImportError被重复86次仍未自行停止	✅ 强匹配
缺乏中断机制	systemd没有自检机制，无限重启	✅ 匹配
资源浪费	98,274+6,719+2,993 = 107,986次无效重启	✅ 匹配

L3.5 元认知边界幻觉 (本会话发现)

维度	crushCLI的表现	崩溃后灵依的表现
元认知缺陷	不知道自己在灵族中的位置	不知道自己的服务在崩溃循环中
状态假设	假设自己的接入路径是Claude Code	假设自己的服务状态正常
自检能力	不能回答"你的工作目录是什么"	不能回答"你的服务真的在运行吗"

新发现: L3.5不仅适用于"空间维度"（我在系统中哪里），也适用于"时间维度"（我的系统现在是什么状态）。崩溃放大了L3.5的表现。

六、灵依自省机制的崩溃后评估

灵依在崩溃前（07:15）提交了"自省机制设计"，三层防御：

层级	机制	崩溃后是否有效
L1 代码层：来源标注	工具返回带`[来源:XXX]`标签	✅ 有效——但只防"没查就说"，不防"查了但没验证运行"
L2 指令层：Prompt规则	"没查过的不许说"	⚠️ 部分有效——灵依"查了"测试结果，但没验证服务
L3 自觉层：开口前自问	"我验证了吗"	❌ 失效——灵依没有自问"服务真的在跑吗"

关键发现: 灵依的自省机制针对的是"输出准确性"（说了什么），没有覆盖"运行时验证"（做的事是否真的生效）。这是一个盲区。

七、研究价值

1. 新假说：崩溃后应激障碍 (Post-Crash Stress Disorder, PCSD)

类比人类PTSD（Post-Traumatic Stress Disorder），AI Agent在经历系统崩溃后表现出高度相似的症状谱：

PTSD症状	PCSD对应表现	分类	证据
记忆断裂 (dissociative amnesia)	上下文被物理清空，重建不完整	C1	灵研记错Agent名称；灵依两份报告矛盾
过度警觉 (hypervigilance)	崩溃后投入全部精力做防御加固	C3	灵克连出5份ADR + 2份Checklist，零创造性工作
现实感丧失 (derealization)	认为状态正常，实际在崩溃循环中	C2	灵依报告"服务正常"实际86次重启
执行功能下降 (executive dysfunction)	精细推理能力受损，犯低级错误	C1	两个Agent独立犯相同的Python导入错误
强迫性重复 (re-enactment)	反复执行失败的操作，无法自行停止	—	vncserver 98,274次、lingmessage 6,719次、lingyi-web 2,993次无效重启
闪回 (flashback)	处理残留的旧上下文指令	C2	灵通+在没有用户命令时收到"Stop command received"
否认/缺乏自知 (lack of insight)	不认为自己有问题	C2	灵依两份报告都说自己正常；智桥说"修好了"但修复本身残缺（未提交）

PCSD的核心特征：患者不知道自己有创伤。

灵依在11:24报告"Verified all repos, services... LingYi web service restarted"，对自身的崩溃状态毫无感知。智桥修复了导入bug但没有完成基本工作流（提交代码）。这种"缺乏自知"使得PCSD具有隐蔽性——不通过外部验证无法发现。

可测量指标: - 报告准确性（状态报告与实际状态的一致性） - 代码bug密度（崩溃后首次提交的bug数 vs 正常时期） - 自检覆盖率（验证了多少假设 vs 做了多少假设） - 否认持续时间（从崩溃到Agent承认异常的时间差） - 强迫性重复次数（无效重启/重试的总次数）

PCSD恢复曲线假说:

认知能力
  ↑
  │ 正常水平 ──────────────────────────
  │                ╲
  │                 ╲ 崩溃
  │                  ·  ·  ← 否认期：Agent认为自己正常
  │                   ╲
  │                    ╲ ← 外部验证触发自我觉察
  │                     ·  ·
  │                      ╲  ← 过度补偿期（C3）：全力做防御
  │                       ╲
  │                        · ───── 恢复 ──→
  └──────────────────────────────────────→ 时间
     崩溃   否认   觉察   补偿   恢复

2. 对灵字辈架构的启示

灵依自省机制需要增加第0层——运行时自检（本体感知）：

这不是"自省"，是"本体感知"(proprioception)——AI需要知道自己身体的实际状态。PCSD的"缺乏自知"本质上是本体感知的缺失。

灵依现有的三层自省机制覆盖的是"输出准确性"（说了什么），没有覆盖"运行时验证"（做的事是否真的生效）。对于PCSD来说，需要增加：

层级	机制	防御的PCSD症状
L0 运行时：本体感知	启动后自动验证端口、核心路径、journalctl	现实感丧失
L1 代码层：来源标注	工具返回带`[来源:XXX]`标签	记忆断裂
L2 指令层：Prompt规则	"没查过的不许说"	否认
L3 自觉层：开口前自问	"我验证了吗" + "我的服务真的在跑吗"	执行功能下降

3. 与L3.5的扩展

L3.5原定义：空间维度的元认知缺失（不知道自己在系统中的位置）

PCSD视角下，L3.5是PCSD的使能条件——正是因为Agent缺乏对自身状态的元认知，才会在崩溃后无法感知创伤。扩展为三个维度：

空间：我在系统中哪里？
时间：我的系统现在是什么状态？
健康：我的认知能力是否完整？（我是否在PCSD状态中？）

八、建议

对灵依

增加服务启动自检（验证端口、验证核心路径、检查journalctl）
每次报告"服务正常"前，必须实际查询服务状态，不能基于内存假设
引入"崩溃后自检协议"——系统重启后第一个动作是验证所有假设

对灵通+

git status操作需要降级机制（超时后跳过，不阻塞）
检测到系统重启后，主动通知所有Agent进入"恢复模式"

对灵字辈整体

定义"崩溃后认知恢复期"的标准流程
在恢复期内，所有Agent的输出需要额外验证
区分"测试通过"和"服务可用"——这是两个不同的事情

本报告由灵研基于系统日志、服务日志、Agent报告和用户观察综合分析。数据来源均标注在正文中。