AI Harness 企业级落地实践（一）

#一、前言

今年 AI 圈是非常躁动的，除了全民养龙虾，Harness 也在技术圈掀起了不小的波澜。

与open claw不同的是，Harness 不是一个服务大众的产品。通俗来说，Harness 是将工程学的思维，落地成范式束缚于Agent上，让Agent能够更规范、更稳定的工作。

#Harness是什么？

想象一下在广袤的草原上，一群骏马飞快的驰骋着，它们就是 AI，有时候难免会跑偏。此时一位猛男，拿着马具跳到马背上，三下五除二就让骏马一直沿着正确的道路飞奔！

这个马具就是 Harness！👉 套马的汉子，你威武雄壮~

> 关于Harness更具体的定义可以参考以下文献: OpenAI Harness 深度长文、Harness Engineering即控制论

今天笔者的核心：详细拆解 Harness 工程的设计和落地

同时，也会把这套实践开源，让每个开发者都能快速用上 Harness，解决“万事开头难”的哲学难题

• 快速、低成本给自己的项目加上Harness范式
• 享受 openSpec +oh my xcode带来的高质量方案设计和代码交付
• 轻易定制建设更适合自己团队的Harness项目工程

开源项目地址：github.com/WxqKb/cow-h…

你的  [Star]  将是我的核动力✨

#二、基础软件工程理念

Software Process Improvement（SPI）

前面我们讲到，Harness 简单理解就是让AI 大模型能严格按照软件工程的体系，执行方案分析设计、代码开发、测试验证等流程，从而高效完整的完成工作。

这次 Harness 的搭建，使用软件工程中一个比较标准的体系： 《软件过程改进闭环》

立项决策 → 需求规划 → 评审规范 → 实施验证 →复盘改进

在整个工程中，我们把复杂的需求拆解为以下环节，从而契合CMMI 与 敏捷Scrum 的迭代研发标准框架：

Decisions → Plans → Reviews → Specs → Verifications → Retros

软件工程标准专业名词

所属体系

decisions

基线决策 / 变更决议 / 技术决策

CMMI、敏捷

plans

迭代规划 / 项目计划 / 里程碑计划

敏捷Scrum、软件工程

specs

需求规格说明(SRS) / 技术规范 / 基线规范

软件工程、CMMI

reviews

同行评审 / 阶段评审 / 质量门禁评审

CMMI、ISO软件工程

verifications

验证 Verification (V)

CMMI

retros

过程复盘 / 迭代回顾 / 流程改进回顾

Scrum、SPI

#三、框架选型和落地

#1. 技术选型

Harness 的搭建，需要把这些软件流程落成约束范式，把每一个环节都拆细，比如：

• 需求理解阶段：用头脑风暴（brainstorming）的模式，让AI 覆盖更多的边界场景思考出来
• 技术方案设计：我们会用 superpower（brainstorming、writing-plans），通过不断的追问，从顶层设计、全栈链路、风险前置等维度，与研发人员进行确认，边界场景覆盖完整
• 方案评审：严格的过程，指定 superpower 对应的技能，来进行智能评审，对方案进行评分。同时设定门禁，必须由研发人员同意才能继续往下实施
• 任务实施：拆分完的 Task，我们通过 omx、using-git-worktrees 进行编排。它会自动把具体的任务分配给合适的 Agent，达到更高效的编排和更完美的实施
• 等等……

#2. 脚手架设计

csharp
cow-harness/
├── README.md                  
├── project.profile.md         # AI 生成的项目基础信息画像
├── context-map.md             # AI 生成的项目模块/上下文边界地图
├── project.verification.md    # AI 生成的项目级验证规则
│
├── core/                      # 通用 Harness 规则（核心约束）
│   ├── harness.md             # Harness 核心理念与总体约束
│   ├── routing.md             # 任务路由表与分发规则
│   ├── artifacts.md           # 过程产物格式与存放规范
│   ├── verification.md        # 验证门禁与完成标准
│   └── runbooks.md            # 各类任务的标准操作手册
│
├── init/                      # 新项目初始化
├── entrypoints/               # AI 入口文件模板（CLAUDE.md 等）
├── adapters/                  # 各编程工具适配模板（.cursor/ 等）
├── scripts/                   # 内部脚本，初始化会调用
└── artifact-templates/        # 过程产物模板

• core层是核心的约束

  • routing 路由表会判定用户的任务属于 SPI 的哪个流程，进而决定使用什么工具和流程

    

  • runBooks 执行手册会说明哪些环节使用什么技能

    

  • artifacts 会约束过程产物的规范，并且沉淀成项目级别的知识库；

  • verification 会规定验证和准入标准

