一个人 = 一支AI军团：深度体验PilotDeck智能体操作系统，从长篇写作到多项目管理的全流程拆解

本文由 莫潇羽@源码七号站（www.fuyuan7.com） 撰写，转载请注明出处。

快速摘要

AI Agent 好用吗？好用。但用久了你会发现一个让人抓狂的问题——它在不同项目之间的记忆会"串台"。 你今天在A项目里问了一句"怎么快速止嗝"，明天写B项目的严肃长文时，AI 莫名其妙就把这段记忆混了进来。聊得越多越混乱，项目越多人越崩溃。

PilotDeck 是 OpenBMB（清华大学 THUNLP 实验室 + 面壁智能 + AI9Stars 联合开发）在 2026 年 5 月开源的一款"智能体操作系统"。它的核心设计理念叫 WorkSpace（工作舱）——每个项目拥有完全独立的文件系统、记忆空间和技能模块，项目之间的记忆天然隔离，互不污染。

我自己折腾了一个多月，用它搭建了一套长篇内容创作系统的原型。实测下来，多 Agent 协同写作 + 白盒记忆管理 + 智能路由省 Token 这三板斧，确实解决了长期用 AI 写作的几个核心痛点：写到后面忘前面、不同项目记忆串台、Token 消耗无底洞。这篇文章就是我的完整实操拆解。

想看完整拆解，往下翻。

一、AI Agent 的"失忆症"——为什么多项目协作总翻车

不知道你有没有遇到过这种场景。

晚上十一点，你打开某个 Agent 工具，建了个新对话，准备写一篇准备了很久的技术长文。开头写得还挺顺，写到第三段的时候，AI 忽然在段落里插了一段跟你当前主题完全不搭的引用——仔细一看，那是你上午在另一个对话框里聊过的家庭琐事。

瞬间出戏。

这个问题我遇到过不下几十次。市面上大多数 Agent 和聊天式 AI 工具，记忆管理其实是"全局共享"的。你可以想象成一个大水缸，所有对话产生的记忆都往里倒。表面上看 AI 越来越"懂你"，但代价是不同话题的上下文会互相渗透。

1.1 这其实是个架构问题

回头想想，这事本身就反常识。你和张三聊天，李四不会知道你们聊了什么。但在 AI 工具里，A 对话框的内容跑到 B 对话框里，系统居然觉得理所当然。

根源在于，大多数 AI Agent 在设计时就没考虑过"多项目并行"这个场景。它们以"会话"为单位组织信息，用全局记忆把所有会话串在一起。对于轻度使用来说，这确实方便——AI 记得你喜欢什么风格、偏好什么表达。但一旦你要同时维护五六个不同类型的项目，全局记忆就变成了灾难。

我列一下自己踩过的坑：

这还只是写作场景。如果你同时在做多个项目——写文章、分析数据、整理文档——混乱程度翻倍。

1.2 长文写作的特殊困境

写作这件事，对记忆的要求比一般任务苛刻得多。

想象一下写一本网络小说：前100章埋下的伏笔，到第500章要回收。世界观架构里某个不起眼的规则，可能在第300章成为关键剧情转折。人物关系图谱随着剧情推进不断变化——谁和谁是敌是友，谁的立场发生了转变。

人类作者用大纲、角色卡、设定集来管理这些信息。但当你把写作交给 AI Agent 时，大多数工具的上下文窗口根本装不下几百章的内容。更麻烦的是，即使上下文窗口够大，把全部历史一股脑塞给模型，Token 成本直接就爆了。

我拿 Claude Code 做过实验。写完一次，关掉，下次重新打开——它完全不记得上次写过什么。这不是模型能力的问题，而是架构层面缺少一套外部记忆持久化机制。

但这些问题的根源，其实不是模型不够聪明，而是缺乏一套能让记忆"有边界、可追溯、可管理"的操作系统层。

二、PilotDeck——这到底是个什么东西

2026 年 5 月 28 日，OpenBMB 社区在 GitHub 上正式开源了 PilotDeck。如果你关注 AI Agent 领域，应该对 OpenBMB 不陌生——这个社区背后的技术力量来自清华大学 THUNLP 实验室和面壁智能（ModelBest），前几年出过不少在开发者圈子里口碑很好的开源项目。

