HBM 介绍
2026/5/13 10:50:40
1. 项目概述：从单兵作战到工程化流水线
如果你用过像OpenClaw这样的AI智能体平台，大概率经历过这样的场景：你给AI一个复杂的开发任务，比如“给我的博客系统加个收藏功能”，它吭哧吭哧写了一大堆代码，你满怀期待地跑起来，结果发现要么接口定义错了，要么前端组件样式崩了，要么压根没处理用户未登录的情况。然后你不得不自己花时间Review、提修改意见、让它重写，一来二去，沟通成本比你自己写还高。这感觉就像指挥一个能力很强但缺乏流程的新人，事无巨细都得盯着，累。
guixiang123124/openclaw-harness（我们姑且叫它“工程化套件”）要解决的，就是这个“累”的问题。它不是一个新工具，而是给OpenClaw这个“大脑”装上了一套成熟的“工厂流水线”和“质量管理体系”。核心思想是：让你的主智能体（Lead Agent）扮演技术负责人或项目经理的角色，把一个大任务拆解成标准化的“冲刺”（Sprint），然后通过OpenClaw内置的ACP（Agent Control Protocol）能力，自动调度像Claude Code这样的“建造者”（Builder Agent）去执行具体编码，最后再由主智能体进行多维度的代码评审。只有评审分数达标，代码才会被自动提交、部署，并通知你。
简单说，它把一次性的、充满不确定性的AI编码指令，变成了一个可重复、可度量、能自我迭代的软件工程流水线。你从“监工”变成了“产品经理”，只需要提出需求，定义验收标准，剩下的规划、拆分、执行、质检、交付，全部由智能体团队自动完成。这对于需要持续迭代的真实项目来说，价值巨大。
2. 核心设计思路：为什么是“Harness”而非“Flow”
在深入细节前，有必要理解这个项目在技术选型上的一个关键决策：为什么基于OpenClaw原生能力构建，而不是另起炉灶搞一套新系统？这直接决定了它的使用成本和架构风格。
2.1 与主流方案的对比：以DeerFlow为例
社区里早有类似的想法，比如ByteDance开源的DeerFlow。它是一个基于LangGraph的多智能体编排框架，功能强大。但如果你仔细看它的架构，会发现它更像一个“全家桶”式的新系统：
- 部署复杂：需要Docker、LangGraph Server，有一整套独立的运行时环境。
- 集成成本高：需要为Claude、GPT等模型编写CLI包装器，要自己实现记忆系统、沙箱执行环境。
- 通道独立：需要额外开发对接Telegram、Discord等消息通道。
OpenClaw Harness则走了完全相反的“轻量集成”路线：
- 零额外部署：它本身只是一组“技能”（Skill）和“智能体模板”（Agent Template），通过
clawhub或openclaw skills install一键安装到你的现有OpenClaw环境中。 - 能力复用：直接利用OpenClaw Gateway作为运行时，用原生的ACP协议调度Builder，用内置的
memory_search做记忆，用exec命令在宿主环境执行命令。 - 通道原生：直接复用OpenClaw已经配置好的Telegram、Discord等消息推送能力。
用一个比喻：DeerFlow是自建了一个全新的汽车制造厂，而OpenClaw Harness是给现有的、运转良好的汽车工厂（OpenClaw）设计了一套更高效的自动化生产流程与质检标准。后者显然更轻、更快，也更符合“站在巨人肩膀上”的开源精神。
2.2 五阶段流水线：Scout, Build, Review, Iterate, Ship
工程化套件的核心是一个严谨的五阶段流水线，它模拟了资深工程师的思考和工作流程：
- 侦察（Scout）：主智能体（Lead）接到任务后，首先会扫描你的代码库，理解项目结构、技术栈和业务逻辑。然后，它会输出一份名为
SPRINT.md的文档。这份文档至关重要，它定义了本次冲刺的具体范围、成功标准、API接口规范、数据结构变更、测试要点等。这相当于把模糊的需求转化为了精确的技术规格说明书。 - 建造（Build）：Lead智能体通过ACP，创建一个Claude Code（或其他编码智能体）会话，并将
SPRINT.md作为核心输入。Builder智能体在此约束下进行编码。这里的关键是隔离：Builder只关心“如何实现规格书”，不参与规划和评审，保证了执行专注度。 - 评审（Review）：Builder提交代码后，Lead智能体会启动评审。这不是简单的“代码好不好看”，而是一个基于四个维度的量化评分体系（后文详述）。Lead会生成详细的评审报告，指出优点和扣分点。
- 迭代（Iterate）：如果综合评分低于预设的合格线（默认7.0/10分），Lead会将评审报告作为反馈，再次通过ACP发给Builder，要求其修改。这个过程最多进行3轮，以避免无限循环。
- 交付（Ship）：一旦评分达标，Lead智能体会自动执行一系列操作：提交代码到Git、推送到远程仓库、触发部署脚本（如果配置了），并通过配置好的消息通道（如Telegram）向你发送交付报告。
这个流程的自动化，将你从繁琐的“代码审查-反馈-等待修改”循环中解放了出来。你只需要关注SPRINT.md的质量和最终的交付报告。
注意：
SPRINT.md的质量直接决定整个流水线的效率。一个模糊的规格书会导致Builder反复猜测，评审不通过，陷入多轮迭代。务必在任务描述中尽可能清晰，或者信任Lead智能体在Scout阶段生成的规格书，并在其基础上进行微调。
3. 量化评审体系：从主观评价到客观评分
传统AI编码的一个痛点是输出质量不稳定且难以评估。工程化套件引入了一个四维度量化评分模型，将主观的“代码好坏”转化为可衡量的分数。这是整个系统能闭环的关键。
3.1 四个核心维度及其权重
| 维度 | 权重 | 考察重点 | 具体检查项举例 |
|---|---|---|---|
| 功能性 | 30% | 是否100%实现了SPRINT.md中定义的需求？ | API端点、参数、返回值是否正确；UI组件是否具备所有指定交互；业务逻辑是否完整。 |
| 代码质量 | 25% | 代码是否整洁、可维护、符合最佳实践？ | 命名规范；函数单一职责；重复代码消除（DRY）；适当的注释和文档；错误处理是否优雅。 |
| 安全性 | 25% | 是否存在明显的安全漏洞？ | 用户输入验证与过滤；身份认证与授权检查（如是否绕过鉴权）；敏感信息（密钥）是否硬编码；CORS配置是否正确。 |
| 边界情况 | 20% | 是否考虑了异常和边缘场景？ | 网络请求超时、失败处理；空数据、非法数据输入的处理；并发场景下的数据一致性；资源清理（如关闭数据库连接）。 |
每个维度会得到一个1-10分的子分数，然后加权计算得到总分。例如：总分 = (功能性得分 * 0.3) + (代码质量得分 * 0.25) + (安全性得分 * 0.25) + (边界情况得分 * 0.2)
3.2 安全一票否决制
在这个体系中，安全性拥有最高优先级，并实行“一票否决”制。如果在评审中发现身份认证绕过、敏感信息泄露、严重的注入漏洞等高风险安全问题，无论其他维度得分多高，本次冲刺都会被判定为自动失败（FAIL），直接进入迭代阶段。这强制智能体在编码时必须将安全作为首要考虑，而不是事后补救。
3.3 评审报告样例
一份好的评审报告不仅是打分，更是改进指南。Lead智能体生成的报告通常类似这样：
## 代码评审报告 - 用户收藏功能API **综合评分：7.8/10** ### 分项评分 - **功能性：9/10** ✅ 所有接口实现正确，符合SPRINT要求。 - **代码质量：8/10** ✅ 代码结构清晰，但`favoritesService.js`中`addFavorite`函数超过80行，建议拆分为更小的函数。 - **安全性：6/10** ⚠️ **关键问题**：`POST /api/favorites`接口未验证当前登录用户与传入`userId`是否一致，存在越权风险。 - **边界情况：8/10** ✅ 考虑了收藏已存在、资源不存在等情况。 ### 主要问题与改进建议 1. **安全漏洞（必须修复）**：在`favoritesController.js`第47行，直接使用客户端传来的`userId`。应改为从会话（session）或令牌（token）中获取当前用户ID。 2. **代码结构**：建议将`addFavorite`函数中的数据验证、业务逻辑、数据库操作拆分为独立函数。 **结论**：由于存在安全漏洞，本次提交未通过。请Builder根据上述建议#1进行修复，并考虑建议#2。这份报告给出了明确的扣分原因、具体位置和修改方向，使得Builder的迭代目标非常清晰。
4. 实战部署与配置指南
理论再好，不如上手跑一遍。下面我将带你完成从零安装、配置到运行第一个自动化冲刺的全过程。
4.1 环境准备与安装
首先，确保你有一个正在运行的OpenClaw环境。然后，安装工程化套件：
方法一：通过ClawHub一键安装（推荐）
clawhub install harness-factory这个命令会自动从技能仓库下载并安装最新的harness-engineering技能包。
方法二：手动安装（适用于开发或定制）
# 克隆仓库 git clone https://github.com/guixiang123124/openclaw-harness.git # 复制技能文件 cp -r openclaw-harness/skills/* ~/.openclaw/skills/ # 复制智能体和工作区模板 cp -r openclaw-harness/agents/ ~/.openclaw/workspace/openclaw-harness/agents/ cp -r openclaw-harness/templates/ ~/.openclaw/workspace/openclaw-harness/templates/安装后，重启你的OpenClaw Gateway以使新技能生效。
4.2 关键配置：启用并配置ACP
工程化套件依赖ACP来动态创建Builder智能体，因此必须正确配置。
# 1. 启用ACP及相关插件 openclaw config set plugins.entries.acpx.enabled true openclaw config set acp.enabled true openclaw config set acp.backend acpx # 2. 设置默认的Builder智能体（这里以Claude Code为例） openclaw config set acp.defaultAgent claude-code # 你也可以配置其他编码智能体，如 `gpt-4-code-interpreter` # 3. 设置ACP权限模式为“全部批准”，避免每次创建会话都需要手动确认 openclaw config set plugins.entries.acpx.config.permissionMode approve-all # 4. 重启Gateway使配置生效 openclaw gateway restart重要提示：
approve-all模式在便利的同时也带来了风险，因为它允许你的Lead智能体无条件地创建新的智能体会话并执行操作。请确保你仅在受信任的环境（如本地开发机或安全的VPC内）中使用此模式。在生产环境中，建议使用更严格的权限控制。
4.3 编写你的第一个“冲刺”任务
安装配置完成后，你就可以对你的OpenClaw主智能体下达指令了。指令有两种风格：
风格一：直接启用“Harness模式”
“使用harness模式，为我的项目`/Users/me/my-web-app`添加一个密码重置端点。”智能体会自动识别harness关键字，触发整个五阶段流水线。
风格二：明确指令
“为路径`/path/to/my/project`激活工程化套件，任务是构建一个用户收藏夹功能。”当你发出指令后，观察智能体的输出。它首先会进入Scout阶段，浏览你的项目，然后生成并展示SPRINT.md的内容。这是你进行干预和修正的第一个也是最重要的机会。仔细阅读这份文档，确保它准确理解了你的需求和技术栈。如果有偏差，可以直接告诉它：“在SPRINT.md中，数据库模型需要增加created_at字段”，它会更新文档后再进入Build阶段。
5. 冲刺规划与拆解的艺术
工程化套件能否成功，一半取决于“冲刺”规划得好不好。根据项目经验，我总结了一份“冲刺规模指南”，能极大提高一次通过率。
5.1 不同任务类型的冲刺规模建议
| 冲刺类型 | 建议最大代码行数 | 首次通过成功率 | 关键注意事项 |
|---|---|---|---|
| 后端API端点 | 80-150行 | 90%以上 | 范围清晰，必须包含请求/响应模式、数据验证逻辑。一个冲刺只做一个端点（如POST /api/users）。 |
| 后端重构 | 100-200行 | 70%-85% | 必须有清晰的“前后对比”规格。例如：“将userService.js中的回调函数改为Async/Await”。范围必须严格限定。 |
| 前端组件 | 50-120行 | 60%-75% | 一个冲刺只做一个组件。例如：“创建一个<ProductCard />组件，包含图片、标题、描述和按钮”。避免在一个冲刺里做整个页面。 |
| 前端页面重写 | 200行以上 | 低于30% | ⚠️强烈建议拆分。将页面拆解为布局、顶部导航、侧边栏、主内容区等多个组件冲刺，分别完成。 |
| 全栈功能 | 任意 | 低于20% | ⚠️必须拆分。永远将“后端API”和“前端调用/展示”拆分成两个独立的冲刺。先完成后端冲刺，再基于稳定的API进行前端冲刺。 |
5.2 如何制定一份优秀的SPRINT.md
Lead智能体生成的SPRINT.md是蓝图。一份优秀的规格书通常包含以下部分，你可以按此标准去审视和修正：
- 目标概述：用一两句话说明本次冲刺要做什么。
- 范围界定：明确包含什么，更重要的是，明确不包含什么。例如：“本冲刺仅实现
GET /api/posts接口，分页和过滤功能将在后续冲刺中实现。” - 技术规格：
- 后端：详细的API路径、方法、请求体/参数、响应体、状态码、可能的错误。
- 前端：组件名称、Props接口、需要触发的交互事件、预期的UI状态。
- 数据：数据库表/集合的变更（新增字段、索引等）。
- 成功标准：可验证的验收条件。例如：“调用
POST /api/login并传入正确凭证，应返回200和JWT令牌；传入错误凭证应返回401。” - 测试要点：需要验证的边界情况，如空输入、超长输入、并发请求等。
- 依赖与假设：说明本次冲刺依赖的其他服务、库或前提条件。
实操心得：我习惯在Lead生成SPRINT.md后，手动添加一条：“请确保所有新增的API端点都包含基本的输入验证，并对涉及用户数据的操作进行身份认证检查。” 这条简单的指令，能提前堵住很多安全性和健壮性上的漏洞，显著提高评审通过率。
6. 高级技巧与故障排查
即使流程设计得再完美，实际运行中也会遇到各种问题。下面分享一些从实战中总结的技巧和常见问题的解决方法。
6.1 提升Builder输出质量的技巧
- 为Builder提供上下文：在项目根目录放置一个
ARCHITECTURE.md或README_DEV.md文件，简要说明项目结构、编码规范、使用的框架和库版本。Lead在Scout阶段会读取这些文件，并将其上下文传递给Builder，使生成的代码更符合项目风格。 - 利用模板：工程化套件自带了
backend-api.md,frontend-component.md等模板。你可以根据自己项目的技术栈（如Express.js + React, Django + Vue）定制这些模板，定义更具体的代码模式和规范，让产出更一致。 - 限制迭代轮次：默认最多3轮迭代是合理的。如果3轮后仍不达标，往往意味着SPRINT.md本身有问题，或者任务过于复杂需要进一步拆分。此时应该中断流水线，人工介入分析原因。
6.2 常见问题与解决方案
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| Lead智能体无法正确Scout项目 | 项目路径错误或权限不足；项目结构过于复杂。 | 1. 检查路径是否正确，确保OpenClaw进程有读取权限。 2. 在指令中提供关键文件路径作为提示，如：“请重点查看 /src/models/user.js和/src/routes/auth.js。” |
| Builder生成的代码完全跑偏 | ACP会话中传递的上下文丢失；SPRINT.md描述模糊。 | 1. 检查ACP配置是否正确，acp.defaultAgent是否指向正确的编码智能体。2. 细化SPRINT.md，使用更精确的技术术语，并提供1-2个现有代码文件作为样式参考。 |
| 评审分数始终很低，卡在迭代循环 | 评分标准过于严苛；Lead智能体过于“挑剔”。 | 1. 可以微调评审智能体（agents/reviewer.md）的提示词，适当放宽“代码质量”维度的要求，更聚焦于功能性和安全性。2. 检查是否是某个特定问题（如一个函数过长）导致重复扣分，可在反馈中明确告知Builder忽略此问题。 |
| “Ship”阶段提交失败 | 本地Git未初始化或远程仓库地址错误；缺少部署脚本执行权限。 | 1. 确保项目目录是一个Git仓库，且远程地址已配置。 2. 检查OpenClaw的 exec权限，确保它能执行git,npm run deploy等命令。3. 可以在SPRINT.md中暂时移除自动部署步骤，改为手动操作。 |
| 安全评分导致频繁失败 | Builder智能体对安全最佳实践不熟悉。 | 在SPRINT.md的“成功标准”部分，明确加入安全要求。例如：“所有API端点必须使用authMiddleware进行鉴权”，“用户输入必须使用joi库进行验证”。给Builder明确的指引。 |
6.3 关于“自我改进”的展望
项目路线图中提到了“跨冲刺学习（Cross-sprint learning）”，这是v0.9版本的目标。其设想是，Lead智能体可以将历史冲刺的评审反馈、常见错误模式积累到记忆系统中。当规划一个新冲刺时，它能主动应用这些经验，比如：“上次我们因为没做输入验证导致安全分低，这次要在SPRINT.md里特别强调验证。” 这将是工程化套件从“自动化”走向“智能化”的关键一步，值得期待。
7. 总结与个人体会
使用OpenClaw Harness工程化套件几个月下来，我的最大感受是：它并没有取代开发者，而是将开发者从重复、低层次的指令与审查中解放出来，让我们能更专注于架构设计、核心逻辑和产品定义。
以前，让AI写一个功能，我需要反复描述细节、检查代码、指出错误，沟通成本巨大。现在，我只需要思考清楚“我要什么”，并用尽可能清晰的语言告诉Lead智能体。剩下的拆分、执行、质量把关，都由这个智能体团队自动完成。它就像一个不知疲倦、严格遵循流程的初级开发团队，而我则是他们的技术主管。
当然，它目前还不是银弹。复杂任务的成功率依然依赖精细的拆分（SPRINT规划），对于非常新颖或缺乏类似模式的任务，智能体也可能表现不佳。但它的价值在于建立了一种可靠、可重复的协作范式。随着“跨冲刺学习”等功能的加入，这个范式会越来越智能。
如果你已经在使用OpenClaw进行开发辅助，我强烈建议你尝试这个工程化套件。从一个小而具体的API端点开始，体验一次完整的“规划-建造-评审-交付”闭环。你会发现，当AI编码被纳入一个严谨的工程流程后，其产出效率和可靠性的提升是显而易见的。这或许是迈向真正AI辅助软件工程时代的一块重要基石。