我曾经以为AI会取代工程师

微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署
AI模型价格对比 | AI工具导航 | ONNX模型库 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

每隔几个月，一波AI热潮就会说服一批新的非技术人群，让你认为你只需要一个好的提示和正确的模型。描述你想要什么，按回车，发货。

有时，对于非常简单的任务，这确实有效。

一旦你的问题变得稍微复杂：真实数据、真实用户、真实风险——车轮很快就会脱落。

Andrej Karpathy，他构建了Tesla的Autopilot并共同创立了OpenAI，将构建可靠的AI智能体描述为"一场工程马拉松，而不是短跑。"他的观点不是AI很弱。而是AI需要结构、监督和架构才能做任何有意义的事情。

那种结构叫做工程。

Karpathy还介绍了他所谓的Software 3.0，其中自然语言成为新的编程层。提示是新的代码。但标题中遗漏了这一点：Software 3.0不会淘汰工程师。它提升他们。角色从编写明确指令转变为设计将意图转化为结果的系统。这是一份更难的工作，而不是更容易的工作。

根据LangChain的2026年AI智能体状态报告，57%的组织现在在生产中有智能体。质量是部署的首要障碍，32%的受访者引用。85%的工程团队将维护和生产稳定性列为主要关注点。不是模型。不是提示。是将它们结合在一起的系统。

1、RAG实际上告诉我们关于工程的什么？

RAG（检索增强生成）是工程为AI做什么的最清晰例子。

开箱即用的LLM有固定的知识截止日期。它不知道上个月发生了什么。它不知道你公司的内部文档、你的产品目录，或者你需要它进行推理的特定患者记录。尽管问它，它会编造一些东西。自信地。

RAG是工程修复。你构建一个管道，从你的实际数据中检索正确的上下文，并在模型回答之前将其注入模型的提示中。模型不再猜测。准确率上升。幻觉减少。

但构建一个好的RAG系统不是拖放。你必须做出真正的工程决策。

分块策略。你如何分割你的文档？太小，你会失去上下文。太大，你会失去精度并消耗token。正确的答案取决于你的数据，知道那个答案需要理解你的领域和模型的行为。

嵌入模型选择。并非所有嵌入模型都理解相同的东西。在Wikipedia上训练的模型不会以生物医学调整模型的方式嵌入医学术语。工程师根据用例进行选择。

检索逻辑。简单的余弦相似度检索在复杂查询上会崩溃。混合搜索，结合关键词和语义检索，通常是修复。知道何时使用它以及如何调整它是一个工程决策。

重排序。检索到的chunk并不总是按相关性正确排序。在将上下文传递给模型之前添加重排序步骤可以显著提高输出质量。你不会在任何自动生成的教程中找到这一点。它来自在生产中迭代的工程师。

一个构建良好的RAG系统可以将一个通用的LLM感觉像一个真正的领域专家。一个构建糟糕的RAG系统会让你质疑你为什么开始这个项目。

这两个结果之间的差距？那就是工程。

2、为什么大多数AI智能体在部署后几周内失败？

智能体AI系统是当前的前沿。不只是回答问题的模型，而是计划、使用工具和执行多步任务的模型。

炒作是真的。潜力是真的。失败模式是惊人的。

没有适当工程的AI智能体会在失败的任务上无限循环燃烧API令牌，直到有人注意到账单。它会误解工具的输出并根据垃圾数据做出决定。它会幻觉一个不存在的函数调用并静默失败。行业数据支持这一点：90%的生产智能体在部署后几周内失败，因为它们缺乏处理现实世界复杂性的架构深度。即使是目前最好的解决方案，在真实企业环境中的目标完成率也低于55%。

这就是为什么最好的智能体系统不仅仅是"LLM加工具"。它们是工程师故意设计的系统：

• 工具定义。精确、无歧义、难以误解
• 错误处理。在失败级联成更大问题之前捕获它们
• 评估管道。测量智能体是否真的在做正确的事情
• 人在环中的检查点。用于具有不可逆后果的决策

Hamel Husain，应用AI中最受尊敬的实践者之一，对此直言不讳：评估是大多数团队跳过的事情，也是大多数AI项目失败的原因。为智能体构建可靠的评估不是令人兴奋的工作。但它是从演示到产品的区别。

3、Anthropic如何从头重建他们的智能体基础设施

2026年4月，Anthropic推出了Claude Managed Agents，一个用于运行长视野自主智能体的托管服务。公告引起了关注随附的工程博客更有趣。

他们的第一个版本是Anthropic工程师所谓的"宠物。"所有编排逻辑、执行沙箱、会话状态都生活在一个容器中。如果容器死了，智能体就死了。网络波动、线束错误、内存错误：失败模式总是完全的。会话消失。

所以他们围绕一个原则从头重建：将大脑与手分开。

在重新设计的架构中，三件事故意解耦。会话是一个仅追加的事件日志，存储在外部，在任何单个容器之外。线束是调用模型并路由工具调用的编排循环。沙箱是代码实际执行的地方。这些通过一个抽象进行通信：execute(name, input) → string。一个函数签名。仅此而已。

