Agent 项目怎么验收？从效果演示到结果契约

原创 AIEngineering AIEngineering

系列：《企业级 Agent 落地的软件工程方法》第三篇 第一篇谈的是：先把业务规格写清楚——对象、口径、边界、异常在哪里。 第二篇谈的是：把 Agent 装进受控流程——状态、门禁、分流、痕迹，都要有“运行时说法”。 这一篇要谈的是一个常常拖到最后一刻、却最能决定项目是“上线”还是“上演”的问题：拿什么标准验收 Agent？ 引言：周四下午四点很美好，下周一上午九点才要命 很多企业里，Agent 项目第一次“看起来像成功”，往往发生在周四下午四点——空调有点冷，投影仪有点热，手机屏幕齐刷刷对准演示台。 项目同学输入一串打磨过的问题，系统在几十秒内给出结构漂亮的结论、体面的措辞、恰到好处的表格。台下的反应多半是点头，甚至有人当场说：“这比我们内部顾问写得还像那么回事。” 领导抬手看了一眼时间，合上笔记本： “效果不错。就这么定了吧，下周业务部门先用起来。” 而真正的验收，常常在下周一上午九点悄无声息地开始——没人再给你鼓掌，只有业务群消息一条接一条冒出来： 业务员： “帮我把这批发票里超标住宿筛出来——哎不对，我只要华东区上周的，别把华南混进来。” 复核岗： “你刚才说这个供应商‘高风险’，依据是哪条规则？我上系统看到的状态明明还是‘观察’？” 如果你把这两条消息丢给一个“只靠演示反馈”的团队，最典型的拆台方式不是吵架，而是一句特别冷静的话： 财务： “你给我的结论我读得懂；但我问过共享中心，工单系统里必填的那三个字段，为什么还是空的？” 到这一刻，项目组才会被一个常识击中： 公司内部验收 Agent，看的不是话术像不像人，而是结果能不能接上真实世界的接口——流程、工单、台账、追责、下一轮迭代。 所以这一篇的结论很直接： 要把验收从观感效果，升级到可以签字画押的结果契约：输出在什么条件下合法、失败了怎样表达、靠什么证据说明达标、改了模型和业务之后怎样还能证明“我仍然敢用”。 【先记住三句话】 ① Demo 证明的是爆发力，契约证明的是——你明天再问一遍，它还是不是同一家企业。 ② 下游不关心你颅内推理多精彩；它只看三件事：字段齐不齐、语义稳不稳、翻车能不能追到路口。 ③ 没有契约的输出就像口头汇报——听着都对，一落系统就散了；在商业里那不叫敏捷，叫作玄学运营。 一、为什么“准确率八成多”，常常验收不了？ 我听过最真实的开场白之一，是业务负责人在饭桌上说的： “我们试点那个智能初审，离线测下来准确率大概八成多，你们技术团队说这还不错。” 先别急着争辩“还不错”到底是不是不错。真正把验收卡住的问题，往往不是百分比本身，而是你答不出下面这些更具体的一句半句—— 八成多里，哪些是“无伤大雅”的分类偏差？哪些是“会把钱批错口径”的事故？ 没有这道分水岭，项目负责人心里一定会长出一根刺：你是在用平均数粉饰风险。 举一个让人血压上升、却极其常见的类型： 系统在周报对话框里侃侃而谈：“华东地区收入环比下降，主要拖累来自某某品类。”——听起来像复盘材料，甚至像一份战略洞察。 可财务同学在 Excel 里对了一遍数，发现一个细节： 数字对上了，币种写成了美元；或者口径是对的，却把“含税”当成了“不含税”；又或者时间窗切分跟公司统一模板差了一天。 对用户来说，这种错误不是“答错了一句话”，而是一种特别恶劣的错误：看起来像真的。它会让你在周一晨会上自信地复述，再在周二被审计或财务一句话打穿。 另一类同样常见：Agent 很聪明地把背景写清了，可当共享中心工单系统要求必须带上“审批链预测标签、风险码、凭证影像编号”三件事时—— 它给了一大段可读性很强的文字，却没有稳定产出那三个必填字段。于是业务同学一边复制粘贴，一边在心里给项目判刑：“你这是给我省时间，还是在给我加时？” 所以，我们建议把合格的验收口令从三连问升级成三件事（听起来土，但比什么都诚实）—— 这东西能否被下游系统直接吃掉？ 关键翻车能否拦住而且有链路可复盘？ 业务改了两条口径、供应商换了一次模型档位之后——你还敢不敢说我仍然达标？ 没有这三桩硬事，“还不错”只是演示灯光打到脸上的还不错。 二、结果契约是什么？你就把它当成对内对外的「接口说明书」 把 Agent 想成企业服务里的一个组件：它当然可以有一副好口才，但更必须有可被依赖的返回值。 我们习惯把契约拆成四层——每一层都能写进评审表，也都能翻译成自动化断言。下面用一个“差旅报销智能初审助手”的假名场景，把四层从概念落到你能想象的按钮和字段上。（你换成合同、招投标、工单分诊，骨架不变。） 1. 输入契约：不是“有话说”，而是“材料齐了吗” 在助手开始判断之前，系统要先回答：我现在有没有资格接单？ 比如：如果没拿到 OCR 识别的发票结构化结果，只有一张糊图；或者没拿到申请人的职级与城市等级；又或者差旅行程与城市规则库版本没对齐——那就不该进入“给结论”，而应该进入 “请先补齐字段 A/B/C”，并且把缺的项列成清单给用户点。 原因很简单：含糊可以留在对话框里，但不该被模型加工成“看起来像齐活”的结论。 2. 输出契约：人看到摘要，机器拿到 JSON 企业内部常见输出从来不是一段“小作文就够”，而更常像一张可以进系统的卡片： 必填字段：是否超标、超额金额（若有）、命中规则编码列表、置信度档位、对客户可见话术、对内诊断摘要、是否需要人工。同时还要约定：哪些字段允许写“未知”、未知时下游该怎么走兜底流程。 这就像 API 文档里写返回值：字段不乱、语义不飘、枚举值有唯一解释。工程上会配合 Schema 校验、范围检查与主数据对照，把“顺眼”挡住，把“可得”放行。 你也可以把它理解成：用户看到体面的解释，系统在后台吃的是硬结构。体面是体验，硬是交付。 3. 质量契约：把错误分出“死刑”与“划伤” 不是每一类错误都值得同等对待——但验收必须把类别写死在纸上。 一类是阻断型：金额单位错、币种错、该不该走特殊审批的路线判反、在必选合规检查上用常识补洞——这一类通常应按契约直接判负，或被自动拦住转人工兜底。 另一类是降级型：语气不够统一、次要标签偶有摇摆——可以放进迭代优化清单，但必须记录发生率与是否在阈值内滚动下降。 不写清这一点，复盘会永远是情绪会议：大家都在说“翻车”，谁也不知道翻的是油罐车还是电瓶车。 4. 运行契约：SLA 不写清，最后就是互相加班 企业负责人真正怕的往往还不是“慢一点”，而是慢得不可预测——一会儿两秒一会儿两分钟，周报节点又卡在接口抖动上。 契约里要写清：在正常并发区间的响应时限、超时之后是排队、降级人机协同，还是切换到规则模式；外部依赖不可用时的用户可见提示与不胡编承诺的底线。 否则上线后的协同方式永远是私聊： “兄弟帮我把这条先手工处理一下…” 三、把验收写成三套「证据」，而不是三场「观感」** 如果验收还停留在“大家看完都觉得好”，那只是活动的闭幕礼。我们建议把它拆成三组可以装进文件夹的证据。 1. 样本证据：测评集不是演出节目单，要能当回归保险箱 离线集不靠堆量取胜，靠的是覆盖三类：主路径 / 长尾怪问题 / 与权限口径咬得最紧的边缘案例——比如“VIP 与普通客户的策略分叉”“含税不含税分叉”“跨区域政策分叉”。 再往前一步：把每一条线上事故反问成一个问题——如果现在再来一次这件事，离线集会不会替我们喊出停？ 很多团队第一年把测评集当“救火资料夹”；成熟了之后，会变成防弹衣缝制车间：每次事故补丁不是嘴上说“我们改好了”，而是要落一条样本、落一条断言、落一条发布门禁。 2. 运行证据：线上不仅看命中率，还要看“翻车时的体面” 你可以用三组现场问题压一压系统： 当出现解析失败或不满足 Schema 的输出，有没有人替业务挡一枪？ 当置信度低到红线、或与规则打架，有没有既定的升级路径，而不是模型的自我发挥？ ERP 超时、向量库报错、网关抽风——系统会不会老老实实说我不行，并提供可继续的处理建议？ 如果这些答案还停留在工程师胸口里，那这个 Agent 还没领到生产工牌。 3. 组织证据：签字不是起哄，是三张不同类型的责任认领 我们常建议别把验收落款写成一个人名。 业务：语义与业务流程是否咬合？哪些错算“硬伤”？ 合规与数据：哪些数据能读写留多久？对用户的话术是否越权承诺？ 研发与运维：版本与回归怎么走？告警阈值是什么？红黄线跌了谁负责按停？ 这就像盖楼验收——土建、机电、消防各签一章；合在一起才敢说能住。 四、「效果验收 vs 契约验收」对照——给你一张会上能用的尺子 下面这些句子不是口号，是真正能把会从“夸夸会”拉回“算账会”的问法：还停留在效果验收的声音进入契约验收时，会问成什么样“回答挺像专家的。”下游字段齐了吗？空值语义写清了吗？“大部分情况都对。”哪些错零容忍？红黄线阈值写在谁的名字底下？“我们觉得体验不错。”同样的输入链路，本周与上周版本对比，回归过吗？“应该不会出大问题。”出事时五分钟能否定位到哪一步哪一个版本？“再优化优化就好了。”优化项 backlog 可否量化追踪，而不是永远在口头下一阶段？ 当讨论开始围绕表格右侧发生，项目组才会松了一口气——因为大家要买的不再是幻象，而是一套可被审计的履约。 五、从 AIE 的实践视角：闭环不是最后再贴一层胶布 说句实话：很多团队把验收当成收官前的“写作文环节”。但在工至科技 AIE 的实践里，更省心的做法是反过来的——从一开始就把系统设计成“注定会失败也值得被追责和修复的东西”。 Pipeline / 语义对象层让企业先想清楚：我到底拿什么数据对齐口径？没有这个底座，离线分数再漂亮也像沙滩城堡，潮水一拍就失真。 Agent Flow / 编排让理解、检索、规则校验、生成、人工复核各司其职——每一块都能有自己的断言点和观测口，复盘时少走弯路。 观测与日志、持续评估，把线上的尴尬事故喂回离线测评集——把智能体从一个“秀场明星”拉回一个不断打补丁的工程系统。 顺带说一句：如果你们把自然语言问数做成了 Chat BI 之类能力，契约只会更较真——因为那不仅是“长得像分析”，还要求口径可复述、脚本可回放、图表可核验。这跟结果契约是一套逻辑，只是把验收伸向数据生产线。 这一句足够总结平台立场： AIE 想做的不是替你写更美的一句话，而是让那句话背后站得住一整套可验收的工程证据。 结语：企业买的不是星期四的掌声 过去买软件是看菜单与演示；今天在 Agent 故事里，人最冲动购买的往往是：一段令人屏息的交互。 但现实里业务部门长期愿意按下去的，从来不是某一次的天才回答，而是一套冷冰冰却踏实的履约： 再问一遍仍成立；要害处能被拦住；翻车能追到路口而不是追到运气；业务和模型换季更衣之后，你还有一套回归可以说话。 你可以在验收收口时，把一个锋利的问题递给全场——它不友好，但往往最救命： “三个月后换个模型档位、财务部改一个词段口径、业务加一条例外条款——在座的各位，谁敢按那个绿的自动键？” 能答上来的团队，才敢把项目从星期四的会议室带到真实的操作系统里。 三篇合在一起，是一句递进行的工程常识： 先有规格——世界是什么，再有受控流程——我怎么动，最后用结果契约——凭什么信。 三件齐了，Agent 才不只是朋友圈里的高光，而是一纸签完之后晚上睡得着觉的交付。

微信扫一扫关注该公众号

继续滑动看下一个