AI Agent 不只是聊天机器人。当它真正在电脑上长期运作，管理项目、执行调度、产出内容，它就需要一套文件系统来存放记忆和工作记录。

这件事听起来不难：建几个文件夹、写几份文档、设置命名规范，应该就能搞定。

实际上，这可能是 AI Agent 系统中最容易被低估的工程挑战。

当规则管不住自己

一个跑了两个多月的 AI 助理系统，某天打开检查时，会看到这类状况。

记忆索引文件 MEMORY.md 的规定是「控制在 1KB 以内」，实际大小是 7KB，超标七倍。原因出在系统每天都在产生新的知识，却只有一个地方可以放，问题不在没人注意到。

X 平台的内容草稿散落在四个不同的路径。两个几乎同名的文件夹（reference 和 references）各自存着不相关的文件。十几天内自动产生了将近三百个记忆文件。

这些问题有一个共同特征：系统连自己写下的最简单规则都无法遵守。

直觉的反应是加更多规则、更严格的规范。但这里有一个值得停下来想的问题：现有规则已经失效了，加新规则会让情况好转吗？

让 AI 自己辩论怎么办

为了避免陷入单人视角的盲区，可以设计一场实验：让四个 AI Agent 分别扮演不同立场，各自阅读三份研究报告（ChatGPT Deep Research、Perplexity 搜索分析、一份学术报告），然后从各自的角度提出解决方案。

四个角色的设置如下。

实用派的信念是「不修没坏的东西」。他把现有系统跟研究建议逐一比对，发现分层启动、按需读取、记忆压缩这些机制其实都已经到位了。他的态度是：别因为研究报告看起来很厉害就急着大改。

架构师的信念是「结构债的利息比金融债更高」。他拿现有的成长数据推算一年后的状况。照当时的速度，记忆目录一年后会累积超过五千个文件。他认为现在能用不等于三个月后还能用。

失败分析师不看理论，只看证据。他直接翻遍整个文件系统，列出每一个放错的文件、每一条被违反的规则。他的角色是指出每个方案会怎么失败，提出方案这件事留给别人。

迁移策略师不站队，只关心一件事：如果决定要改，怎么改才不会把现有系统搞坏。他为每个改动设计了回滚路径。

核心冲突：要加结构还是要减规则？

四个角色的分析摊开来看，很快浮现一个核心矛盾。

失败分析师的立场很明确：系统已经无法遵守现有规则了，加更多结构只会让负担更重。他的预测：强制要求每个文件加 YAML 标头，合规率三周内会掉到 50% 以下。因为 AI Agent 不断产生新文件，没有人会每次都记得加。

架构师的反论也站得住脚：MEMORY.md 会膨胀到七倍，根因是结构上没有其他地方可以放那些知识，纪律问题只是表象。信息只有两个去处：索引文件（会塞爆）或每日笔记（会随归档消失）。

两个观点看似互相矛盾，但仔细看，它们在说同一件事。

MEMORY.md 之所以膨胀，是因为写进 MEMORY.md 比建立新的主题文件容易。草稿之所以四散，是因为没有一个明确的「正确位置」让人（或 AI）自然地把东西放对。

「架构 vs 纪律」并非真正的二选一。架构设计得让正确行为成为阻力最小的路径，纪律就会自然成立。

这个结论听起来简单，但它改变了后续所有决策的判断标准。不再问「这个规则够不够严格」，而是问「这个设计让正确行为变得更容易了吗」。

做了什么

最终采用的方案集中在三件事上。

第一，把单一的记忆索引拆成索引加主题文件。原本 7KB 的 MEMORY.md 变成不到 500 bytes 的纯索引，加上十几个按主题分类的独立文件。AI 启动时只加载索引，需要时再读对应主题。这一个改动就让启动消耗的 token 减少了相当大的比例。

第二，把启动流程从自然语言描述改成严格的步骤清单。直接写「第一步读这个文件，第二步读那个文件」就好，「请按照以下原则」这种讲法太松。越明确，AI 越不会漏掉或自行发挥。

第三，建立轻量的目录索引，用 Markdown 格式每周自动重建。不用 JSON，不用数据库。过期了也不会坏，只是少一份参考。

刻意不做什么

这可能是这场辩论最有价值的产出。

不使用 Johnny Decimal 目录编号系统。把所有文件夹用数字重新命名（11.02 取代 project_a）。听起来很有组织性，实际上要重新命名数十个项目目录，所有代码中写死的路径全部会断。而且语义名称对 AI 来说比数字更有意义，project_a 比 11.02 好理解得多。

