AI Agent落地失败根因： prompt知识冻结问题

去年，我在公司的支持下启动了一个试点项目，打算围绕开发工作构建自主运行的 AI 工具。

一年后，团队里的两名开发者交付了承诺故事点的两倍——而且这种效率提升与他们的 seniority 无关。

在这两个时间点之间，是一次彻底的失败。先从这部分说起，因为这是没人会讲的经历。

自动贬值的试点

当时我用的是那一套流行的方案：Agent 编排器、角色定义、工具链。每个 Agent 都有各自的 prompt、各自的职责和在链中的位置。

有点用。但它在自动贬值。

问题不在于模型也不在于框架——两者都兑现了承诺。问题在于我给它们的知识是冻结的。每个 Agent 只知道我在写它 prompt 那一天写进去的东西，仅此而已。

而真实系统打交道所需的大部分知识，根本没有任何地方写。它存在于人们的脑子里：为什么那张表有一个奇怪的字段、动了那个服务会坏什么、两年前做了什么决定、为什么没人回滚。这些知识主要存在于 senior 脑子里，而且不会因为写一个更长的 prompt 就传递出去。

系统在做工的同时不断老化。每过一周，它对自己工作的代码就少了解一点。

停工一个月

我花了一个月重新开始。那段时间我没有停止工作：和往常一样继续处理自己的 ticket，用 Cursor 和 Claude Code这些日常工具。我停下来的，是构建——那个月里我没有多写一行自动化代码。

我把时间用来阅读和重新聚焦。那段时间 Anthropic 几乎每周都在发文章，我花了功夫去理解噪声之下真正在发生什么变化。

我回来时问的问题变了。不是"怎样让一个 Agent 更聪明"，而是"怎样不再丢失知识"。

不会老化的文档

我找到了一种记录业务决策历史的方式。不是那种没人更新、三个月后就变成谎言的文档——而是记录事情为什么是现在这样的东西：做了什么决定、相比哪些替代方案、以及是什么约束推动了它。

然后我加了那个改变一切的要素：每次实现完成后，那份文档会用结果更新自己。

这是一个小细节，但也是全部差异所在。知识不再是一张照片，而变成了一份活着的记录。上下文不再是，我对 Agent 需要知道什么的主观推测，而变成了工作本身在维护的东西。

我在自己身上试了。在我的机器上、用我每天的 ticket、没有告诉任何人。

结果超出了比例：小 ticket 和大 ticket 之间的时间差从几小时或几天变成了几分钟。不是因为我写代码更快了——而是因为我不再每次都花时间重建上下文。

但它仍然只活在我的笔记本电脑里。

这正是我们开发者为自己构建的大多数东西的归宿：那套让你效率翻倍但没人再用的工具，因为它从来没有离开过你的 scripts 文件夹。

把它从那里拿出来是下一个问题。而结果表明，这是一个设计问题，不是代码问题。

这是系列文章（共五篇）的第一篇，讲述我如何构建了一个在生产环境交付软件的 Agent 系统。