用 Claude Code 或者类似命令行 Agent 超过两周的人，大概率都会患上同一种“数字囤积症”。
刚开始总是很美好的：遇到一个特定的构建坑，或者摸索出一套冷门的部署命令，顺手写个 Skill 丢进目录。心里想着：“下次 AI 遇到就能直接按规矩办了。”
可随着项目往前推，你的规则目录很快就变得像多年没清理的杂物间。里面塞满了相互冲突的命令、半年前旧框架的废弃配置，以及三四个名字不同但内容有 80% 重叠的“踩坑指南”。更糟的是，你根本不知道 AI 每次处理任务时，到底有没有真正调起这些规则；即便知道失效了，也很难腾出手去逐一校对、删除。
我们本来是为了让 AI 帮我们干活，最后却沦为给 AI 的提示词和规则库当全职保姆。
最近开源社区出现的一个项目 AutoHarness（tigerless-labs 开源），切入的角度非常刁钻：既然 Agent 能帮我们写业务代码，为什么它不能自己维护自己的技能库？
Harness 的瓶颈不在模型，在“人工维护”
这两年 AI 圈有个被广泛引用的观察：“大模型重要，但 Harness（外围脚手架与运行层）往往决定了上限。”
CORE-Bench 的测试里，同样的底层模型，配上优秀的工程 Harness，任务通过率能从 40% 出头直接拉升到近 80%。但尴尬的地方在于，行业每更新一代模型，这套外围工程系统几乎都要人类重新肉搏写一遍。
Prompt 和 Skill 本质上是 Agent 的“外挂工作记忆”。把这份记忆全盘推给开发者手写，其实违背了直觉——人类自己形成工作直觉时，也是在踩坑中归纳、在反复调用中强化、在长期不用时自然淡忘。
AutoHarness 试图建立的，就是这么一套基于真实使用自生长、自折叠、自淘汰的规则层。
它不搞花架子：没有常驻后台，也不刷假基准
很多人看到“自我学习的 Agent 框架”，第一反应通常是：是不是又要开一个耗电耗内存的后台常驻守护进程（Daemon）？是不是要在每次对话后调用昂贵的裁判模型跑一套 Benchmark 评分？
AutoHarness 的工程设计相当克制。它完全运行在本地，零第三方依赖，纯靠 Python 运行机制与 Claude Code 的原生插件/Hook 打通。
它的运行逻辑可以拆解为极其实用的四个环节：
1. 触发不看闲聊，看“真动手”的次数
不少自动化总结工具最大的毛病是“话痨”，你跟它随便聊两句日常，它就煞有介事地总结出一篇冗长笔记。AutoHarness 的触发条件非常工程化：统计主会话中的工具调用次数（Tool Calls）。
纯文字交流不推进计数器；只有当排查问题、修改文件、运行命令等重度操作推进到一定阈值（比如默认的 50 次工具调用），它才会在后台静默唤起一次反思（Reflection）。这意味着它捕捉的永远是真正发生过排错与执行的硬核上下文。
2. 合并与重构，拒绝垃圾近义词
这是它最像人类经验积累的地方。当新的一轮操作结束，反思模块拿到新的经验片段，它不是无脑新建一个 skill_v2.md，而是拿新结论与现有的技能索引做比对。
如果发现同一场景在旧规则里已经有记录，甚至过去的结论在今天被推翻了，它会直接发起“折叠”或“打补丁”，更新原有的技能内容，并在专属账本（.ledger.jsonl）里记下这次修改的原因与对应的历史会话快照。整个技能库是在合并中精简，而不是无休止地堆叠。
3. 淘汰靠“真实调用率”，而不是拍脑袋
许多写得极好的规则，实际上在后续几个月里一次都没被触发过，白白挤占宝贵的上下文窗口。
AutoHarness 引入了一套轻量的生命周期机制：
- 试用期保护：新沉淀的技能会有一定的观察窗口，在此期间不会被随便抹杀。
- 分级容量硬约束：项目级和全局级技能库都有明确的数量上限。
- 使用留存，闲置归档：一旦技能池达到上限，系统会依据调用率从低到高淘汰。值得一提的是，它严格区分了“被浏览（View）”和“被实际遵循执行（Load）”。真正决定一个技能存活的，是它在后续开发中是否真的被 AI 执行。没有用的技能会被挪进
.archive 目录，一旦哪天重新被调起，还能平滑恢复，绝不直接暴力销毁。
4. 会话开局即见“索引”，不赌宿主的运气
通常情况下，Claude Code 依靠自身的语义检索去判断要不要拉取某个本地 Skill。AutoHarness 在这之上加了一层薄薄的“自生成目录”，在每次新会话启动时，把当前存活的技能提炼成一两行精炼索引直接挂载。AI 从一开始就知道自己“掌握哪些独门秘籍”，省去了在大海里盲捞的过程。
最好的工具，应该像人体的免疫系统
在实际体验这种工作流时，最强烈的感受是心理负担的骤降。
你不再需要在一个复杂排错完成之后，停下手头的工作，切换到编辑器里咬文嚼字地写规章制度；也不用定期花半天时间去清理过时的开发文档。你只需要像平时一样写代码、查 Bug、做微调。做得多了，系统自然会为这个仓库沉淀出独属的工程习惯。
如果某一天框架升级，某个旧方法失效了，你在交互中顺口指出的纠正，就会在下一次反思时自动覆盖旧条目。它在真实代码的碰撞里自己长出抗体，在业务环境变迁后默默代谢掉衰老的组织。
过去一年多，大家把太多注意力放在“如何写出更完美的 System Prompt”和“怎样搭建复杂的评测回路”上。但在日常写代码这件琐碎、高频且极度依赖上下文的事情里，往往最简单、最贴近真实工作动作的闭环，才最经得起长期推敲。
让 AI 像做学徒一样，从挨训中长记性，在无用时自己闭嘴——这或许才是个人工程智能化该有的模样。
发表于 2 小时前
|
查看: 3|
回复: 0
