Harnessmith 解决什么问题

Harnessmith 面向同时使用一个或多个 Coding Agent、并希望长期维护自己工作方式的人。它不创造新的模型能力， 而是把容易散落在配置、聊天和个人经验里的工作约束，变成一套可以安全安装、按需读取和持续验证的本地 Harness。

它并不是先按一套 Harness Engineering 理论设计出来的。最初只是想把实际项目中已经有效的 AGENTS.md、文档检索和 工作记录方法抽出来，让它们可以跨项目、跨 Coding Agent 复用；宿主、授权、Memory、生命周期和验证等边界，都是在 通用化过程中逐渐出现的。完整过程见历史与思想来源。

问题不是少写一份规则

假设你在 Codex 中规定“只读分析不能改文件”，在 Cursor 中补了测试命令，又在 Claude Code 中记录了发布流程。 几周后，三份规则已经不同；换到新的项目或宿主时，你也很难知道哪一份才是最新的。

继续把所有内容塞进一个巨大的 AGENTS.md 也不能真正解决问题。常驻上下文变长后，最关键的边界会被大量细节 淹没；而具体流程仍可能过期。真正需要管理的是一套系统：稳定入口、按需文档、宿主适配、可恢复安装、工作状态和 验证证据。

历史文档也不能为了缩小目录就直接删除。它们记录了决策和方案如何演进，但不应该默认进入每一次对话。否则大量过期、 弱相关甚至互相冲突的内容会挤占上下文，增加误判和幻觉风险。Harnesssmith 因此保留历史，同时通过路由、元信息和检索 只加载当前任务需要核对的部分。

安装前：规则和状态各自漂移

• 每个宿主分别维护规则路径和格式，容易漂移。
• 规则文件既承担安全边界，又承担所有操作手册，越来越难读。
• 长任务依赖聊天历史；上下文压缩或换会话后，目标、进度和验收条件容易丢失。
• 安装脚本可能直接覆盖文件，失败后难以恢复原状。
• “Agent 说完成了”容易和“结果已经机械验证”混在一起。

安装后：形成一套可维护的工作层

• 一份宿主中立的 Harness 通过 Adapter 分发到多个 Coding Agent。
• 短入口只保留高损失规则和路由，详细流程在需要时才加载。
• Personal overlay 中的 Repository Map 保存有来源的仓库职责与直接关系，帮助跨项目任务定位 owner、契约和发布边界。
• Memory 保存待核对线索；Task 保存目标、检查点、验收条件和证据。
• 安装前可以 dry-run；写入经过预检、锁、staging、备份和失败回滚。
• 能力声明区分已实现、宿主负责和不支持，不把文档建议包装成技术强制。

它适合什么场景

Harnesssmith 适合个人长期维护、跨项目复用的 Coding Agent 工作环境，尤其适合多宿主、长任务、严格 Git/发布边界， 以及希望把经验沉淀成可检索文档而不是无限增长提示词的使用方式。

如果你只偶尔使用一个 Agent、只需要几行项目说明，直接维护一个简短 AGENTS.md 可能已经足够。Harnessmith 也不是团队级云端控制平台，不提供模型服务、多 Agent 调度或集中式权限系统。