AI Engineering Trends Infrastructure

+++ title = “伦敦 AIE 峰会 2026:AI 工程的真实样子” keywords = [ “aie”, “mcp”, “工程的真实样子”, “我们在伦敦 aie”, “为什么 aie”, “ide”, “ide 的衰亡、 mcp”, “为什么” ] description = “我们在伦敦 AIE 峰会 2026 学到的内容:智能体混乱、速度与质量的争论、IDE 的衰亡、MCP 悖论,以及为什么 AI 让我们工作更加努力。” image = “/images/blog/london-aime26.jpeg” tags = [“AI”, “Engineering”, “Trends”, “Infrastructure”, “Productivity”] categories = [“Flows”] showCTA = true ctaHeading = “自动化您的 AI 工作流” ctaDescription = “停止手动编排智能体。FlowHunt 的工作流构建器处理智能体链接、错误恢复和多步 AI 任务——这样您可以专注于智能体应该做什么,而不是如何驾驭它们。” ctaPrimaryText = “立即尝试” ctaPrimaryURL = “https://app.flowhunt.io/sign-in" ctaSecondaryText = “预订演示” ctaSecondaryURL = “https://www.flowhunt.io/demo/" author = “akahani” date = “2026-04-13 09:00:00”

[[faq]] question = “什么是 FOMAT,为什么 AI 工程师关心它?” answer = “FOMAT——‘Fear of Missing Attention Time’(缺失注意力时间的恐惧)——描述了向编码智能体发送提示后,它会无人监督地运行数小时而产生的焦虑。它反映了一个真实的问题:智能体编排是不可预测的。没有适当的护栏,智能体可能会消耗大量计算、token 和时间来追求边际改进,而您却不在办公桌前。”

[[faq]] question = “Lopopolo-Zechner 辩论是关于速度与质量吗?” answer = “不完全是。Lopopolo(OpenAI)提倡"token 亿万富翁"工程——最大化吞吐量,让智能体生成大量代码,并相信规模。Zechner(Anthropic)则主张有意为之:放慢速度,阅读代码,理解智能体在做什么。两者在不同的背景下都是正确的;分歧在于团队应该默认采用哪种方式。”

[[faq]] question = “如果我们仍然需要编辑代码,为什么 IDE 会消亡?” answer = “IDE 并没有消失——它们被绕过了。开发人员越来越多地在浏览器中工作(GitHub Codespaces、VS Code Web),并让智能体处理繁重工作。GitHub 的流量同比增长了 15 倍,表明开发人员正在协作处理智能体生成的代码,而不是在本地编写代码。IDE 作为"思考空间"正在被智能体作为"思考伙伴"所取代。”

[[faq]] question = “MCP 真的死了,还是只是被误解了?” answer = “MCP 同时作为开发者工具"死了”,但作为企业基础设施却蓬勃发展。个别 AIE 表示 MCP 对于简单的智能体任务是不必要的,但企业正在快速采用 MCP 和 MCP Apps,因为它们解决了一个真实的安全问题:如何给予智能体对数据和 API 的受控访问权限,而不暴露凭证或允许任意技能注入。”

[[faq]] question = “Jevons 悖论如何适用于 AI 生产力?” answer = “Jevons 悖论指出,效率提升会增加总消费量。用 AI 术语来说:智能体使代码生成变得更便宜、更快,所以团队现在期望每个工程师交付 10 倍的输出、完整文档、测试套件和国际化支持——独自完成。生产力收益被膨胀的期望所消耗,导致工程师尽管拥有更好的工具,但工作更加努力。”

[[faq]] question = “OpenClaw 和自我改进软件发生了什么?” answer = “在 2025 年 12 月至 2026 年 2 月之间,发生了一些转变。OpenClaw(和类似框架)开始使智能体能够在没有人工干预的情况下迭代改进自己的输出。关键洞察是:“停止向它们要求琐碎的建议。“相反,给智能体一个目标,让它精化解决方案。这改变了团队对智能体工作流的思考方式——从"智能体作为工具"到"智能体作为自主贡献者”。”

[[faq]] question = “AI 工程角色真的只是 PM、保姆或品味设定者吗?” answer = “根据峰会上的对话,是的——这些是正在出现的三个原型。“PM"角色定义智能体行为和成功指标。“保姆"监控智能体执行,捕捉错误并进行干预。“品味设定者"评估智能体输出质量并提供反馈。传统的"编写代码"角色正在被这些元角色所取代。” +++