PilotDeck 的官方定位很有意思，他们管它叫"智能体操作系统"（Agent OS），或者更形象地说，叫"智能体协作舱"。这个名字不是随便起的，它确实透露了这个项目的核心设计思路。

2.1 用操作系统的思维来做Agent

PilotDeck 的底层语言是 TypeScript，前端用 React + Vite + Tailwind + shadcn/ui 搭建，版本号截至写作时是 v0.0.11（发布头三天就连续迭代了好几个版本，更新相当勤快），采用 AGPL-3.0 开源协议。

它把操作系统的几个核心概念搬到了 AI Agent 领域：

这个类比不是营销话术，而是实实在在地反映在架构设计上。我自己折腾下来最大的感受就是——它确实用"项目"（而非"会话"）作为信息组织的基本单元，这个设计决策几乎决定了后续所有体验的走向。

2.2 项目的技术架构

翻了一下它的源码结构，几个核心模块值得展开说一下：

src/
├── agent/          # Agent 核心：loop、runtime、session、sub-agent
├── always-on/      # 后台执行引擎
├── context/        # 上下文管理（记忆、压缩、预算、恢复）
├── router/         # 智能路由（编排、场景、tokenSaver、统计）
├── mcp/            # MCP 协议客户端 / 运行时
├── gateway/        # API 网关层
├── extension/      # 插件系统
├── lifecycle/      # 生命周期管理
├── permission/     # 权限控制
├── tool/           # 工具接口层
├── session/        # 会话管理
├── task/           # 任务系统
├── adapters/       # 前端适配器（Web / CLI / IM）

这里面有几个设计我觉得很有前瞻性：

context 模块独立出来做上下文管理和记忆压缩，这意味着记忆的存储、压缩、恢复是一套独立于 Agent 推理流程的完整系统——后面要展开讲的白盒记忆和 Dream Mode 都依赖这个模块。

router 模块做的是子 Agent 级别的模型路由，而不是每次请求都切换模型。这个区别看着小，实际上影响很大——子 Agent 级别的路由不会打断 KV-cache，推理效率高得多。

adapters 层让它支持 Web UI、桌面端（macOS/Windows）、命令行和 IM（飞书/企业微信），多端适配是基建级别的能力，不需要在业务层反复处理。

2.3 它和同类工具的区别在哪

如果用一句话总结：Claude Code 的本质是编程 IDE 套了 AI，OpenClaw 是通用 Agent 框架，PilotDeck 是在它们之上一层——面向多项目并行的 Agent 操作系统。

具体对比：

这个对比表没必要拉踩谁好谁坏，不同工具适合不同场景。如果你是纯写代码，Claude Code 仍然是这个领域最顺手的。但如果你跟我一样，需要同时维护好几个完全不同类型的 AI 创作项目，PilotDeck 那种"每个项目是一座独立的岛"的设计哲学就会让你觉得很解渴。

三、WorkSpace 工作舱——项目隔离才是真正的杀手锏

如果说 PilotDeck 只有一个功能值得长篇大论地讲，那一定是 WorkSpace。

不是因为其他功能不重要，而是因为 WorkSpace 是整个系统的地基。智能路由、白盒记忆、Skill 系统、Always-on——所有这些能力都建立在 WorkSpace 的项目隔离机制之上。地基没打牢，上面盖什么都晃。

3.1 什么叫"项目隔离"，说人话

先讲个我自己的真实经历。

去年下半年，我开始同时用同一个 Agent 工具维护两个完全不同的内容项目：一个是在写一套偏严肃的企业数字化转型系列文章，另一个是在做一个偏轻松的游戏剧情脚本。风格毫无交集，领域完全不搭，受众更是两拨人。

但那个 Agent 工具的全局记忆不管这些。它把我的偏好、表达习惯、常用词汇全部搅在一起，慢慢就出现了"风格漂移"——企业文章里开始冒出游戏的台词感，游戏脚本里又时不时蹦出"数字化转型""组织赋能"这种八竿子打不着的词。

