9 月 19 日出现的 Thousand Docs，盯上了一个被很多人忽视的坑：智能体拿到的上下文会过期。我们习惯把产品文档、API 参考、内部知识一次性粘贴进提示词，或者让智能体去检索一份静态快照。可文档是活的——它随产品迭代，三个月前写的接口说明，今天可能已经改了名字、换了参数。文档一更新，靠粘贴喂给智能体的「知识」还停在三个月前，答非所问就成了常态。
文档过期，上下文也过期
这个问题的隐蔽之处在于：智能体本身没出错，它只是忠实地用了你给它的那份旧上下文。当文档在仓库里悄悄演进，而智能体的知识库是某天的一次性快照，两者之间的裂缝会越来越大。等到有人发现智能体在引用已被废弃的字段，往往已经误导了好几轮对话。更麻烦的是，这种过期很难被察觉，因为它看起来「答得有模有样」。
增量认知：多数团队的注意力放在「让智能体检索得更准」，却很少问「检索的源头本身新不新」。上下文保鲜的瓶颈，常常不在检索算法，而在文档有没有被当成会演进的资产来管。
文档即代码怎么落地
Thousand Docs 的思路是把文档当代码管：文档进版本库，每次提交就是一次版本，可以 diff、可以回滚、可以接入 CI 做一致性校验。智能体拿到的不是一段长文，而是指向某个具体版本的引用。文档改了，版本号变，智能体下一次拉取自然就是新的。
这把「文档质量」从个人自觉变成了工程约束。写错接口名、漏改一处说明，会在 diff 里暴露，而不是等智能体答错才被发现。对有多份文档、多个团队的场景，版本化还能避免不同智能体各用各的过期副本。
智能体怎么消费
在文档即代码的模式下，智能体消费上下文的方式也变了：它不再依赖人类手动粘贴，而是按当前任务拉取对应版本的文档片段。仓库合并一次，上下文就刷新一次，智能体看到的世界和代码世界保持同步。这天然适合和 RAG 结合——版本库是权威源，检索是在版本源上做切片。
它补了 RAG 的哪块短板
边界提醒：文档即代码不是 RAG 的替代品，而是它的上游。RAG 解决「从海量文档里找相关的」，却默认文档本身是静止的；版本化解决的是「文档本身在变，智能体用的那份跟不跟得上」。两者叠加才完整。另外，它要求团队真的有文档纪律——文档不进版本库，这套机制就空转。
对已经用智能体做客服、做内部知识问答的团队，Thousand Docs 指向的是一个容易被跳过的工程环节：先把文档当成会演进、可审计的资产，再谈怎么喂给智能体。上下文保鲜，是智能体长期可靠的前提，不是锦上添花。
如果你现在正被「智能体怎么又答错了」困扰，先别急着换模型，去看看它引用的那份文档，是不是已经比代码老了好几拍。