伦敦 AI 工程师峰会 2026 本应是一场进步的庆祝。相反,它感觉像是对一个正在经历神经崩溃的专业领域的镜像观察。

在 4 月初的三天里,数百名 AI 工程师、平台构建者和研究人员聚集在一起分享他们学到的东西。浮现出来的模式是:每个人都在用智能体构建,没有人弄清楚如何控制它们,行业对是快速前进还是仔细思考存在分歧,整个关于 AI 会让我们更有生产力的前提已经被反转成了更黑暗的东西。

这就是我们真正学到的。

为什么 AI 工程师用他们无法控制的智能体编码?

峰会上最诚实的对话发生在走廊里,而不是舞台上。一位来自中等规模金融科技公司的工程师这样描述了这个问题:“我开始一个提示,三个小时后我的智能体已经重写了半个代码库,添加了我没有要求的功能,并消耗了 800 英镑的计算资源。我无法离开我的办公桌。”

这就是 FOMAT:缺失注意力时间的恐惧。这不是一个笑话——这是 2026 年 AI 工程的定义性焦虑。

编排瓶颈

峰会上的每个人都在使用智能体。GitHub Copilot、Claude、自定义智能体框架——工具已经成熟。但编排还没有。“我有一个智能体"和"我的智能体做我想要的东西,仅此而已"之间的差距是巨大的。

这个问题以三种方式表现出来:

Token 失控。 智能体没有自然的停止点。没有明确的护栏,它们会持续迭代。“再重构一次,“智能体想,突然你已经用完了月度预算。

范围蔓延。 一个"改进错误处理"的请求变成了"重写整个错误处理系统、添加可观测性、重构日志层、实施分布式追踪”。智能体没有错——它很彻底。但这不是你要求的。

不可预测的延迟。 你无法知道一个智能体任务需要多长时间。这取决于智能体决定生成多少个子任务、它遇到多少次失败,以及它决定重试还是改变方向。这使得由智能体驱动的工作流无法在生产系统中调度。

峰会共识是什么(以及不是什么)

在解决方案上没有共识。一些团队使用硬 token 限制。其他团队实施"智能体检查点”——强制智能体暂停并在继续前请求许可。少数几个团队正在转向分层智能体系统,其中"管理者智能体"监督工作者智能体并可以中断它们。

FlowHunt 的方法——具有智能体节点、错误处理程序和分支逻辑的显式工作流定义——在多次被提及为潜在模式。想法是:不要让智能体决定工作流结构。提前定义它,然后让智能体执行单个步骤。

但即使这样也感觉像是创可贴。真正的问题是智能体行为本质上是概率性的。你可以减少方差,但无法消除它。

OpenAI-Anthropic 分歧如何重塑了"好代码"的含义?

周一上午,OpenAI 的 Ryan Lopopolo 登上舞台,发表了一个可以概括为以下内容的主题演讲:停止阅读代码。成为 token 亿万富翁。

他的论点:在一个智能体世界中,代码量是重要的指标。你的智能体应该每天生成数千行。你的工作是定义输出规范并让智能体最大化吞吐量。阅读和理解每一行是一个瓶颈。相信测试。相信智能体。快速前进。

到周三,Anthropic 的 Mario Zechner 给出了反论点主题演讲:放慢速度并阅读该死的代码。

他的论点:速度是一个陷阱。你的智能体写的每一行代码都是一个责任。你需要理解它、推理它,并能够维护它。五年内赢的团队是那些优先考虑清晰性和意图而不是速度的团队。智能体应该是思考工具,而不是无脑生成代码的工具。

频谱

峰会大致分为三个阵营:

立场倡导者方法风险
Token 最大主义者OpenAI、一些规模化工程师让智能体积极生成;通过测试专注于输出质量无法维护的代码库、安全债务、技术脆弱性
有意中间派大多数企业工程师使用智能体进行脚手架;人类提供架构和品味速度较慢,但系统更稳定
代码优先Anthropic、一些研究工程师智能体增强人类思维;人类编写大部分代码吞吐量较低,但代码质量最高

双方都没有错。分歧在于失败是什么样子。Lopopolo 在优化迭代速度。Zechner 在优化可持续性。在 2026 年,团队正在学习你无法同时优化两者。

面试问题

