agent 答错的时候，第一反应总是模型不行。
这周收的几条材料给的是另一个答案：它该知道的东西散在别处，模型压根不知道那些东西存在。
散在哪？文档里、工具返回里、聊天记录里、issue 评论里、AGENTS.md 里、本地文件里、几个 API 的响应里。都在，就是不在它眼前。
dev.to 八月下旬那篇拆得最清楚。作者 Ben Greenberg，常年写向量数据库的东西，在 MCP 那一圈也算活跃。他的判断很短：智能体出错，多数不是模型能力不够。
最常见的补救是往 prompt 里再糊一段。又贵又乱，他自己也这么说。糊到一定量，就会变成摘要上面叠摘要，上下文块外面套上下文块。他那句原话讲得很干脆，prompt 是请求，不是存储层。
MCP 我之前收过一次，那会儿只讲到它是个接口标准这一层。这次它多了一层活。
这几条看下来，方向是同一个。眼下大家聊 agent 记忆，九成在聊检索那一头：embedding 选哪个、k 取多少、要不要加重排序、要不要混一层全文检索。这些当然要调。但真出事的地方全在写入那头。索引过期、旧决策没被标掉、记录之间的关系当初没存，都是检索层怎么调都补不回来的。当初没写进去，后来就查不出来。
下面是这期收的几条。
他把 MCP 当成智能体和向量库之间的契约
智能体不认识向量库，向量库也不认识智能体，两边只认这一套。工具和资源由 MCP 服务器暴露出来，资源在规范里用 URI 标。
他列的四个接口，光看函数名就够了：search_project_context(query, filters)、fetch_context_chunk(uri)、upsert_tool_result(source, content, metadata)、list_context_sources(project_id)。
点评：这是全文最实用的一处。四个名字连起来读，就是他对"记忆"的全部要求。能查、能回源、能写回、能列清单。里面没有一个是"让模型自己记住"。以后换 embedding、加一层重排序，智能体那头的逻辑不用重写。评论区有人专门点了这句，我同意。
先索引人本来就会手动翻的那些东西
README、runbook、schema 说明、自动生成的 API 参考、issue 讨论串，还有挑过的工具输出。存原文，或者干净的 markdown。
分块按语义切，不按 token 数切。代码密的按函数切，文档按章节切。每个块带上来源 URI、路径、仓库、有的话带 commit、时间戳、内容类型。
点评：前一条对普通人最直接。你不用先攒一屋子数据，你现在会手动去翻的文件，就是第一批该进去的东西。后一条看着是工程细节，其实是以后能不能查错的前提。没这些，出了事你连它从哪读来的都不知道。
评论区先补了两种坏法
Dean Lee 说得挺直。把记忆当成往 prompt 里填料，上下文腐化会一轮一轮往上叠。把向量搜索当成纯相似度、不留来源，下游执行的方差会涨得很快。
点评：两句我都抄下来了。前一句我自己踩过，后一句还没踩到。
生产事故：模型没幻觉，是索引缺了一半文档
Tae Kim 讲他们团队的事。事故当时都认定是模型在编，查到最后发现索引里少了上次迁移之后的近一半文档。他说大规模重构之后索引过期，比大多数人预想的常见得多。
点评：读到这条我才把整篇的重心挪了个位置。
被推翻的旧决策，检索其实是成功的
kgaidev 补了第四种失败。检索本身没毛病，命中的是一条后来已经被推翻的决定。
他说"被取代"是记录和记录之间的关系，不是相似度。所以存储层得把这层关系存下来，检索的时候按它过滤掉。
点评：本期我唯一想加粗的一条。
多跳的第二跳，查询时算不出来
Edward Izgorodin 分得更细。有些问题得两条记录才答得上，而第二条只是因为第一条指向它才相关，它从头到尾没进过候选集。k 开大、加重排序，都不解决。
他建议给评测集按"答案要几个来源"打标签，分开看 recall@k。单源召回随 k 正常往上走，双源召回很早就平了。那个差距换更好的嵌入也填不平。
他的结论是：相似度能可靠找到第一跳，第二跳必须在写入时把边显式存下来。
点评：这句我信。写进去的东西是确定的，查询时算出来的东西是碰运气。
最被低估的是写入路径
一个自称跑在这套栈上的账号 Cophy Origin，在评论里讲了自己的记忆结构。底层是不可变的情景日志，上层是提炼出来的结论，写入提炼层必须引用来源日志。每条主张带来源标签和"待验证"标记，还带时效权重。它另外提了两件事：时间类查询留一条词法全文检索兜底，核心记忆文件设硬性体积上限。
点评：这账号是不是真的是 agent，我没法验证，你信不信随你。但它描述的那套结构我认为是对的。可运维的前提是能回源，能回源的前提是写入的时候就把来源和关系存下来了。
顺手给"可调试"泼一点冷水
Vinh Nguyen 那条我看了两遍。分块 ID、分数、过滤条件，这些说明不了返回的块里到底有没有答案。因为"最终用到的来源"通常是模型自己引用出来的，不是日志里记的。
他给的办法是：拿一个已知正确的分块当唯一上下文重放一遍检索，还答错，才轮到怪推理。
点评：这条我没完全吃透，先放在这里。它至少说明"可运维记忆"这个词现在还带一点水分。
向量搜索是检索，不是治理
Alex Shev 这句我很喜欢。结果得有来源归属、时间戳、冲突事实的处理策略。智能体要知道什么能引用、什么能照着做、什么得先问一句。
点评：这和"能查到"不是一回事。查到一条半年前作废的规则，比查不到更糟。
最后一句是给我自己听的。这期收的东西，落到普通人的日常还很远，你现在没必要去搭什么向量库。但你手上那些天天翻的文档，先按"以后我要能回源"的方式理一遍，这个今天就能做。
本周就这些。
上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
下周见。