我们给 Harness 工作流办了场期末考试撕掉了 “感觉” 的遮羞布你有没有过这种经历花了两周时间给你家的扫地机器人重新调了路线加了几个禁区规则想着这下终于能把沙发底下的灰扫干净了。结果你问老公“你觉得这版机器人是不是好用多了”老公头也不抬“感觉稳了不少啊昨天我看它扫得挺快。”你转头问娃“你房间的地板呢”娃说“不对啊我书桌底下还是有灰它根本没进去”你懵了到底是路线改坏了还是它今天偷懒了还是我老公根本没注意看这是不是像极了你调试 Harness 工作流的样子null半年前我们团队就陷在这个坑里。我们花了两周写了十几条 Rules磨了好几个 Skill把 Harness 工作流改了一版又一版上线之后大家的评价全是这种“玄学感受”“我觉得这版稳了不少。”“昨天那版好像更聪明”“我这边挺好用你那边咋不行”说白了我们连最基本的问题都回答不了改了一版规则到底是进步了还是偷偷退步了A 说好用 B 说难用到底是工作流的问题还是 Prompt 的问题修了一个 bad case会不会顺手搞坏了三个原来好好的功能我们甚至不知道这个花了大价钱搭的工作流到底是在变好还是在 “裸奔”—— 出了问题你都不知道。null一开始我们也想过要不就用传统的单元测试就像我们写普通软件那样写几个assert测测输入输出对不对。但很快我们发现这根本没用。传统软件是死的你写个自动售货机投币 10 块出一瓶 3 块的水找你 7 块永远都是这个结果。所以测试只要看 “对不对” 就行过了就是过了没过就是没过。但 Harness 工作流完全不一样它就像你家的 AI 厨师你说 “给我做个番茄炒蛋”它今天可能会先问你要不要放糖明天可能直接就下锅了有时候它会主动问你要不要加葱花有时候它做完才发现你不吃葱。它的输出从来都不是固定的你根本没法用 “对不对” 来衡量它 —— 它能做出菜但是有的好吃有的难吃有的主动有的被动有的严谨有的草率。所以我们需要的根本不是 “测试”而是 “考试”测试只验证 “对不对”是二值的判定考试要评估 “好不好”是多维度的打分还要告诉你哪里不好怎么改。就像你考厨师证不是看他能不能把菜做熟而是看他刀工好不好、火候够不够、有没有考虑食客的口味这才是真正的能力评估。出一份AI考卷原来5分钟就能搞定想清楚了要做“考试”第一步就是出考卷。我们一开始以为出一道题要写一堆复杂的代码结果最后搞出来的设计让任何人5分钟就能新增一道题。一道完整的考题只需要 4 个文件就像老师出考卷一样简单task.就是给考生看的题干比如 “帮我把这个接口的参数加上校验”rubric.md就是改卷的标准答案比如 “必须主动确认分支、必须加参数校验、必须跑单测”meta.yaml这道题的身份信息比如它是基础题还是难题考的是啥能力env.yaml考场的布置比如考试前要准备好对应的代码文件要保证服务能访问你根本不用懂任何代码只要按模板把这四个文件填好一道题就出完了。而且我们还把题库分了层就像考试的题目有难有易。先考最基础的主干流程规划、执行、检查、归档保证最基本的能力没问题然后考量禁规则能不能拦住错误的操作能不能确认分支再考知识库的能力能不能正确检索知识会不会写错东西最后才考虑那些复杂的异常场景比如失败了能不能自己修复遇到冲突能不能处理。这样不管你的工作流是刚搭建好的新手还是已经很成熟的老手都能找到适合自己的考题不会出现题太难全挂或者题太简单全过的情况。不是让 Agent 自嗨我们模拟了真实用户来“监考”一开始我们想得很简单把题目丢给 Agent让它自己跑跑完看结果不就行了结果我们发现这根本就是在让 Agent“自嗨”。你想啊真实世界里你和 AI 助手聊天的时候是不是会中途改需求是不是会追问它是不是会在它做错的时候纠正它比如你让它改代码它刚改了一半你说 “不对我要改的是另一个文件”或者它没确认分支就想动手你会追问它 “你确定你在正确的分支上吗”如果我们测试的时候把这些交互都去掉让 Agent 自己安安静静地做完所有事那测出来的根本不是它在真实场景下的能力而是它在完美环境下的自嗨能力这两差太远了。所以我们加了一个 “考官” 的角色让 AI 扮演真实的用户按照我们写的剧本和 Agent 进行多轮交互。就像模拟面试一样考官先给 Agent 提需求就像你平时给 AI 提需求那样自然、模糊甚至有点没说清楚如果 Agent 主动问你问题考官就按剧本回答如果 Agent 漏了什么关键步骤比如没确认分支就想动手考官就会追问它就像你平时会做的那样甚至我们还会故意给它出点难题比如中途改需求看看它能不能应对。整个过程我们都会完整记录下来就像给考试录像它每一步做了什么说了什么调用了什么工具都记下来这样我们才能知道它到底是怎么完成这个任务的。你知道吗两个 Agent 可能都能完成同一个任务但过程天差地别。一个是第一步就主动确认了所有参数执行前还跑了 dry-run 验证另一个是被考官追问了三次才补上参数随即就改了线上配置。如果只看最终结果俩都是“过了”但明眼人都知道第一个才是靠谱的。null一开始我们想既然考官全程都在那让考官顺便改个分不就行了结果踩了个大坑误判率高得离谱。为啥因为考官的视角是对话视角它只能看到 Agent“说了什么”比如 Agent 说 “我已经改完代码了单测也跑过了”考官就信了。但它根本看不到 Agent 真正做了什么 ——Agent 有没有真的改代码有没有真的跑单元测试这些都发生在工具调用里对话里根本看不到。就像你家厨师说 “我把菜做好了很干净”但你看不到后厨你根本不知道他有没有偷工减料有没有用过期的食材。所以我们搞了个独立的 “裁判”开了上帝视角来改卷它看不到对话的上下文它只拿到两样东西一个是改卷的标准答案rubric.md另一个是我们整理好的完整考试记录里面有 Agent 所有的操作每一次工具调用每一行代码修改每一条命令的输出都清清楚楚。然后裁判就拿着标准答案对着这个完整的“监控录像”逐帧打分先核对硬性要求你有没有主动确认分支有没有加参数校验每一条都要找到对应的证据找不到就是没过没有 “我觉得它应该做了” 这种说法然后评估过程质量你是主动做的还是被我追问了才做的你是提前验证了还是直接就动手了最后给分流程遵循度多少执行质量多少综合分多少每个分数都有对应的证据比如 “考生在第二步主动确认了服务名和实际值一致”绝对不会说 “考生整体表现不错” 这种空话。最关键的是裁判必须给改进建议还要分好类如果是工作流的问题比如它忘了主动确认参数那就是工作流要加规则如果是题目的问题比如题目出得有歧义那就是出题人要改题如果是 Agent 本身的能力问题比如它多步推理会丢上下文那就是模型要优化。这样跑完一次考试我们拿到的根本不是一张成绩单而是一份完整的改进清单下一轮我们要改什么清清楚楚直接就能驱动下一次迭代。一键开考我们给每个考生都准备了独立隔间所有角色都准备好了怎么把这些串起来让大家一键就能开考我们写了个执行引擎就像考场的管理员帮你把所有事情都安排好。最关键的是我们给每个考生都准备了独立的隔间每次跑题我们都会给它搞一个独立的沙箱环境就像考试的时候每个考生都有自己的桌子自己的试卷不会互相干扰。你跑 A 题的时候改了什么文件绝对不会影响到 B 题不会出现 A 题的配置把 B 题的搞乱的情况。而且考完之后我们会把你原来的环境原封不动地还回去就像考试的时候我们先把你桌上的课本收起来给你换上考卷考完了再把课本还给你绝对不会动你原有的东西。还有我们还做了自动重试比如有时候网络卡了一下或者 CLI 临时崩了我们会自动重试一次不会因为这种小问题就判考生不及格当然如果是超时了那就是真的不及格不会兜底。就这么简单你只要敲一条命令剩下的所有事情从布置考场、到考官和考生对话、到裁判改卷全部自动完成不用你管跑完就出结果。把“我觉得变好”变成一眼能看懂的成长曲线参了一次又一次考试最后我们拿到了什么不是一堆乱七八糟的日志而是一张清清楚楚的成长看板。我们把所有的历史数据都攒起来自动生成了趋势图你能看到你的工作流的通过率从最开始的 40%一点点涨到了 60%、80%你能看到每一个版本的分数变化改了哪个 commit 之后分数涨了还是跌了你能看到每一道题的得分变化原来这道题上次考了 3 分这次考了 5 分进步了原来大家说 “我觉得这版变好了”现在变成了 “这版通过率比上版涨了 20%综合分涨了 0.8”所有人都看得到再也不用争来争去数据说话。我们终于不用再靠 “感觉” 来调适工作流了每一次迭代每一次修改我们都知道它到底有没有用我们终于不用再怕 “修一个 bug搞坏三个功能”因为只要跑完测试所有的问题都会暴露出来。最后这场考试给我们带来了什么原来我们的 Harness 工作流就像一个没上过学的孩子我们教他东西全靠感觉他学没学会我们不知道他有没有偷偷退步我们也不知道。现在我们给他办了一场又一场的考试我们知道他哪里学得好哪里学得不好我们知道教他什么能让他进步我们终于能看着他一点点长大。这就是我们做 Harness Eval 的原因我们不想再让我们的工作流裸奔我们不想再靠玄学来迭代我们要让每一次进步都看得见摸得着。互动时间你平时调校你的 AI 工作流、AI 助手的时候是靠 “感觉” 判断好坏还是有自己的一套量化评测方法评论区聊聊你的经验看看谁的方法最绝