这个问题困扰了我好一阵子。后来我发现很多人都有类似遭遇：做学术论文的和写小红书笔记的记忆混在一起，写技术文档的和做营销文案的风格互相污染。根源就在于那些工具拿"全局记忆"当卖点，却忽略了用户并不需要一个什么都记得的 AI——用户需要的是一个在该记得的地方记得、在该忘记的地方忘记的 AI。

PilotDeck 的 WorkSpace 把这个逻辑反过来：默认什么都不共享，除非你主动要求共享。

3.2 WorkSpace 的三层隔离

打开 PilotDeck，你见到的不是一排对话框列表，而是若干个"工作舱"。每个工作舱是一个独立项目，里面包含三层东西：

graph TD
    A[WorkSpace 工作舱] --> B[专属文件系统]
    A --> C[专属记忆空间]
    A --> D[专属技能模块]
    B --> B1[Markdown 文件]
    B --> B2[代码文件]
    B --> B3[配置文件]
    C --> C1[项目记忆]
    C --> C2[反馈记忆]
    D --> D1[已安装Skill]
    D --> D2[Skill配置]

第一层：专属文件系统。 每个 WorkSpace 有自己的文件目录，你在项目里生成的 .md 文档、设定的角色卡、积累的素材库，全部存在这个项目内。切换到另一个项目，文件列表是完全独立的，看不到上一个项目的东西。

这听起来好像没什么大不了的——文件夹隔离不是操作系统的基本功能吗？但对 AI Agent 来说，这意味着 Agent 在 A 项目中创建和读取的文件天然不会"泄漏"到 B 项目。Agent 处理文件时不需要先判断"这个文件是哪个项目的"，因为它的操作域已经被 WorkSpace 边界限定好了。

第二层：专属记忆空间。 这是含金量最高的一层。每个 WorkSpace 维护自己独立的记忆库，包含两部分：Project Memory（项目记忆）和 Collaboration Feedback（反馈记忆）。Project Memory 记录项目进度、设定、关键决策；Feedback Memory 记录你在这个项目里的偏好、风格要求和互动习惯。

关键是这两类记忆都不会跨 WorkSpace 共享。你在"A 项目-小说创作"里告诉 AI 你喜欢简洁干练的文风，这个偏好只存在于小说项目里。切换到"B 项目-技术文档"后，技术文档的 Agent 不会知道你写小说时用过什么文风偏好——除非你在技术文档项目里也明确说过你喜欢什么风格。

第三层：专属技能模块。 Skill 的安装、配置和使用都是项目级的。在小说项目里安装的"去套路化写作 Skill"，不会出现在你的数据分析项目里。这个后面讲 Skill 系统时会展开。

3.3 实际体验——建了两个项目做对比

为了验证隔离效果，我故意做了个对比测试。

在"项目 Alpha"里，我告诉 Agent："我写文章喜欢用短句，每段不超过四行，多用生活化的比喻。"整个项目过程中，Agent 确实保持了这个风格。

在"项目 Beta"里，我什么都没说，让 Agent 保持默认状态。

两个项目各聊了十几轮后，我再回到项目 Alpha，Agent 仍然按照短句+比喻的风格输出。切换到项目 Beta，默认风格，没有受到任何 Alpha 项目的影响。

这事如果放在全局记忆的 Agent 工具上，项目 Beta 大概率已经被项目 Alpha 的偏好"污染"了。

3.4 不止是写作——这个设计为什么重要

WorkSpace 隔离的意义不只体现在写作场景里。往大了说，它解决的是一个 AI Agent 走向"生产力工具"的必经门槛——可管理性。

一个人用 AI 做事情，天然就是多项目的。早上查资料写报告，下午分析数据做表格，晚上搞点个人创作。如果这些场景的记忆混在一起，AI 帮你越多，混乱感就越强。WorkSpace 让每个 AI 项目都像运行在一个独立的虚拟机里，各自的资源、配置、记忆互不干涉。

