台账记忆系统：让AI Agent复用经验不重复踩坑

为什么Agent需要一个「台账」

如今下载任意一个开源Agent框架，配好Session、Context、Memory，它就能跑得很好。既然如此，为什么还需要额外做一套「台账记忆系统」？

这位UP主在过去一个月里连续开发了多个Agent智能体，在实战中提炼出了一个核心痛点：现成的Session/Context/Memory机制虽然能工作，但缺乏跨会话的经验沉淀能力。每一次会话结束，那些宝贵的报错分析、复盘教训、设计决策往往就随着上下文一起消散了。下一次遇到同样的坑，Agent还会再踩一遍。

台账系统（Ledger）正是为了解决这个问题而生。用更直白的说法，它就是Agent的「账本」「记事本」或「便签」——把每次会话中的教训固化为行为规则，让每次新会话都能带上这些积累下来的经验。

值得一提的是，作者指出这套思路与谷歌研究员提出的**WikiSkill（进化系统）**有异曲同工之处。两者都是让Agent在使用过程中不断进化、沉淀知识，但作者强调台账是自己独立设计开发的，并非照搬。

Session、Context、Memory 是目前主流 Agent 框架处理「记忆」的三层结构：Session 指单次对话的临时上下文，Context 是注入模型的信息窗口，Memory 则是框架提供的短期或长期存储接口。这三者的共同局限在于——它们本质上都是会话级的，生命周期与单次对话绑定。一旦对话结束，相关信息要么被丢弃，要么需要开发者手动序列化持久化。即便框架提供了 Long-term Memory 选项，其检索粒度和写入时机通常也由框架控制，开发者难以精细干预「什么值得记、以什么形式记、何时注入」。这正是台账系统试图从框架层之上另开一层来解决的问题。

台账里到底存了什么内容

作者将台账封装成了一个Skill（技能），移植到了DeepSeek Harness上。用户只需说一句「看看台账」，就能触发这个技能，查看当前台账的全貌。

在实际演示案例中，仅仅两三天的使用时间里，台账已经沉淀出了相当丰富的内容：

• 24条铁律：最硬核的部分，都是从报错和复盘中总结出的不可违背的行为规则
• 2条偏好：记录用户的个人习惯
• 18条草稿：待处理或观察中的信息
• 4条固化轨迹
• 14条采集信息

铁律是怎么沉淀出来的

台账里的「铁律」不是人工写死的，而是在使用过程中逐步进化、自然沉淀出来的。作者举了几个真实例子：

• 「代码安全，绝不带码」「禁止绘画日志喷发」等安全规则
• 「改包、改核心代码后必须重启」——这条来自一次真实的报错。作者在项目中修改了核心配置文件后系统报错，Agent抓住了这个错误，随即将它沉淀为一条铁律
• 「文档、代码双轨制，以代码运行时为真相，禁止猜测」——这条更有意思，是Agent在复盘时发现自己「绕了弯路」：本应直接看代码才知道如何修改，却凭猜测行动。于是它给自己立了这么一条纪律

这种「从错误中学习并自我约束」的能力，正是台账记忆系统的精髓。它有点像一个不断自我完善的维基百科——每一条经验都是一个词条。

底层架构：从采集到入账的完整链路

从技术架构上看，台账系统可以分为几个清晰的层次。

存储层：纯文档基础设施

整个台账的底层其实就是一个纯文档存储层。所有的铁律、偏好、草稿、采集信息，本质上都是文档类存储。这是一个基础设施层，简单可靠，也保证了极强的可移植性。

采集层：Hook钩子 + 手工复盘

数据是如何进入台账的？主要有两条路径：

1. 自动采集：通过Hook（钩子）机制自动抓取工具报错。目前几乎所有主流Agent框架都提供了注册Hook的能力，这是台账能够跨框架移植的关键
2. 手工复盘：用户可以主动发起指令，比如「复盘一下最近执行的几个任务」，Agent会从Session的底层数据中分析出可沉淀的内容，然后「入账」

作者特别强调了台账的跨框架可移植性：它与Agent本身的关系不大，只需要Agent提供Hook能力，剩下的完全靠「契约 + 工具」来实现。大模型可以调用这个Skill里的工具，把报错、复盘分析、摘要等信息从Agent原有的Session、Context、Memory中脱离出来，独立存放到台账里。

