我用 OpenClaw 搭了一套多Agent对抗式开发流水线，一个需求2.5小时出可运行代码

作为工业视觉领域的工程师，白天跑客户、谈方案、做报价，晚上还要写算法、调模型、搭系统。一个完整产品从需求到可运行代码，传统方式少说一周。但一周对于冷启动阶段的一人公司来说，太奢侈了。上下文焦虑（任务一长就急着收工）和自我评价膨胀（写完永远说"完美通过"）。解法来自两个地方：Anthropic的一篇工程博客，和我从GAN（生成对抗网络）借来的一个思路。

头帕王子

772人浏览 · 2026-04-06 12:33:33

头帕王子 · 2026-04-06 12:33:33 发布

我用 OpenClaw 搭了一套多Agent对抗式开发流水线，一个需求2.5小时出可运行代码

10年工业视觉老兵，一人创业中。用OpenClaw搭了一套AI公司的操作系统——多Agent协作开发、自动化工作流、智能获客。技术+踩坑+创业，都写。

在这里插入图片描述

前言：一人创业的效率困境

作为工业视觉领域的工程师，白天跑客户、谈方案、做报价，晚上还要写算法、调模型、搭系统。一个完整产品从需求到可运行代码，传统方式少说一周。但一周对于冷启动阶段的一人公司来说，太奢侈了。

我试过让单个AI Agent写代码——能跑，但有两个致命问题：上下文焦虑（任务一长就急着收工）和自我评价膨胀（写完永远说"完美通过"）。

解法来自两个地方：Anthropic的一篇工程博客，和我从GAN（生成对抗网络）借来的一个思路。

一、两个让AI代码质量打骨折的问题

Anthropic在《Harness design for long-running application development》中系统定义了这两个问题：

问题1：上下文焦虑

Agent执行长时间任务时，随着上下文越来越长，模型会提前收工——跳过细节、写"总结性"代码。Anthropic测试了Claude Sonnet 4.5，发现即使做上下文压缩也解决不了，最终靠"上下文重置"（每个阶段清空上下文，用结构化文档传递状态）才解决。

问题2：自我评价膨胀

“When asked to evaluate work they’ve produced, agents tend to respond by confidently praising the work—even when the quality is obviously mediocre.”
—— Anthropic

让Agent自己审自己写的代码，它几乎永远打高分。Anthropic的解法是角色分离——写代码的人和审代码的人不是同一个Agent。“Separating the agent doing the work from the agent judging it proves to be a strong lever.”

我完全认同。但我在工程落地时发现Anthropic的三角色（Planner/Generator/Evaluator）缺了一个关键层——他们把代码审查和功能评估混在一起了，而这两件事需要的能力完全不同。

二、我的方案：OpenClaw + Harness v3.0

我在OpenClaw上落地了自己的Harness协议，5个角色：

角色	职责
Planner	拆需求为Sprint，定义评分标准
Generator	按Sprint实现功能
Evaluator	按评分矩阵打分——产品视角（功能全不全、方案对不对）
Validator	独立代码审查——工程视角（有没有Bug、代码规不规范）
Integrator	汇总决策：通过 / R1修改 / R2重做 / R3推翻

Validator是我比Anthropic多出的一层。Evaluator看的是"做的东西对不对"，Validator看的是"代码能不能跑"。两个视角不同，需要两个独立Agent。

Sprint机制

每个Sprint是独立可验证的功能单元，分三层：

Core Sprint：核心功能，不通过则全量重做
Standard Sprint：标准功能，不通过则局部迭代
Light Sprint：微调优化，不通过则直接修改

每个Sprint流程：

Planner拆解 → Generator编码+自测 → Evaluator评分 → Validator代码审查
                                                      ↓
                                      Integrator决策（通过/R1/R2/R3）
                                                      ↓
                                                  下一Sprint

评分矩阵（7维度）

维度	权重	阈值	评分要点
场景定位准确性	20%	≥16	是否准确理解应用场景和用户需求
技术方案合理性	20%	≥16	算法选型、架构设计是否恰当
功能完整性	15%	≥12	需求覆盖度
创新性	10%	≥8	是否有差异化价值
文档/注释质量	10%	≥8	可维护性
风险识别	15%	≥12	是否预判了潜在问题
商业可行性	10%	≥8	成本、实施难度是否合理

任一维度低于阈值则该项不通过，总分低于80则Sprint失败。

这个矩阵不是拍脑袋定的，是踩过坑之后迭代出来的（后面第四节会详细讲）。

一个Evaluator Prompt示例

调教Evaluator是这篇文章最有价值的干货。Evaluator的Prompt里要明确：

你是一个严格的產品评审，不给面子。
- 先找问题，再找优点
- 每个扣分项必须说明：问题是什么、严重程度（致命/严重/轻微）、改进方向
- 打分标准：满分100，每维度有明确阈值（见附录）
- 低于80分的Sprint，必须给出"具体要修改什么"而非"整体还行"
- 鼓励在关键风险点上给低分，宁可过度严格，不可放过问题

加上这段之后，Evaluator的评分才真正有参考价值。之前它会说"整体不错，只有小问题"，现在它会说"这个API设计在并发场景下有崩溃风险，必须修改"。

OpenClaw的局限性

说实话，OpenClaw不是完美的。我在落地过程中遇到过这些问题：

上下文传递有损耗：Generator写的文档传到Validator，偶尔会有格式小问题，需要人工核对
Token消耗大：多Agent协作比单Agent消耗的token多3-5倍，成本是真实考量
Sprint配置需要人工维护：目前我的Sprint定义和评分矩阵是手写的YAML，还没自动化