这让我想起腾讯收购游戏工作室的策略——买了很多工作室，但每个工作室保持独立创作，不强行"整合"。结果反而出了不少好作品。PilotDeck 的思路异曲同工：不强求 AI 在所有场景下都"打通"，而是让每个项目的 Agent 保持专注。

3.5 几个让我觉得"这才对嘛"的细节

除了三层隔离本身，WorkSpace 在交互层面还有几个细节让我觉得设计团队真的想清楚了。说几个我实际用下来感受比较深的。

跨项目切换的零摩擦感。 从项目 A 切到项目 B，不需要手动"关闭上下文""清空记忆""重新配置"——点一下切换按钮，整个环境就换了。文件列表换了、记忆库换了、已安装的 Skill 也换了。这个切换速度快到你会觉得它本来就应该这样——但用过全局记忆工具的人都知道，"本来就应该这样"的东西，市面上大多数产品根本没做到。

项目级别的配置继承。 WorkSpace 可以基于模板创建。比如你有一个"写作项目"的配置模板——里面预装了去 AI 味 Skill、配置好了记忆管理策略、设定了适合创作类任务的模型路由偏好——你就可以基于这个模板快速创建新的写作项目。不用每次从零开始搭，但创建出来的新项目是完全独立的，不会和老项目的记忆混在一起。这个设计兼顾了"效率"和"隔离"，在操作系统的世界里这是常识，但在 Agent 工具里目前还比较少见。

文件归属的视觉反馈。 在右上角文件面板里打开的文件，视觉上明确标注了它属于哪个 WorkSpace。你不会在 A 项目的文件列表里看到 B 项目的文件。这是一种"确定性的安全感"——当你同时开了好几个项目在跑的时候，你不会怀疑"这个文件到底是哪个项目里的"。这种安全感在全局记忆工具里是很难获得的，因为那些工具的文件归属往往是模糊的，全堆在同一个目录下，靠文件名前缀来辨认。

这些细节单独看都不算什么大功能，但凑在一起，就构成了一个"可以放心把项目交给 AI 长期维护"的基础。你不需要每次都检查一遍"AI 有没有把 A 项目的东西记到 B 项目里"，系统帮你把这个担忧消化掉了。

四、白盒记忆——你可以随时打开 AI 的"脑子"翻看

如果说 WorkSpace 隔离是地基，那白盒记忆就是盖在这地基上最核心的一层楼。

聊白盒记忆之前，先说说"黑盒记忆"是怎么回事。目前大多数 AI Agent 的记忆系统，对用户来说是不透明的。AI 记住了什么、为什么记住这些、有没有记错的、是不是该删掉的——你一概不知道。你只能从 AI 的回复里"猜"它记得什么，猜错了就出问题。记忆在你眼前，但你碰不到。

PilotDeck 的记忆设计是相反的——你能看到，也能动手改。

4.1 记忆面板——每条记忆都摆在你面前

在界面右上角点开"记忆"标签，你会看到一个清晰罗列的记忆条目列表。每条记忆都标了时间戳、来源路径和类型标签（Project Memory 还是 Collaboration Feedback）。

这种感觉怎么形容呢……就像你打开了一个人的日记本，每一条记录都写好了日期和来由，你可以翻、可以改、可以撕。对 AI 来说可能有点残酷（笑），但对使用者来说，这种透明感是前所未有的。

给你看看我在写作项目中积累的一些记忆条目的结构：

这种透明度带来一个直接好处——你可以在写作之前快速扫一眼记忆列表，看看 AI 对当前项目"理解"成什么样了。如果发现 AI 记错了某个设定（比如把"主角能力 CD 为 12 小时"记成了"6 小时"），直接手动编辑修改，不需要重新跟 AI 解释一遍。

4.2 手动修改 vs 自动更新——双轨并行

PilotDeck 的记忆管理有两个轨道：

自动轨道：对话驱动。 你和 Agent 的对话过程中，当出现相互冲突的偏好时，新偏好自动覆盖旧偏好。当出现新设定、新决策时，系统自动把关键信息追加到记忆中。这个机制跟大多数 Agent 工具类似，区别在于它是可见的——你可以随时去验证它是不是真的记对了。

