两次领导AI转型的工程负责人谈智能体工程进阶路径

去年八月，我开始带领一家700人公司里一个100人的研发团队做AI转型。十月事情有了真正的转机，之后每出现一个重要的模型或工具，就又转一次。

现在我在现在的公司又做了一遍。我们还没做完，但已经在交付了，而且有了让这一切运转起来的循环、自动化和云环境。

现在市面上有很多“agentic engineering 的层级”清单。我觉得它们有用。但大多数读起来像一张工具阶梯：先用这个，再加上那个，然后买这个。经历了两次之后，我更愿意用一个问题来描述它。

一开始，答案就是一切。之后的每一层都是同一个动作。你找到循环里你还在手动做的那部分，然后想办法把自己从中拿掉。

如果让我给别人建议怎么给一个组织“喂AI药”，我会从这里开始。你必须让人们看到什么是可能的。你不能坐在象牙塔里告诉所有人用新方式工作。你得跟团队一起进去，通过自己做给他们看，有更好、更快的交付软件的方式。

自己动手还有第二个原因。当你交付时，你会撞上每家公司都有的系统性摩擦。很多时候是基础设施。有时是评审政策或合规政策。每个产品都有些多年前出于好理由设下的东西，现在却挡路了。

你不能活在幻想里说“嗯，我希望它这样运作”。还有什么比亲自撞上墙、然后去把墙拆掉更好的找墙方式呢？

在我做这件事的每家公司，墙通常都是基础设施。这不是在贬低基础设施团队。基础设施就是最难改的东西。它是一张由 CI 任务、部署流水线和环境交织成的乱网，而且它出问题时代价更大。相比之下架构就简单了：只要 API 端点不变，agent 可以重做它们背后的东西。政策是另一堵墙。一次变更需要多少人评审？自动评审算数吗？只有当你自己卡在等这些规则时，你才会发现它们拖慢了你多少。

所以这就是我的方法，它有两半。首先我交付一个全新的原型。那里没有摩擦，所以它能展示标杆在哪：没有任何阻碍时什么是可能的。然后我在现有产品里交付一个真实路线图项目或待办事项，带着现有软件的所有现实。这两者之间的差距就是地图。它精确告诉你摩擦在哪里，你可以从那里设计改变。

我想从理解出发来领导，而不是从理想主义出发。

不过第二次看起来不一样。在第一家公司时还很早期、很自然。我在那里有很多社会资本，很多工作是培训：怎么用 Claude Code，怎么同时跑多个 agent。在现在的公司，每个人已经在用 Claude，软件工厂风靡一时。培训基础已经不是价值所在了。工作是前沿那部分：把所有东西迁到云上、自动化、工厂。我进来时社会资本更少，也许正式权力更多，但后者买不到那么多东西。交付才是你赢得要求别人改变的权利的方式。

以下是我这一路爬升的样子。

开发者不该再手写代码了。如果你的组织还在手写，让所有人用上 Claude Code 并指向真实问题，是你能获得的最大单次提升。

即使在这一层内部也有一个范围。很多人一开始说“建这个类”。那还是你在设计代码，agent 在打字。今天你可以直接给它工单。如果有工单和代码库，它不需要重度管理就能完成工作。

你在学习把结果托付给机器，而不是指令。

一旦 agent 在写代码，你会注意到仍然是你在告诉它系统怎么运作。东西放在哪、哪个服务拥有什么、我们这里怎么做迁移。所以下一步是让代码库对 AI 可导航，这样它就不需要你了。

一年前这是个更大的问题。现在的模型非常擅长翻查代码库，多数情况下只要你给它们访问权限，它们就能找到需要的东西。但如果你的架构分散在多个服务和仓库里，不是所有东西都在一个地方，留几个索引和指针总没坏处。

显而易见的工具是 AGENTS.md（或 CLAUDE.md）文件。我会给任何人两条规则：

Skills 也是同样的道理。它们是你把“我们这里这么做”编码下来的方式。但要小心，skills 往往变得过于限制性。如果你用的是较旧或较便宜的模型，规定性的 skill 有帮助。如果你用的是像 Opus 5.5 这样的前沿模型，你往往根本不需要 skill，或者它应该简短且以目标为导向。对于更大的架构决策，你也可以让更强的模型负责规划，让更便宜的模型去构建。

两年前我超级规定性，手把手带着模型做每件事。现在我大多把结果委托出去。

现在 agent 写代码、认得路，而你是那个检查它能不能跑的人。如果一个人必须验证每一次变更，你只是把打字搬到了评审里。

所以你给 agent 和工程师一样的访问权限。对日志的完整访问。能端到端运行应用、调试、测试和自行做 QA 的能力。真正的验证循环，这样它们能给你无可辩驳的证据。agent 现在非常擅长录制功能正常工作的视频，所以要一个。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）