heqi13258115297 (LuckyOneTwoThree)

🪢 harness-all：给 AI Agent 造一个「个人工作室」—— 206 个技能、5 大框架、合约协作的多 Agent 体系

heqi13258115297 — Thu, 25 Jun 2026 10:18:21 +0800

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

独立优先 · 合约协作 · 循环验证 · 安全红线

一个人就是一支军队：我开源了一套 “多 Agent 协作框架”，把个人 AI 工作室搬到了本地

heqi13258115297 — Tue, 23 Jun 2026 11:05:50 +0800

哈喽 W2Solo 的各位老哥/小伙伴们，

作为独立开发者，我们最头疼的往往不是技术本身，而是上下文切换的巨大损耗。上一秒还在构思产品的核心痛点，下一秒就要调 CSS 的渐变色，晚上还要硬着头皮去搞服务器部署和跑 SEO。

为了解决这个问题，很多人尝试把各种任务扔给 AI（比如 Cursor 或者各类单体 Agent 工具）。但很快就会发现一个致命问题：上下文爆炸和记忆污染。当你试图让一个 Agent 既懂产品又写代码时，它的记忆和设定就会变得混乱，改个前端 Bug 甚至能把最初的产品约束给忘了。

既然我们在现实中也是通过不同角色的协作来完成项目的，为什么不给 AI 也分个工？

经过一段时间的打磨，我做了一套给 AI Agent 用的框架家族，今天正式开源分享给大家 —— harness-all 多 Agent 框架家族。 🔗 GitHub 开源地址：https://github.com/LuckyOneTwoThree/harness-all

说明一下：这个框架是可以演变的，在一定程度上来说，整合在一起也是可行的，但并不推荐（就目前的 agent 工具）。框架目前是基于项目的，当然也可以演变成一个工作室，可以同时处理多个项目，就需要将这个框架的层级提升，并做一些处理（依然不推荐）。目前这个状态是我用起来比较舒服的，当然这个东西因人而异，大家可以基于我这整个框架设计按自己的喜好去进行优化。

它能帮你真正在本地搭建一个“个人 AI 工作室”。

🌟 核心理念：独立优先，契约协作

我没有搞那些花里胡哨的 “多智能体自动群聊” 架构，而是采取了最务实的设计： 物理隔离的独立框架 + 基于文档的契约协作。

每一个领域都有独立的 Agent 框架（独立的 Memory、知识库和工具链），它们彼此互不干扰。这就好比你拥有了五个专业的独立工位：

🎯 harness-pm（产品总监）：负责用户探索、竞品分析，帮你写出带验收标准（AC）的 PRD。
🎨 harness-design（设计总监）：负责视觉系统和交互。它甚至带有防越权机制，不会盲从 PM 瞎指挥的丑陋 UI 指令。
💻 harness-solo（核心骨干开发）：专注工程实现。严格遵循 TDD 和卡帕西工程原则，只改必须改的代码。
🚀 harness-growth（增长黑客）：帮你出 SEO 策略、内容营销方案和漏斗分析。
🛡️ harness-ops（SRE 运维）：搞定 IaC 部署、GitOps 和线上监控告警。

🤝 独立开发者怎么用它？（契约协作模式）

框架之间的沟通极度克制，不走复杂的内部通信 API，而是走 交接文档（Handoff Docs）。

比如你的工作流可以变成这样：你在 PM 框架里聊出一份 PRD ➡️ 把 PRD 文档扔给 Design 框架，它产出设计稿和组件映射字典（Component Map）➡️ 把这俩文档连同 PRD 塞给 Solo（开发）框架，它负责完美写出代码。

整个过程的每一步产出，你作为 “老板” 都是可读、可 Review、可随时手动修改干预的。

🚀 开箱即用的工业级配置

既然是辅助独立开发的生产力工具，就必须足够健壮。这套项目目前已经处于 Production-Ready 状态，内置了：

206 个专业 Skill 和 36 个标准 Workflow，开箱即用。
统一的 LOOP 循环引擎：所有 Agent 干活必须遵循 plan → execute → verify。没有验证证据不许声称完工！带有状态断点续传（重启接着干）和 10 次硬熔断防死循环。
严格的安全红线：底层宪法（Constitution）级拦截，绝不允许 rm -rf 或者硬编码上传你的服务器 Secret。

