# harness-engine

**Repository Path**: toxcode/harness-engine

## Basic Information

- **Project Name**: harness-engine
- **Description**: harness-engine（驾驭引擎）：听起来像是一个强大的底层基础设施，非常契合你“可复用底座”的定位。

- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-07-02
- **Last Updated**: 2026-07-02

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 🎛️ Enterprise AI Harness (企业级数字员工驾驭工程)

欢迎来到企业级 AI Harness 工程！本仓库是团队的"数字员工通用底座"，包含了跨项目共享的安全红线、角色定义和标准化技能（SOP）。

通过本 Harness，我们将 AI 编程助手从"随机的聊天机器人"升级为"受控的、具备企业级素养的数字员工"。

## 目录结构说明

```text
.harness/
├── agents/            # 角色定义层（数字员工的"岗位说明书"）
│   ├── coder.md       # 编码专家：负责业务逻辑实现
│   └── reviewer.md    # 评审专家：负责代码审查与安全合规检查
├── rules/             # 全局治理层（不可逾越的"企业红线"）
│   └── security.md    # 安全规范（禁止硬编码密钥、高危操作拦截等）
├── skills/            # 技能体系层（标准化的"SOP 操作手册"）
│   └── unit-test/     # 编写单元测试的规范与工具链
└── templates/         # 模板库（减少重复造轮子）
    └── prd-spec.md    # 需求规格说明书模板
```

---

## 如何挂载到业务项目？

本 Harness 采用 **"全局底座 + 项目专属上下文"** 的双层架构设计。请按照以下步骤将其引入你的业务项目：

### 第一步：挂载全局底座（Git Submodule）

在业务项目根目录下，执行以下命令将本仓库作为子模块引入：

```bash
git submodule add <本仓库的Git URL> .harness
```

**版本管理建议**：Submodule 会锁定当前版本。当本仓库有规则更新时，业务项目需手动执行 `git submodule update --remote` 拉取最新规范，确保团队平滑过渡。

### 第二步：配置项目专属上下文

在业务项目根目录下，创建 `context/AGENTS.md` 文件（或直接在根目录创建 `AGENTS.md`）。  
这个文件是数字员工的"项目入职培训包"，需要由业务开发者手动维护，包含：

- 当前项目的技术栈与框架版本
- 项目目录结构约定
- 本地启动、测试、构建的常用命令（Runbooks）
- 特殊的业务逻辑约定

### 第三步：适配 AI 编程工具

- **Cursor**：将 `context/AGENTS.md` 的内容复制到项目根目录的 `.cursorrules` 文件中。
- **Claude Code / Cline**：原生支持读取 `AGENTS.md`，将 `context/AGENTS.md` 重命名为 `AGENTS.md` 放在根目录即可。

---

## Harness 的日常维护与自进化

Harness 是一个"活系统"。为了让数字员工越来越聪明，请遵循以下维护原则：

### 1. 建立"错误驱动"的自进化闭环

当数字员工在业务项目中犯错（如幻觉、格式错误、越权操作）时，不要只在对话中纠正它：

- **分析根因**：是缺乏上下文，还是规则不够明确？
- **更新规范**：将修复逻辑转化为明确的约束，提交 PR 更新本仓库的 `rules/` 或 `agents/` 文件。
- **全局生效**：让所有业务项目的数字员工"永远不再犯同类错误"。

### 2. 将"软约束"升级为"硬校验"

自然语言的 Rule 终究是软约束。在维护 Harness 时，应逐步把高频、易错的规则沉淀为可执行的脚本（如配置 `pre-commit` 钩子、CI 流水线）。只有机器校验通过，任务才算真正完成。

### 3. 保持架构的"可拆卸"与弹性

随着底层大模型能力的提升，很多以前需要复杂 Pipeline 才能实现的功能，现在模型一个 Prompt 就能搞定。请定期审视 Harness 中的规则，及时移除冗余的控制逻辑，保持系统的轻盈。

---

## 贡献指南

欢迎团队成员在日常开发中沉淀优秀的 SOP 或发现新的安全漏洞。

1. 从 `main` 分支拉取新分支（命名规范：`Feat_xxx`）
2. 修改或新增 `rules/`、`agents/`、`skills/` 下的文件
3. 提交 Pull Request，并在描述中说明 **"为什么需要这条新规则"**（最好附带踩坑案例）
4. 经过团队 Code Review 后合并

---

**核心理念：人类掌舵，AI 执行。用工程化的手段，驯服大模型的不确定性。**