但在"多Agent协作"、“SubAgent独立上下文”、"Cron自动化"这几个核心需求上，OpenClaw是目前我找到的最优解。

三、实战案例：智慧养老AI检测系统

项目背景

一个养老场景的AI检测系统，包含跌倒检测、行为分析、异常报警、Web管理后台等功能。从需求到可运行代码，全程由Harness流水线执行。

执行过程

Sprint 1：跌倒检测核心算法（81.4分，R2通过）

Generator实现了基于人体姿态估计的跌倒检测算法。R1评审时发现场景定位有偏差——系统过于关注"跌倒瞬间"而忽略了"跌倒后的持续状态监控"。修改后R2通过。

Sprint 2：边缘服务+报警+API+数据库（82.0分，R2通过）

R1发现部分API设计缺少权限控制，修改后R2通过。

Sprint 3：Web管理后台+AI增值模块（83.5分，R1一次过）

质量最高，直接通过。

Validator发现的4个关键Bug

这是全文最有说服力的部分——独立审查确实能发现Generator自测遗漏的问题：

Bug 1：角度计算逻辑错误（致命）
直立人体被误判为偏离超过60°，三级预筛选机制完全失效。Generator的测试用例里没有覆盖"标准站立姿态"这个边界情况。

Bug 2：计数器归零顺序错误（致命）
连续帧计数器在错误位置被清零，导致弯腰捡东西这类动作被误判为跌倒。

Bug 3：API方法名拼写错误（严重）
一个关键接口的方法名拼错了，运行时会直接抛出异常崩溃。这个Bug连自测都能"通过"，是因为测试用例本身写错了——测的是方法存在性，不是方法能不能正常调用。

Bug 4：测试推送永远返回True（中等）
报警推送功能的单元测试，无论输入什么都返回成功。是因为测试用例的断言写反了（assert result == True 而不是 assert send_alert() == True）。

这4个Bug，Generator自测时全部"通过"。如果是自己写+测，估计要调2-3小时。

成果数据

代码量：约8500行（16个Python文件 + HTML + 配置）
总耗时：约2.5小时自动执行，其中Planner拆需求约15分钟，各Sprint自动执行，我负责关键节点确认
Sprint通过率：100%（Sprint 1和2需要R2迭代）
局限性说明：这个案例是后端+算法密集型，涉及复杂前端UI的话时间估计会翻倍

四、5条用真金白银换来的经验

1. 评分标准写得太泛，等于没写

我最初版的评分标准写的是"代码质量好"、“架构设计合理”——Evaluator看完说"好的"，给分全是80+。看起来很美，跑起来全是坑。

后来改成具体指标：“API响应时间<200ms”、“并发连接数≥1000”、“跌倒检测召回率>95%”——这才真正能筛选出问题。

踩坑故事：有一轮Sprint我写了"风险识别≥12分"，结果Generator交上来的"风险识别"内容是"暂无已知风险"——5个字，拿了13分。后来加了规则：“风险识别必须有具体风险点列表，每个风险点需标注概率和影响，否则0分”。

2. Sprint粒度太大，是最大的时间杀手

我第一次跑Sprint 2，拆成了一个大Sprint（边缘服务+报警+API+数据库+加密），Generator用了将近1小时，结果交出来一看——功能全有，但每块都只做了60分，API简陋，加密是Dummy实现，数据库连索引都没建。

后来规则改了：每个Sprint不超过1500行代码，不超过3个核心子功能。粒度小，Generator不会因为任务太长而走偏，也方便精确定位问题出在哪一块。

3. Evaluator要调教成"挑刺型"，不是"鼓励型"

LLM默认倾向于给正面评价。我在Evaluator的Prompt里明确要求：

打分低于70分时，必须写出"哪个具体问题导致了低分"
不能用"整体不错"、"基本满意"这类模糊表述
发现任何一个致命/严重级别的问题，该维度直接扣50%分

调教之后，Evaluator从"好好先生"变成了"毒舌评审"——有一次给了72分，理由是"并发测试未覆盖边界条件，在高负载下有内存泄漏风险，建议立即修改"。

4. 三级恢复策略省了80%的token浪费

不是每次不通过都要推翻重来：

L1（小改）：局部修改后R1重新提交。适用于命名错误、边界条件遗漏等。占80%情况
L2（局部重做）：某个子模块打回重做。适用于架构设计不合理、功能缺失等。占15%情况
L3（全量推倒）：根本性重做。适用于场景理解完全错误。占5%情况

第一次跑Sprint 1时，Generator交了，我没想清楚应该给L1还是L2，直接让它全改了——结果白白浪费了1小时。后来发现90%的问题其实都是L1就能解决的。

5. 不绑定模型才能活下来

这个流水线里，Planner用推理能力强的模型（需要强规划能力），Generator用代码能力强的模型，Validator用中间档。

我目前用的组合在2026年4月性价比最优，但模型能力更新很快。关键是接口抽象，随时可以换。现在我每个角色的模型配置都是YAML里的一行，改模型只需要改配置，不影响整体流程。

五、这套东西为什么有价值

一人公司最大的瓶颈不是能力，是时间和注意力。

Harness流水线把**“写→测→审→改→再测”**这个原本需要人工串行的循环自动化了。质量不降反升，原因是：Evaluator和Validator不认识Generator，没有面子问题；评分标准比人工Review更一致；每个Sprint独立上下文，Generator不会因为上下文太长而焦虑收工。

在工业视觉这个领域，我需要同时是算法工程师、售前顾问、项目经理和售后支持。代码开发的时间被压缩到极限。Harness让我在"有质量保证"的前提下，把精力花在真正需要人的地方：判断需求是否真实、方案是否可行、客户是否值得跟。