最近我做了两个很小、但让我很受启发的实验。
一个目录用来管理高中物理的学生、课程、讲义和阶段反馈；另一个目录用来整理招聘登记表，把 PDF 和图片转换成可以搜索、筛选和追溯的候选人知识库。
它们没有传统意义上的后台，没有单独部署数据库，也没有先开发一个完整的 Web 系统。它们首先只是两个普通文件夹。但当我把说明文档、业务规则、原始资料、结构化数据、索引、业务 Skill、模板和脚本放进目录，再让 WorkBuddy 这类 Agent 软件直接在当前目录工作时，文件夹开始表现得像一套真正的业务系统。
我可以直接用自然语言说：
帮我找出还需要复核的资料。
新增了一批文件，整理后更新索引。
查一下哪些讲义涉及牛顿第二定律。
按工作年限和技能筛选候选人，但不要输出无关的个人信息。
Agent 不需要每次从零理解业务，也不需要临时发明一套处理方式。它先读目录里的规则，再查询现成索引，调用已经准备好的脚本，最后按照目录约定归档结果。
这让我开始相信：未来一类非常实用的 Agent 产品形态，可能不是一个更大的聊天框，而是一个可以被 Agent 直接驱动的本地文件夹。
当知识、规则、Skill、程序和数据一起进入目录，普通文件夹就开始拥有业务系统的形态。
聊天框不是工作的最终容器
今天大多数 AI 助手仍然以对话为中心。
用户上传几个文件，解释一次背景，Agent 临时分析，然后在聊天里返回结果。下一次再处理同类问题时，往往还要重新上传、重新说明、重新确认规则。如果任务稍微复杂一点，Agent 还可能现场编写一段 Python 或 Shell 脚本，用完以后就消失在某次会话里。
这种模式适合一次性问答，却不适合长期业务。
真实工作有自己的历史和秩序：原始文件不能被覆盖，数据要有来源，未知信息不能被编造，修改后要更新索引，异常要进入待复核队列，敏感信息只能在必要范围内使用。一次对话可以完成一个动作，却很难稳定承载这些长期约束。
更麻烦的是，聊天记录通常不等于业务状态。Agent 在对话里说“已经整理完成”，并不能证明结构化数据可解析、原始文件可追溯、索引已经同步，或者结果能在下一次任务中继续使用。
如果每一次任务都依赖 Agent 临场理解、临场写代码、临场决定文件放在哪里，我们得到的只是一个能力很强的临时工，而不是一个可靠的工作系统。
一个文件夹，也可以是一套完整的业务环境
传统软件通常把业务能力拆进数据库、后端服务、管理界面和云端存储。对于个人或小团队来说，这套形态常常太重了。
但很多业务的真实规模，并不需要先建设一套 SaaS。它们需要的只是几种基本能力：
- 保存原始资料；
- 把资料转换成可搜索的文本和结构化记录；
- 定义新增、修改、归档和复核规则；
- 执行一组稳定的数据处理程序；
- 让人能随时检查、修正和带走全部结果。
这些能力完全可以被封装在一个目录里。
my-workspace/
├── README.md # 给人看的业务地图和使用入口
├── AGENTS.md # 给 Agent 看的操作合同与边界
├── skills/ # 按业务场景封装的操作方法与能力入口
├── inbox/ # 新到、尚未处理的文件
├── raw/ # 不可修改的原始证据
├── records/ # 按业务对象组织的事实记录
├── catalog/ # 面向检索的 Markdown / JSONL 索引
├── schemas/ # 结构化数据的字段与约束
├── templates/ # 报告、记录和输出模板
├── scripts/ # OCR、导入、重建、统计、校验程序
└── review/ # 冲突、缺失和低置信度事项
这不是简单地“把文件分分类”。目录中的每一层都承担了软件系统里原本由不同组件承担的职责。
README.md 是产品说明和导航；AGENTS.md 类似运行时策略；skills/ 沉淀可复用的业务方法；raw/ 是证据仓；records/ 是事实层；catalog/ 是检索层；schemas/ 是数据契约；scripts/ 是可执行能力；review/ 则是人机协作的异常队列。
当这些部分组合起来，文件夹就不再只是存储空间，而是一个带知识、规则、程序和状态的运行环境。
目录工作站不是一堆散落文件，而是由入口、边界、能力、执行、数据与校验共同组成的分层系统。
README 与 AGENTS.md，解决的是两个不同问题
这类目录最重要的两个文件，通常是 README.md 和 AGENTS.md。
README.md 首先服务于人。它要告诉用户这个目录是什么、从哪里开始、数据放在哪里、常见问题怎么查，以及哪些结果值得信任。即使没有 Agent，人也能通过它理解这套系统。
AGENTS.md 服务于执行。它不应该只写一句“请认真处理资料”，而要明确：
- Agent 进入目录后按什么顺序读取信息；
- 哪些文件是原件，禁止修改、覆盖或删除；
- 查询时优先使用哪个索引，什么时候必须回看原文；
- 哪些字段可以推断，哪些字段必须保留为未知；
- 新资料进入后应该调用哪个脚本；
- 什么条件满足后，任务才可以被描述为完成；
- 哪些数据属于敏感信息，输出时如何最小化披露。
这相当于把过去藏在某位员工脑中的操作经验，变成 Agent 每次进入工作现场都会读取的本地合同。
但文档本身还不够。真正稳定的规则，最终应该尽可能进入 Schema、脚本和自动校验。文档告诉 Agent“应该怎么做”，程序负责保证“做错时不能悄悄通过”。
Skill 是目录里的业务能力包
如果只有一个越来越长的 AGENTS.md，目录最终也会变得难以维护。
因为全局规则和具体业务流程不是一回事。原件不能删除、敏感信息最小披露、写入后必须校验，这些是整个目录都要遵守的规则；而“生成一次阶段反馈”“导入一批候选人资料”“执行一次技能筛选”，则是只有在特定任务中才需要加载的业务方法。
因此，我认为目录中还应该允许定义自己的 skills/：
skills/
├── import-materials/
│ ├── SKILL.md # 触发条件、处理步骤、输入输出和完成标准
│ ├── scripts/ # 导入、OCR、去重或转换程序
│ └── references/ # 字段说明、判断规则和示例
├── generate-report/
│ ├── SKILL.md
│ └── templates/ # 报告模板
└── search-records/
└── SKILL.md # 查询顺序、索引选择和隐私约束
一个目录级 Skill 不应该只是一段更长的 Prompt。它应该把一项业务能力完整封装起来：
- 什么时候使用：用户表达什么意图时触发；
- 需要读取什么：使用哪个索引、事实文件或参考规则；
- 应该怎样执行：调用哪些脚本，按什么顺序处理；
- 产出放在哪里：文件名、目录、格式和数据结构；
- 怎样才算完成：必须通过哪些校验，更新哪些索引；
- 什么时候交给人：遇到冲突、低置信度或高风险操作如何暂停。
这样，目录中的业务逻辑就有了清晰的层次：
README.md 告诉人：这里能做什么
AGENTS.md 告诉 Agent：在这里工作必须遵守什么
SKILL.md 告诉 Agent：某一类业务具体怎样完成
scripts/ 负责：把确定性步骤稳定执行
schemas/ 负责：约束数据结构
templates/ 负责：统一产物形态
例如在教学工作站中，可以定义“导入新讲义”“记录新课次”“生成阶段反馈”等 Skill。生成反馈时，Skill 会要求 Agent 先读取学生事实、课程进度和掌握度观察，再调用固定模板生成报告，并检查是否把“课程已经讲过”误写成“学生已经掌握”。
在招聘工作站中，可以定义“重建候选人知识库”“按条件筛选候选人”“处理人工纠错”等 Skill。筛选 Skill 可以规定先读结构化索引，只在需要核实时回看 OCR 和原件，并默认隐藏与问题无关的身份证号、电话和住址。
Skill 的另一个价值是按需加载。Agent 不必每次进入目录就把所有业务知识塞进上下文，而是先理解用户意图，再加载对应 Skill。目录越复杂，这种渐进式加载越重要：它既减少注意力噪声，也降低不同业务规则相互干扰的风险。
从这个角度看，目录不只是保存数据，还能保存这个业务领域自己的“能力插件”。换一个 Agent 或模型，只要它能理解目录规则并调用本地工具，这些 Skill 仍然可以继续使用。
两种目录，代表两类常见工作
我这次实践的两个目录，刚好代表了两种不同的业务模式。
第一种是持续积累型工作站。
物理教学资料库会不断增加学生、课程、课次、测评、讲义和反馈。每一条新记录都要关联到稳定的学生和课程对象，并保留日期、来源和置信度。课程讲过某个知识点，不代表学生已经掌握；阶段反馈也不能被反向虚构成几次具体课堂记录。
因此，这类目录更像一套长期生长的本地业务数据库。Agent 的主要工作是查询、追加、关联、生成报告和维护索引。
第二种是批量重建型工作站。
招聘材料目录中保存的是大量 PDF 和图片。脚本负责提取文字、执行 OCR、合并同一候选人的多份材料、生成结构化档案和全局索引，再把姓名冲突、低置信度识别等问题放进人工复核队列。
这类目录不鼓励直接修改生成结果。人工确认应该写入单独的纠错配置，然后重新运行构建脚本。这样，无论原始材料增加多少次，整个知识库都能从“原件 + 纠错配置”稳定重建，而不是在一次次手工修补中逐渐失真。
这两个案例的业务完全不同，但底层结构非常接近：
原始资料 → 提取与转换 → 事实记录 → 检索索引 → 自然语言查询
↓
冲突与低置信度 → 人工复核 → 规则化修正
这也是我所说的“LLM Wiki”与传统知识库的区别。传统 Wiki 主要保存可阅读的内容；这种目录不仅能被阅读，还包含可以运行的处理流程。它更像一个可执行 Wiki。
自然语言负责表达意图，脚本负责稳定执行
Agent 最有价值的地方，不是替用户记住每一条命令，而是把自然语言映射到目录中已经存在的能力。
用户说“把新资料整理一下”，Agent 可以理解为：
- 检查
inbox/或原始资料入口； - 调用固定的导入或重建脚本；
- 查看校验结果；
- 汇总新增对象和异常项；
- 只把真正需要判断的问题交给人。
用户说“帮我找出需要跟进的人”，Agent 可以先查询 JSONL 索引，再根据业务规则筛选，必要时回到单个档案和原件核对，而不是每次重新扫描全部 PDF。
这里最关键的设计，是把不确定性放在正确的位置。
自然语言可以是模糊的，Agent 可以负责理解意图；Skill 负责把意图映射成业务流程；而数据转换、去重、编号、校验和归档应该尽可能确定。Agent 不必每次临时写一个新脚本，而是优先选择目录里的 Skill，再组合和调用已经验证过的程序。
这会显著降低系统对模型“临场发挥”的依赖。模型升级或更换 Agent 软件以后，业务数据、处理脚本和规则仍然留在原目录中，不需要从头迁移。
减少技术支持，不等于消灭技术设计
我认为这一点必须说清楚。
把业务做成目录工作站，并不意味着任何人随手写一个 AGENTS.md，Agent 就能可靠地接管工作。数据模型怎么划分、原件如何保留、稳定 ID 怎么生成、冲突如何处理、脚本是否幂等、校验条件是什么，这些仍然需要认真设计。
真正改变的是技术投入发生的位置。
过去，每来一次需求，都可能需要技术人员临时取数、写脚本、改脚本和解释结果。目录工作站则把这些重复逻辑提前沉淀为本地能力：常用查询有索引，常见转换有脚本，固定输出有模板，数据质量有 Schema，异常有复核入口。
技术人员不是彻底退出，而是从“每次帮忙执行”转向“把执行方法产品化”。一旦目录结构和脚本稳定下来，业务人员就可以长期通过自然语言使用它。
不是让 Agent 每次都学会编程，而是让技术人员把正确的程序放进工作现场，让 Agent 学会在正确的时候调用它。
Local-first 的意义，不只是隐私
这类工作站天然适合 Local-first。
首先，数据掌握在用户手里。教学档案、招聘材料、财务记录和个人研究资料都可能包含敏感信息，本地目录可以沿用操作系统的权限、磁盘加密和备份策略，不必默认把全部内容上传到某个云端产品。
其次，它具有很强的可迁移性。目录可以复制到另一台电脑，可以进入私有 Git 仓库，可以定期备份，也可以换一个支持本地文件和命令执行的 Agent 继续使用。真正的资产是文件、规则和脚本，而不是某个平台中的一串对话历史。
再次，它具有天然的可解释性。用户随时可以打开 Markdown、JSON 和脚本，检查 Agent 依据了什么、修改了什么。即使 Agent 暂时不可用，这些资料仍然是人可以阅读和维护的。
当然，本地并不自动等于安全。Agent 的读写范围、脚本权限、外部网络访问、删除操作和敏感信息输出仍然需要明确控制。目录限定的是业务上下文，不应该被误解成无限权限。
WorkBuddy 这类软件，可以成为目录的通用运行时
如果沿着这个方向继续发展，WorkBuddy 等 Agent 软件承担的角色会发生变化。
它不需要为教学、招聘、研究、财务和客户管理分别开发一套固定后台。它可以成为这些目录工作站的通用运行时：
- 打开一个目录，自动发现
README.md和AGENTS.md； - 根据用户意图发现并加载目录内的业务 Skill；
- 根据用户意图逐步加载相关文件，而不是一次读取全部资料；
- 优先调用目录内已经声明和验证的脚本；
- 在写入前展示计划，在高风险操作前请求确认；
- 记录执行日志、文件差异和校验结果；
- 将无法确定的问题放进
review/，等待人处理； - 在完成后更新索引，让下一次任务直接复用结果。
自然语言负责表达意图，Agent 负责路由，Skill 组织业务流程，脚本处理确定性步骤，例外最终回到人。
这样一来，同一个 Agent 客户端可以打开很多不同的工作目录。每个目录都有自己的知识、规则、能力和边界，像一台台用途不同的本地小型工作站。
用户不需要先学会数据库、命令行或 Python。他面对的仍然是自然语言。但在自然语言背后，执行不再依赖一次性的聊天上下文，而是落在一个长期存在、可以检查、可以重建的文件系统里。
文件夹可能是最轻量的 Agent 应用格式
过去，我们习惯把一个业务需求想象成“要不要开发一个系统”。现在也许可以先问另一个问题：它能不能先被做成一个 Agent 可运行的目录？
如果一个业务主要围绕文件、记录、搜索、批处理、报告和归档展开，那么答案很可能是肯定的。
它不需要先有复杂界面，也不需要先把数据交给某个封闭平台。先建立清晰的目录，写好人类入口和 Agent 规则，把重复动作做成脚本，把关键数据做成结构化索引，再让 Agent 用自然语言驱动这些能力，一个最小可用的个人工作站就已经出现了。
我越来越觉得，文件夹可能是最轻量、最开放，也最容易长期保存的 Agent 应用格式。
它同时是知识库、数据库、Skill 集合、工具箱、操作手册和审计记录。模型负责理解，Skill 负责组织业务方法，脚本负责确定性执行，文件系统负责保存，人负责定义边界和处理例外。
当这几部分真正组合起来，我们得到的就不只是一个会读取文件的 AI 助手，而是一台属于个人、运行在本地、可以随着工作持续生长的 Agent 工作站。