手动轨道：白盒操作。 你可以随时打开记忆面板，查看、编辑、删除、置顶任意一条记忆。不需要走"对话→AI 理解→更新记忆"的路径，直接改就行了。

两个轨道同时工作，这种设计挺聪明的。自动轨道保证你不会错过该记的东西，手动轨道保证你不会被记错的东西坑到。

4.3 Dream Mode——AI 也有"睡眠巩固"

这是 PilotDeck 记忆系统里最有想象力的功能，名字也起得好。

Dream Mode（做梦模式）的设计思路是这样的：当系统处于空闲状态时，Agent 会自动启动一个后台任务，像人睡觉时大脑整理记忆一样，对已有的记忆条目进行梳理、去重、压缩和归纳。重复的记忆合并，矛盾的记忆标出，过时的记忆归档。整理完成后，生成一份"记忆整理报告"，你可以一键回滚。

为什么要有这个功能？因为随着项目推进，记忆条目会越来越多。世界观设定可能有几十条，章节剧情记录可能上百条，用户偏好也可能随项目阶段变化。如果不定期整理，"记忆库"就会变成一个巨大的杂物间——东西都在里面，但要用的时候找不到。

Dream Mode 的聪明之处在于，它不是简单地"压缩记忆"（那样会丢信息），而是模拟了人类记忆巩固的过程：睡眠时大脑会把白天获取的信息从海马体转移到皮层，筛选重要的长期保存，不重要的自然遗忘。PilotDeck 的 Dream 做的是类似的事——它不是在删记忆，而是在给记忆重新"建档"。

而且支持一键回滚，这就给了你充分的安全感。万一 Dream Mode 整理错了（比如把两个相似但不同的设定合并了），你可以立刻退回到整理前的状态。

Dream Mode 的触发时机也值得一提。它不是到了某个固定时间就强制执行的定时任务——如果是那样，很可能正好在你正在用 Agent 的时候"做梦"，打断工作流。它的触发逻辑是"检测到空闲窗口 + 记忆条目数超过阈值"的双条件判断。系统判断你当前没有活跃的对话在进行、且记忆库已经积累到了一定规模，才会启动 Dream 整理。这个设计避免了"你想用 Agent 干活但它在忙着做梦"的尴尬。对经常长时间挂机的用户来说，这个细节处理得相当到位。

4.4 为什么非要有白盒记忆不可

回到写作场景，这个问题就更清楚了。

长篇创作最大的敌人不是"写不出来"，而是"写到自己前后矛盾"。一个设定在第 30 章改了，但 AI 记的还是第 10 章的版本，从第 31 章开始剧情就歪了。这些问题在黑盒记忆模式下，你只能等 AI 出了错再回去修——修的成本往往比重写还大。

白盒记忆让你在剧情跑偏之前就能发现并纠正。AI 记了什么你一清二楚，不对就改。对长篇创作来说，这种"可验证性"比"记住更多"重要十倍。

五、多 Agent 协同实战——搭建一套不会忘剧情的写作系统

前面聊的都是"为什么"，这章进入"怎么做"。

我用 PilotDeck 搭建的这套写作系统，名字说不上多高级，但结构是认真设计过的。它由四个 Agent 协作完成长篇内容创作：一个负责最终输出正文的"主写作 Agent"，三个负责前期准备的"设定 Agent"——分别处理世界观架构、人物设定和章节细纲。

整套系统的核心思路就一句话：把"创作"这件事拆成可管理的流水线，每一步都有外部化的产物沉淀，而不是让一个 Agent 在上下文窗口里死扛所有信息。

5.1 为什么要拆成四个Agent

这事得从写作流程本身说起。

写一个长篇，从零到产出第一章正文，中间隔着好几道工序。你要先想清楚这个世界是怎么运转的（世界观），然后确定谁在这个世界里行动（人物），再规划他们依次做什么事（细纲），最后才是逐章码字。这是创作者再熟悉不过的三段式准备流程：世界观 → 人物 → 细纲 → 正文。