Hook（钩子）是 Agent 框架提供的事件拦截机制，允许开发者在特定生命周期节点（如工具调用前、工具报错后、任务完成时）注册回调函数。以 LangChain 为例，其 CallbackHandler 接口提供了 on_tool_error、on_chain_end 等事件钩子；AutoGen、CrewAI 等框架也有类似的事件总线设计。台账系统利用这一通用机制，在工具调用出错时自动捕获错误信息并触发「采集 → 分析 → 入账」流程，而无需侵入框架核心逻辑。这也是为什么作者强调台账具备跨框架可移植性——只要框架暴露了 Hook 能力，台账就能挂载上去，与具体的编排引擎解耦。

契约机制：任务完成后的强制摘要

台账系统中有一个重要的「契约」设计：Agent在执行完一个任务后，有义务按契约生成一条摘要，并放入台账。

作者演示了一个场景：他让Agent修改了某个功能，改完后Agent汇报完成。这时按照契约，Agent需要把排查结论、修改方案整理成一条草稿摘要，存入台账的「观察区」。作者展示的观察区里，18条草稿被细分为「早前清账」「分析排查点」「本会话」等不同类别。

关键难点：台账如何注入Agent上下文

台账建好了，但如果账本只是静静躺在那里，没人知道里面记了什么，那它的价值就大打折扣。作者提出了一个核心追求：让台账像「常识」一样自然地为Agent所用。

这就引出了台账系统最关键的技术挑战——如何将台账内容注入到运行时的上下文中。

问题在于规模。作者做了一个假设：如果一个系统运行十年，台账里可能积累几十万甚至上亿条记录，相当于建了一个庞大的维基百科网站。显然不可能把全部内容一股脑塞进有限的上下文窗口。

作者给出的方案是**「抽屉式」分层注入**：

• 通过声明式的机制（类似Agent的MD文件配置）进行分段管理
• 只在需要时，一层一层地拉取相关的「抽屉」内容注入上下文
• Agent自身也配备了一整套工具脚本，包括存储层的初始化、结构化处理、观测、流水线等命令

大语言模型的上下文窗口（Context Window）是其一次推理所能「看到」的信息总量上限，目前主流模型从数万到百万 token 不等。尽管窗口在扩大，但将海量历史记录全量注入仍面临两个现实瓶颈：一是成本，token 数量直接影响推理费用；二是「迷失在中间」问题（Lost in the Middle），研究表明模型对位于上下文中段的信息关注度显著低于头尾，信息过多反而会稀释关键内容的权重。因此「抽屉式」分层注入的核心价值不仅是节省窗口空间，更是通过精准检索确保最相关的经验条目出现在模型注意力最集中的位置，从而真正发挥台账的「常识」作用。

现成Agent框架的心智局限

作者在分享中还提出了一个值得深思的观点：现成Agent框架的「心智」不够。

他坦言，在自己完全自研的Agent里，从系统提示词、Context规划到Tool工具、SOP流程都能精细控制，几乎能做到「指哪打哪」。但当把台账Skill移植到DeepSeek Harness这类现成框架上时，由于框架缺少一些标准化的流程和动作，最终效果会打折扣。

因此他给出了一个实用建议：如果你拿到这个台账Skill，无论是用Claude Code还是Codex，都不要直接注册成Skill，而应该先让模型分析、调教一番，再注册使用。这也提醒我们，记忆系统这类基础设施的落地效果，高度依赖底层Agent框架的「可控性」。

总结：采集—存储—沉淀—注入的闭环

台账记忆系统本质上是给Agent装上了一套长期记忆与自我进化机制。它跳出了单次会话的局限，通过Hook自动采集、手工复盘、契约摘要三条路径把经验沉淀为文档，再通过分层注入的方式在关键时刻为Agent提供「常识」支持。

对于正在做Agent开发的人来说，这套「采集—存储—沉淀—注入」的闭环思路，比任何单一功能都更有借鉴价值。它回答了一个根本问题：如何让AI真正从经验中学习，而不是每次都从零开始。