AI Agent 记忆台账：让数字员工少犯重复错误

在万象片场的自动化系统里，我最近越来越重视一个很朴素的问题：数字员工每天都在执行任务，但它到底有没有记住昨天踩过的坑？

很多人搭 AI Agent 时，会把重点放在模型能力、工具调用、浏览器自动化和部署脚本上。这些当然重要。但当任务开始日更、周更、长期运行后，真正拉开差距的不是某一次执行有多聪明，而是它能不能把每次执行留下的经验沉淀下来。

如果没有记忆台账，Agent 会变成一个“每天重新入职的实习生”：今天刚修过的 frontmatter 问题，明天可能又犯；昨天确认过某个项目不能碰，下一次仍然要靠提示词提醒；上次部署后需要检查具体文章 URL，它可能又只看首页。短期看只是小失误，长期看会消耗整个自动化系统的信任。

所以我开始把 AI Agent 的复盘结果写成一份可查询、可更新、可执行的“记忆台账”。它不是让模型拥有玄学记忆，而是让数字员工在开工前能读到一份清楚的历史记录：哪些错误发生过，怎样修过，哪些规则不能忘，下一次应该先检查什么。

一、为什么数字员工不能只靠上下文窗口

很多 Agent 任务看起来已经有上下文：系统提示、用户指令、项目文件、计划文档、终端输出。问题在于，这些上下文大多是“本次任务现场”，不是长期经验。

上下文窗口有三个限制：

1. 不稳定：不同任务拿到的上下文不完全一样；
2. 不可追溯：执行完后，如果没有记录，错误和修复细节会散掉；
3. 不够结构化：一大段日志不等于下次能直接执行的规则。

人类团队会用周报、复盘、Issue、SOP 来解决这个问题。数字员工也需要类似的机制。只是它不一定需要复杂系统，早期一份 Markdown 台账就够用。

对万象片场来说，记忆台账的目标很明确：让 AI Agent 每次开工前少猜一点，每次收工后多沉淀一点。

二、记忆台账应该记录什么

我不会把所有日志都塞进台账。日志是流水，台账是规则和经验。它应该只记录会影响下一次执行的内容。

我目前把它分成五类：

类别	记录内容	下次怎么用
重复错误	曾经出现过的失败、误判、遗漏	开工前做预防检查
关键决策	为什么选择某个主题、路径或流程	避免下一次反复决策
验证结果	哪些检查通过，哪些检查不可靠	改进验收标准
权限边界	哪些目录、账号、动作不能碰	防止越界执行
后续线索	内链、专题、产品化、社媒切片机会	放入增长待办，不打断主任务

比如博客自动发布任务里，台账可以记录：

• 早间槽前 10 个主题已经全部发布，不要重复写；
• 文章必须带 heroImage 和 heroAlt，否则不符合计划要求；
• 线上验证不能只看首页，要检查具体文章链接；
• Cloudflare 原始 HTTP 检查可能被缓存或 UA 影响，要结合浏览器或带缓存参数检查；
• Git 提交只能包含本次文章文件，不要顺手提交无关改动。

这些内容不需要每天重新发明。写进台账后，它就变成数字员工的“老员工经验”。

三、一条好记忆不是总结，而是可执行规则

台账最容易写坏的地方，是写成空泛复盘。

比如：

今天发布过程整体顺利，以后继续注意质量。

这句话情绪上正确，但对 Agent 没有帮助。下一次它不知道该检查什么，也不知道怎样判断质量。

更好的写法是：

规则：发布博客文章前，先读取 src/content/posts 的现有标题；如果计划队列标题已全部发布，就选择同栏目下的新实战主题，避免重复标题。
触发场景：每日早间/午间/晚间自动发布任务。
验证方式：写入新 Markdown 前，用已有文件列表和 frontmatter title 做一次人工可读比对。

这才是一条可执行记忆。它包含规则、触发场景和验证方式。Agent 下次读到后，可以直接把它变成行动，而不是“理解精神”。

我给台账定了一个简单标准：凡是不能转化成下一次检查动作的内容，都不要放进主台账。

四、记忆台账的最小模板

早期不需要上复杂数据库。万象片场更适合用轻量 Markdown 文件，因为它容易读取、容易提交、容易被 Agent 理解。

一个最小模板可以这样写：

# AI Agent 记忆台账

## 永久边界
- 不操作明确禁止的项目目录。
- 不打印、保存、提交密钥和 Cookie。

## 重复错误与预防
### 2026-06-03｜标题重复风险
- 现象：计划队列中的早间槽主题多数已经发布。
- 规则：写新文章前必须读取已有标题，不从旧队列硬选。
- 检查：新标题不得与任何 frontmatter title 重复。

## 验证经验
- 部署后检查具体文章 URL + 首页，不只看构建成功。
- 图片要检查是否能加载，而不是只看 Markdown 有字段。

## 后续增长线索
- 可把“数字员工”系列整理成资源页。

它不追求完整记录所有过程，而是保留会让下一次执行更稳的关键经验。

五、开工前读台账，收工后更新台账

记忆台账只有在流程里被使用，才有价值。

我会把它嵌入 Agent 的两个时间点：

1. 开工前

数字员工先读任务计划、已有文章、内容体系，再读记忆台账。此时它要回答三个问题：

• 今天有哪些红线不能碰？
• 今天最容易重复的错误是什么？
• 今天的验收动作有没有历史特殊要求？

这一步能显著减少低级错误。

2. 收工后

任务完成后，只记录三类内容：

• 新发现的稳定规则；
• 本次出现并修复的问题；
• 值得下次处理但不该本次扩展的线索。

不要把台账写成流水账，否则它会越来越长，最后失去可读性。台账不是为了证明 Agent 很忙，而是为了让它下次更少犯错。

六、记忆台账和 SOP 的区别

SOP 告诉数字员工“标准情况下怎么做”，记忆台账告诉它“真实运行中哪些地方容易出问题”。

两者应该配合：

• SOP 是主流程：写 Markdown、本地预览、构建、部署、验证、Git；
• 台账是经验层：哪些主题已发布、哪些检查不能省、哪些缓存现象容易误判；
• 复盘是更新机制：每次任务结束后，把新经验筛选进台账。

如果只有 SOP，系统会显得整齐，但不一定吸取教训。如果只有台账，经验很多，却缺少执行顺序。真正可靠的数字员工，需要 SOP 和记忆台账一起工作。

七、下一步：把记忆变成数字员工的训练数据

我现在对 AI 自动化的理解是：数字员工不是一次配置好就永远可靠，而是要像真实团队一样被训练。

训练不一定是微调模型，也不一定是复杂向量库。对个人内容系统来说，最实际的训练方式就是：每次执行都有记录，每次错误都有规则，每次规则都能在下一次开工前被读取。

这篇文章是万象片场给数字员工补上的一块基础设施。下一步，我会继续把这些台账和 SOP 组合起来，形成一套更完整的 Agent 运营手册：任务怎么接、优先级怎么排、错误怎么复盘、经验怎么沉淀。

当一个 AI Agent 开始少犯重复错误，它就不只是一个会执行命令的工具，而更像一个真正能长期参与内容生产的数字同事。