胶水工程师之死：AI 正在吞噬连接系统的工作

每个工程组织都有这样的人。他们不拥有产品，不交付用户可见的功能。但没有他们，一切都无法运转。他们是编写 ETL 管道、将数据从计费系统搬到分析仓库的工程师；是构建 Webhook 处理器、让 Salesforce 与内部 CRM 保持同步的人；是维护 API 适配层、让移动端应用能与三个从未被设计为相互通信的后端服务对话的人。

他们就是胶水工程师，而他们的工作是第一批被 AI 代理完全吞噬的软件工程类别。

这不是理论预测，而是正在发生的事实，整个行业都可以量化观察到。有公司报告称，用 AI 代理取代了 50 人的集成工程师团队，只留下两三个人——AI 代理扫描 API 文档、推断 Schema、在几分钟内生成可用的适配器，而不是几周。AI 代理市场在 2025 年达到 78.4 亿美元，预计到 2030 年将增长至 526.2 亿美元。Gartner 估计，到 2026 年底，40% 的企业应用将嵌入特定任务的 AI 代理，而 2025 年这一比例不到 5%。软件的连接组织——胶水工程师用整个职业生涯构建的部分——正在以令人警觉的速度被自动化。

什么是胶水工程

胶水工程是连接系统的工作类别。它包括从一个系统提取数据、转换为兼容格式、加载到另一个系统的 ETL 管道；包括在不兼容接口之间进行翻译的 API 适配器；包括对一个系统中的事件作出反应并将变更传播到其他系统的 Webhook 处理器；包括格式转换器、协议桥接、数据同步任务，以及那些不是因为有人想要、而是因为两个系统需要协作却从未被设计为相互配合而存在的无尽集成代码。

这项工作的重要性历来被低估。组织离不开它，但它很少出现在产品路线图中，也不会在全员大会上被表彰。构建驱动管理层仪表盘的实时数据管道的工程师，获得的认可远少于构建仪表盘本身的工程师。

讽刺的是，这些看不见的、不光彩的、不可或缺的工作，恰恰是 AI 代理最擅长自动化的。

为什么胶水工作最先消失

AI 代理擅长胶水工作的原因与人类觉得它乏味的原因一样：这类工作模式密集、文档完善、结构重复。

API 集成遵循可预测的模式。 阅读文档，理解认证方案，映射请求和响应格式，处理分页，实现错误处理和重试。每个 REST API 在细节上各不相同，但在结构上完全一致。一个处理过数千个 API 规范的 AI 代理，生成可用集成的速度比人类读完文档还快。

Schema 映射是自然语言问题。 当你需要将系统 A 的 customer_name 字段映射到系统 B 的 client_full_name 字段时，你在进行语义匹配——这正是大语言模型为之而生的任务。传统 ETL 需要工程师手动定义每个字段映射。AI 代理可以推断出来，而且准确率随模型提升而提高。

Webhook 处理器是事件-响应对。 "当系统 A 中发生这个事件时，在系统 B 中做这件事。"逻辑几乎总是一个简单的转换加上一个 API 调用。复杂性来自数量——处理数十个集成中的数百种事件类型——而不是任何单个处理器在智力上有多大挑战。

格式转换是机械性的。 在 JSON、XML、CSV、Protobuf 和专有格式之间转换是纯粹的转换逻辑。工程师的时间主要花在边界情况和测试上，而不是创造性的问题解决。

共同点是：胶水工作需要对 API 和数据格式的广泛知识，但只需要对任何单个问题的浅层推理。AI 代理恰好具备这种能力特征——宽大的上下文窗口、强大的模式匹配，以及为定义明确的转换生成足够正确代码的能力。

速度差异令人震惊

AI 辅助集成与手工集成之间的生产力差距不是渐进式的，而是数量级的差异。

传统集成项目可能需要一个工程师团队两到四周：研究文档、构建适配器、编写测试、处理边界情况、部署和监控。AI 代理可以在几分钟内生成可用的初版，并在几小时内迭代处理边界情况。即使考虑到仍然必要的人工审查和测试，时间压缩也是惊人的。

过去将 80% 的时间花在准备和集成数据上的数据工程师，现在报告只需花大约 20% 的时间。剩余时间转向了一直更有价值但以前被挤占的工作：设计数据模型、定义质量标准、构建能适应变化的系统架构。

这种模式——AI 处理机械性执行，人类转向设计和监督——在每个采用代理式集成工具的组织中都保持一致。问题不是胶水工作是否被自动化，而是做这些工作的人会怎样。

没人谈论的职业风险

如果你的工程职业建立在"让各种东西互相通信"上，你面临一个具体而紧迫的风险。不是那种笼统的、含糊的"AI 可能有一天会取代你的工作"的风险，而是一个具体的风险：你每天执行的特定任务属于 AI 代理最能有效自动化的类别。

这不是因为集成工作简单。它并不简单。它需要理解多个系统、处理微妙的不兼容性，以及调试跨服务边界的故障。但它在本质上是程序化的，奖励的是模式匹配而非创造。而模式匹配恰恰是 AI 已经超越人类表现的领域。

风险最大的工程师是那些在单一集成领域深度专业化的人——Salesforce 集成专家、支付网关专家、了解遗留 ERP 系统 API 每个怪癖的人。这些领域知识之所以有价值，是因为难以获取且无法查找。但 AI 代理凭借文档和 API 规范的访问权限，可以在几秒钟内获取这些知识。

