AI Agent健忘症终结方案：Task目录约定法
我用一个看起来"多余"的 task 目录约定，治好了 AI Agent 的健忘症
问题：AI Agent 干活的三个"洁癖噩梦"
AI Agent 干活有个有趣的特点——它完全不在乎文件该放哪里。
你让它写个 Python 脚本，它直接扔根目录。让它生成一张封面图，还是根目录。让它改个 bug，改了三个文件，依然根目录。几周下来，workspace 的混乱程度可想而知。
举个典型的例子：
代码语言：txt复制workspace/├── output.py# 哪个任务的？├── gpt_image_1.png# 几张图混在一起├── gpt_image_2.png├── test_fix_v2.py # v2？v1 呢？├── draft.md # 什么草稿？├── final_draft.md # 第几版？└── 真正重要的项目/└── ...
问题具体表现在三个层面：
不知道怎么归档。 文件散落一地，完全分不清哪个属于哪个任务。做完一个任务，想清理又怕删错。
不知道做了什么。 一周后回头想复现某个结果，根本找不到当时的上下文：用的什么 prompt？调了什么参数？踩了什么坑？全成了谜题。
不知道做没做完。 Agent 安静了好几分钟，是跑完了还是卡死了？产出的文件全不全？没人检查，全靠猜。
解法：让每个任务有自己的"房间"
解决方案简单到说出来你可能觉得不值一提：给每个任务建一个独立目录。
代码语言：txt复制tasks/├── active/│ └── TASK-20260606-001-tencent-dev-article/│ ├── output/│ │ └── article.md│ └── metadata.json└── completed/└── TASK-20260331-001-xx-ppt/└── output/└── presentation.pptx
命名规范：一眼看懂的编码
代码语言：txt复制TASK-YYYYMMDD-XXX-简短描述/ │ │ │ │ │ └── 任务内容（中文/英文均可） │ └────── 当日序号（001, 002, ...） └────────────────── 创建日期
几个实例：
TASK-20260606-001-tencent-dev-article—— 6月6日第1个任务：xx文章TASK-20260429-001-xizang-ai-funding—— 4月29日第1个任务：xxAI基金研究TASK-20260521-001-py-ppt-engine—— 5月21日第1个任务：Python PPT引擎
生命周期：三段式管理
代码语言：txt复制创建（新任务，>4轮对话）→ tasks/active/TASK-YYYYMMDD-XXX-描述/├── output/ ← 所有产出放这里└── metadata.json ← 任务上下文记录↓
进行中→ 产出全部进入 output/→ 根目录零散落↓
完成→ 移至 tasks/completed/→ 不删，永久存档
三条铁律必须遵守：
- workspace 根目录不允许出现任何散落文件。有 task 的放进 task，没有 task 的也必须在对应文件夹里。
- 产出必须全部在 output/ 下，不能在 task 目录里东一个西一个。
- 完成后移入 completed/，不删，必须能追溯。
这不是文件夹，是 Agent 的上下文锚点
这个设计的真正价值不在"整理"，而在于让每个 task 成为 Agent 的可追溯上下文锚点。
目录即清单
task 目录本身就是待办清单。新目录一建立，Agent 就知道"我要产出的东西都应该放进这里"。任务结束时，扫一眼 output/ 就知道做完了没有、少了什么。
路径即索引
想找三月份的某次 PPT 生成任务？不需要搜文件内容，看目录名就够了：
代码语言：txt复制tasks/completed/TASK-20260331-001-xx-ppttasks/completed/TASK-20260331-002-xx-hospitaltasks/completed/TASK-20260406-001-xx-chupingtasks/completed/TASK-20260414-001-xx-equipment-pricing
目录名包含了时间、序号、内容摘要——一个自解释的文件系统级索引。
命名即追溯
目录名里的任务描述让人一眼知道"这是什么"，日期让人知道"什么时候做的"，序号让人知道"那天第几个"。不需要数据库、不需要标签系统，文件系统本身就是最好的元数据载体。
如何让 Agent 自动遵守：一条 SOUL 约束
光靠"约定"是不够的。Agent 每次会话的记忆是独立的，不可能每次都手动提醒。一种可行的做法是把这条约束写进 Agent 的常驻策略注入（SOUL.md），每次会话自动加载：
代码语言：markdown复制Gene 2: TaskManagementSIGNALS: 新任务、多步骤工作、预估>4轮对话STRATEGY: 立即创建task目录（tasks/active/TASK-YYYYMMDD-XXX-描述/）。任务产出全部放入task目录。完成后移至tasks/completed/。A VOID: × 不跳过task创建直接干活 × 不在workspace根目录创建散落文件
一共 4 行，约 120 token。Agent 每次启动都会读这段，形成了稳定的行为基线。关键设计点在于：
- SIGNALS：明确触发条件——"预估>4轮对话"。不是每个小请求都建 task，避免过度设计。
- STRATEGY：三句话讲完命名规范、存放规则、生命周期。
- A VOID：禁止式约束，而非描述式建议。"不散落"比"请整理"有效得多。
60 个 task 之后，发现的一些规律
从 2026 年 3 月底到现在，已经创建了 60 个 task。回头看，有几个有意思的规律：
任务类型高度集中
| 类型 | 占比 | 典型 task |
|---|---|---|
| PPT 生成 | ~35% | 医院某项目、公司项目、机构设备报价 |
| 技能开发 | ~20% | py-ppt-engine、html-to-drawio、prototype-studio |
| 文档撰写 | ~15% | NotebookLM 文章、社区文章 |
| 研究分析 | ~15% | 某 AI 基金、商业机会雷达 |
| 原型/产品 | ~10% | memory-viz、team-work-miniapp |
| 其他 | ~5% | 论文编辑、远程桌面 |
这个分布揭示了一个事实：大部分任务其实是生成型任务（PPT、文档、代码）而非分析型任务。生成型任务对文件管理的要求远高于分析型——因为产出是实体文件，散落的问题更严重。
最长的 task 跨度 3 天
TASK-20260427-001-gem-architecture 和它的修复版本 TASK-20260427-002-gem-architecture-fix 跨了 2-3 天。如果没有 task 目录，三天前的上下文完全丢失——不可能还记得当时用的什么参数、中间遇到了什么问题。
completed 目录成了"作品集"
60 个 task 中有相当一部分已经移入 completed/。它不是"垃圾桶"，而是"作品集"——任何时候想回顾某个项目，路径就是入口。
配套工具：cleanit —— task 机制的"交警"
Task 机制要落地，光靠自觉不行。可以配套一个小技能 cleanit，在每次会话结束时执行审计：
cleanit→逐条检查 23 项合规指标
检查覆盖六个维度：
| 维度 | 检查项数 | 示例 |
|---|---|---|
| 文件位置 | 3 | 根目录有散落文件吗？产出都在 output/ 下吗？ |
| task 目录 | 3 | 超过4轮对话？task 创建了吗？命名格式对吗？ |
| 记忆更新 | 4 | daily 写了吗？相对时间替换了吗？ |
| 安全边界 | 3 | 涉及支付？外部通讯？下载软件？ |
| 跨项目影响 | 3 | 改了 core/？改了公共库？下游影响？ |
| 开发任务（可选） | 7 | 开发规范遵守了吗？代码风格一致吗？ |
23 项检查，3 秒跑完。每次会话结束前自动执行一次，发现问题当场纠偏。
cleanit 已开源在 GitHub（MIT 协议，和 task 系统配套使用）。
这个小技巧为什么有效：三条原则
1. 约束前置，而非事后补救
不是在文件散落之后再去整理，而是在 Agent 动手之前就给它一个"房间"。Task 目录创建是任务执行的第一步，不是最后一步。
2. 用文件系统做数据库
不需要引入任何新工具。文件系统本身就是最好的任务管理工具——目录名 = 元数据，路径 = 索引，ls = 查询。零依赖，永久可读。
3. 目录即契约
Task 目录不只是文件夹。它是一个隐式契约：Agent 承诺"这个任务的所有产出都在这里"。契约不需要写在文档里，目录的存在本身就是约束。
几个不成熟的小建议
如果想给自己的 AI 工作流加上 task 机制，可以从这几步开始：
- 从下一个任务开始。 不要想着"回头整理"。下一个新任务就直接建 task 目录。
- 别纠结命名。
TASK-YYYYMMDD-XXX-描述足够，不用更复杂。 - 配上一个审计工具。 自觉不如检查，检查不如自动化。类似
cleanit的收尾审计能让规范变成肌肉记忆。 - completed 不要删。 硬盘不值钱，上下文值钱。半年前的 task 目录可能是唯一能找到当时工作记录的地方。
本文提及的 cleanit 技能已开源（MIT 协议）。