Paul Everitt 谈向 Agentic Engineering 的转变

核心论点：从 Vibe Coding 到 Agentic Engineering

软件工程目前正经历着一种生产力悖论：虽然 AI 允许代码输出量大幅增加，但这尚未转化为持久的组织价值。行业目前正处于“vibe coding”阶段——本质上是寄希望于 AI 生成的代码能够运行——这往往导致质量下降，并导致企业通过裁员而非长期创新来关注短期利润率。

为了解决这个问题，行业必须转向 agentic engineering。这是“构建构建事物的工具”的实践。Agentic engineering 的重点不在于使用 AI 来取代人类程序员，而在于构建能够增强人类并确保 AI agents 在严谨的工程学科内运行的系统、脚手架和护栏。

尽管拥有强大的 AI 工具（“god box”），许多组织仍未能实现系统性价值。Paul Everitt 指出了几个关键的失败点：

编码瓶颈谬误： 引用诺贝尔奖得主 Daron Acemoglu 和 Grady Booch，Everitt 指出，编码本身从未是软件工程中的主要瓶颈。
质量与信任问题： 信任方面存在显著差距，仅有 3% 的开发者报告对生成结果的准确性有高度信心。这带来了“Challenger-style”灾难的风险，即 agents 在没有人类监督的情况下直接将错误的代码推送到生产环境。
“Token Maxing”问题： 员工可能会为了增加 token 使用量或输出指标而操纵系统，导致管理层对 AI 成功的感知与工程师的实际体验之间出现脱节。
激励机制错位： 许多公司正将 AI 作为“mega layoffs”的借口来推高股价，而不是利用这项技术来创造以前无法构建的产品。

Agentic engineering 不关乎编写代码的行为，而关乎管理 AI agents 的系统设计。它将工程师的角色从手动构建者转变为系统架构师。关键的实践组成部分包括：

Evals 优于“点击按钮”： 工程需要客观测量。开发者必须实施严格的评估（evaluations）来确定 agent 是否在特定的预算和轮次内生成了高质量的代码。
针对 Agents 的 Red-Green 测试： 通过先编写一个失败的测试，工程师可以精确定义“成功”是什么样子。然后，agent 会模仿工程师的测试风格并朝着定义的 green state 努力，从而减少在代码库中“漫游”的时间。

安全沙箱： Agents 不应只是简单地 grep 代码库；它们应该在安全、低延迟的沙箱中（例如使用基于 Rust 的 Python 子集如 Monty）生成并运行特定的工具代码来解决问题。
Harness Engineering： Everitt 强调，“如果你不拥有你的 harness，你就无法拥有你的 memory。” 拥有编排和执行环境对于维持对 agent 行为的控制至关重要。

以 Agent 为中心的架构： 大型、遗留代码库可能需要重新组织。在 agentic 世界中，模块化看起来有所不同，它需要支持并行子 agent 和高度专业化的上下文工程（context engineering）的结构。
QA Agents： 与其让人员成为质量保证的瓶颈，工程师应该构建 QA agents，让它们通过浏览器或开发工具协议收集自己的 instrumentation，为人类审查做准备。

Everitt 认为，软件社区必须夺回“工程”作为一门严谨科学和实践的定义权。他挑战开发者超越当前的炒作周期，并建立 agentic design patterns——一套用于构建 AI 驱动系统的标准化、可复用的架构模式。

目标是将领导层的叙事从“更多代码，更少的人”转向“通过增强实现创新”。通过专注于系统设计和工程学科的严谨性，开发者可以确保 AI 被用于构建宏伟的新解决方案，而不是仅仅为了榨取利润率。