北京
Reddit上有个帖子让我停下了滚动——有人在炫耀自己刚搭好的"AI线索处理智能体"，专门做贷款预审。听起来很高级，直到你把实际步骤拆开看：监控邮箱、提取企业名称和月流水、查CRM、判断是不是重复线索、按需分配给新银行、只在流水超3万美元时才派销售跟进。
这根本不是智能体该干的事。
这是工作流逻辑，中间夹了一个输入格式混乱的环节。评论区有人说了句大实话：别用AI做确定性处理，写个简单脚本更可靠也更便宜。我觉得这话说到了点子上。
很多团队正在犯的错，是把大语言模型当成决策引擎。他们做的"AI线索自动化"其实该拆成两块：模糊提取和确定性状态转移。这是两回事。
如果输入确实脏乱——转发的邮件链、扫描件、格式混乱的经纪人笔记——那确实该用Claude、GPT-5或者通义千问来提取字段。但一旦拿到结构化数据，就别再让模型做那些能用代码表达的业务决策了。
糟糕的做法是让模型"判断是不是重复线索""决定要不要分配销售""确定该发给哪家银行"。更好的做法是：模型只负责提取business_name、monthly_deposits、contact_email这些字段，代码去查CRM状态，代码执行明确的规则，代码原子化地写入结果。这种拆分在生产环境里至关重要。
如果让我来搭这套预审或线索路由系统，我会用这样的架构：邮件或webhook触发，确定性解析发件人、主题和附件，只把脏文本丢给大模型做严格提取，归一化提取值，用归一化标识符查CRM，在一个加锁步骤里判断重复/新建/分配，写入成功后再触发下游动作。这样LLM的边界很小，核心逻辑是确定性的。
最安全的契约是像下面这种无聊的结构：business_name、monthly_deposits、contact_email、requested_amount、confidence。这才是GPT-5、Claude Sonnet或通义千问该干的事。
我不会做的是：让模型读邮件、判断重复、决定分配资格、选择目标银行。这种提示词看起来方便，直到你需要一致性、可审计性和防重复机制。
生产环境里最先崩的往往不是提示词，是并发。这是智能体演示通常撒谎的地方——单封邮件跑得很漂亮，然后两个经纪人20秒内转发了同一个商户，两个工作线程同时查CRM、都看到没记录、都判断为新线索、都执行路由、造出重复工作。这不是AI失败，这是竞态条件。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