💡 写在最后

harness-all 的初衷，就是想让那些充满奇思妙想、但苦于精力有限的独立开发者们，真正拥有一个 “不知疲倦、各司其职” 的虚拟外包团队。

目前项目已经开源，代码仓库也算是我写的一份 “如何构建企业级 Agent Prompt 和 Skill” 的最佳实践参考。

🔗 GitHub 开源地址：https://github.com/LuckyOneTwoThree/harness-all

非常欢迎大家试用、Fork 或提出建议。独立开发的路上，希望这套工具能帮你省下宝贵的睡眠时间！欢迎在帖子里交流探讨~

苦于 AI 技术选型？我用 Next.js 撸了一个 2026 最新 AI 全景图网站，已开源！

heqi13258115297 — Thu, 11 Jun 2026 11:25:31 +0800

大家好！

不知道大家在平时开发或者做架构选型的时候，有没有这种感觉：现在的 AI 工具和框架出得太快了，简直一天一个样。

前几天我想找个好用的 RAG 框架，结果在 GitHub 和各大技术群里翻了半天，发现很多高赞的项目其实已经几个月没维护了，反而一些新的轻量级框架没人总结。光是测试这些框架就花了我大半个周末。

为了解决自己和团队 “挑花眼” 的问题，干脆一不做二不休，我花时间把目前市面上主流的 AI 基础设施、大模型、开发框架以及提效应用，全部盘点了一遍，并且自己动手造了个轮子，做成了一个开源网站。

💡 先看成果

在线体验： https://LuckyOneTwoThree.github.io/ai-landscape/ GitHub 源码： https://github.com/LuckyOneTwoThree/ai-landscape（如果你觉得有点用，求个 Star ⭐️，感谢各位大佬的支持！）

🛠️ 为什么不直接写篇博客，而要搞个网站？

因为静态博客没法维护。AI 领域的数据一旦写死在 Markdown 里，三个月后就彻底过期了。

所以我设计了一套高度自动化的更新流，也是这个项目我觉得最 Geek 的地方：

数据与视图分离：所有模型和工具的数据全部存在 data/*.yaml 里。
自动化构建：写了个 Python 脚本，只要修改 YAML，运行一下脚本就会自动生成对应的带排版的 Markdown 文档。
全局超链接注入：为了避免满屏幕的 URL 导致源码杂乱，我写了个正则注入脚本。只要在数据源里配置了官网，表格里提到该工具的地方，全网自动挂载超链接，连组合工具（比如 DALL-E 4 + Sora 2.0）都能精准解析。

🎨 极简 Vercel 风格

前端部分用了 Next.js 16 + Tailwind CSS（实际上只用了基础类）+ Next-Themes。我个人非常喜欢 Vercel 这种冷淡但极其克制的极简风格，所以：

砍掉了所有多余的视觉噪音，全站支持 完美顺滑的暗黑模式 (Dark Mode)。
超链接我做了一个丝滑的蓝色下划线悬停动画，大家可以在网页里自己感受一下手感。

📦 里面有什么内容？

目前已经按分类整理了 10 大模块：

基础设施：GPU 云厂商、向量数据库、推理引擎
大语言模型 (LLM)：国内外最新闭源、开源模型对比
多模态模型：图像、视频生成（对齐了 2026 年最新数据）
RAG 与开发框架：数据解析引擎、Agent 框架选型
合规与评测：红蓝对抗、内容风控工具

🤝 欢迎共建

一个人的精力始终有限，这个全景图我计划以 “季度” 为单位持续维护下去。如果你正在做 AI 相关的开源项目，或者发现了某个极客级别的神级工具我没有收录，非常欢迎各位提交 PR。只需要在 YAML 文件里加两行代码，自动化脚本会搞定剩下的一切。

如果你觉得这个汇总或者这套架构对你有帮助，恳请给个 Star ⭐️，这是对我这种周末不休息纯为爱发电的开源作者最大的鼓励！

Github 传送门：https://github.com/LuckyOneTwoThree/ai-landscape