作为AIPM在设计监控AI产品全链路过程中有一个不可或缺的步骤——agent逻辑设计。我有个浅薄的认知现在的agent不论功能多么强大受到多少赞誉本质上就是一个接一个的workflow的有机结合。但是恰巧是中间的逻辑设计离不开产研团队夜以继日的苦思冥想。如今所有优秀的agent产品如果能细细剖析其运行逻辑每次都忍不住感叹这些优秀工程师的奇思妙想。甚至遇见某些设计和自己想法相近但是当时自己却离实现只差一步之遥当然可能不止“一步”甚至都会有种悔不当初的痛悟。之前提到过我在橙厂做过一段时间的机评流程极其简单输入–模型自己玩去–输出写写prompt就能够有个看的过去的准确率。然而在黄厂当1交给我机评的业务时候直接推翻了我之前“机评啊我会简单”这样的可笑想法。北京–黄厂–某生活助手-02据1说上面对这个产品寄予厚望但是目前不管是市场反馈还是流量数据都表现出这个产品的普及程度远不如预期。当时的情况是我们统计整合后台的用户评论每天大概有3k左右的新增评价2.7K是骂人的。后来这个产品和市面上另一款比较优秀、用户量较大的友商产品做一次合作我个人认为主要目的之一就是导流为自家孩子吸引更多用户。但是两边一对接不管是技术上的、理念上的、执行上的diff可以用海量来形容而且仅是灰度上线的数据就可以用海量来形容。我们一个新建两三个月的评测组哪怕是把原来的活都搁下全部人力都投入这次合作也算得上捉襟见肘。因此一套自动化流程的机评可以说势在必行。要求达到的效果包括准确率达到人工级别实际实施是按照9成人工准确率执行逻辑上可以复用在这个业务行得通相似业务只需要轻微修改就能够实现上线等等。我就来当这个业务的leader了1还和我说当初面试的时候就我有自动化经验办成了以后就把这个交给我。结合后面他原形毕露我合理怀疑这纯粹就是打鸡血、画大饼。第一次试验由于两边很多都没有拉齐规则比较简单数据也很规矩一致率一下子干到95%给我和分配给我的同事到全组乃至12都干出自信来了。我采用的方法还是很原始就是写几套prompt每个维度都写一套规则比较含糊的地方我们就和业务方拉会理解下业务逻辑理清之后补充到prompt里面剩下的都交给裁判模型。但是后面随着双方此起彼伏的想法评测规则越来越复杂说是繁琐也不为过而且规则的质量并不好说直白点就是颗粒度很差。但是不管是业务还是产研都忙着和对面打嘴炮问1一些业务细则不是之后查无此事就是查无此人。开会汇报还会来一句要我俩摒弃学生思维不要等着业务来给我们细则要我们自己去问。顶着这些压力我俩的思路仍然是提示词不够好于是加班加点的改提示词。当然这些压力确实有我的原因我不该把问题丢给别人之后自己就不去追问了。现在我的教训就是说出来有点得罪人别把领导当人。做不出活来吃亏的永远是自己。说一嘴我这个同事我对他的评价很好没有坏心思我的想法他都会接受写文档等什么活都愿意。而且他更擅长使用ai经常coding出一些很好用的小工具帮我少走了不少弯路。要说什么不好的话即使有点太老实了不会为自己申辩1拿他当老实孩子使劲招呼但是很多事情其实不应该这么做也不去说出自己的想法。后来终于算是出来一套比较稳定的规则后面的变动都是在这套benchmark上的细微改动。但是这套规则到我俩手上当时就傻在原地——6个评测维度34个子维度100多个指标还有两组整体评测模块两个模块还有20多个维度。原本我们接到的需求是按照每一轮人机交互进行作业现在又要把一整个session塞给裁判模型去打标。第一版prompt我的一致率跳水到65%同事直接掉到58%。不得不说是个不小的打击以至于我当时手足无措还在想在一组prompt上做改动完全没有跳出来把全链路当作一个ai agent产品去经营的想法。对于所谓agent逻辑设计是想都没想。汇报会议上1问我们还有没有改进思路我当时说了好几点改进prompt的方案1说是自己之前干过机评也认同了我的想法说是尽管试试。但是一致率始终卡在70%一直上不去。我当时想一定是规则颗粒度不够事实上确实不够我应该继续理解业务场景、拆分评测规则只要我拆的够细我就能让裁判模型理解人的想法——毕竟规则我们都能看懂但是很多情况下人的思维是连贯的是一气呵成的而模型并不能一直理解这种人脑习以为常的思维跳跃。于是我又仔细拆分每一个业务场景尝试理解我们这边产研的逻辑又要想通对面的思路只要一条拆的足够细致我就迫不及待的塞进prompt中结果却是原本模型能理解还差不多的并没有实现提升模型理解挺好的反而因为收到别的拆解的干扰又降了下来。当时真的是一团乱麻。更糟糕的消息是给我提供数据的同事是个实习生回学校报到去了。换了别人几乎完全不配合我们的工作1说是去反馈也没有下文我们只能自己去数据库抓数据。其实这对我难度倒不大毕竟公司数据库查询用sql语言就能实现再复杂无非就是做联表查询。我做开发时候虽然是个采购但是这点编程我还是能做到有条不紊。至少当时我是这么想的。不得不承认大厂的数据真的细致每一张表虽然字段多如牛毛但是仍然把每一个业务场景都拆分出无数个表库。我俩那几天整天自己找需要什么字段去哪些表里找我的编程功力消退的差不多了但是好在有ai在还能边问边学。好不容易导出来数据又需要做数据格式上的整理我们又自己开发工具当然是agent开发的难道是我啊去做数据处理、清洗。但是那段时间机评的任务就几乎完全落下了。1倒没有因为这个批评我们但是也要求我们在ddl前一致率必须上去不然没法交差不能把时间浪费在数据上面。他当然是有意见的但是我管不了这些了。不知何时心中也产生了执念不是为了证明我能行不是为了证明我是对的而是我一定要做出来我要让自己更强。但是这种执念也算是限制了我变得偏执变得狭隘。现在想想我写的prompt肯定不够细但是就算把那么一坨业务给裁判模型理清楚一致率也不见得就能上去。毕竟仅仅是规则就这么复杂一股脑全交给模型自己当甩手掌柜这肯定不是明智之举。SEO 摘要一次机评项目从 95% 一致率跌至 65%让我明白当规则复杂到 100 指标时堆 Prompt 永远不够。真正的解法是把全链路当作 Agent 产品来设计而非把业务一股脑塞给模型。本文复盘从 Prompt 工程转向 Agent 逻辑设计的核心教训。