当容器在任务中途崩溃时，线束不会恐慌。它将死容器视为工具调用错误并传递给Claude，Claude处理重试。会话日志完整。线束可以通过调用wake(sessionId)重新启动，获取完整的事件历史，并从停止的地方继续。

性能提升是真实的。将推理与容器配置分离将p50的首次token时间减少了约60%，p95减少超过90%。因为模型不再需要等待沙箱启动才能开始生成。

安全收益是根本性的。在旧设计中，凭证生活在运行不受信任生成代码的同一容器中。一次成功的提示注入，这些凭证就会暴露。在新设计中，凭证保存在外部保险库中。沙箱永远不会接触它们。

这些都不是模型改进。模型没有改变。Anthropic围绕它工程了基础设施，结果系统变得显著更快、更安全、更可靠。

4、OpenClaw案例：当工程做对时会发生什么

如果你想要一个工程使AI变得非凡的干净例子，看看OpenClaw。

它始于一个周末项目：2025年11月Peter Steinberger编写的一个简单的WhatsApp中继脚本。前提很谦虚：将消息从你的聊天应用路由到Claude或GPT。

八周内，它从那个脚本变成了GitHub历史上增长最快的开源项目之一，2026年2月初超过180,000颗星。到3月，247,000颗星和47,700个分支。Andrej Karpathy称之为"我见过的最不可思议的科幻起飞相关的事情。"

让OpenClaw病毒式传播的不是AI模型。Claude和GPT已经对每个人都可用。

使其非凡的是模型周围的工程。

OpenClaw将你的AI助手视为基础设施问题，而不是提示工程问题。不是试图通过巧妙的提示让LLM"记住"上下文或安全地行为，而是构建一个结构化的执行环境：适当的会话管理、内存系统、工具沙箱、消息路由。LLM提供智能。OpenClaw提供操作系统。

考虑并发问题。当多条消息同时到达智能体时，天真的实现并行运行它们。这听起来不错，直到两个任务试图修改同一个文件，或者智能体的内存因为一个任务在应该先完成的任务之前完成而被破坏。OpenClaw用"默认串行、明确并行"的哲学解决这个问题。每个会话有自己的车道。车道内的任务一个接一个地执行。只有低风险、幂等的任务移动到并行车道。

这不是模型功能。那是工程。

真实结果：一个开发者的OpenClaw智能体在他睡觉时谈判了4,200美元的汽车购买。它抓取了经销商库存，填写了联系表格，并花了几天时间用竞争的报价让经销商互相竞争。这些不是演示。它们是可靠地做真实工作的智能体。

创造者对此很清楚。当Steinberger宣布他将项目转移到一个开源基金会时，社区的反应不是"太好了，AI正在接管。"而是：我们如何维持使这项工作的工程纪律？团队注意到提示注入仍然是一个行业范围的未解决问题。

模型没有解决提示注入。工程师正在努力。

5、工程师现在是架构师

这是实际的转变，值得深思。

以前，工程师是实现者。他们接收需求并将其翻译成代码。那部分，是的，AI正在吃掉。

AI无法吃掉的是判断层。关于实际要解决什么问题的决定。决定系统是扩展还是崩溃的架构选择。从发布真实东西并观察它们在生产中破坏中建立的直觉。

Satya Nadella简单地说：这些AI能力"不仅仅从模型中自然出现。我们试图工程能力。"AI不会自我组织成有用的东西。某个人必须设计结果。

本文中的每个例子都证明了同样的事情。Anthropic的Managed Agents变得显著更好，不是因为模型改进，而是因为工程师重新思考了状态、执行和凭证如何分离。OpenClaw成为现象，不是因为它使用了更好的模型，而是因为有人围绕一个广泛可用的模型设计了正确的系统。

在这个时代蓬勃发展的工程师将LLM视为更大系统中强大但不可预测的组件。不是魔法棒。他们知道何时使用RAG而不是微调。他们知道如何设计优雅失败的智能体。他们明白AI产品中最重要的工程决策通常与模型本身无关。

Karpathy对此提出了一个让我印象深刻的观点。在他的实验中，编码智能体很好地处理了样板：可预测、定义良好的任务。对于真正新颖的系统设计，它们崩溃了。他的反应不是放弃智能体。是知道边界并相应设计。

那是工程直觉。它不是来自模型。它来自经验。

如果你现在是一名工程师：开始担心替代品。开始考虑编排。深入学习RAG。理解智能体设计模式。为你的AI输出构建评估管道。将LLM视为强大的初级开发者——快速、有创意、有用，并且严重需要清晰的结构和资深工程师关注关键路径。

AI是工程师拥有最强大的工具。

但工具的好坏取决于围绕它设计系统的人。

原文链接: I Thought AI Would Replace Engineers. But Anthropic and OpenClaw Proved Me Wrong

汇智网翻译整理，标明出处