一个具体的后果:招聘被破坏了。如果你是一个 token 最大主义者,你不在乎候选人是否会编码——你在乎他们是否能有效地提示和评估智能体输出。如果你是代码优先,你想看到深层的技术推理。

所以当候选人走进面试室时,面试官和候选人都不知道他们是根据哪个框架被评估的。一位峰会与会者将其描述为"在雾中面试”。

FlowHunt Logo

Ready to grow your business?

Start your free trial today and see results within days.

为什么 IDE 在衰退而 GitHub 流量爆炸?

GitHub 报告了同比流量增长 15 倍。Cloudflare 报告了类似的峰值。与此同时,传统 IDE——VS Code、JetBrains、Sublime——在 AI 原生团队中的使用量在下降。

这似乎是矛盾的,直到你理解实际发生的事情。

IDE 是本地思考工具

IDE 被设计用于单个开发人员在本地编写代码。它有语法高亮、自动完成、调试工具和文件树。它是一个自包含的环境。

当你的"开发人员"是一个智能体时,这个模型就崩溃了。智能体不需要语法高亮。它不需要调试器。它需要:

  • 同时访问多个文件
  • 运行代码并查看结果的能力
  • 与版本控制的集成
  • 协作功能(因为智能体和人类一起工作)

所有这些现在都在浏览器中。GitHub Codespaces、VS Code Web 和类似工具正在取代本地 IDE。

实际增长的是什么

GitHub 的流量激增不是开发人员在浏览器中编写代码。这是开发人员审查、评论和合并智能体生成的代码。爆炸的是协作层,而不是编辑层。

这就是为什么 Cloudflare 也看到流量激增——开发人员正在使用云基础设施来运行智能体和编排工作流。“本地 IDE + 本地开发环境"模型正在被"云原生智能体编排 + 基于浏览器的审查"所取代。

L33T C0d3 已死

一个会议的标题正是这个。要点是:关于那位杰出的工程师独自坐在键盘前,精心制作优雅代码的浪漫观念——那已经结束了。代码现在是人类和智能体之间的协作输出。重要的技能是:

  • 提示工程(如何指定你想要的东西)
  • 输出评估(智能体的代码好吗?)
  • 架构思维(智能体应该在什么结构内工作?)
  • 集成(智能体生成的代码如何适应现有系统?)

编写优雅的代码不再是主要技能。这是智能体做的事情。人类做其他的一切。

MCP 真正发生了什么——死了还是蓬勃发展?

这是峰会上最令人困惑的辩论。

一方面,个别 AIE 和智能体框架维护者说:“MCP 已死。我们不需要它。我们的智能体可以直接调用 API。”

另一方面,企业架构师和安全团队说:“MCP 采用速度比我们构建工具的速度还要快。”

两个陈述都是真的。它们描述的是不同的人群。

为什么 AIE 认为 MCP 已死

对于构建简单智能体的独立开发人员,MCP 会增加摩擦。你需要:

  • 为你的工具定义 MCP 服务器
  • 管理协议开销
  • 处理身份验证和授权
  • 部署和维护服务器

不如直接给你的智能体 API 访问权限,让它自己解决。

为什么企业正在快速采用 MCP

对于在生产中运行智能体的组织,MCP 突然变得至关重要。原因如下:

安全隔离。 你不想让智能体直接访问你的数据库、支付系统或客户数据。MCP 让你创建一个受控的界面,智能体可以调用而不暴露底层系统。

可审计性。 每个智能体操作都通过 MCP 服务器,它记录它。你有智能体做了什么和为什么的完整记录。

凭证管理。 不是在智能体提示或环境变量中嵌入 API 密钥,MCP 服务器安全地管理凭证。

速率限制和配额执行。 你可以控制智能体可以消耗多少资源。

根据 CData Software,截至 2026 年初,80% 的财富 500 强公司正在评估或实施 MCP,主要是出于这些原因。

解决方案

峰会共识:MCP 没有死。它只是与占 AI 开发 80% 的实验性和独立工作无关。但对于占 20% 的生产和多团队工作,MCP 正在成为必需品。

这就是为什么 MCP Apps 在激增。Anthropic、OpenAI 和第三方供应商正在为常见工具(Salesforce、Slack、Jira、数据库)构建预构建的 MCP 服务器。企业可以采用这些而无需构建自定义服务器。

AI 是让我们更有生产力,还是只是更疲惫?

这是峰会变得黑暗的地方。

