我为受监管行业的客户批准代理构建。失败的试点项目从来不是因为模型本身。

我在一家软件公司负责项目交付。我们为保险、医疗保健和金融科技行业构建定制系统。我目前的大部分工作涉及代理： intake分诊、理赔路由、承保支持和内部运营助手。我失败的项目比成功的还多。没有一个是因为模型缺乏智能而失败的。我分享真实原因是因为这里的构建者优化了错误的变量。1. 演示运行在一个生产中不存在的API上。你的原型使用一个干净的REST端点。客户的实际系统是一个2011年的保单管理平台。它使用SOAP接口、夜间批量文件和一个供应商合同，要求他们的专业服务团队进行任何更改。代理逻辑花了三周时间。集成需要七个月和一个采购周期。在编写提示之前，先询问写入路径。而不是读取路径。每个人都能读取。写入路径才是崩溃的地方。2. 在构建开始前没有人定义“正确”。“看起来不错”不是验收标准。我不能把这个提交给风险委员会。存活下来的项目使用了200个具有已知结果的历史案例。我们在开发前就同意了通过标准。失败的项目使用演示电话，每个人都只是点头。这不光彩但杠杆很高。先构建黄金集。这是唯一诚实的方式来判断六个月后新模型是否真的更好。3. 人在循环中被放置为方便，而不是责任。我看到管道末尾的审批按钮，因为它容易。在受监管的工作流中，门控属于不可逆操作发生的地方：记录状态更改、出站消息或财务移动。上游的一切都可以是自主的。搞错了你就输了。太多的门控导致橡皮图章。太少则一个坏操作就会杀死项目。4. 发布后没有人负责。这杀死最多的项目。代理不是你发布后就忘记的功能。数据形状变化。策略转变。模型提供者更新。必须有人负责提示、监控失败和更新评估集。这个角色在组织结构图中很少存在。质量漂移。用户遇到三次坏输出。信任崩溃。人们绕过工具使用。系统仍在运行，但没人使用它。企业代理项目就是这样死的。不是关机，只是沉默。企业代理的困难部分与其他任何企业系统相同：集成、标准、责任和所有权。代理部分现在很容易。每个人都在容易的部分竞争。对于那些将代理部署到组织的人，你对所有权的答案是什么？谁在上线后负责提示质量？我还没有看到一个干净的解决方案，我想偷一个更好的。