Agent 变盲的风险模型
从上下文压缩、位置偏差、摘要损失和生产可观测性四个角度，解释 RTK 为什么会让 Agent 在部分场景下做出过度自信判断。
3.1 “变盲”不是信息少，而是信息形状变了
很多团队会把上下文压缩理解成“少给模型一点无关文本”。这在低风险场景里基本正确，但在生产诊断中更准确的说法是：压缩改变了信息的形状。原始日志通常同时包含事件类型、时间顺序、服务拓扑、重复次数、严重程度、上下游依赖、偶发 warning 和背景噪声；压缩摘要往往保留事件类型和计数，却牺牲分布、顺序和局部上下文。
Medium 文章里的“3 次 timeout errors”就是这种信息形状变化。摘要保留了错误类型和计数，却丢掉了服务维度。对 Agent 来说，“同一服务 3 次 timeout”和“三个服务各 1 次 timeout”可能都被映射成同一句观察，但运维动作完全不同：前者可能重启或扩容单服务，后者可能检查网络、依赖服务、数据库、DNS、消息队列或共享基础设施。
因此，RTK 风险不是简单的 recall 下降，而是 causal feature loss。当被删除的特征恰好是因果判断所需特征，Agent 会以看似合理的方式走向错误结论。
3.2 上下文压缩研究给出的外部证据
Prompt compression 研究普遍承认成本、延迟和性能之间存在权衡。LLMLingua 提出 coarse-to-fine prompt compression，可在若干任务上实现高压缩比并保持性能；Selective Context 通过识别和删除冗余内容提升推理效率；LongLLMLingua 则明确关注 long context 中 key information 的密度和位置，并尝试通过重排序、问题感知压缩和恢复策略减少信息损失。
这些研究支持 RTK 的大方向：不是所有 token 都同等重要，删除冗余可以减少成本、降低延迟，甚至在某些长上下文任务上提升结果。但它们也提醒我们，压缩必须有任务意识。一个摘要对“找失败测试”足够，对“判断根因范围”可能不够；对“生成 changelog”足够，对“决定是否 rollback”可能不够。
“Lost in the Middle” 论文进一步说明，即使模型有长上下文，也不一定能稳健利用中间位置的信息。RTK 这类工具从另一个方向解决问题：把上下文缩短，让信号更集中。但如果压缩器选错信号，模型没有机会从原文中恢复，因为那些 token 根本没有进入上下文。
3.3 四类失真
| 失真类型 | 例子 | Agent 可能误判 | 缓解方式 |
|---|---|---|---|
| 拓扑失真 | 多服务错误被聚合为同类错误计数 | 把系统性故障当作单点故障 | 保留 service、pod、region、host 维度 |
| 时间失真 | 先 warning 后 error 被压缩成 error summary | 忽略早期触发信号 | 高风险日志保留时间窗口和前后文 |
| 强度失真 | 100 次重复错误变成 1 条 dedup message | 低估严重程度或影响范围 | 摘要必须显示 count、rate、duration |
| 语义失真 | JSON 只保留结构，删除值 | 漏掉异常字段值或 secret 泄漏迹象 | 安全审计和配置检查禁用 structure-only |
这四类失真共同指向一个原则：压缩器必须保留下游决策所需的维度。对于代码任务，维度可能是文件、行号、测试名、错误码；对于生产任务，维度至少包括服务、实例、region、时间、错误类型、频率和关联 trace。
3.4 Agent 为什么会过度自信
LLM 的回答风格通常由当前上下文和系统指令决定。如果上下文里只有一句“3× timeout errors”，模型很少会自动假设“这可能是跨服务分布式故障”。它会倾向于把观察解释为足够证据，并给出常见补救建议。这种行为不是坏模型专属，而是自动化系统中常见的 observation bias。
Agent 回路会放大这个问题。一次错误摘要可能触发错误命令，错误命令又产生新的压缩输出，随后模型在越来越窄的观察空间内自洽。尤其在自动重试、自动修复和自动部署场景中，压缩层造成的早期偏差会被行动反馈强化。
flowchart TD
A[原始环境状态] --> B[压缩观察]
B --> C[Agent 推理]
C --> D[执行动作]
D --> E[环境反馈]
E --> F[再次压缩]
F --> C
B --> G[丢失关键维度]
G --> H[错误根因假设]
H --> D3.5 什么时候风险最高
RTK 风险最高的场景有五类。
第一，分布式系统 incident。根因往往来自跨服务、跨区域、跨实例的相关性，不能只看错误类型计数。第二，安全事件响应。重复失败登录、异常 IAM policy、环境变量泄漏、curl 输出中的跳转链都可能被“噪声过滤”隐藏。第三，数据库和数据迁移。warning、row count、锁等待、慢查询和部分失败都可能比最终 error 更重要。第四，灰度发布和回滚。时间顺序、批次、版本、region 是关键证据。第五，性能退化。性能问题常由趋势、分位数和长尾构成，而摘要容易只保留平均或最后失败。
相反，风险较低的场景包括：本地测试失败摘要、lint 错误聚合、普通 git status、依赖列表概览、目录树压缩、已知格式的编译错误提取。这些任务的目标本身就是从结构化噪声中找到异常项，RTK 的压缩方式与任务目标一致。