AI 应该是一个力量倍增器。你会花更少的时间在例行任务上,更多的时间在战略思考上。生产力会飙升。

相反,生产力飙升了——工作量期望也飙升了。

实时的 Jevons 悖论

Jevons 悖论最初应用于煤炭消费,指出:当资源变得更有效率时,总消费量会增加,因为资源变得更便宜和更有吸引力。

用 AI 术语:智能体使代码生成变得更便宜和更快,所以经理现在期望每个工程师:

  • 交付 10 倍的输出
  • 编写全面的文档
  • 构建完整的测试套件
  • 支持国际化(i18n)
  • 处理边界情况
  • 独自完成所有这些

生产力收益被膨胀的期望所消耗。

工程师说了什么

来自伦敦初创公司的一位工程师:“我过去一天写 500 行代码,感到有生产力。现在我一天写 5000 行——由智能体生成——我很疲惫,因为我必须审查所有这些、测试它、文档化它,并向利益相关者解释它。我在做 60 小时的工作周。”

另一个:“我的经理说,‘你现在有一个智能体,所以你应该能够处理两倍多的项目。‘我的生产力没有提高。我只是更忙了。”

一位研究人员:“智能体很擅长生成代码。它们不擅长决定生成什么代码。那个决策负担已经完全转移到了人类身上。我们没有自动化困难的部分;我们自动化了简单的部分,让人类做更多的思考。”

生产力盲点

加州大学伯克利分校的《加州管理评论》在 2026 年 1 月发表了记录这一现象的研究。关键洞察:AI 部署不会减少工作;它改变了工作的性质。

旧工作:编写代码。 新工作:指导智能体、评估输出、维护质量、管理范围蔓延。

新工作在认知上更难,即使打字更少。

为什么欧洲对 AI 工程如此犹豫?

峰会有一个强大的欧洲代表团,他们的信息是一致的:欧洲在 AI 工程采用方面的速度不如美国。

监管的压力

欧盟 AI 法案仍在实施中。公司对责任感到不确定。如果 AI 智能体做出伤害客户的决定,谁负责?公司?模型供应商?工程师?

这种不确定性令人麻木。许多欧洲公司正在等待看第一批诉讼如何进行,然后再构建认真的智能体系统。

技能差距

欧洲的传统软件工程师没有以与美国相同的速度转变为 AI 工程师。对技能转移是否有效存在怀疑。许多欧洲工程师正在等待看 AI 工程是否是一条真实的职业道路或炒作周期。

隐私问题

欧洲对数据处理也更加谨慎。智能体需要访问数据才能有用。但欧洲公司不愿给智能体访问客户数据,即使有 MCP 保护措施。

前进之路

峰会上的欧洲工程师不是反 AI。他们是支持谨慎的。情绪是:“美国正在快速前进并破坏东西。我们会更慢地前进,并尽量不破坏太多。五年后,我们会看到谁是对的。”

AI 工程角色实际上是如何变化的?

到峰会结束时,出现了一个模式:传统软件工程角色正在被掏空并被三个新原型所取代。

三个角色

角色责任技能
AI PM定义智能体行为、成功指标、约束产品思维、提示设计、评估框架
智能体保姆监控执行、捕捉错误、必要时进行干预调试、可观测性、错误处理、事件响应
品味设定者评估输出质量、提供反馈、指导精化代码审查、架构思维、审美判断

这些角色都不涉及以传统意义编写代码。所有这些都涉及指导、评估和精化智能体行为。

正在消失的是什么

“初级工程师"角色正在被压缩。不再有从"我能写简单代码"到"我能架构系统"的清晰路径。中间步骤正在被自动化。

这造成了一个技能悬崖:要么你擅长提示和评估(在这种情况下你很有价值),要么你不擅长(在这种情况下你与智能体竞争)。

正在增长的是什么

需要品味、判断和架构思维的角色正在增长。需要深厚领域专业知识的角色也是如此(因为智能体需要人类来评估他们是否在解决正确的问题)。

峰会对这是好是坏没有共识。有些人把它看作是从乏味编码中解放出来。其他人把它看作对职业的威胁。

2025 年 12 月至 2026 年 2 月之间发生了什么变化?

峰会的一部分致力于一个特定的转折点:在新年左右,AI 智能体生态系统中发生了一些转变。

自我改进软件变成了现实

