OpenClaw 测试团队实践(一)

同事问我:”你花这么多时间研究这个,值不值?”

我愣了两秒。

他说的”这个”,是我最近一两个月都在折腾的 AI实践——一个开源 Agent 框架,加一套 Agent 工程方法论。我下班后写 skill、调 memory、跑 pipeline,周末还在看源码。他不是质疑我,是真心问。

我没正面回答。我想了几天,把要说的写下来,大概是这样。

一、先把我们的处境摆出来

我在一家做机械臂的公司做软件测试。

我们的日常,跟很多研发型企业很像:需求挂在 Teambition,缺陷写在禅道,版本节奏由项目经理拍,测试团队夹在硬件、控制、上位机之间,既要保整机出厂,又要管驱控、伺服、力控这些底层模块的回归。

机器人不是 App,跑一次回归测试不便宜。一款轻型协作机械臂,开关机 30 秒;一款大负载机型,开关机要 2 分钟。每一轮力控标定要空载、要校准、要观察示教器有没有飞车。某个关节动一动就可能报奇异点警告。做一次运动类测试,要先热机 8 小时做完辨识才能继续测试。

更要命的是,这些经验只在老员工脑子里。

新人进来,你不可能让他真的去复现一次驱动板报错。你只能让他看文档、看 case、问老人。问到第三次,老人会烦。

所以这几年我一直在想一件事:测试团队的知识能不能不只在人脑里,能不能让一个工具帮我们记下来、传下去、用起来?

我最早的尝试,是用 ChatGPT、文心、Kimi 这类网页版 AI 帮我写脚本、解释报错、整理文档。它能解决很多单点问题,但救不了团队——它没有上下文,没有记忆,不知道我们的产品,也接不上禅道、接不上 Teambition。

我那时候模糊地知道,我要的不是”对话框”,是”能跑流程的东西”。

直到今年年初 OpenClaw 这类开源 Agent 框架陆续放出来,Harness 这套方法论也开始有人系统讲,我才看到一个可能的路径。

二、买了工具不等于用得起来

我最早也是先用现成产品。

QClaw、Cursor、各家国内的 AI 编程助手,我都试过。挑一个需求扔进去,让它生成测试用例,demo 阶段确实漂亮——结构齐整、覆盖全面、连边界条件都给你列出来。

我那时候差点信了。

然后我让团队试用了三周,问题全冒出来了:

第一,多人同时用,串了。A 工程师让它写奇异点的用例,它会把 B 工程师上午聊的力控标定混进来。它没有上下文边界。

第二,它不知道什么是”我们的”测试。生成的用例像通用模板,没有不同机型启动时长的差异感,没有”力控空载先于标定”的隐含顺序,没有我们禅道里那种”按模块归类、按版本回归”的组织方式。

第三,它编造。我让它读一份驱动板报错日志,它能给我说出 87% 的”修复建议”,听起来很专业,但里面 6 成是它瞎想的。我后来才知道,这种现象有个名字叫幻觉,但叫什么不重要,重要的是它真的会把团队带沟里去。

第四,它没有记忆。今天教过它的事,明天得重教。我们好不容易整理出一套缺陷归类规则,它每次都用不一样的标签。

我那时候才明白一件事——

模型本身已经够强了,但”够强的模型”和”团队能用的工具”,中间隔着一整套工程化的功夫。

这套功夫,不是装个软件就有的。

三、那要不要亲自下场?要做到多深?

下场这件事,我犹豫过。

一开始我想外包:找个团队定制一套。但很快放弃——他们不懂机器人测试,我得花更多时间给他们解释什么是奇异点、什么是热机、为什么力控标定不能在带载时做。等我解释完,我自己也学会怎么做了。

第二个想法是让下面工程师去做。但这件事的特点是,没有现成 SOP。它要求做的人既理解测试业务,又能判断 AI 工程的选型,还要愿意为团队的长期收益让渡短期的个人效率。这不是分一个任务出去就能解决的。

第三个想法是等成熟产品。等不到。这个赛道半年一变样,我等一年,团队的认知就掉一年。等我有空了再追,可能连追的入口都找不到。

我最后选择自己下场,有一个朴素的判断:

团队负责人不下场,没人替你下场。

这件事说到底,是要把”测试团队的隐性知识”转化成”Agent 可以执行的显性流程”。这种转化,只有真正知道这些知识长什么样的人能干。我不干,就不会有人干。

接下来的问题是:做到多深?

我给自己画的线是:做到我能在团队里复用、能教给新人、能在两年内还跟得上社区演进。再深就成科研了,再浅就停在 demo 阶段。

OpenClaw 这个开源框架,加上 Harness 这套从 Anthropic 出来的 Agent 工程方法论,正好卡在这个深度上。它们不是产品,是基建。基建意味着我要花时间打地基,但打完之后,上面盖什么楼是自由的。

四、OpenClaw 是抓手,Harness 是方法论

OpenClaw 是抓手——它是开源的 Agent 框架,有现成的 QClaw、AutoClaw、MaxClaw 这些发行版,模型层、Skill+Tool 层、Memory 层分得清清楚楚。我用它来落地具体的 Agent:解析需求、生成用例、归类缺陷、做版本风险画像。

Harness 是方法论——它把”一个能用的 Agent 工程”拆成六件套:上下文管理、工具系统、执行编排、状态记忆、评估观测、约束与恢复。这六件套是我后来回头看,才反应过来”为什么之前 demo 能跑但落地用不起来”的答案。

为什么是测试团队来做这件事,而不是其他职能?

我想了三个理由:

一是高频。测试每个版本都要跑一遍,Agent 能不能用,跑一周就见分晓。比开发那种半年才上线一个大功能的迭代周期合适得多。

二是规则清晰。测试有用例、有评审、有缺陷分类,这些都是显性结构化的东西,正好是 Agent 最擅长接管的部分。

三是数据价值大。禅道里几千条缺陷、几万条用例,这是金矿,但金矿一直躺在那里,没人挖。Agent 给了我们挖矿的工具。

我不打算做工具评测,也不会贴长段代码。Agent 工程的难点从来不在模型,在工程化、流程化、组织化。我要写的,是从”能跑通”到”能交付”中间那一段——这一段最痛最琐碎,但也是真正决定 AI 能不能在你团队里活下来的那一段。

我后来回了那个同事的问题。

我说,值不值这件事,我不是按时间算的。

我现在每天比以前多花两到三小时在这上面,这两三小时,如果只换来”我自己用 AI 提效”,其实不太划算——一个老测试用 AI 提效的天花板,也就是别人的两三倍,不会更多。

但如果换来的是”团队会用 AI 拿结果”,这笔账就完全不一样。十几个人每人提一倍,那是十几倍的复利,而且这种复利会沉淀成团队的能力护城河,不会随某个人离职而消失。

我想要的不是前者,是后者。

所以这件事对我来说,从来不是技术问题,是带队问题。