★ FEATURED ARTICLE 1. 从模型够强了人是不是可以撤了这个念头说起过去一年我身边不少做 AI 应用的朋友都有过同一个念头模型能力涨得这么快是不是很多人工兜底的环节可以砍掉了尤其是当推理模型在代码、数学、长文档理解上一次次刷新成绩的时候这种冲动特别强烈。我自己也动过这个心思——既然模型能自己规划、自己调工具、自己纠错那还要人进现场干嘛但真把 Agent 推到生产环境里跑几周结论会反过来模型越强越需要有人进现场。这不是情怀也不是给人工找存在感而是被一堆线上事故逼出来的认知。FDEForward Deployed Engineer前线部署工程师这个角色之所以在这两年被反复提起本质上就是因为纯靠 API 调用和离线评测根本覆盖不了真实业务里的长尾。这篇是 FDE 实战课的第二讲我想把为什么必须有人进现场这件事讲透。不是讲概念而是讲我踩过的坑、看过的日志、以及那些只有蹲在现场才能发现的诡异问题。适合正在做 Agent 落地、AI 应用交付、或者准备转型 FDE 的工程师看。如果你只是调调 API 做个 demo那这篇可能有点重但只要你打算把 Agent 交给真实用户用这里面的每一条都值得你提前知道。先说结论模型能力解决的是通用推理上限而现场解决的是具体业务下限。这两件事不在一个维度上模型再强也替代不了后者。2. 模型强在哪、又强不到哪去能力边界的一次实测拆解2.1 强的是通用推理弱的是你这家公司的常识我拿一个真实项目做过对比。任务是让 Agent 从一堆客服对话里抽取工单信息并自动分类。用当时最强的模型跑离线测试集准确率能到 92%看着很漂亮。但一上线准确率掉到 71%。差在哪差在业务常识。比如用户说我那个东西又不行了模型不知道那个东西指的是上周刚买的某型号设备用户说按你们上次说的弄了还是不行模型不知道上次说的是哪次工单里的哪条建议。这些信息不在训练数据里也不在你喂给模型的 prompt 里它藏在业务的历史脉络和现场语境中。模型越强越容易让人产生它应该懂的错觉。但通用推理能力再强也推不出你公司内部那套没写进文档的约定。这就是现场的价值——有人知道那个东西是什么有人能把上下文补进去。2.2 一个反直觉的实测模型升级后事故反而变多了更反直觉的是我遇到过模型升级后线上事故增加的情况。原因说出来很简单新模型更聪明更愿意自己发挥遇到模糊指令时会主动脑补一个它认为合理的方案而不是像旧模型那样老老实实报错或追问。旧模型笨笨在它会说我不确定请补充信息新模型聪明聪明在它会说我理解你的意思是……然后自作主张。在 demo 里这是加分项在生产里这是灾难。因为生产环境要的是可预测不是有创意。这件事让我彻底改变了对模型越强越好的迷信。强模型需要更强的约束、更细的现场规则、更及时的人工干预。换句话说模型能力的提升反而抬高了现场工程的门槛。2.3 能力边界对照表哪些事必须人进现场我把实际项目里模型能搞定和必须人进现场的事列了个对照你可以对照自己的场景看看任务类型模型独立完成度是否必须人进现场原因通用文本生成、摘要高否不依赖私有上下文代码补全、单元测试生成高否有明确对错标准业务工单分类中是依赖内部术语和历史多系统数据对齐低是字段映射靠人确认异常工单根因定位低是需要跨系统现场排查用户情绪安抚话术中是涉及合规和品牌调性长流程任务编排中是边界条件靠现场补这张表不是绝对的但规律很清楚越靠近私有上下文和跨系统边界越需要人。模型强在通用弱在具体而具体恰恰是业务价值的所在。3. FDE 到底在现场干什么不是调参是补上下文3.1 FDE 和普通 AI 工程师的分工差异很多人把 FDE 理解成驻场的 AI 工程师这个理解太浅。普通 AI 工程师的工作重心在模型选型、prompt 调优、评测集构建FDE 的工作重心在把业务现实翻译成模型能吃的输入再把模型输出翻译成业务能用的动作。我打个比方普通 AI 工程师是在实验室里造发动机FDE 是把发动机装到一辆具体的车上还要考虑这辆车跑的是什么路、加的是什么油、司机是什么习惯。发动机再好装不对车也跑不起来。具体到日常FDE 干的事包括跟业务方对齐术语、梳理系统间的数据流、定义 Agent 的权限边界、设计人工兜底的触发条件、以及最重要的——在出问题时第一时间蹲到现场看日志。这些事没有一件是调参能解决的。3.2 现场补的三类上下文术语、状态、意图我把现场要补的上下文归成三类这三类基本覆盖了 80% 的线上问题第一类是术语上下文。业务方嘴里的订单可能指三个不同系统的三张表模型不知道你得告诉它。这类问题靠文档解决不了因为文档往往过时只有现场问人才能确认。第二类是状态上下文。用户当前处于什么状态、这个工单走到哪一步了、这个账号有没有特殊标记。模型看不到这些实时状态你得通过 API 或工具调用把状态喂进去。这里就涉及 Agent 的工具设计后面细讲。第三类是意图上下文。用户说这句话到底想干嘛。字面意思和真实意图经常不一致模型容易按字面理解。现场的人能根据语气、历史、场景判断真实意图然后把这个判断转成规则或 few-shot 示例。提示这三类上下文里术语和状态可以工程化沉淀意图最难往往需要人持续介入。别指望一次配置就永久解决。3.3 一个真实案例工单分类从 71% 拉回 94% 的全过程回到前面那个掉到 71% 的工单分类项目。我是怎么把它拉回 94% 的第一步我蹲了两天客服现场把用户高频说的黑话整理成一张映射表比如那个东西上次那个老问题分别对应什么。这张表直接作为 system prompt 的一部分喂给模型。第二步我把工单系统的实时状态通过工具调用接进来让 Agent 在分类前先查一下这个用户的历史工单和当前订单状态。第三步我设计了低置信度转人工的机制。模型输出置信度低于阈值时不硬猜直接转人工同时把模型看到的上下文一并展示给人工让人工快速判断。三步做完准确率回到 94%而且人工介入率只有 8%。关键在于这 8% 的人工不是负担而是把剩下 92% 的准确率撑起来的保险。没有这 8%模型会为了不转人工而硬猜整体准确率反而更低。4. Agent 架构里那些必须留给人的接口设计4.1 工具调用的权限边界为什么不能让 Agent 全权操作Agent 架构里最容易出事的地方是工具调用。模型能调 API 了是不是就能让它自己下单、自己退款、自己改数据我的答案是能读的尽量让它读能写的必须留人确认。原因很实际。读操作错了顶多是信息不准写操作错了是真金白银的损失。我见过 Agent 因为理解错了一个字段批量修改了上千条订单状态事后回滚花了两天。这种事故不是模型能力问题是权限设计问题。我的做法是给工具分三级只读工具查询、检索Agent 可自由调用低风险写工具打标签、加备注Agent 可调用但需记录审计日志高风险写工具退款、改状态、发消息必须人工确认后才执行。这个分级不是拍脑袋是根据业务损失容忍度定的。4.2 置信度阈值与人工兜底的触发条件Agent 什么时候该转人工这个阈值怎么定我的经验是别用固定值用分层阈值。简单任务比如意图识别阈值可以低一点0.7 就转复杂任务比如根因分析阈值要高0.9 才敢让它自己下结论。同时还要加异常触发比如模型连续两次给出矛盾答案、或者工具调用返回了预期外的错误码直接转人工不看置信度。这里有个坑很多人把阈值设得太高导致人工介入率飙升业务方觉得这 AI 没用。阈值设得太低事故率上升业务方觉得这 AI 不靠谱。我的建议是先松后紧上线初期阈值设低一点让人工多介入同时收集这些介入案例慢慢把规则补进去再逐步收紧阈值。4.3 多 Agent 协作时的现场仲裁谁说了算多 Agent 协作听起来很美实际跑起来经常打架。两个 Agent 对同一个问题给出不同结论听谁的纯靠模型投票不靠谱因为模型之间会互相带偏。我的做法是设一个仲裁层仲裁规则由现场业务方定。比如财务相关的以财务 Agent 为准技术相关的以技术 Agent 为准冲突时转人工。这个仲裁层不是技术问题是业务权责问题必须让业务方参与设计。注意多 Agent 协作的复杂度是随 Agent 数量指数上升的。三个以内还能管超过五个基本就是灾难。别为了架构先进硬上多 Agent单 Agent 加好工具往往更稳。5. 现场排查实录那些日志里看不出来的问题5.1 一次模型答非所问的完整排查链路有次线上反馈说 Agent 答非所问日志里看模型输入输出都正常prompt 没问题工具调用也成功。光看日志完全找不到原因。我蹲到现场让用户复现了一遍才发现问题用户是在手机端操作的输入框里有个自动补全用户打字打到一半点了补全结果发出去的是半句话。模型收到半句话只能猜猜错了。日志里记录的是完整输入因为补全后的文本才进日志但用户以为发的是自己打的那半句。这个问题日志永远查不出来只有现场看用户操作才能发现。后来我们在输入端加了发送前确认问题就没了。这就是典型的现场问题跟模型能力一点关系没有。5.2 环境差异导致的诡异 bug本地好好的现场就崩另一个经典问题是环境差异。本地测试一切正常到了客户现场就崩。原因五花八门客户内网有代理、客户浏览器版本老、客户的时区设置不同、客户的字符编码是 GBK 不是 UTF-8。我印象最深的一次是时区问题。Agent 处理时间相关的任务本地测试用的是 UTC客户现场用的是本地时区结果今天的定义差了 8 小时所有跟日期相关的逻辑全错。日志里时间戳看着都对因为日志本身也用了错误的时区。这类问题没有捷径只能在现场把环境对齐。我的习惯是上线前先跑一遍环境体检清单时区、编码、网络、浏览器版本、依赖版本一项项对。这个清单是踩坑踩出来的每踩一个新坑就加一项。5.3 用户行为的非理性模型永远预测不到的那部分模型是基于理性假设训练的但真实用户经常不理性。比如用户会在输入框里粘贴一整段带格式的文本模型解析不了用户会连续发三条消息模型只回了第一条用户会在半夜三点用而你的 Agent 设计时假设的是工作时间。这些非理性行为离线测试集里永远覆盖不到因为测试集是人造的人造的数据天然理性。只有现场的真实用户才会用你想不到的方式使用你的产品。我的应对策略是埋点 回放。把所有真实交互录下来定期回放找出那些模型处理得很差的 case补进测试集。这个循环跑几轮Agent 的鲁棒性会有质的提升。6. 把人进现场变成可复用的工程能力6.1 现场知识的沉淀从个人经验到团队资产人进现场最大的问题是不可规模化。今天张三蹲现场解决了问题明天张三休假问题又来了。所以必须把现场知识沉淀成团队资产。我的做法是建一个现场知识库结构很简单问题现象、排查过程、根因、解决方案、预防措施。每解决一个现场问题就写一条。时间长了这个库就成了团队的护城河。新人遇到问题先查库查不到再进现场进完现场再补库。这个库的价值不在于记录而在于复用。很多现场问题看着不一样根因是同一类。有了库你就能从个案里抽象出模式把一次性的现场经验变成可复用的规则。6.2 自动化能替代多少现场工作我的实测比例经常有人问这些现场工作能不能自动化我的实测比例是能自动化 60% 左右。能自动化的部分环境体检、日志采集、异常告警、置信度监控、常见问题的自动分类。这些有明确规则脚本能搞定。不能自动化的部分新类型问题的根因定位、业务术语的对齐、用户意图的判断、跨系统的权责仲裁。这些需要人的判断而且往往是第一次遇到的问题没有现成规则。所以正确的姿势不是用自动化替代人而是用自动化把人从重复劳动里解放出来让人专注在真正需要判断的地方。这个比例会随着你知识库的积累慢慢提高但永远不会到 100%。6.3 给准备转型 FDE 的工程师的几条实在建议最后给几条实在建议都是我自己踩过坑总结的第一别只练模型练沟通。FDE 一半时间在跟人打交道业务方、客户、运维、产品你得能把技术问题翻译成他们听得懂的话。第二学会看日志之外的东西。日志只能告诉你系统发生了什么现场才能告诉你用户经历了什么。两者结合才是完整画面。第三接受不完美。FDE 的工作永远是在约束下找最优解不是找完美解。模型有边界、预算有上限、时间有 deadline你得在这些约束里交付可用的东西。第四把每次现场都当成学习。现场是最好的老师因为它不骗人。模型评测可以刷分现场问题刷不了。我个人在实际操作中的体会是模型越强FDE 的价值越不是补模型的短板而是把模型的能力精准地对接到业务的价值上。这个对接工作短期内看不到被替代的可能。所以如果你在考虑要不要往这个方向走我的答案是值得但要准备好长期蹲现场。
阅读完成 · 觉得有帮助？
