上周四下午一个客户说他们的 K8s 集群死活连不上外部的模型推理服务网络策略、Ingress、防火墙全查了一遍折腾了三个多小时没搞定。换成以前我大概会先 ssh 上去curl 一下测连通性再抓包看看流量走到哪断了然后翻半天文档查这个云厂商的网络策略写法。一套下来少说一两个小时。但这次不一样。我把报错信息和集群配置扔给了一个 Agent 工作流它花了大概 30 秒分析完直接告诉我你检查一下节点安全组的出站规则UDP 端口 53 被禁了DNS 解析失败导致服务发现拿不到地址。我查了一下——还真是。说实话那一刻我的心情挺复杂的。不是那种哇 AI 好厉害的兴奋而是一种有点慌的平静。你花了好几年练出来的经验人家 30 秒就搞定了。而且它的分析路径比我更系统——我不是没想到 DNS我是被网络策略这个方向带偏了先入为主了。第一季我写了 12 篇 FDE 工程师修炼的内容从入门到面试到项目实战自认为把这个岗位的方方面面都讲透了。但写完之后我一直在想一个问题如果 FDE 的核心价值是快速解决客户现场的各种问题那 AI Agent 会不会让这个岗位变得不再需要人我花了一个月专门研究这个事今天这篇就当是第二季的开篇聊聊我看到的真相。先说结论Agent 不会让 FDE 失业但它会彻底改变 FDE 的工作方式。就像计算器没有让数学家失业但让会计的手工算盘彻底退出了历史舞台。我拿自己最近一个项目举例子。客户是一家做 AI 客服的创业公司他们的模型需要部署到某个政务云上。搞过政务云的人都知道这玩意儿有多坑——网络隔离严格、白名单审批要三天、没有公网镜像源、连 Docker 拉镜像都要走代理。以前做环境适配我的流程是先看客户发的文档再远程连进去摸一圈手动跑几个检查脚本一边等一边查资料。顺利的话一个下午不顺利的话第二天接着干。这次我试着让 Agent 来做这件事。我只给了它三样东西客户发来的环境说明文档、一个我写好的检查清单模板、还有我自己以前踩过的坑记录。Agent 自己读文档自己生成了一组检查脚本自己连上去跑了一遍然后把结果整理成了一份报告标出了三个风险点。你们猜花了多久从我把材料丢给 Agent到它给出报告不到 10 分钟。其中有一个风险点是我自己都没注意到的——客户的集群节点操作系统是 CentOS 7.9但他们的模型依赖一个需要 glibc 2.28 以上的库。这个兼容性问题我可能要到部署的时候才会发现Agent 在第一轮检查就标记出来了。有意思的是这个 Agent 也不是一次就成功的。我第一次让它跑的时候它生成的检查脚本里有个逻辑漏洞——它假设所有节点的配置是一样的但实际上那个集群有三台机器的内核版本不同。我把这个反馈告诉它它自己修正了脚本又重新跑了一遍。这个交互过程本身就很像我在带一个 junior 工程师你给他一个任务他做错了你指出问题他改完再试。不过我必须得说Agent 也不是万能的。有几次它给出的建议完全跑偏了——比如它分析网络问题时建议我检查某个中间件的配置但那个中间件在这个环境里压根就没部署。它是在文档里看到了一段配置示例就以为是实际配置了。这就是典型的 AI 幻觉在没有足够上下文的情况下它会用看起来合理的内容填补空白。你别说这恰恰说明了为什么 FDE 这个岗位不会消失——Agent 能帮你干活但不能替你判断。你需要的不是听话照做而是我知道它在做什么所以我能判断它做得对不对。这种判断力来自于对系统整体的理解来自于踩过坑的经验来自于你脑子里那张全链路地图。所以第二季我想聊的不是AI 来了FDE 该怎么办。而是FDE 怎么跟 AI 搭档干活把效率提上去把自己从重复劳动里解放出来。接下来几篇我会一个一个场景拆开来讲环境适配怎么做、数据清洗怎么自动化、部署脚本怎么让 Agent 生成、远程调试怎么跟 Agent 协作……每一个都是我自己真实跑过的流程有效果也有翻车我会如实写出来。最后问一句你现在的工作里有没有那种明明很简单但就是很花时间的重复活你试过让 AI 帮你干吗评论区聊聊说不定下一篇就是你想看的场景。