[玩转大模型] 第九篇：给 Agent 加状态——Notion、飞书还是本地 Markdown，主档只能有一个

上一篇给 Agent 装上了嘴巴这一篇要装的是记事本。听起来两件事实际上是一件事的两头会喊话前提是它得知道自己昨天喊过什么。我机器上挂着十个定时任务每天按时跑签到、同步、发文、打卡。最开始的一周它们跑得很正常直到有一天我发现同一件事被报了两遍——因为任务本身没有我今天已经做过这个概念。上下文窗口一压缩前文里那句已完成就消失了对它来说每一天都是第一天。这不是模型不够聪明的问题。定时任务没有跨会话的记忆而我做过什么、结果是什么、下一次该接着哪一步这些信息必须有个地方存。于是问题就变成了一个很具体的选型题这个存放状态的地方用 Notion、用飞书多维表格还是干脆在自己仓库里放一个 Markdown 文件所以这一篇就沿着我自己的这套配置讲下去状态层怎么设计、三种存法各自的失败模式长什么样、以及为什么最后本地文件只能当导出物、主档只能有一个。这是「玩转大模型」系列的第九篇。一、Agent 有手有脚有嘴巴就是没有记忆这一章回答上下文和状态到底差在哪为什么不能靠写在提示里糊过去。先把三个容易混在一起的东西分开存在哪生命周期能被查询吗能被审计吗模型能力权重永久但不会变否否上下文当前会话的窗口会话内压缩即丢只能想起来否状态外部存储跨会话、跨机器是是第三行和第一行的区别就是能干活和能干同一件活的第二天的区别。笔者的判断是只要一个任务会重复运行它就必须有外部状态没有外部状态的重复任务等价于每天从零开始赌运气。赌的是上下文没被压缩、模型没换、前文那句已完成还在。这三个条件我一天都没同时满足过。具体会坏在哪三处没有状态 -- 重复执行 今天已经做过又做一遍 没有状态 -- 无法续做 昨天做到一半今天从头开始 没有状态 -- 无法交代 你问它上周成功率多少它只能编一个前两处是效率问题第三处最危险它会编。一个没有事实来源的 Agent被问这周发了几篇的时候会用一个听起来合理的答案填上而不是说我不知道去查。简单理解成一句话模型负责思考上下文负责此刻状态库负责昨天。二、状态放哪三种选择的正面对照这一章回答Notion、飞书多维表格、本地 Markdown 各自买到了什么赔了什么。这三个选项我都真的在跑不是设想。它们的差别不在能不能存全在写入语义上维度Notion 数据库飞书多维表格本地 Markdown / git写入单位行page 属性行record 字段整个文件覆盖行级唯一约束靠自己的幂等键约定靠自己的幂等键约定无查询能力filter / sort / 视图API 侧有分页视图 筛选API 支持条件查询只能 grep或再上一层脚本并发写同一行后写覆盖无冲突提示同左git 能报冲突但要有人看人在中间看强网页端随手就能核对强顺手且团队都在飞书里弱要么开编辑器要么看 diff结构化统计视图 公式够用图表更成熟全靠脚本离线可用否否是鉴权方式内部集成 token作用域到页应用 tenant token作用域到表格无也就是文件系统权限典型失败写进回收站的库会静默失败权限没开全时返回业务错误码一次覆盖写坏整篇靠 git 回滚适合谁个人 / 小团队的单主档状态要被别人看的场景导出物、审计副本三条路各自的调用链画在一起是这样我自己的结论很干脆Notion 当主档本地 Markdown 只做导出物。理由不是 Notion 更强而是它同时满足了我三个苛刻条件我要能在网页上一眼核对它写对了没有。状态库一旦不能随手检查我就会开始不信它然后退回到自己记。它得能被定时任务从任何一台机器写。我的任务在本机跑也可能在另一台机器上跑。行级操作。一天一行、一次运行一行这种语义用 page 表达最自然用 Markdown 表达就得整篇重写。飞书多维表格其实比我现在的方案更适合团队协作图表能力也强。但它在我这里输在一个很具体的点我所有 Agent 的配置、日记、待办已经都在 Notion 里了再开一个状态层等于把主档只有一个这条规矩先破掉。三、Notion 当主档我自己的这套结构长什么样这一章回答状态层怎么切分以及为什么一库一职责是第一条规矩。我在 Notion 里给 Agent 划了一个独立的工作区所有可写状态都在这下面外面一律只读。当前实际在跑的库是这几个库承担什么状态谁写谁读写入节奏每日签到打卡每个外部站点当天有没有打卡成功定时任务我 周报脚本每天一次一行一项发文日盘 · 2026-09每天发了几篇、发在哪、状态定时任务 我手填统计脚本每天一次待办与资源未完成事项、资源链接我定时任务导出随时月度日记一天一区块的日记正文同步任务我每天一次agent-bios-notionAgent 自己看到的今天状态摘要定时任务下一次运行每天覆盖⚙️ 同步配置上面这些库的 id、视图、规则我所有任务极少变更最后一行是这一节真正想说的东西配置本身也要进库。哪张表叫什么 id、用哪个视图读、字段规则是什么——这些如果硬编码在脚本里换一张表就得改代码放在一张配置表里脚本只需要在启动时读一次配置。而这张配置表自己就是整个状态层的根。结构关系是这样三条设计约束是我踩出来的一、一库一职责。我最早想把打卡 发文 待办塞进一张大表用类型字段区分两周后就放弃了——三类状态的字段几乎不重叠一张表里一半属性常年为空视图越建越歪。二、状态行必须有幂等键。我的键是日期 任务名。同一天同一任务再跑一次是覆盖那一行不是新增一行。没有这条重复执行只会从重复做升级成重复记。三、结构演进留归档不要删。我有一版一行一天的按日日记库后来改成一月一行、内部嵌日区块的月度结构。旧库我没有删而是整库挪进一个归档页里注明已弃用。因为旧数据还在被引用而删掉的库是找不回来的。按月分表这件事要单独提醒一下“发文日盘 · 2026-09” 这种名字里带月份的表跨月时库 id 会变。我的处理是把当月库的 id写进同步配置表每月初人工更新一次脚本永远只从配置表拿 id。听起来土但它比任何自动建表的方案都少出事——自动建表意味着自动产生两个月的同名库然后你会开始怀疑哪张是真的。四、写进去之前先确认这张表还活着这一章回答状态库最阴的失败模式以及 Notion API 的硬边界。我遇到过的最贵的一课是这个一张被我丢进回收站的库写它不会报错。当时有一个内容索引库我在 Notion 界面里把它删了进回收站但脚本里还留着它的 id。接下来的一段时间里写入调用返回成功任务日志一切正常索引一条也没有。因为对 API 来说一个处于回收站的对象仍然可以被寻址——它只是不在任何人的视野里了。所以第一条纪律是写入之后必须回读一次用回读的结果判定成功。写 -- 拿到返回的 page id 回读 -- 按 id 读一次属性确认值真的是我刚写的那个 判定 -- 回读失败才叫失败返回 200 不算Notion API 这一侧的硬数字建议记一下截至我核对时限制数值对定时任务意味着什么请求速率非企业版平均3 次 / 秒Business / Enterprise 约 10 次 / 秒一次跑十个库的批量任务必须串行或限速请求体上限500 KB长正文别整塞进一个属性要拆块超限响应HTTP429响应头带Retry-After退避要读这个头不要自己猜秒数这三条决定了状态层脚本的形状串行写、按 id 回读、遇 429 读 Retry-After 再退。我现在的写法是一个任务一次运行最多几十次 API 调用全部串行跑完约十几秒——对定时任务来说完全无所谓。读取侧还有三个坑都不是文档会告诉你的有的库只能按行rows模式取。我那张同步配置表用另一种查询方式拿回来的结构是残缺的换回逐行读才对。有的字段只有走 SQL 才暴露。月度日记库里那个页面链接属性普通查询里读不到走 SQL 查询才拿得到值。界面上的链接形态不等于存储值。有些属性在网页端渲染成一个漂亮的链接看起来像存了个 URL实际存的是文件关联。我曾按界面显示去修复过一遍结果把好的数据改坏了。这三条的共同点是你看到的表示层不等于存储层。写状态库的脚本必须以回读到的原始值为唯一事实别信界面也别信上一次调用的返回结构。五、把怎么读写写成 Skill而不是写进每次的 prompt这一章回答状态层为什么该由 Skill 承载以及 Skill 里到底要写哪几样东西。到这里能力其实已经齐了Notion 提供了存储MCP 提供了端点我这个会话里 Notion 那侧注册了 45 个工具。但这两样都不解决按规矩做。承接第八篇那张表——MCP 交付端点Skill 交付纪律——状态层恰恰是纪律最密的一层。一个状态 Skill 要写清楚的东西就四样Skill 里写什么为什么必须在 Skill 里哪个库、哪个视图、字段含义从配置表读但读配置表这个动作本身要有人教幂等键怎么算覆盖还是新增是状态库的第一生死线写后回读的判定标准返回 200 不等于成功这条只能写进文档禁止清单不许删行、不许改库结构、不许往工作区外面写禁止清单这一项我想多说一句。状态库的删除权限我一开始是给的因为万一写错了要清理。后来收掉了理由是清理动作应该由人做。一个能删行的 Agent写错只是一条脏数据删错就是丢历史。现在我的规则是Agent 只能新增和按幂等键覆盖要删必须人来点。幂等键的设计值得给一个具体例子。我的每日打卡行是这样的键date(2026-09-29) task(每日签到) 写存在则 update 那一行不存在则 create 读按 date 取当天全部行交给统计侧同一天里这个任务被跑三次正常调度一次、我手动补一次、重试一次库里永远只有一行字段值是最后一次的结果。而如果我想保留今天试过三次这个事实那是另一个字段attempts自增不是另开一行——行的语义必须唯一确定否则跨天统计一定会算错。最后把第七篇和这一篇接上外部世界 -- [入口] 状态库我做过什么、结果如何 定时任务 -- [出口] notify.py把结果喊出来没有入口的出口是聒噪没有出口的入口是哑巴。两个 Skill 各自管一头中间靠同一套幂等键串起来——通知里写的那句今日四项全部完成就是当天那四行状态的回读结果不是模型凭印象写的。把这条链画全就是我现在每天真正跑的形状六、本地 Markdown 为什么只能当导出物这一章回答为什么反过来不成立以及导出物到底值什么。我的同步配置里有一条每天 23:35把「待办与资源」整库导出成一份 Markdown 表格落到本地目录。这个动作看起来是多此一举——数据已经在 Notion 里了为什么还要一份副本因为 Markdown 有两样 Notion 给不了的东西导出物的价值具体表现可 diff状态变化进了 git能回答这周谁改了什么Notion 的版本历史在界面上不在工具链里可离线审计Notion 挂了、token 过期、库被误删进回收站我遇到过本地那份还是事实但反过来——把 Markdown 当主档、Notion 当导出物——不成立原因很硬没有行级唯一约束。一天一行靠约定一旦两个任务同时改同一个文件就是整篇覆盖。没有并发控制。git 能报冲突但定时任务不会停下来读冲突标记。人和机器看到的是两份东西。我要核对状态得开编辑器而不是随手刷一眼网页。换一台机器就要同步文件。而 API 是无状态的。所以正确的方向只有一个主档写 Notion副本落 Markdown副本永远不参与判定。一旦某个脚本开始读本地那份就会出现两份事实不一致的时刻——而那一刻你无法判断哪份是真的。我的处理是本地那份只用于三件事——进 git 留痕、被离线脚本 grep、在 Notion 不可用时人工兜底。任何统计口径都以库为准。七、几个绕不开的问题这一章回答向量记忆、删除权限、飞书能不能当主档、并发写、库会不会膨胀。Q1要不要直接上向量库 / 记忆插件让 Agent 自己记我试过然后退回来了。差别在于可核对性。向量检索返回的是语义相近的片段它回答的是我大概记得不是2026-09-29 这一天这一项的状态是已完成。定时任务要的是后者。更麻烦的是它没法审计结果不对时你无法回答为什么召回了这条。我的取舍是——事实用结构化状态库存经验用 Skill 文档存向量检索只用来辅助找文档绝不参与判定。Q2状态库要不要给 Agent 删除权限不要。理由在第五节说过写错是一条脏数据删错是丢历史。我的权限边界是这样切的新增 允许 覆盖 允许仅限命中幂等键 改结构 禁止新增字段、改字段类型 删行 禁止必须人来点 删库 物理上做不到作用域只到页另外有一条更前置的边界可写区只有一个。我在 Notion 里给 Agent 划了独立工作区其余个人笔记区一律只读。这条比任何字段级权限都有效因为它把误写的爆炸半径限死在一个目录里。Q3飞书多维表格能不能当主档能而且如果你的状态需要被别人看它比 Notion 更合适——权限体系、图表、和 IM 的连通都是现成的。我上一节给它的定位是团队场景优先。真正要提前确认的是两件事应用权限有没有开全没开全时它返回的是业务错误码而不是 HTTP 错误很容易看漏以及你的定时任务能不能长期持有那个 tenant token。这两点解决了飞书和 Notion 之间就是口味问题。Q4多个 Agent 同时写同一行怎么办Notion 不会告诉你冲突后写的覆盖先写的。我的做法是从调度上避免而不是从存储上解决同一个库的写入只允许来自一个任务需要多任务参与时给每个任务一个自己的字段。必须并行时用幂等键把范围切小不同日期、不同任务名天然不冲突。真出现同一行被两方改的情况就把它当成设计错误——说明这张库的职责划分不对。Q5状态库会不会越写越大最后没法用会所以要预先定归档策略。我现在是两条按月分表发文日盘这种高频表和只保留滚动窗口bios 这种摘要表只留最近 N 天历史靠导出物。判断标准很简单一张表如果它的当前视图需要滚动三屏才能看完就该分了。分完记得把新表 id 更新进同步配置表——回到第三节那条规矩脚本永远只从配置表拿 id。最后总结只要任务会重复跑它就需要外部状态。上下文不是状态它连今晚都活不过。主档选 Notion 的理由不是它强是我能一眼核对。不能随手检查的状态库最后都会变成没人信的黑盒。配置也要进库幂等键必须唯一写后必须回读。这三条是状态层的全部纪律缺一条就会出事。本地 Markdown 只做导出物绝不参与判定。它的价值是可 diff 和离线兜底不是并发写入。可写区只有一个删除权限不给 Agent。把爆炸半径限死比事后校验有效得多。对后端 / 架构方向的开发者我更想说的一句这套东西本质上就是一个只有单写者、按天分区、带软删除的极简数据仓库。你在业务系统里学到的那套约束——唯一键、写后确认、归档策略——一条都省不掉只是执行者从服务变成了模型。参考资料 致谢[1] Notion Developers - Request limits速率与请求体上限[2] Notion Developers - API 参考首页[3] Agent Skills - 开放规范 Specification[4] Model Context Protocol - 官方规范首页[5] 飞书开放平台 - 多维表格记录 API 文档