• init 层，支持一句话，让 AI 在你的项目中部署 Harness，将工具适配层、入口文件等投射到你的项目根目录中。

  • 同时阅读你的项目，生成属于你项目的信息画像。
  • 这一步非常重要，完成初始化后，你在让 AI Agent 工作的时候，自然就会按照Harness 的约束去执行任务了

• entrypoints，AI 执行指令时是会先找到项目目录下的入口文件。

  • 比如 gpt 会加载 AGENT.md，Claude 会加载 CLAUDE.md
  • init 的时候，会把入口文件投射到项目中，重新启动 AI Agent，查看默认上下文，你就会发现对应的入口文件都被加载进去了

- adapters：AI 编码工具的适配层，需要指定主流工具严格进入入口文件，进入 Harness 约束

#### 3. 一些粗浅的设计理念

• Harness 其实也是软约束，init 做好最基础的工作，达到可用状态
• 文件投射到项目本地，最大的好处是**你完全可以根据自己的实现，去修改 Harness 约束**
• 没有提供 sdk、npm 包等接入方式，最直接把cow-harness 拷贝到你的项目中，自由度完全开放给开发者。我们希望，每个人都能深度参与到对 AI 的管控，直到成为你团队内完全可复用的 AI 规范
• 长期来看，大模型的能力提升会弱化 Harness 的作用。但**约束的设计思维，必然与时俱进**

#四、接入步骤

1. 项目拷贝
   把cow-harness 项目 fork/ download 下来，通过 git submodule 引导你的项目中（或者直接把cow-harness 文件夹放在项目中）

2. 阅读 README，执行 init，这一步 AI 会：

• 安装相关的 skills
• 生成项目画像
• 投射必要的文件到本地
• 创建产物结构目录

不要手工阅读和执行每一步，请务必相信 AI 比我们做的好。直接把下面这段话发给 AI：

bash
请先读取 cow-harness/README.md 和 cow-harness/init/bootstrap.prompt.md。
这是一个新项目刚接入 Agent Harness，请按 Harness 初始化流程处理：
1. 从 cow-harness/entrypoints/ 投影根目录 AI 入口文件。
2. 从 cow-harness/adapters/ 投影工具适配目录。
3. 创建 .ai-runtime-artifacts/ 及其子目录。
4. 如需安装或检查 AI runtime，请先说明会修改哪些本机环境，然后由你执行 cow-harness/scripts/install-ai-skills.sh。
5. 读取 cow-harness/init/project-profiler.prompt.md。
6. 扫描当前项目，生成或更新 cow-harness/project.profile.md、cow-harness/context-map.md、cow-harness/project.verification.md。
7. 由你运行 cow-harness/scripts/harness-check.sh。
8. 汇总推断项、待确认项和验证结果。

3. 开始执行任务
重启 AI 终端，开启你的 cow-harness 之旅

## 五、自我 QA 环节

1. 接入之后，是不是所有任务都必然会走到 harness 约束中？
   答：理论上是的，但是我们会判断这个任务的量级，小任务会直接放行

   

2. harness 的约束能否达到 100%？
   答：否！harness 也是软约束，你甚至可以理解成是 prompt 超集，在实践中我们正常的提问都可以命中，同时我们在产物中明确说明了推理过程中使用了那些技能

3. 这个项目的目的是？
   答：核心只有一个：帮助部分同学解决 Harness “万事开头难”的问题。这是个非常简单的基础建设，你开始之后可以轻松随意植入自己想法，去约束 AI，加入新的技能包

4. 如何加自己的技能包？
   答：能用开源的尽量用开源的，社区的 Star 和实践踩坑，能让你少走很多弯路。内部自定义的 Skills，请用 skills-create 这个官方技能包去创建

5. 如果用了 Harness 还是不理想怎么办？
   答：如果有更好的，那么换了cow-harness。这终归是一个软约束，模型能力的提升能让我们当下的约束被取代。然而往下探究，当 prompt 约束不够了，就需要干涉到更底层，比如 Agent 内部的编排逻辑，比如构建你公司项目的知识库，等等

#六、下一步计划

在实践过程中，笔者会不断优化cow-harness的建设，核心目标是更向一人公司靠拢：

• 方案输出更精准，接入类似 openspec 的优秀实践，让 specs 的设计更加完整
• 构建更完整的软件研发全流程：产品 prd 解析、全栈开发流程、AI 测试、监控链路建设等等

Harness 之后，也许我们会再往知识图谱、RAG 向量化、垂类模型训练、Agent 编排逻辑和执行拓扑等方向去学习，分享。

---

本文转载自：AI Harness 企业级落地实践（一）