一个人管153个AI技能，文件系统崩了

凌晨两点，三个AI代理同时往同一个文件写数据。Vilius Vystartas第二天醒来，发现技能缺口记录成了一团乱码——他根本不知道哪些技能坏了，哪些还能用。

从20个技能到153个：哪里开始崩的

Vilius不是在玩聊天机器人。他跑的是自主代理——定时任务监控基础设施、自我改进模块分析历史会话、委托编码器趁他睡觉写功能。这些代理共享一个技能库：153个可复用的结构化流程，从发iMessage到调试SPFx构建，每个技能都是一份SKILL.md文件。

20个技能的时候，一切正常。文件存在~/.hermes/skills/，代理发现问题就往skill_gaps.jsonl里记一笔，Vilius定期review修复。

但自主代理不会排队。

凌晨2点的定时任务、自我改进循环、代码审查代理——三个进程同一秒内往同一个JSONL文件写数据。并发写入冲突，行被截断，数据消失。Vilius失去了对技能状态的追踪，代理静默加载坏掉的技能，因为缺口报告本身已经不可靠。

更麻烦的是搜索。想找"那个关于PyPI发布的技能"？只能grep目录树，祈祷frontmatter格式一致。

纯文件方案在几十个技能时还能撑，153个彻底崩了。

Skill Forge：把技能库做成本地优先的"pip"

解决方案叫Skill Forge。不是搬家，是就地索引——用SQLite替换破碎的JSONL管道，保留原有的SKILL.md文件不动。

核心设计很直白：

WAL模式（预写式日志）让多个代理同时读写不互锁。每个代理有自己的连接，外键约束生效。两个代理同时注册不同技能，都能成功。原子事务，状态不损坏。

FTS5全文搜索覆盖名称、分类、描述和正文内容。找"PyPI release classifiers"直接forge search "pypi classifier"，瞬间出排序结果。

单文件数据库forge.db丢在~/.hermes/skill-forge/，无服务器进程，零配置，forge export就能备份，完全可移植。

质量门禁是新增的东西。以前坏技能要到代理运行时才暴露，现在两道验证：

Frontmatter验证器检查必填字段缺失、格式错误；

语义验证器解析技能步骤，标记循环依赖、不可达指令、外部工具版本冲突。

验证失败阻断注册，问题在入库前暴露。

命令行界面刻意保持极简。forge status看全局状态，forge search查技能，forge validate跑检查，forge export备份。没有Web界面，没有分布式架构，一个人本地管理够用。

153个技能的现状：108个未分类

运行forge status，输出很说明问题：

总计153个技能，按分类统计：MLOps 12个，DevOps 8个，创意类15个，职业发展3个，研究类7个。剩下108个——70%——躺在"未分类"里。

质量检查运行306次，当前失败数为0。但Vilius清楚这个数字的脆弱：验证器能抓格式错误和明显逻辑缺陷，却判断不了"这个技能在真实API变更后是否仍然有效"。

分类混乱是更深层的问题。技能增长速度快于整理速度，108个未分类意味着检索依赖全文搜索而非结构化浏览。FTS5救场，但也暴露了管理债务。

代理自主发现技能缺口的能力仍在。但现在写入SQLite是并发安全的，数据不再丢失。Vilius能信任gap报告，定期批量修复而非被动救火。

为什么选SQLite：三个被验证的假设

Vilius解释技术选型时很具体。不是"轻量"或"成熟"这类空话，是三个可验证的特性：

并发安全有明确机制。WAL模式不是SQLite独有，但在这个场景里恰好够用——读多写少、写操作原子性要求高、无跨网络需求。PostgreSQL需要运维，LevelDB没有全文搜索，SQLite是功能与复杂度的 sweet spot。

FTS5的ranking算法对技能搜索意外合适。技能描述通常短而结构化，BM25评分能很好地区分"提到PyPI"和"专门讲PyPI分类器配置"。

单文件部署消除了环境差异。Vilius的代理跑在多台机器上，forge.db随dotfiles同步，新机器几分钟内拥有完整技能库状态。

这些假设在153个技能规模下成立。Vilius没有测试过1000个技能的性能，但他怀疑瓶颈会在验证器而非数据库——语义检查需要解析每个技能的步骤图，复杂度随技能数量非线性增长。

未解决的问题：技能版本与代理兼容性

Skill Forge没有版本管理。一个技能更新后，正在运行的代理可能持有旧版本引用，行为不一致。Vilius目前的做法是"尽量在代理空闲时更新"，没有强制同步机制。

更麻烦的是技能依赖。技能A调用技能B，B更新后A可能断裂。验证器能抓显式声明的依赖，但技能之间的隐式耦合——比如都假设某个环境变量存在——无法静态检测。

代理的"自我改进"模块也在制造混乱。它们会基于运行历史生成新技能或修改现有技能，这些变更需要人工审核才能入库。Vilius设置了一个staging区域，但审核队列经常堆积。

108个未分类技能是技术债务的冰山一角。分类需要理解技能的实际用途，而技能的用途往往只有在特定代理上下文中才清晰。Vilius尝试过让代理自动建议分类，但准确性不足以信任。

