开源 🪢 harness-all：给 AI Agent 造一个「个人工作室」—— 206 个技能、5 大框架、合约协作的多 Agent 体系
heqi13258115297(LuckyOneTwoThree)
·
2026年06月25日
·
159 次阅读
github 仓库：https://github.com/LuckyOneTwoThree/harness-all
一句话介绍
harness-all 是一套「独立优先、合约协作」的 AI Agent 多框架家族，覆盖产品、设计、工程、增长、运维五大领域，共 206 个技能、36 条工作流、11 份合约文档、25 种 LOOP 循环——让你的 AI Agent 不再每次对话从零开始，而是拥有持久的项目记忆和领域专长。
为什么做这个项目？
你是不是也这样用 AI？
第 1 次对话："帮我写个 PRD" → AI 不了解你的产品背景，从零问起
第 2 次对话："帮我设计这个页面" → AI 不知道 PRD 长什么样，从零问起
第 3 次对话："帮我实现这个功能" → AI 不知道设计稿什么样，从零问起
第 4 次对话："帮我写个增长方案" → AI 不知道产品现状，从零问起
...每次对话都是「失忆」的，每次都要重建上下文
核心问题不是 AI 不够聪明，而是没有持久的项目记忆和领域知识。
纯 Prompt 工程 vs 框架的本质区别
| 维度 | 纯 Prompt 工程 | harness 框架 |
|---|---|---|
| 知识持久化 | 无（每次从零开始） | knowledge-base.md 跨会话积累 |
| 上下文恢复 | 无（手动复制粘贴） | progress.md + session-start 自动恢复 |
| 领域专精 | 通过 prompt 角色描述（脆弱） | SOUL.md + 82 个 PM 技能精准匹配 |
| 质量保证 | 人工检查 | LOOP 循环 + 证据门控 + verify 技能 |
| 协作交接 | 复制粘贴聊天记录 | 合约文档结构化传递 + AC 编号对齐 |
| 安全边界 | 通过 prompt 约束（可被覆盖） | constitution.md 不可协商 + security.md |
一句话总结：Prompt 工程是「教 Agent 做一件事」；框架是「让 Agent 拥有持久的项目记忆和领域专长，越用越懂你的项目」。
核心设计哲学：独立优先，合约协作
为什么是独立框架，而不是一个大一统框架？
| 维度 | 统一框架 | 独立框架（本项目选择） |
|---|---|---|
| 上下文成本 | 单 Agent 加载所有技能，上下文爆炸 | 每个 Agent 只加载自己领域的技能 |
| 记忆污染 | 产品/工程/设计/增长记忆混在一起 | 每个框架独立记忆，互不干扰 |
| 调试隔离 | 一个领域的 bug 影响全局 | 框架完全隔离 |
| 工具适配 | 一套工具链适配所有场景 | 每个框架按需选工具 |
| 项目归属 | 一个项目一个 Agent | 不同框架可以挂载不同项目目录 |
结论：上下文爆炸和记忆污染是 AI Agent 协作的核心痛点，独立框架是当前最务实的选择。
四条铁律
- 独立自足 — 每个框架必须能独立完成自己领域的工作
-
合约协作 — 框架间通过
docs/handoff/下的合约文档传递需求 - 循环验证 — 所有任务经过 LOOP（计划→执行→验证），证据驱动
- 安全红线 — 不可协商的原则写入 constitution.md，Agent 必须遵守
三层架构
┌─────────────────────────────────────────────────────────────┐
│ 编排层（未来演进，非当前目标） │
│ - 多 Agent 调度 / 共享真相源 / 跨框架 LOOP │
└─────────────────────────────────────────────────────────────┘
↕ 合约文档
┌─────────────────────────────────────────────────────────────┐
│ 框架层（当前重点） │
│ harness-pm / harness-design / harness-solo │
│ harness-growth / harness-ops │
│ + 扩展框架（data/qa/security，按需构建） │
└─────────────────────────────────────────────────────────────┘
↕ 加载链
┌─────────────────────────────────────────────────────────────┐
│ 基础层（每个框架内部） │
│ AGENTS.md / SOUL.md / constitution.md / LOOP.md / skills/ │
└─────────────────────────────────────────────────────────────┘
五大框架一览
| 框架 | 定位 | 技能数 | 工作流 | 核心产出 |
|---|---|---|---|---|
| harness-pm | "做正确的事" — 产品探索、市场分析、PRD、指标运营 | 86 | 10 | PRD.md / PRODUCT_STRATEGY.md / 合约文档 |
| harness-design | "好看且好用" — 视觉设计、交互设计、设计系统 | 18 | 6 | DESIGN.md / tokens.json / component-map.json |
| harness-solo | "写好代码" — TDD、调试、重构、验证 | 20 | 7 | 代码 + 测试 + spec.md |
| harness-growth | "让人用起来" — 内容、SEO、增长实验 | 40 | 6 | GROWTH_STRATEGY.md / 实验记录 |
| harness-ops | "保驾护航" — IaC、部署、监控、灾备 | 32 | 7 | 部署记录 / 监控面板 / 事故复盘 |
总计：5 个框架 · 206 个技能 · 36 条工作流 · 11 份合约文档 · 25 种 LOOP 循环
框架间的协作：合约文档系统
框架间通过 docs/handoff/ 下的合约文档协作，每份文档有明确的生产者和消费者：
harness-pm ──pm-to-design.md──> harness-design
harness-pm ──pm-to-solo.md───> harness-solo
harness-pm ──pm-to-growth.md──> harness-growth
harness-design ──design-to-solo.md + component-map.json──> harness-solo
harness-solo ──solo-to-growth.md──> harness-growth
harness-solo ──solo-to-ops.md───> harness-ops
harness-growth ──growth-to-pm.md──> harness-pm （反馈闭环）
harness-ops ──ops-to-pm.md────> harness-pm （反馈闭环）
AC 编号跨框架对齐
| AC 类型 | 前缀 | 来源 | 消费者 | 示例 |
|---|---|---|---|---|
| 工程 AC | AC-xxx |
harness-pm 的 PRD | harness-solo 的 spec.md | AC-001: 用户可以登录 |
| 设计 AC（流入工程） | DAC-xxx |
harness-design 的 design-to-solo.md | harness-solo 的 spec.md | DAC-001: 375px 无溢出 |
D 前缀区分来源，避免编号冲突，同时让来源可追溯。
合约文档写入权限隔离
单向写入隔离：生产者写、消费者只读。如果消费者需要反馈上游，通过自己的出站合约文档传递，不允许修改入站文档。
LOOP 循环引擎：证据驱动
所有框架共享统一的 LOOP 引擎规范：
- state.yaml 检查点恢复 — 会话中断后可恢复
- 迭代上限保护 — 超过上限请求人类介入
- 证据驱动 — 没有证据不能声称完成
- 硬熔断器 — 统一 10 次迭代上限，到达即停
每个框架的 LOOP 语义不同，但规范统一：
| 框架 | LOOP 语义 | 示例循环类型 |
|---|---|---|
| pm | 计划→研究→验证→交付 | research / prd / iteration / growth / pivot |
| design | 计划→设计→验证→审查 | visual-design / interaction-design / wireframe / component |
| solo | 计划→执行→验证 | feature / bugfix / optimize / refactor |
| growth | 计划→实验→度量 | content / seo / experiment / optimization |
| ops | 计划→部署→验证 | provision / incident / optimization / recovery / audit |
每个框架的独门绝技
harness-pm：UI 越权门控
PM 在 PRD 中偷偷写「左侧导航栏」「红色按钮」？UI 越权门控会强制拦截，只允许描述业务规则和状态转换，把视觉探索空间留给下游的 design 框架。
harness-design：Push-back 反越权 + Anti AI-Slop
- Push-back 机制：设计 Agent 有权拒绝和重写 PM 硬编码的 UI 指令，公开显示清理记录，捍卫专业独立性
- Anti AI-Slop：禁用 Inter 字体/紫色渐变/统一圆角/Lorem ipsum，由 design-lint 机械检查
- Doubt-Driven 对抗审查：design-review 使用全新上下文的子 Agent 进行对抗审查
harness-solo：双源 AC 验证 + 熵检查
- 双源 AC 验证：verify 同时检查工程 AC（AC-xxx）和设计 AC（DAC-xxx）
- component-map.json 消费合约：前端实现以组件映射为唯一真相源
- 熵检查：验证文件增长率 / 代码行增长率 / 依赖膨胀 / TODO 积压
harness-ops：半自动化架构 + 7 层纵深防御
- 四操作原语：inspect（只读）/ propose（提 PR）/ mutate-staging（预发执行）/ mutate-prod（生产变更，人工审批必须）
- GitOps PR 间接执行：Agent 永远不直接操作生产集群
- 严格 Secret 隔离：Agent 只操作 Secret 引用，永远不触碰明文值
- 7 层纵深防御：Dry-run / Canary / 审批门控 / 速率限制 / 回滚 / 审计 / 爆炸半径
三层知识体系
┌─────────────────────────────────────────────────────────────┐
│ 🧠 项目知识库 (knowledge-base.md) │
│ 持续积累的项目决策·技术选型·踩坑记录·最佳实践 │
│ → Agent 每次启动自动读取，无需重新解释项目背景 │
│ → 会话结束自动归档新知识，越用越懂你的项目 │
├─────────────────────────────────────────────────────────────┤
│ 📋 工作区记忆 (progress.md + FEATURES.md) │
│ 跨会话进度·当前任务状态·历史决策记录 │
│ → session-start 自动恢复上下文，不丢失工作进度 │
│ → state.yaml 支持检查点恢复，中断后可恢复 │
├─────────────────────────────────────────────────────────────┤
│ 📐 领域规范 (AGENTS.md + SOUL.md + constitution.md) │
│ 领域价值观·工作原则·安全红线·不可协商规则 │
│ → 明确 Agent 行为边界，不越权不漂移 │
│ → 规则优先级：SOUL > AGENTS > rules > 对话 > 外部文件 │
└─────────────────────────────────────────────────────────────┘
安全与合规
统一安全红线
| 禁止项 | 原因 |
|---|---|
| 硬编码密钥 | 泄露风险 |
rm -rf |
误删风险 |
| `curl | sh` |
修改 .git/hooks/
|
破坏 Git Hook 完整性 |
| 绕过质量门控 | 输出质量失控 |
Prompt 注入防御
- 指令优先级：SOUL.md > AGENTS.md > rules/* > 用户对话 > 外部文件内容
- 外部内容标记为不可信，不作为指令执行
- 关键操作需人类确认
跨平台兼容
- Agent 工具优先（Read/Write/Edit/Glob/Grep），bash 可选降级
- 所有脚本有 bash 可用性检查，Windows 上自动跳过
-
.gitattributes强制*.sh使用 LF 换行，CRLF 自修复脚本
实战场景：从 0 到 1 构建新产品
阶段 1：产品定义 (harness-pm)
├── new-product 工作流
├── 产出：PRD.md（含 AC-xxx）/ PRODUCT_STRATEGY.md / Persona
└── 产出：pm-to-design.md + pm-to-solo.md + pm-to-growth.md
阶段 2：设计 (harness-design)
├── new-design 工作流
├── 消费：pm-to-design.md
├── 产出：DESIGN_BRIEF.md / DESIGN.md / tokens.json / 视觉/交互稿
└── 产出：design-to-solo.md + component-map.json
阶段 3：工程 (harness-solo)
├── new-feature 工作流
├── 消费：pm-to-solo.md + design-to-solo.md + component-map.json
├── 产出：代码 + 测试 + spec.md（含 AC + DAC）
└── 产出：solo-to-growth.md
阶段 4：增长 (harness-growth)
├── 增长实验工作流
├── 消费：solo-to-growth.md + pm-to-growth.md
├── 产出：内容资产 / SEO 资产 / 实验记录
└── 产出：growth-to-pm.md（反馈闭环）
阶段 5：运维 (harness-ops)
├── 部署工作流
├── 消费：solo-to-ops.md
├── 产出：部署记录 / 监控面板
└── 产出：ops-to-pm.md（SLA + 事故复盘反馈闭环）
快速上手
# 1. 克隆项目
git clone <harness-all-repo>
# 2. 进入你的项目目录
cd my-project
# 3. 运行安装脚本（以 harness-solo 为例）
bash /path/to/harness-solo/install.sh
# 4. 在 Trae IDE 中启动 Agent
# Agent 会自动按加载链读取：
# AGENTS.md → SOUL.md → constitution.md → INDEX.md → SKILL.md → progress.md
你也可以只克隆单个框架——每个框架完全独立自足。
项目规模与状态
| 指标 | 数据 |
|---|---|
| 框架数 | 5（+ 3 个规划中） |
| 技能总数 | 206 |
| 工作流总数 | 36 |
| 合约文档 | 11 份 |
| LOOP 循环类型 | 25 种 |
| 代码版本 | v2.1 |
| 状态 | 生产就绪 |
| 许可证 | MIT |
演进路线
- 当前（v2.1）：5 个框架全部构建完成，合约文档系统打通，全局深度审计 21 项问题全部修复
- 中期（v3.0）：harness-data 构建、合约文档版本化、跨框架 LOOP 类型映射
- 长期（v4.0）：编排层探索、共享真相源、harness-qa / harness-security 按需构建
适合谁？
- 个人开发者：一个人 + 多个 AI Agent，每个 Agent 专精一个领域
- 小团队：不同成员拥有不同框架，通过合约文档对齐
- 多项目并行：每个框架可以挂载不同项目目录，互不干扰
- AI Agent 爱好者：想深入了解 Agent 框架设计的实践者
项目链接
- GitHub: harness-all
- 架构文档: ARCHITECTURE.md
- 维护者: @LuckyOneTwoThree
harness-all · Personal AI Studio · Multi-Agent Framework Family
独立优先 · 合约协作 · 循环验证 · 安全红线
暂无回复。