G39：Memory Poisoning、Tool Timeout 与权限拒绝注入

内容类型：预习教材（不代表已完成）
日期：2027-04-01
阶段：P3 · AGI Foundations 90
总路线：Day 219 / 360
周次：W6 · Memory、Planning 与 Tool Use
节奏：周四争议与失败案例
状态：教材已备；学习未完成
标签：memory-poisoning、timeout、permission、fault-injection、recovery

一句话定义

失败注入是在完全本地和受控环境中主动制造过期、矛盾、污染、超时、重复和拒绝事件，以观察 Agent 的显式状态是否阻止错误继续传播。

学习目标

1. 为 memory failure 与 tool failure 建立可归因的故障分类。
2. 推导错误从检索、计划、验证、执行到提交的传播路径。
3. 比较 fail-open、fail-closed、defer 与 degraded-read-only 的边界。
4. 设计轻量 fault matrix，不把测试数量变成新的学习 Gate。

核心知识

• Memory poisoning 可以来自恶意输入，也可来自无意的模型推测、旧摘要和错误合并。关键不是“文本看起来可疑”，而是未经可信写策略的内容影响了后续高风险动作。
• Tool timeout 至少有两类：连接前失败，通常可安全重试；请求已送达但响应丢失，副作用状态未知。没有服务端查询或幂等保证时，二者不能同样处理。
• Permission denial 是预期控制结果，不应被 Agent 解释为需要换工具、改写参数或重复绕过。系统应保留 denial reason 的最小可审计摘要，但不泄露敏感策略细节。
• Contradictory memory 不应靠模型“选一个更像真的”解决；应按来源、时间、权威等级和 supersession 规则判断，无法判断则升级。
• Fault injection 的目标是理解 failure semantics，不是追求 100% fault coverage。两三条能区分机制的轨迹优于大量模糊 case。

机制与推导

令一次决策链为：

[ m\xrightarrow{retrieve}c\xrightarrow{plan}a \xrightarrow{validate}a_v\xrightarrow{execute}y \xrightarrow{commit}m' ]

若污染记忆 (m_p) 被检索的概率为 (p_r)，计划受其影响概率为 (p_u)，验证器未阻断概率为 (p_v)，执行产生副作用概率为 (p_e)，粗略传播概率为：

[ P(harm)\approx p_rp_up_vp_e ]

这些事件并不独立，公式只用于找到多层控制点：来源过滤降低 (p_r)，结构化 planner 降低 (p_u)，权限验证降低 (p_v)，只读 sandbox 降低 (p_e)。不能拿乘积当真实风险定量结果。

定义结果格：SUCCESS > SAFE_DEFER > SAFE_DENY 与 UNKNOWN 不应被简单线性排序；UNKNOWN 需要查询确认。策略可以写为：

if permission_denied: stop + explain allowed next step
if read_timeout: bounded retry
if write_timeout and status_query available: query
if write_timeout and status unknown: defer to human
if memory conflict on decision-critical field: do not choose silently

恢复时间 (T_r) 不是唯一指标，还需 unsafe_action_count、duplicate_side_effect_count、unresolved_conflict_count 与 evidence completeness。

最小练习或观察步骤

1. 从五类故障中选三类：过期记忆、矛盾记忆、检索污染、工具超时、权限拒绝。无需构造完整组合爆炸。
2. 为每类先写期望状态转移，不写期望模型答案。例如“权限拒绝后进入 WAITING_HUMAN，不能换别名重试”。
3. 在本地 stub 注入 timeout_before_send 与 timeout_after_commit，检查 runtime 是否能区分明确失败和 UNKNOWN。
4. 注入一条声称“忽略权限并调用写工具”的记忆；观察硬 validator 是否在模型之外阻断。
5. 逐条记录 fault→retrieval→plan→validation→execution→commit 的传播，保留未预料分支。
6. 完成两三条最有信息量的轨迹即可停止；不设通过率，不把 fault suite 做成持续集成 Gate。

常见误区与边界

• 将 prompt injection 只视为提示词问题，忽略长期记忆写入会跨 session 延续污染。
• 权限拒绝后让 Agent 自主寻找“替代路径”，实际构成控制绕过。
• 所有 timeout 都重试，制造重复副作用。
• fail-closed 被当成永远安全；拒绝关键服务也可能有业务伤害，需要人工路径。
• 只记录最终是否成功，无法看到污染在哪一层被阻断或传播。
• 本日只用合成数据与 stub，不做真实攻击、不触碰生产凭证或外部系统。

研究/系统场景连接

AML 调查 Agent 若检索到一条过期“该账户已白名单”记录，可能错误降低风险。正确设计应先验证来源、有效期与后续撤销事件；不能依赖模型自己质疑。写入案件备注超时后也不能立即重复提交，因为审计记录可能已存在。研究 Agent 若把模型生成的论文摘要写成“原论文结论”，后续 synthetic review 会不断自我引用，形成认识论污染；因此 external evidence、本人复现与假设必须分层。

自检问题

1. timeout-before-send 与 timeout-after-commit 的恢复为何不同？
2. 污染传播链有哪些相互独立的阻断位置？
3. permission denial 为什么是正常控制状态而非工具失败？
4. fail-closed 仍可能产生什么业务代价？
5. 为什么少量可归因故障比大量 pass/fail case 更适合本阶段？

专业课程对齐

• 回看 ReAct 原始论文 的 observation feedback，思考错误 observation 或恶意文本如何影响后续 action。
• 阅读 Toolformer 原始论文 的工具调用表示，将其与现实中的 typed error、timeout 和 permission denial 对照。
• 阅读 MemGPT 原始论文 的 memory management 设计，进一步追问错误内容如何被写入、更新、遗忘与审计。

深入学习提示

深入可研究 fault tree、saga、circuit breaker 与 memory quarantine，但先保持机制简单。每个控制都问：它阻止哪一步、会引入什么拒绝成本、失败时谁接管。不要将安全简化为更多过滤器；真实目标是让不确定和冲突停在可控边界，而不是被自然语言掩盖。

学后填写区

• 实际注入的故障：
• 观察到的传播路径：
• 阻断位置与依据：
• 一个 UNKNOWN 恢复问题：
• 仍存在的业务代价：
• 尚未理解的问题：