一个人的基础设施：规模与复杂度的边界

Vilius的 setup 是个极端案例：单点管理、无团队分工、代理自主运行。传统软件工程的分层架构、代码审查、CI/CD在这里要么不存在，要么由代理自己执行。

Skill Forge是这个边界上的妥协。它引入了最低限度的结构化——数据库、验证、搜索——但拒绝过度工程。没有Web UI，因为Vilius熟悉命令行；没有分布式事务，因为代理跑在同一台机器上；没有技能市场，因为技能高度个人化，通用化成本高于收益。

153个技能的规模很微妙。远低于企业知识库，远高于个人笔记。Vilius发现这个区间缺乏现成工具：Notion太重型，Obsidian无并发安全，传统CMS需要服务器。Skill Forge填补了缝隙，但填补方式高度特定于他的工作流。

质量门禁的设计反映了信任层级。机器生成的技能必须通过验证，但验证规则由人编写。Vilius保留了对"什么算有效技能"的最终定义权，没有把判断外包给代理或外部服务。

从JSONL到SQLite：一次延迟的架构升级

回头看，文件系统的崩溃是可预测的。JSONL的追加写模式在单进程场景简单可靠，但从未设计为多代理并发使用。Vilius的延迟升级有典型性：基础设施债务在规模压力下突然爆发，而非渐进暴露。

SQLite的选择带有保守色彩。2026年的数据库选型，PostgreSQL、DuckDB、甚至嵌入式向量数据库都是可行选项。Vilius的决策依据是运维负担而非性能上限——他宁愿牺牲查询灵活性，换取"scp就能迁移"的确定性。

这种保守与代理系统的激进形成对比。代理被赋予自主改进、委托编码的权限，但技能的基础设施层却刻意简单。Vilius的解释是：代理的行为需要可预测的基础，复杂基础设施的故障模式难以调试，而调试代理本身已经够麻烦了。

全文搜索的引入是用户体验的关键转折。grep的模糊匹配在20个技能时可用，153个时认知负荷爆炸。forge search的ranking让"大概记得内容"的查询成为可能，降低了技能库的心智管理成本。

代理时代的个人工具链

Skill Forge的定位值得玩味。它不是框架，不是平台，是一个人的运维脚本集合。Vilius没有开源计划，因为代码硬编码了他的目录结构和验证规则；也没有产品化意图，因为目标用户画像太狭窄。

但这种狭窄可能预示更广泛的形态。随着AI代理普及，"一个人+大量代理"的工作模式会从极端案例变成常见配置。每个人都需要管理代理的技能库、状态、失败模式，而现有工具链对此准备不足。

Vilius的解决方案是"本地优先"的——数据在文件系统，查询用SQLite，备份是标准导出。这与云原生代理服务的趋势相悖，但符合个人基础设施的控制需求。当你的代理在凌晨两点自主运行时，依赖外部API的可用性是一种风险。

质量门禁的设计也暗示了人机分工的边界。验证器抓机器可判定的错误，分类和语义正确性留给人。这不是技术限制，是意图保留：Vilius希望技能库反映他的工作方式，而非代理的优化目标。

数字背后的真实状态

forge status的输出可以读作成功故事：153个技能，0个验证失败，306次检查通过。但分类分布暴露了治理缺口，版本管理缺失暗示着潜在的运行时故障，审核队列的长度从未被披露。

Vilius的诚实在于承认这些限制。他没有把Skill Forge包装为通用解决方案，而是作为特定规模、特定工作流下的权宜之计。这种诚实本身是一种方法论：基础设施的价值在于解决问题，而非呈现完美。

代理自主发现技能缺口的能力，与Vilius的人工修复形成闭环。这个闭环的效率决定了系统的实际可靠性——验证器减少但无法消除人工负担，SQLite的并发安全只解决写入冲突，不解决语义冲突。

108个未分类技能可能永远不会被整理。Vilius的优先级是"能搜索到"而非"结构完美"，这个选择反映了实用主义对理想架构的胜利。在代理持续生成新技能的压力下，完美分类是不经济的目标。

如果你也在管理多个AI代理

Vilius的经验有几个可直接迁移的检查点。

你的技能存储方案能处理并发写入吗？不是"理论上支持"，是"三个代理同一秒写入"的实际场景。文件追加在压力下会背叛你。

你能快速定位"那个关于XX的技能"吗？grep在规模面前失效，全文搜索不是奢侈品是必需品。但搜索质量依赖文本质量，技能描述的写作规范需要早期建立。

坏技能多久被发现？运行时暴露是最昂贵的失败模式，静态验证的成本在技能数量增长前显得过高，但债务会累积。

你的分类系统能跟上技能增长速度吗？不能的话，搜索优先于浏览，但要有心理准备：70%的技能可能永远躺在"未分类"里。

最后，基础设施的复杂度要匹配团队规模。一个人的工具链不需要企业级架构，但"简单"不等于"无结构"。SQLite是结构的最小有效剂量，Skill Forge是这个原则的具体化。

现在打开你的技能目录，数一下有多少个文件。如果超过50个，grep一下"skill_gaps"——看看你的代理们，是不是也在深夜互相覆盖着写数据。