这三个月，跟 AI 编程搭伙做那个热点监控工具，踩坑不少。但有一个坑最隐蔽，跟模型聪明不聪明没什么关系——
Cron 定时去扫热点，Cursor 那边的对话再长，也帮不上忙。
问题怎么解？那篇《我的 AI Agent 工作了 3 周，但它还是像失忆一样》的文章，说得挺透彻。
热点监控看起来简单，状态说丢就丢
需求其实很直白：配好关键词，定时从 Twitter、HackerNews、B 站这些源抓内容，AI 跑一遍分析，判断真假和相关性，真有价值的就推送通知。
用 Cursor 写代码那会儿，一切都很顺。模型记得我刚改了哪个接口、哪个组件报错、Prisma schema 加了什么字段。聊得热火朝天，感觉它「全记住了」。
但第一次把定时任务跑起来，问题立马浮出水面。
有个关键词「Claude 4」已经扫过一遍，数据库里也有记录。第二天 Cron 一触发，日志里它又从头抓、从头分析，把昨天判成「低相关」的内容又跑了一遍 AI——Token 烧了不少，通知栏还弹出重复条目。
翻 Cursor 的聊天记录，昨天的分析结论一字不少。但 Cron 进程根本读不到那段对话。它只认数据库、只认 lastScannedAt、只认这次任务写进去的 Hotspot 行。
那一刻才明白：在 IDE 里跟 AI 聊出来的「项目理解」，和系统真正跑起来需要的「运行状态」，完全是两码事。
聊天记录管的是「写代码」，数据库管的是「跑业务」
后来凡是需要跨任务保留的信息，全部落到了持久化层：
| 需要记住的 | 存在哪 | 为什么 |
|---|---|---|
| 关键词上次扫描时间 | Keyword.lastScannedAt | 避免重复抓取 |
| 用户开关的数据源 | Settings 表 | Cron 按配置决定抓哪些源 |
| 已入库的热点 | Hotspot 表 + URL 去重 | 防止同一链接反复通知 |
| AI 分析用的 prompt 偏好 | 设置页 + .env | 换会话也不丢 |
这些不是 RAG，也不是向量库，就是普通的关系型存储。但对一个 7×24 小时定时跑的 Agent 链路来说，比任何聊天窗口都可靠。
Cursor 会话关掉，代码还在 Git 里；Cron 跑完，状态还在 SQLite 里。下次任务启动，读的是磁盘上的事实，不是「你上次跟模型说了什么」。
给 AI 编程同学的三个习惯
三个月走下来，给自己定了三条规矩，跟写业务代码无关，跟怎么跟 AI 协作有关：
1. 任务状态写进文件，别写进聊天
让 AI 分析 monorepo、改十个文件的时候，要它在 docs/ 或项目根目录留一个 checkpoint：改动了哪些文件、还剩什么没做、有什么风险。新开会话，先让它读这个文件，而不是说「继续上次的工作」。
2. 长期运行的逻辑，必须有外部存储
凡是 Cron、Webhook、后台 Job 会用到的东西——上次执行时间、去重键、用户配置——不能指望 prompt 里「提醒一下」。在热点监控里吃过亏，后来每个 Job 入口第一件事就是读库。
3. Agent Skills 是能力，不是记忆
项目里封装了 Agent Skills 技能包，Cursor / Claude Code 可以直接调热点搜索、关键词管理。但 Skills 告诉模型「能做什么」，不告诉它「上次做到哪」。记忆还得靠项目里的数据库和配置文件。
这跟「Agent 失忆」是同一类问题
上面说的，本质上是聊天上下文和 Agent 运行状态的边界问题。
IDE 里跟 AI 结对编程，聊天记录就是它的「短期记忆」——窗口够大，体验确实像它在持续理解项目。但一旦 Agent 脱离聊天界面、独立跑任务，这段记忆就断了。
最近读到 VPSSPark 一篇 OpenClaw 实践笔记，把这个问题讲得很透——作者让 Telegram Agent 跟进了三周客户，对话全留着，结果发邮件时问「您是哪家公司」。文章标题就叫 《我的 AI Agent 工作了 3 周，但它还是像失忆一样》。场景跟热点监控不同，但根因一样：把聊天记录当成了 Memory。
我做的是定时扫热点，他们做的是长期跟客户——表面业务不一样，底层都需要回答同一个问题：下次启动时，Agent 从哪里恢复状态？
最小实践清单
如果你也在用 AI 做自动化工具，不一定需要上向量库或 Memory 框架。可以先从这几件事做起：
- 每个定时任务有 idempotency——同一个输入，跑两次不应产生两份副作用。热点监控靠 URL 去重 +
lastScannedAt实现。 - 关键决策有落盘记录——AI 判定的真假、重要性，写入数据库，而不是只出现在当次日志里。
- 换会话前先让 AI 写 checkpoint——一行也行：「docs/ 写到第三章，待确认 legal 条款」。
- Settings 和 Secrets 分离——业务配置进库或配置文件，API Key 进环境变量，别让模型在聊天里「记住」密钥。
做到这四条，Agent 就算没有 fancy 的 Memory 系统，也不会每次开机都像第一天。
写在最后
AI 热点监控这个项目，让我从「跟 AI 聊天写代码」走到了「让 AI 链路自己跑起来」。后者多了一层工程问题：状态存在哪、怎么读、怎么过期。
Cursor 的上下文窗口再大，也替代不了一个 lastScannedAt 字段。
如果你也在修长期运行的 Agent，推荐读一下 VPSSPark 那篇 OpenClaw 失忆复盘——他们从客户跟进、Claude Code 重复劳动到 Memory / Gateway 分层，视角不同，问题同源。
先把「下次启动读什么」想清楚，再谈窗口有多大。
