autoharness
tigerless-labs/autoharness加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一个场景：周五下午，你花了两小时调试一个 CI 流水线问题，最后发现根因是部署前必须先重新生成 production manifest。第二天你又踩进同一个坑——只不过这次 Claude Code 记得上次的事，因为它自己把这条经验写成了一条技能（skill）。
这正是 Tigerless Labs 在 2026 年 6 月开源的 AutoHarness 想解决的事。它的自我描述相当直接："Building the self-learning layer next-gen agents will ship with, learning skills from real work."（构建下一代智能体将随包发布的自学习层，从真实工作中学习技能。）
在 Claude Code 已经成为事实标准编码代理的当下，绝大多数人的技能库是手写的——用完一条就躺在 .claude/skills/ 里慢慢积灰，既不会合并重复项，也不会在过时后自动退场。AutoHarness 押的是一个具体的赌注：技能层这一小块，完全可以自己维护自己。
要理解这个项目，得先理解 2026 年 AI 工程圈的一个流行说法：swyx 提出的 "Big Model vs Big Harness"——同一个模型，换一套外壳，能力可以天差地别。AutoHarness 引用了 CORE-Bench 上的一组数据（出自论文 HAL，arXiv:2510.11977）：42% → 78%。也就是说，模型本身不变，光是"外壳"设计得好不好，就能拉开一道巨大的鸿沟。
传统做法是：每换一个模型世代，整套 harness 就得手工重写一遍。AutoHarness 的赌注是——harness 里最琐碎的那一层（技能层），可以交给系统自己打理。
这个思路的直接参照物在它的 README 对比表里列得很清楚：Self-Harness（离线批量 + 需要 held-out benchmark 的自编辑）、hermes-agent（定时器 + 常驻守护进程）。AutoHarness 的差异化主张写在每一列里：不要 benchmark，不要 oracle，不要守护进程。
如果把技能库比作一个书架：
关键是这个实习生只动自己写的书。你自己写的、你从别处装的技能，它一个字节都不碰。
AutoHarness 是一个标准的 Claude Code 插件（.claude-plugin/plugin.json，版本 0.5.3，MIT 协议），零第三方依赖，纯 Python 标准库实现。整套系统挂在四个宿主钩子上：SessionStart、PreToolUse、Stop、SessionEnd，全部指向同一个分发器 python3 -m autoharness.hook.dispatch。
流水线由七个组件构成，职责切得很干净：
| 组件 | 职责 |
|---|---|
| CAP 捕获 | 钩子驱动的" dumb pipe"，抓取每一轮的用户输入、代理输出、工具 I/O，出口处做脱敏，不在本地复制对话内容，只回指宿主日志 |
| REF 反思 | 读 episode，对比现有技能索引，决定新增/合并/打补丁/删除附属文件，产出意图（intent）。它只提案，没有写工具 |
| promoter 校验·落盘 | 唯一的写入者。在内存中 lint 意图（安全、结构、账本、完整性、仅限自产），通过后用原子 rename 落进真实技能目录 |
| IDX 呈现 | 会话启动时注入分组索引，把 autoharness 写的技能按类别列在模型面前，不依赖宿主"碰巧"想起它们 |
| MNG 生命周期 | 无守护进程，会话启动时惰性重算。按"加载次数 ÷ 之后到来的请求数"给技能排序——机会相对的分母，关机一夜不会让谁"变老" |
| curator 整合 | 更稀疏的全库级巡检，把近似重复的技能折叠到大伞下，合并前先做快照 |
| LED 账本 | 每个技能的 append-only 旁挂文件，记录它为何诞生、为何改变，以及证据切片 |
这是整个项目最值得学的一处架构决策。反思环节跑在一个后台子代理里（claude -p，用 Haiku 模型），它能读会话记录、能 grep 代码库，但它的工具白名单被死死限制在 Read / Grep / Glob 和一个专用的 stage_skill MCP 工具上——后者只往意图队列追加 JSON 行，永远不碰任何技能目录。
真正决定技能是否落盘的是 src/autoharness/lib/validate.py 里六类纯静态检查器：安全（skills_guard）、结构、账本存在性、内容完整性、全局技能必须与仓库无关、以及"只允许动自产技能"。发现任何一条 find 就整体拒绝。没有 LLM 调用，快速、精确、抗提示注入。
换个说法：模型可以提议，但判决权在确定性代码手里。这正是让"AI 自我修改自己的配置"这件事变得可审计的关键。
MNG 组件里有个细节很见功力：它把三个信号分开记账，绝不混为一谈。
为什么要这么较真？因为如果把 view 也算成"使用"，那一个只是被浏览过一次的技能就会看起来像被认真执行过，生命周期系统就彻底失灵了。
同理，新技能有个"缓刑期"（probation）：项目层 100 个请求、全局层 300 个请求。在这之前它照常被召回，但既不计入容量上限，也不可被淘汰。缓刑期满的复核只归档那些既没被 load 也从没被 view 的技能——"没有使用证据"不等于"有使用无效的证据"。
门槛低得有点反常识：
# 在 Claude Code 输入框里
/plugin marketplace add tigerless-labs/autoharness
/plugin install autoharness@autoharness
然后 /reload-plugins 或重启。零配置。
唯一硬性前提是 PATH 上的 python3 必须是 3.11+。README 里特意点出了这个坑：hooks 里解析的是裸 python3 命令，而 macOS 上 Xcode 自带的 /usr/bin/python3 是 3.9.6，如果它排在 PATH 前面，整个会话的钩子会全部静默失效（项目里 dispatch.py 有专门的版本守卫，会在 stderr 上明确报错并以 exit 0 退出，宁可不干活也不能让会话崩）。
上手形态上只有一个手动入口：/learn——在你想把某个刚想通的道理立刻固化时说一声，它走和后台反思完全一样的提案-校验链路。除此之外全靠钩子自动触发。
所有配置项都是 AUTOHARNESS_* 环境变量，每个都有内置默认值：反思节奏按工具调用次数计（默认 50，不是轮数，所以纯聊天的会话永远不会触发反思）、整合巡检 250、描述长度上限 1024 字符、技能正文超过 25 行非空行会被判定为"转录稿"直接拒绝（细节应该放进 references/）。
这个项目有几处值得泼冷水的地方：
第一，"验证方式"本身就是它最薄弱的一环。 项目方自己也知道——README 里那句 "Validated in use, not on a benchmark" 是双刃剑。官方在 Tigerless 自己的 insights 博客里写得更直白："Usage proves that a skill entered the workflow; it does not prove that the skill caused a better task outcome."（使用证明技能进入了工作流，但不能证明技能带来了更好的任务结果。）在 10000+ 星的项目里，这句话值得原样记住。
第二，"零依赖"是优点，也是约束。 为了不拉 MCP SDK，团队手写了 MCP stdio 协议的服务端（_PROTOCOL_VERSION = "2024-11-05"）。这在当前阶段是划算的，但等 MCP 协议演进时，零依赖会变成维护负担。
第三，代码里的"ponytail"注释暴露了工程债。 dispatch.py 和 stage_skill/server.py 里都留着 ponytail: 标记，坦承了"分离式启动的孤儿进程与超时隔离留待观察""MCP stdio 进程外壳延后到 Phase 7"。这种诚实的 TODO 标注是好迹象，但也说明项目年轻——仓库 2026 年 6 月才创建，四个月，354 次提交，37 位贡献者。
第四，插件形态意味着它绑死在 Claude Code 上。 它的整个设计（hooks 事件、.claude/skills/ 路径、宿主原生召回机制）都是 Claude Code 专属的。README 里提到 MCP server 命名那个细节时，甚至专门解释了为什么必须"以插件方式安装"才能让工具全限定名对上——这类耦合对跨宿主复用是硬约束。
第五，/learn 排在 Stop 钩子里跑，这意味着通知器最多能把一轮对话卡住 AUTOHARNESS_NOTIFY_TIMEOUT_S 秒（默认 5 秒）。虽然设计上做了 fail-open，但确实存在体验上的延迟风险。
翻遍 src/autoharness/ 整个源码树（hook 事件层、lib 核心库、stage_skill MCP 服务），工程规范度明显高于同星级的同类项目：
ruff.toml 选了 E4/E7/E9/F/I/UP/B 七类规则，明确跳过 E501（因为中文注释会超 88 字符，"是噪音不是缺陷"）pytest.ini 里 filterwarnings = error——把警告当错误处理，这个配置比很多商业项目都严格test_capture_truncation_budgets.py、test_promoter_substring_match.py、test_drain_lock.py、test_transient_read_retry.py），还标了 live marker 把需要真实宿主的端到端用例从 CI 里摘出去docs/adr/ 下有两份架构决策记录：归档 sidecar 稳定锁、usage sidecar 失败安全lib/atomic.py）、跨进程锁（lib/lock.py）、脱敏规则表（lib/redaction_rules.toml + lib/redact.py）都是独立模块，有专门测试覆盖，包括针对 redact_email 二次方复杂度和供应商密钥正则的专项用例安全设计上有一条特别值得注意：反射子代理的写工具在钩子层面被直接 deny（dispatch.py 里对 Write/Edit 且 agent_type 为 reflector 的调用一律拒绝）。注释里写明理由是"插件代理不遵守自己的钩子"，所以宿主侧必须有兜底。这是一道比"靠提示词约束"可靠得多的防线。
2026 年上半年，AI 编码代理的竞争已经从"谁的模型更强"转向"谁的外壳更好"。AutoHarness 把这个赛道推到了一个新位置——从"给人提供更好用的工具"转向"让工具自己进化"。
它选择的切入点很聪明：不碰模型、不碰推理、不碰基准测试，只做那件最无聊也最耗时的事——维护技能库。这个问题的特点是：价值真实存在（重复劳动确实在浪费）、信号可以在真实使用中廉价获得（用没用是二元的）、而且完全不需要评测基础设施。
值得注意的对比是它对 hermes-agent 的致谢——README 里明说"研究其自动技能创建与记忆整合设计，帮助打磨了 autoharness 基于遵循度、无守护进程的思路"。开源项目之间互相借鉴设计而非互相攻击，这个生态氛围本身值得记一笔。
如果你想试：
agents/reflector.md（10KB）——这是整个系统的"灵魂文件"，反思代理的完整提示词。看懂了它，就看懂了 autoharness 到底在让模型学什么。{ "env": { "AUTOHARNESS_REFLECT_EVERY_N": "3",
"AUTOHARNESS_MATURITY_PROJECT": "5",
"AUTOHARNESS_CAPACITY_PROJECT": "2" } }
python3 --version 是不是 3.11+，这是最常见的翻车点。.claude/skills/<name>/.ledger.jsonl 里有每条技能的诞生原因和证据文件（references/evidence-*.md，内容寻址存储），这是判断"这技能到底是真有价值还是幻觉产物"的唯一依据。AUTOHARNESS_DISABLE_GLOBAL=1，只在项目层试水。全局层的技能会在每个项目里加载，影响面大得多。AutoHarness 用 10500+ 星和 354 次提交证明了"自学习层"这个概念在 Claude Code 生态里确实有人买单。它的技术贡献不在于某个精妙的算法——事实上整个项目里没有一个深度学习模型——而在于一套边界划得非常清楚的责任划分：模型负责提议，代码负责判决和执行；模型只碰自己的产物；每一次变更都留下可回溯的账本。
这套划分，加上"用真实使用而非离线基准来验证"的取舍，让它成为一个值得仔细读的样本。哪怕你不用 Claude Code，这套"模型提案 / 确定性校验 / 单一写入者"的分层思路，也完全可以搬到你自己的 Agent 系统里。
基本信息
tigerless-labs/autoharness