你的 AI 智能体患上了失忆症
- 原文链接：www.coderabbit.ai/blog/your-a…
- 原文作者：Harjot Gill
“进度灾难和系统缺陷的出现，是因为左手不知道右手在做什么。”——Fred Brooks 在 The Mythical Man-Month 中如此描述几乎拖垮项目的 IBM OS/360 项目协调失败。
《The Mythical Man-Month》依然是工程管理里最受欢迎的书之一，也是许多管理者书架上的常驻读物。
过去五十年的 SDLC 演进，本质上都在反驳这种失败模式。Agile 让开发与产品坐进同一间屋子。DevOps 拆掉了开发与运维之间的墙。Git 和 Pull Request 让团队拥有了“改了什么、为什么改”的共享记录。CI 让构建变成每个人的责任。平台团队铺好“公路”，避免每位新同事都去重学一遍部落知识。每一次关键转变，都押注在“共享理解”能胜过“个人英雄主义”。
然后编码智能体来了，我们却倒退了。
现在每位工程师都在自己的机器上运行一个私有智能体，处在别人看不到的会话里。智能体每天早上都从“什么都不知道”开始。昨天构建出的推理、权衡过的方案、加载过的上下文、站会里做出的决策，都会消失。流程开始断裂，并制造出一种错误等价：“我们交付速度前所未有地快！”
Brooks 当年描述的是人类团队在数周内逐渐漂移。现在我们加入了会在一个工作日内就漂移的 AI 队友，却还把它叫作高生产力。
至少新入职的人，昨天学到的东西今天还记得。
上下文税
最近，我看一位资深工程师在智能体写出第一行代码前，花了 11 分钟做上下文准备。他解释架构，解释为什么他们使用 Postgres 而不是别的方案。最后，他又粘贴了三个文件、一张 Linear 工单，以及技术负责人在 Slack 里关于某服务将被弃用的上下文消息。
智能体确实写出了代码，而且说实话，代码还不错。
但这位资深工程师第二天早上说，他会开一个新会话，然后很可能为了另一段上下文把这一切从头再做一遍。智能体缺乏团队层面的洞察。
这就是 2026 年的 AI 辅助开发。
错位的问题
没有人在讨论智能体在开始工作前“已经知道什么”。
对人类来说，问题框架是否正确，足以让普通思考者表现得像天才。对 AI 智能体来说，这个差距更大。同一个模型，给同一个提示词，如果它是否理解所处系统不同，产出的代码会天差地别。
给智能体一个没有上下文的代码库，你会得到看起来像样、却错过团队两年沉淀规范的代码。给同一个智能体相同代码库，再加上架构决策、工单历史、值班手册，以及团队决定弃用旧认证服务的 Slack 讨论串，你会得到看起来像队友写出来的代码。
而现在，开发者仍在每次会话里手工拼装这些上下文，像翻译官一样在工程组织与本应“自己知道”的工具之间来回转换。
五种智能体失忆
上下文问题是最明显的症状，但这种病更系统。当前这一代智能体至少有五种遗忘方式：
系统层面的遗忘
每次会话都在毫无系统背景和决策背景下冷启动。智能体打开文件，却不知道你们为何为队列选了 Postgres 而非 Redis，不知道哪个认证服务即将下线，也不知道你们上季度决定“错误不要再额外包一层”。但这些上下文其实存在于没人读的 PRD、三月的一段 Slack 讨论和一位资深工程师的脑子里。开发者每天早上做的第一件事，就是把这些信息翻译成提示词。
换句话说，开发者正在重建那些公司里本来已经存在的信息，并把它们塞进受限于个人会话的上下文窗口。
对自己过往工作的遗忘
你昨天教会的智能体，不是你今天在用的智能体。你带它过了一遍计费模块：看起来像 bug 其实不是的重试逻辑、为什么 webhook 场景下不能信任 Stripe 的幂等键、以及去年夏天失败重构留下的 git 历史“警示碑”。它也确实产出了好代码。
你关掉标签页后，留下的只有一个 commit。导向这个 commit 的推理过程（真正想保留下来的部分）会随着会话一起消失。下周再打开同一个文件，你还得重来一遍。
附注：是的，你可能在 agents.md 或别的持久化知识库里存了内容并做了共享。但这些内容是否被持续更新到足以承载关键团队上下文，能让团队日常维护真正轻松？
对队友协作的遗忘
编码智能体是单人游戏。一个开发者，一个会话，一台机器。工作过程对团队其他人不可见。如果你要交接一件事，你的队友会从零开始，因为根本没有可交接的“会话对象”。
我们花了十年把开发做成协作型：Git、Pull Request、共享 CI、谁都能打开的看板。然后我们却造出了让开发再度孤岛化的 AI 开发工具。
对后续结果的遗忘
智能体写出一段代码，进了 PR，经历代码评审。下个迭代有人重写了其中一半，再过一个月线上出现一个间歇性拉低生产指标的 bug。工程师随后在 Slack 或 GitHub 上协作修复回归问题。
你的智能体并不在这些决策闭环里。
工程师之所以会变强，是因为他们经历了“代码被评审、被部署、出问题、再修复”的完整链路。在每个阶段，团队和个人都会形成集体学习。如果把智能体排除在这条链路之外，你得到的就会是一个永远只会生成“看起来合理”代码、却从不学习哪种“合理”能在生产环境里存活的智能体。
对“有人在看”的遗忘
好吧，无论是 CLI、IDE 还是未来新形态（ADE?!），我们都无法阻止每位开发者运行本地 AI 编码智能体。但工程组织没有一个共享视图去看智能体在团队范围内“做了什么、怎么做的”。它们在触碰哪些系统？花费如何？
经济账迟早会逼你面对这个问题。Uber 的 CTO 今年告诉 The Information，他们团队已经把 2026 年整年的 AI 编码预算烧完了。
智能体失忆，本质上正在变成一个经济问题。每位工程师的 token 消耗按天叠加并复利增长，这对工程团队来说是个更难解的问题，因为他们又无法放弃已经到手的生产力提升。
但我的终端编码智能体明明很好用
对你个人来说，对你自己的机器来说，确实如此。
我并不是在说终端智能体不好用。它们显然有用。Claude Code、Codex 都是很棒的工具。而且我们也不是想取代它们。
实际上，像 steering control、sub-agent framework、hooks 和 plugins 这样的能力，对开发者都非常有价值，帮助他们比以往产出更多代码。
说清楚一点，这些工具也并非没有记忆。Claude Code 会读取项目级 CLAUDE.md、用户级 CLAUDE.md，还会在本地 memory 目录持久化笔记，让信息跨会话存在。
问题在于，团队的可持续知识在本地 agentic 编码会话里仍会丢失。那位资深工程师对计费模块的硬核理解，存在她笔记本电脑上的 markdown 文件里。当另一位异地同事开启第一次会话时，这些都不会自动带过去，也不会自动延续。
智能体需要变成什么
Edsger W. Dijkstra 曾在文章中写道：一个称职的程序员会充分意识到自己头骨容量的严格上限。智能体没有头骨。它们本不必遗忘。是我们把它们建成了会遗忘的样子，因为我们把它们建模成“短命的终端会话”，而不是“团队真正工作的持久化环境”。
当我们不再把失忆当成默认设定时，下一代应该是这样：
知识应该可复利积累。与其让上下文文件留在某个开发者机器上，不如让每一次代码评审、每一张已解决工单、每一场架构讨论都汇入一个知识层，让智能体下个月比今天更有用。这是一个按团队、项目、领域划分的共享知识层。新工程师加入时，智能体已经带着过去只存在于少数资深工程师脑中的机构记忆。
工作应该可持久化且可恢复。任务从 Slack 线程里开始。被打断。交给队友。两天后你回来，工作仍然在那里。它可见、可评论、可由具备权限的人恢复继续。它不会被困在某个开发者笔记本上的一个浏览器标签页里。
智能体应该像任何有生产访问权限的系统一样被治理。如今多数编码智能体按 seat 定价、按用户隔离。你花多少钱，取决于开发者碰巧烧掉多少。你的访问控制，取决于工具默认值，而默认往往是“全都给”。你对智能体在全组织范围内究竟在做什么，几乎没有可见性。你不会给每位工程师生产环境 root 权限，也没有理由把组织全部上下文的平面访问权交给 AI 智能体。
上下文应该自动从各处拼装，而不是人工粘贴。智能体应从代码库、工单、文档、可观测性栈、云基础设施和团队长期积累的知识中自动取材。开发者的工作应该是指挥智能体，而不是做它的研究助理。
关于编码智能体的头号抱怨，是它们在生成“一次性代码”：返工太多，迭代太多，最后才勉强可合并。但如果第一次就有更好的上下文，第一次就更可能产出更好的代码。
这件事将走向哪里
今天，我们发布 CodeRabbit Agent for Slack。
我们从核心闭环开始：规划、代码生成、评审、问题调查、知识增强开发。
一个智能体覆盖你的整个软件开发生命周期。它全部发生在 Slack 内，同步进行，并且带有护栏。
但愿景不止是把编码智能体放进 Slack。
我们要构建的是贯穿整个 SDLC 的 agentic 层：它理解系统、连接工具、保留团队知识，并端到端执行工程工作流。
- 部署后回归排障：把 Datadog 指标尖峰关联到具体 commit，并起草修复方案，无需任何人手工拼上下文。
- 破坏性变更检测：在合并前跨仓库追踪下游消费者。
- 客户 bug 调查：从支持工单起步，联查错误日志，定位根因，并把初步分析发回团队。
- 迭代摘要：从 Linear、GitHub、Datadog 和 PostHog 自动拉取并汇总。
我们相信，智能体的有用程度，取决于它能触达多少上下文、能执行多少动作。
终局是这样一层能力：它把整套技术栈连起来，并且能从团队本来就在协作的地方被编程驱动。
这场下注
采用 AI 的每个工程团队，个人生产力都在上升。团队级生产力仍然停滞，而且停滞的原因与模型质量无关：没有可解释的执行记录、没有符合团队组织方式的成本归因、智能体也不在工程真正发生的地方。把这三件事解决掉，团队生产力才会像个人生产力一样开始复利增长。
最终胜出的智能体，不会是模型最好的那个，而会是你一打开它就已经理解你系统的那个——理解你的约定、你的弃用计划、那些没写进文档的决策。那就是可持续的团队知识，也是今天所有工具普遍缺失的东西。
我不会说这能替代开发者。只要你上过生产代码，你就知道工程里最难的不是敲键盘，而是判断：理解系统、知道该构建什么、也知道不该构建什么。
在 CodeRabbit，这正是我们多年下注的方向。
我们独立构建的上下文引擎每周跑两百万次代码评审，这就是我们把优秀工程团队真实做法编码化的方式。CodeRabbit Agent 将这套引擎扩展到 Slack，并叠加你团队自己的决策与模式。工作在开放空间中进行，队友可见、可介入、可接续。上下文会累积，而不是在会话结束时死亡。
谁能解决智能体失忆，谁就会赢。谁还在用“失忆智能体”追求更快，只是在更快地构建错误的东西。
参考资料与延伸阅读
图 1 数据来源：Becker、Rush、Barnes、Rein 的《Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity》（METR，2025-07-10）；以及 Xu、Medappa、Tunc、Vroegindeweij、Fransoo 的《AI-assisted Programming May Decrease the Productivity of Experienced Developers by Increasing Maintenance Burden》（arXiv:2510.10165，2025）。
术语表（本篇命中）
| 术语（EN） | 本文用法（ZH） | 备注 |
|---|---|---|
| SDLC | 软件开发生命周期 | 保留英文缩写并给中文全称 |
| coding agent | 编码智能体 | 与 agentic 开发语境一致 |
| context | 上下文 | 工程管理与 AI 提示语境通用 |
| prompt | 提示词 | 与全局术语库 approved 一致 |
| LLM | 大语言模型 | 与全局术语库 approved 一致 |
| CI | 持续集成 | 首次出现保留缩写 |
| runbook | 值班手册 | on-call 语境对应 |