关键是，这四个步骤之间存在明确的单向依赖关系。先有世界，才有人物存在的合理性；先有人物性格，才有合乎逻辑的剧情走向。步骤之间环环相扣，但每步的任务性质和产出物完全不同。

如果我把世界观、人物、细纲和正文全部塞进一个 Agent 的上下文窗口里，会发生什么？信息量太大导致 Agent 注意力分散，世界观细节可能在写到第 50 章时被遗忘，人物性格可能在漫长的对话过程中发生"漂移"——Agent 悄悄地把配角的行为模式写得和主角一样了（这是长对话 Agent 的经典问题）。

更致命的是，单个 Agent 在黑盒里完成所有设定后，你作为作者根本没法审阅它到底"想"了些什么。你只能从最终输出的正文质量反推设定有没有问题——这是一种非常被动的协作方式。

拆成多个 Agent 的逻辑很直接：

graph LR
    A[世界观Agent] -->|输出世界观Skill| B[人物Agent]
    B -->|读取世界观+输出人物Skill| C[细纲Agent]
    C -->|读取前两者+输出细纲文件| D[正文Agent]
    D -->|读取所有设定+输出正文| E[正文.md]
    D -->|每章更新| F[剧情记忆文件]
    F -->|下一章写作前读取| D

5.2 世界观 Agent——先让AI追问你，而不是你追着AI喂

我创建世界观 Agent 的时候，设了个初始目标：为一本都市异能题材的长篇小说构建完整的世界观体系。

有趣的事发生了。Agent 没有像 ChatGPT 那样立刻甩出一个"在某个平行世界，人类觉醒了超能力……"的模板化开头。它反过来问了我一连串问题。

"这个世界里异能是如何产生的？先天遗传、后天觉醒、还是外部注入？"

"异能在社会中是公开存在的还是隐秘的？如果是隐秘的，维持这个秘密的机制是什么？"

"主角的异能定位在什么水平？和其他能力者相比处于什么位置？"

我一轮一轮回答，前前后后大概回答了七八组追问。每轮追问都建立在我上一轮的答案之上，逐渐把我想法里的空白区域给填上了。说实话，这感觉确实不像在跟一个聊天机器人交流——它像是有经验的策划在帮你把脑洞补全。

最终产出的世界观设定文档，细化程度超出了我的预期。让我截取一段展示一下结构：

## 世界观设定概览

### 一、世界背景
- 时代：近未来（2087年）
- 社会形态：表面正常运转的现代社会
- 隐藏层：异能者构成的"里世界"

### 二、异能体系
#### 2.1 觉醒机制
- 触发年龄：18岁生日当天（称为"烙印日"）
- 觉醒条件：经历一次濒死体验
- 能力分类：元素系、精神系、时空系、生命系、特异系

#### 2.2 能力等级
| 等级 | 名称 | 人数占比 | 特征 |
|------|------|---------|------|
| Lv.1 | 初觉者 | 80% | 能力不稳定，时灵时不灵 |
| Lv.2 | 掌控者 | 15% | 可在常规场景下主动使用 |
| Lv.3 | 精英 | 4% | 可同时驱动两种能力 |
| Lv.4 | 领主 | 0.9% | 拥有领域级影响力 |
| Lv.5 | 神座 | 0.1% | 传说级，全球不超过10人 |

### 三、庇护所体系
- 功能：异能者的半地下生存网络
- 日常运转：物资调配、身份伪装、冲突仲裁
- 管理结构：长老会+区域执事
- 筛查机制："烙痕检测"（通过特殊光谱扫描识别能力者）

世界观文档不仅涵盖了"异能怎么来的""世界是什么样子"这类宏观设定，连庇护所的日常运营规则、能力者身份筛查手段、不同派系的意识形态分歧这些中观甚至微观层面的东西都有了完整的描述。这在我用过的其他 Agent 工具里是很难做到的——它们通常在"世界是什么"这一步就停下来了，要你反复追问才会补充细节。

5.3 人物 Agent 和细纲 Agent——让前序产出成为后序输入