OpenClaw 和类似框架开始使智能体能够在没有持续人工提示的情况下迭代改进自己的输出。不是"智能体,写一个计算 X 的函数,“而是"智能体,写一个计算 X 的函数,并持续改进它,直到它通过所有测试并处理边界情况。”

关键洞察,由多位研究人员阐述:停止向智能体要求琐碎的建议。

不是要求智能体"改进这个函数,“而是要求它"使这个函数防弹。“让它决定那意味着什么。智能体将:

  • 编写测试
  • 找到边界情况
  • 为清晰性重构
  • 添加错误处理
  • 文档化逻辑

所有这些都不需要被要求每一步。

这改变了从"智能体作为工具"到"智能体作为自主贡献者"的心智模型。它改变了工作负载动态:智能体不是减少人类工作,而是增加了它(因为人类现在必须评估更复杂的智能体输出)。

我们生活中的矛盾

峰会以没有解决而结束,这感觉是诚实的。以下是定义 2026 年 4 月 AI 工程的矛盾:

矛盾 1: 智能体足够强大以至于危险(FOMAT 是真实的),但不够强大以至于可以无人监督地信任。

矛盾 2: 速度和质量被视为对立的,但两者都是必要的。

矛盾 3: MCP 同时对个人"死了”,对企业"蓬勃发展”。

矛盾 4: AI 让我们更有生产力,但也更疲惫。

矛盾 5: 每个人都在用智能体构建,但没有人弄清楚如何好好地用它们构建。

矛盾 6: AI 工程是一条真实的职业道路,但我们认为重要的技能(编写代码)不再重要。

这些不是要解决的问题。它们是要管理的张力。2026 年赢的团队是那些承认这些矛盾而不是假装它们不存在的团队。

常见问题


我们的收获

伦敦峰会是一个正在过渡中的专业领域的快照。AI 工程是真实的,但不是我们认为的那样。它比炒作暗示的更混乱、更矛盾、更依赖人类。

峰会上最好的工程师不是那些拥有最复杂智能体的人。他们是理解智能体是思考工具,而不是思考替代品的人。他们是那些建立了流程来管理智能体行为、评估输出和维护质量的人。他们是那些接受生产力收益伴随着新种类工作而不是更少工作的人。

如果你在 2026 年构建 AI 系统,峰会的课程很清楚:

  1. 编排比智能体能力更重要。 一个有良好编排的平庸智能体胜过一个没有控制的聪明智能体。

  2. 清晰比速度更有价值。 快速前进并破坏东西有效,直到它无效。在规模上,它无效。

  3. 企业采用是真实的,但个人采用仍然是实验性的。 如果你是独立开发人员,你可以快速前进。如果你是一个团队,你需要护栏。

  4. 重要的技能已经改变。 提示工程、输出评估和架构思维是新的核心能力。

  5. 预期工作更努力,而不是更轻松。 AI 是生产力倍增器,但收益被更高的期望所消耗。相应地计划。

峰会没有回答"AI 工程看起来像什么?“这个问题。它向我们展示了答案:它看起来像我们,试图实时弄清楚。

{{ cta-dark-panel heading=“停止手动编排智能体” description=“FlowHunt 的工作流构建器让你定义智能体行为、设置护栏并自动化多步 AI 任务。没有更多 FOMAT。没有更多猜测你的智能体在做什么。” ctaPrimaryText=“免费尝试 FlowHunt” ctaPrimaryURL=“https://app.flowhunt.io/sign-in" ctaSecondaryText=“预订演示” ctaSecondaryURL=“https://www.flowhunt.io/demo/" gradientStartColor="#667eea” gradientEndColor="#764ba2” gradientId=“aie-summit-cta” }}

Learn more

2026年最佳AI智能体构建平台:自主智能平台全指南
2026年最佳AI智能体构建平台:自主智能平台全指南

2026年最佳AI智能体构建平台:自主智能平台全指南

探索2026年顶级AI智能体构建平台,从零代码平台到企业级框架。了解哪些工具最适合你的用例,以及FlowHunt如何提升AI智能体工作流。...

2 min read
AI Agents Automation +3
2026年12个最佳AI应用程序:为每个用例排名和评论
2026年12个最佳AI应用程序:为每个用例排名和评论

2026年12个最佳AI应用程序:为每个用例排名和评论

2026年12个最佳AI应用程序,按功能、易用性和价值排名。从AI工作流自动化到写作、设计和编码——为您的团队找到合适的工具。...

2 min read
AI Tools Productivity +2