AI Agent健忘症终结方案：Task目录约定法

我用一个看起来"多余"的 task 目录约定，治好了 AI Agent 的健忘症

问题：AI Agent 干活的三个"洁癖噩梦"

AI Agent 干活有个有趣的特点——它完全不在乎文件该放哪里。

你让它写个 Python 脚本，它直接扔根目录。让它生成一张封面图，还是根目录。让它改个 bug，改了三个文件，依然根目录。几周下来，workspace 的混乱程度可想而知。

举个典型的例子：

复制

workspace/├── output.py# 哪个任务的？├── gpt_image_1.png# 几张图混在一起├── gpt_image_2.png├── test_fix_v2.py # v2？v1 呢？├── draft.md # 什么草稿？├── final_draft.md # 第几版？└── 真正重要的项目/└── ...

问题具体表现在三个层面：

不知道怎么归档。 文件散落一地，完全分不清哪个属于哪个任务。做完一个任务，想清理又怕删错。

不知道做了什么。 一周后回头想复现某个结果，根本找不到当时的上下文：用的什么 prompt？调了什么参数？踩了什么坑？全成了谜题。

不知道做没做完。 Agent 安静了好几分钟，是跑完了还是卡死了？产出的文件全不全？没人检查，全靠猜。

解法：让每个任务有自己的"房间"

解决方案简单到说出来你可能觉得不值一提：给每个任务建一个独立目录。

复制

tasks/├── active/│ └── TASK-20260606-001-tencent-dev-article/│ ├── output/│ │ └── article.md│ └── metadata.json└── completed/└── TASK-20260331-001-xx-ppt/└── output/└── presentation.pptx

命名规范：一眼看懂的编码

复制

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引擎

生命周期：三段式管理

复制

创建（新任务，>4轮对话）→ tasks/active/TASK-YYYYMMDD-XXX-描述/├── output/ ← 所有产出放这里└── metadata.json ← 任务上下文记录↓ 进行中→ 产出全部进入 output/→ 根目录零散落↓ 完成→ 移至 tasks/completed/→ 不删，永久存档

三条铁律必须遵守：

1. workspace 根目录不允许出现任何散落文件。有 task 的放进 task，没有 task 的也必须在对应文件夹里。
2. 产出必须全部在 output/ 下，不能在 task 目录里东一个西一个。
3. 完成后移入 completed/，不删，必须能追溯。

这不是文件夹，是 Agent 的上下文锚点

这个设计的真正价值不在"整理"，而在于让每个 task 成为 Agent 的可追溯上下文锚点。

目录即清单

task 目录本身就是待办清单。新目录一建立，Agent 就知道"我要产出的东西都应该放进这里"。任务结束时，扫一眼 output/ 就知道做完了没有、少了什么。

路径即索引

想找三月份的某次 PPT 生成任务？不需要搜文件内容，看目录名就够了：

复制

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），每次会话自动加载：

复制

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。回头看，有几个有意思的规律：

任务类型高度集中

这个分布揭示了一个事实：大部分任务其实是生成型任务（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 项合规指标

检查覆盖六个维度：

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 协议）。

来源：互联网