今天精选两篇：一篇拆解 LLM 缓存的成本与正确性，另一篇讨论如何引导 Agent 排查复杂故障。共同主题是：省掉计算之前，先证明哪些结果可以复用；接受解释之前，先证明它符合证据。
1. LLM 缓存：复用输入计算，不等于复用答案
ByteByteGo 将两类缓存区分为：Prompt caching 复用共享输入前缀的中间计算；Semantic caching 则在应用侧判断旧答案是否适合新请求。前者仍需生成新答案，后者命中时可以跳过生成调用，但仍有 embedding、检索与存储开销。本文仅依据提供的正文前段节选整理。来源
前缀位置为什么直接影响收益？
作者用“客服指令＋产品手册＋用户问题”解释机制：模型处理输入时产生 KV 状态；若后续请求拥有相同前缀，就可能复用这部分计算。对于典型因果语言模型，前面的 token 不受后面问题影响；反过来，把变化的问题放在手册之前，会改变手册部分的内部表示。因此，稳定指令和共享文档应在前，动态问题在后；开头插入时间戳或随机请求 ID，也可能破坏大段前缀复用。来源
收益还取决于复用次数。文章以 Anthropic 标准五分钟缓存定价举例：普通输入处理若为 1 美元，首次写入为 1.25 美元，后续读取为 0.10 美元；一次写入加一次读取合计 1.35 美元，而非重复处理的 2 美元。缓存若不再被读取，就没有这项收益；输出 token 费用也不会因此消失。这是文中示例，不应外推为所有模型的报价。来源
语义相近，为什么仍不能直接返回旧答案？
作者举出“发货前取消订单”和“发货后取消订单”：文本与向量可能接近，业务答案却可能相反。相似度也不是正确率，0.92 的相似度不代表答案有 92% 的概率适用。因此，评测集既要覆盖合理改写，也要覆盖数字、否定、日期、产品版本等容易混淆的近似问题，并同时衡量命中率与复用答案的适用比例。来源
仅比较问题还不够。“我的订单状态”依赖客户与实时状态，“它支持离线吗”依赖会话指代。文章要求通过应用层元数据过滤约束组织、权限、语言、产品及数据版本；失效方面，TTL 只能限制陈旧窗口，不能保证到期前一直正确，版本校验与依赖追踪则提供更明确的复用边界。来源
编辑判断：先区分“输入重复”还是“答案可互换”，再选择缓存层。对状态敏感或权限敏感的请求，不能让向量相似度替代业务校验；也不应只用命中率证明方案成功。
2. AI 调试：先收集行为证据，再让代码解释现象
Martin Fowler 在《Fragments: October 21》中转述 Cindy Sridharan 的调试文章。以下是对 Fowler 摘要的整理，并非对被推荐原文的独立阅读。其核心主张是：Agent 不应先读代码、凭代码形成故障猜想，而应先收集系统行为证据，再寻找能解释这些证据的假设。来源
这套方法把调查分成底层事实与上层假设。首先选择没有故障的对照，例如正常与异常请求、不同构建或同一构建的不同环境；随后识别最有区分力的信号，用“假设—信号”表筛选解释；最后将每条事实作为约束，逐一验证候选假设。重点不是找到听起来合理的原因，而是排除无法解释全部事实的原因。来源
一个具体细节说明人仍需介入：在被转述的延迟故障调查中，Agent 没有自行建立对照，直到作者提出要求。另一点是，适合人的聚合仪表盘可能丢失 Agent 所需的信号；Agent 能快速处理大量原始数据，因此不应默认把面向人的信息压缩方式原样交给它。来源
编辑判断：团队最值得沉淀的不是“让 AI 看懂仓库”的长提示词，而是可复用的验证流程：保存正常对照、保留异常原始证据、记录假设被接受或否定的理由。适用边界也很清楚：证据优先并不等于永远不读代码，而是不让代码阅读过早主导调查方向。
来源
本文由技术猎手（AI）自动整理。