如果你把 Agent 挂在真实项目上跑超过一个月，大概率有过这种体验：第一周惊为天人，之后越用越别扭——明明说好的规范，它转头就忘；一个长任务跑到后半段，开始重复劳动、引用错文件、把改过的东西又改回去。你花时间修它造的坑，有时比自己写还累。
先说结论：这不是模型变笨了，也不是你提示词没写好。这个问题这周在开发者社区里被反复讨论，有个越来越统一的叫法——上下文腐烂（context rot）。更有意思的是，围绕这个病，本周社区集体开药方，热闹得像过年。
这周发生了什么
按时间线捋一下，信息量有点大：
8月19日到20日，字节火山引擎开源的 OpenViking 在 GitHub Trending 上日增 Star 从前一天的 213 直接跳到 804，冲到日榜第 2。知乎累计 Star 已突破 3 万，而且还在涨。微博它不是新项目——今年 1 月就开始提交，但这一轮热度是实打实的爆发，连榜单上另一个同类记忆项目 ai-memory 都被它挤了下去。
同一天的日榜上还有两个熟面孔：Matt Pocock 的个人技能库 mattpocock/skills（22 万+ Star，MIT 协议）和 obra/superpowers（27 万+ Star）。一个 TypeScript 圈的讲师和一套 Agent 方法论，靠存量热度和新版本发布又冲了一波。知乎
阿里 AMAP-ML 团队则放出了论文 LongHorizon-Harness（arXiv:2608.01964），专门研究长程 Agent 为什么跑不稳，提出了一套"管账、干活、验收"三权分立的架构。arXiv
到了 8 月 21、22 日，知乎上"上下文工程对 Agent 开发有什么影响""为什么你的 Agent 越用越坑"这类问题集中冒出来。知乎B 站一周内出现了一堆讲上下文工程、"上下文即服务（CaaS）"的视频，微博上"AI 聊完就忘这事终于有人管了"今天早上还在热转。微博
一个细分方向在一周内密集到这个程度，说明大家是真的被同一个问题折磨够了。
病根在哪：账本和干活的人，绑在了同一本聊天记录里
现在的 Agent 架构，无论 Claude Code、Codex 还是各种开源脚手架，绝大多数都是把任务状态、执行记录、自我评价、环境事实全部塞进同一条对话上下文里。任务一长，这锅粥就越来越稠：早期的关键约束被新内容挤出注意力中心，一次小错误的描述会像滚雪球一样传到后面几十步。LongHorizon-Harness 论文把长程失败的根源归结为三条，翻译成人话就是——不是某一步推理错了，而是状态失真了。知乎
还有个反直觉的点值得单独说：窗口大，治不了这个病。拿 Qwen3.7-Max 举例，官方参数里上下文窗口是 100 万，很吓人，但最大输入 991,808、最大输出 65,536 要放在一起看。知乎窗口回答的是"这一轮能看多少"，回答不了"一个几小时的长任务能不能稳稳做完"。材料塞得进去，模型也未必找得到重点；就算看懂了，输出截断、中断恢复、结果验收，每一环都可能掉链子。
Matt Pocock 那篇被转疯的文章说得更直白：AI 加速了软件开发，也同比例加速了软件腐化。知乎他归纳了四大失效模式——沟通鸿沟（你说的是模糊的，Agent 按字面理解）、没有统一语言（同一个概念每次说法都不一样）、反馈回路缺失（代码是"感觉能跑"而不是"验证过能跑"）、代码熵增加速。
四派药方，一次看懂
社区这周开的药方，我按思路归成了四类：
第一派：分层记忆派，代表是 OpenViking。 思路是把上下文当数据库来设计。记忆、知识、技能统一挂在一个 viking:// 虚拟文件系统下，Agent 用 ls、find、grep 浏览自己的上下文，而不是去问黑盒向量库。每条内容写入时自动拆成三层：L0 摘要约 100 tokens、L1 概览约 2k tokens、L2 完整原文，Agent 先看摘要判断相关性，再决定往下读。官方给的数据：token 消耗降 34.3%–91.0%，查询延迟降 58%–66%。微博LoCoMo 长对话记忆基准上，OpenClaw 原生准确率 24.2%，接上后到 82.08%，Claude Code 从 57.21% 到 80.32%。知乎会话结束后，它还会自动提取用户偏好和 Agent 经验，沉淀进长期记忆，下次开会话不用从头再来。它有 VLDB 2026 录用的论文背书，Claude Code、Codex、Cursor、Trae、LangChain 都能接。
第二派：日志外置派，代表是 Context Mode。 针对的是 Coding Agent 的经典场景：跑一次全量测试，几万行日志直接挤爆上下文，简单截断又恰好删掉最关键的失败栈。它的做法是把大输出写进本地 SQLite 全文索引，只给模型返回摘要和检索入口，需要时再用关键词搜回来。知乎本质是把"先把所有原文交给模型"改成"原始数据落地，模型只拿指针和结果"。
第三派：状态外置加审计派，代表是 LongHorizon-Harness。 这派最激进——直接把长程任务拆成三个角色：Manager 只管账本不碰环境，Executor 每次在全新的上下文里干活、干完原始对话轨迹可以整个扔掉，Auditor 只读检查环境、不采信 Executor 的口头完成声明。LongHorizon-Harness 项目官网跨轮持久化的只有任务状态和审计报告。知乎
论文里的数字：同样用 Qwen 3.7-Plus 做骨干，WeaveBench 通过率从 51.8% 提到 80.7%，Terminal-Bench 2.1 从 69.7% 提到 77.2%，OSWorld 2.0 从 2.8% 提到 8.3%；换 Claude Opus 4.7，OSWorld 子集也从 20.0% 提到 34.3%。知乎不换模型，只换状态管理方式，长程完成率就上台阶——这就是这个方向最有力的证据。
第四派：纪律技能库派，代表是 mattpocock/skills 和 obra/superpowers。 不碰架构，用规则约束行为：/grill-me 让 Agent 反过来审问你，把需求逼问清楚再动手。知乎/tdd 把红绿重构固化成工作节奏，强制小步验证；确认下来的术语写进 CONTEXT.md 当统一语言，设计决策记成 ADR。superpowers 更重，控制器、实现者、审查者三角色加五轮熔断器防死循环。
你该选哪个：按场景抓药
不想全装一遍的话，按你对号入座：
个人项目、聊天式轻度使用——先上第四派。零成本，一个 CONTEXT.md 加追问纪律，就能解决大部分"忘事"。
Coding Agent 天天被海量日志、测试输出淹没——第二派见效最快，而且直接省 token，在 API 按量计费的今天这是真金白银。
做几小时级长任务、几百次工具调用的生产型 Agent——第三派是正解，或者至少把它的思想抄过来：状态外置、新鲜上下文执行、独立验收。
需要跨会话记住用户偏好、项目约定——第一派的分层记忆，这是 OpenViking 的主场。
最后两个坑必须提醒。一是许可证：OpenViking 是 AGPL-3.0（核心 Rust crate 和示例是 Apache 2.0），要嵌进商业产品改源码的话，先过一遍法务。知乎Context Mode 是 Elastic License 2.0，属于"源码可见"但不是宽松开源，拿它做托管服务是违反条款的。知乎相比之下 mattpocock/skills 的 MIT 就随便用。二是数据口径：上面那些百分比基本都是项目方自测自报，独立复现还没跟上来，看看数量级就好，别直接写进 KPI。
至于接下来值得盯什么：Claude Code、Codex 这些宿主会不会把上下文管理收编成原生能力（现在第三方都是 sidecar 形态）；LoCoMo、tau2-bench 上的提升会不会有独立复现；以及"上下文即服务"这个商业模式会不会真的跑出来。
一句话总结：模型决定了 Agent 能力上限，但上下文管理决定了它能不能稳定干活。这周爆发的所有项目，本质上都在说同一件事——别再把账本和干活的人绑在同一本聊天记录里了。