世界观搞定后，人物 Agent 的工作就有一个稳固的地基。在创建人物时，Agent 会先去阅读世界观 Skill（也就是上一步产出的设定文件），理解这个世界的规则之后，再基于故事核心去设计角色。

举个例子：世界观设定里规定了"异能首次觉醒在 18 岁生日当天"。人物 Agent 在设计主角时，就会自然地围绕"18 岁生日那天的濒死体验"来构建角色的起源故事——而不是凭空编一个和世界观冲突的来历。

人物设定产出后，细纲 Agent 接过接力棒。细纲 Agent 同样会先读取世界观和人物设定的文件，基于已确立的世界规则和人物性格来规划剧情走向。这个"逐层递进"的设计保证了：世界观里的规则限制会约束剧情不会跑偏，人物性格会驱动情节走向而不是被情节推着走。

细纲有一个设计细节值得单独提一下：可扩展的追加写入机制。

细纲文件不是一次性生成完就冻结的。PilotDeck 会把细纲保存为一个 .md 文件，后续需要新增章节细纲时，Agent 会自动把新内容追加到这个文件的末尾，而不是覆盖或创建新文件。这个设计保证了正文 Agent 在需要查阅细纲时，一个文件就能看到所有已规划的章节。

在 PilotDeck 右上角的"文件"面板里，你可以直接打开当前项目的文件目录，世界观、人物、细纲、正文全在里面，结构一目了然。

5.4 主写作 Agent + 记忆系统——解决"写到后面忘前面"

正文写作 Agent 是整个系统里最关键的一个环节。单靠 PilotDeck 自带的记忆系统还不够，我额外设计了一套"流程性记忆"。

我的做法是：在正文 Agent 的工作流里加入一个步骤——每写完一章，自动更新一个"剧情记忆文件"，记录本章的核心剧情、已埋下的伏笔、人物状态变化。下一章写作之前，先把这个记忆文件读一遍。

写作流程：

第 N 章写作前：
  1. 读取"剧情记忆文件.md"（回顾已有剧情）
  2. 读取"细纲文件.md"（获取当前章节规划）
  3. 必要时查阅"世界观Skill"和"人物Skill"（确认设定细节）
  4. 开始写作第 N 章正文

第 N 章写完后：
  1. 运行"去AI味优化"流程
  2. 更新"剧情记忆文件.md"（追加第 N 章摘要+伏笔+状态变更）
  3. 输出正文到文件目录

这套机制的核心价值在于，它把"上下文"从 Agent 的会话窗口转移到了外部文件里。Agent 不需要在每一轮对话中重读全书——它只需要读取一份不断更新的"剧情摘要 + 伏笔清单 + 状态记录"就够了。这份文件的体积远小于把几百章正文全部塞进上下文的做法。

这同时解决了两个问题：

第一，记忆连贯性。哪怕你关了电脑三天后再打开，Agent 只需要读取记忆文件就能快速进入状态，不会出现"你是谁我在哪这小说写到哪了"的尴尬。

第二，Token 经济性。与其每轮对话都重读全部几百章的历史记录（那是真的烧钱），不如让 Agent 读取精心维护的摘要式记忆文件。信息密度更高，成本反而更低。

这套系统的"记忆规范"本身也被纳入了 PilotDeck 的项目记忆中——也就是说，Agent 会记住"每次写作前要先读记忆文件"这件事，不需要你每次手动提醒。

展开说一下这个记忆文件的结构设计。一份典型的长篇创作记忆文件，大致长这样：

# 小说剧情记忆文件

## 卷次概览
- 第一卷（第1-30章）：觉醒篇 ← 已完成
- 第二卷（第31-80章）：庇护所篇 ← 进行中（已写到第47章）

## 核心伏笔追踪
| 伏笔 | 埋下章节 | 计划回收章节 | 状态 |
|------|---------|-------------|------|
| 林越手腕上的神秘数字"2047" | 第3章 | 第55章 | 待回收 |
| 陈默的真实身份 | 第12章 | 第42章 | 已回收 |
| 地下实验室的秘密入口 | 第28章 | 第70章 | 待回收 |

## 人物关系变更记录
- 第3