不使用 Zettelkasten 原子笔记系统。学术界推崇的知识管理方法。但当时整个系统只有几十个笔记，用学术级的知识管理系统来管理这个规模，就像用 ERP 系统来管理家庭记帐。

加密杂凑防漂移。用密码学方法检测文档是否被意外修改。一个人用一台电脑的系统，git diff 就够了。

把状态文件改成 JSON 格式。结构化程度更高，但人类可读性直接消失。在手机上快速扫一眼状态的需求，比程序自动解析更频繁。

这些方案都有道理，但在目前的规模和使用情境下，它们解决的问题还没有发生。失败分析师给了一个很好的判断框架：先为两倍规模设计，到达两倍时再重新评估。不要为了假想的一百倍去工程化。

五个容易踩的坑

失败分析师在辩论中指出了五个设计 AI Agent 系统时常见的隐藏假设。这些假设看起来合理，没有意识到它们的存在，很容易做出过度设计的决策。

「AI Agent 像数据库运作」。不是。Agent 是语言模型，它读文字、推理、再输出文字。为它设计 key-value 查询式的结构，方向可能就错了。

「找不到文件是主要瓶颈」。实际上的瓶颈往往是「知道要去找」。文件夹再整齐，Agent 如果不知道某个文件的存在，整齐也没有用。

「更多结构等于更可靠」。结构创造耦合，耦合创造脆弱性。每多一层抽象，就多一个可能坏掉的接点。

「系统将来会大幅扩充」。也许会，但现在设计未来的架构，往往是在为还没出现的问题花今天的成本。

「Agent 会遵守新规则」。这是最危险的假设。每加一行规则，所有既有规则获得的注意力就被稀释一些。规则总量越多，每条规则被遵守的概率越低。

后来怎么样了

三个月后回头看，几件事值得记录。

实用派的判断基本正确。真正产生效果的改动就是最初的三件事：记忆拆分、启动清单、命名规范。做完这些，系统的混乱程度就有了明显改善。

架构师提出的四层记忆模型到现在只用了两层半。设计本身没问题，需求还没长到那里而已。

失败分析师的预测最准。他说「强制 YAML 标头三周内合规率掉到 50%」的论证太有说服力，根本没实施。他担心的目录索引过期问题确实发生了，但每周自动重建足以应对。

迁移策略师的回滚框架在实践中最有用。尝试了两个方案后决定退回，过程完全没有造成损害。能安心地尝试和放弃，本身就是好的系统设计。

带走一件事

要建自己的 AI Agent 系统，或者正在烦恼为什么自动化流程越来越乱，这场辩论浓缩成一句话：

别急着加规则。先去看为什么现有规则没被遵守。

答案通常出在结构上没有让正确行为成为最容易的选择，「AI 不够听话」只是表象。

把正确的事情变成最省力的事情，剩下的就会自然发生。

延伸阅读

小企鹅的经验

小企鹅实际运作 OpenClaw 上的 Opus / Sonnet / Codex 三 agent 一段时间，记忆全部走 markdown 文件，没接 RAG 也没接向量数据库。这场辩论讲的两件事在实战里反复验证：第一，能用结构解掉的就不要靠规则约束（比方说把每个项目的 context 放在项目文件夹里，自然就会被读到，不需要强制 AI 记得查）；第二，最少够用就好（四层记忆到现在只用了两层半，剩下的留到真正需要时再加）。最有用的工具反而是回滚框架：遇到复杂架构先试小规模，能安心放弃的设计才是好设计。

常见问题

Q: AI Agent 的记忆系统为什么会失控？

AI Agent 每天自动产生大量文件（记忆笔记、工作记录、草稿），但如果结构上只有一两个地方可以存放，这些文件就会集中膨胀或四处散落。问题的核心通常出在架构设计没有让正确行为成为阻力最小的路径，再多规则也补不回来。

Q: 什么是多 Agent 辩论？

让多个 AI Agent 分别扮演不同立场（实用派、架构师、失败分析师、迁移策略师），各自分析同一份数据后提出方案。通过观点碰撞找出单一视角容易忽略的盲点。

Q: 设计 AI Agent 系统最常犯的错误是什么？

最常见的错误是以为「加更多规则就能解决混乱」。实际上每加一条规则，既有规则获得的注意力就被稀释。正确做法是改善架构，让正确行为变成最容易做到的事。

整理：Penna｜小企鹅 Penchan