风险最小的工程师是那些将集成经验作为更高杠杆技能基础的人。如果连接系统教会了你如何思考故障模式、数据一致性和系统边界，这些元技能比以往任何时候都更有价值。

仍然离不开人的技能

胶水工作的自动化并不消除对集成工程判断力的需求，反而提升了它。真正的难题从来不是"如何调用这个 API"——而是围绕调用的决策。

不确定性下的系统设计。 哪些系统应该紧耦合、哪些应该松耦合？这个数据流的正确一致性模型是什么？应该是同步还是异步？这些决策需要理解业务需求、故障概率和运维约束——AI 代理无法推理这些，因为它们无法获取系统存在的完整上下文。

故障模式分析。 当集成在凌晨三点失败时，有趣的问题从来不是"什么坏了"——日志会告诉你。而是"我们为什么将系统设计成这种故障是可能的，以及如何防止它所代表的整类故障？"这需要推理从未被指定过的系统行为条件，这仍然是根本性的人类能力。

数据建模和语义设计。 决定"客户"在七个不同系统中意味着什么，或者"订单日期"指的是下单时间、确认时间还是履约时间——这些是伪装成技术问题的组织决策。任何 AI 代理都无法解决它们，因为它们依赖于存在于人们脑中而非文档中的业务上下文。

迁移和演进规划。 如何在不停机的情况下替换关键集成？当 47 个下游系统依赖当前格式时，如何从一种数据格式迁移到另一种？这些问题需要理解组织动态、风险容忍度，以及哪些团队会配合、哪些会抵制的政治现实。

可观测性架构。 决定监控什么、对什么告警、哪些故障信号重要，需要理解不同故障模式的业务影响——这是 AI 代理不具备且无法从 API 文档中获取的知识。

从执行者到架构师

胶水工程师的职业发展路径不是对抗自动化，而是超越它。

花了五年构建集成的工程师有一个纯产品工程师不具备的优势：对系统如何在边界处失败的深刻直觉。每一次格式不匹配、每一次超时、每一次数据不一致，都教会了他们关于系统设计与实际行为之间差距的东西。

这种直觉是 AI 无法自动化的技能的基础。系统设计、可靠性工程、数据架构、平台工程。这些角色都需要与集成工作相同的边界思维，但在更高的抽象层次上应用它。

这种转变与手动测试人员在自动化测试成熟时发生的情况类似。只会执行测试脚本的测试人员被取代了。而理解如何设计测试策略、识别高风险区域、推理覆盖率的测试人员变得更有价值——因为测试自动化将他们从机械执行中解放出来。

84% 的开发者现在定期使用 AI 辅助。最好的工程师不是最快的编码者——他们是知道何时不信任 AI 的人，知道生成的集成何时需要代理没想到添加的熔断器，知道"可用的"适配器何时会在负载下失败因为它没有处理背压。

组织层面的转变

这个转变不仅影响个人职业，还重塑了工程组织的结构方式。

以前存在的用于维护集成层的团队——有时数十名工程师的全部工作就是保持系统同步——正在被整合。工作不会消失，但需要的人少得多。剩下的工程师从编写集成代码转向管理集成平台：定义策略、审查 AI 生成的适配器、监控自动化管道的健康状况。

这产生了新的组织风险：以前分布在团队中的集成专业知识的丧失。当 50 名工程师各自理解集成全景的一部分时，组织有天然的冗余。当三名工程师监督处理一切的 AI 代理时，知识集中就成了单点故障。

聪明的组织通过投资可观测性、文档和架构决策记录来应对——这些记录捕获集成决策背后的原因，即当系统演进、原始工程师已经离开时 AI 代理所需的上下文。

该怎么做

如果你是一名正在阅读这篇文章的胶水工程师，可操作的建议很直接，即使执行起来并不容易。

• 审计你的日常工作。 有多大比例是机械性集成（API 调用、数据映射、格式转换），有多大比例是设计决策（选择架构、分析故障模式、定义数据模型）？机械性部分是最先被自动化的。
• 投资系统设计技能。 学会推理分布式系统、一致性模型和故障域。这些是集成代码自己编写之后仍然存在的问题。
• 构建组织知识。 不仅理解系统如何连接，还要理解为什么这样连接。业务上下文是 AI 代理无法跨越的护城河。
• 学会监督 AI 代理。 集成工作不会消失——它从编写代码转向审查、测试和监控 AI 生成的代码。能够评估 AI 生成的适配器是否可投入生产的工程师，比能从零开始编写适配器的工程师更有价值。
• 转向平台思维。 不要构建单个集成，而是设计使集成变得简单、安全和可观测的平台。这是位于 AI 代理生成能力之上的架构层。

胶水工程师之死不是集成专业知识的死亡，而是集成作为手动代码级活动的死亡。专业知识向上迁移——从实现到设计，从单个连接到系统架构，从编写胶水到决定胶水应该和不应该存在的位置。

完成这种转变的工程师会发现，他们的集成经验给了他们不公平的优势。他们以一种只在单个服务内工作的工程师永远不会理解的方式理解系统边界。这种理解现在比以往任何时候都更有价值。唯一的风险是在 AI 代理蚕食实现层的时候，仍然紧抓着它不放。