我的 FDE 日常被 AI Agent 颠覆了——从半天到 10 分钟

上周四下午，一个客户说他们的 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 帮你干吗？评论区聊聊，说不定下一篇就是你想看的场景。