智能体工程实战手册

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

Peter Steinberger 与 Lex Fridman 进行了三小时的对话。大多数报道关注的是 OpenClaw 的起源故事、与 Anthropic 的命名"纠纷"、以及 Meta 和 OpenAI 的收购洽谈。这些都很有趣，但不是引起我注意的地方。

在对话中隐藏着 Steinberger 实际使用 AI agent 的具体原则。不是理论。不是感觉。而是具体的决策——这些决策让他在大约三个月内，基本独自一人，构建了 GitHub 历史上增长最快的开源项目之一。

我通读了完整的文字记录，提取出了真正有用的内容。

1、Vibe coding 是一个贬义词

Steinberger 对此直言不讳。他称 vibe coding 是一个贬义词。他更喜欢的术语是 agentic engineering。

这个区别很重要。Vibe coding 是不加思考地提问，希望模型能搞定。Agentic engineering 是刻意地引导有能力的 agent 走向你深思熟虑后的结果。

"我总是告诉别人我做的是 agentic engineering，然后也许凌晨 3 点之后我会切换到 vibe coding，然后第二天我就会后悔。"

正如 Lex 所说的"羞愧之路"。你醒来，看着自己产出的东西，然后花一上午收拾残局。我们都经历过。

2、Agentic 陷阱

Steinberger 描述了一个大多数构建者都会经历的曲线。它看起来像一个 U 形。

左边：你是初学者。简短的提示。"请修复这个。"简单直接。

中间：你发现了力量。八个 agent 同时运行，复杂的编排，多次检出，将 agent 链接在一起，一个包含 18 个不同斜杠命令的库。

像 LinkedIn 和 Reddit 上的所有人一样，你在构建复杂的大教堂。

右边：你从另一端出来了。再次使用简短的提示。"嘿，看看这些文件，然后做这些修改。"但现在这种简单是挣来的。你知道什么可以省略。

大多数人卡在中间。他们过度工程化工作流，自动化一切，试图将自己完全排除在循环之外。Steinberger 认为那是一条死路。

"那些试图使用编排器来自动化整个过程的人，我觉得如果你那样做，就失去了风格、热爱和人情味。"

3、与 agent 共情

这是 Steinberger 反复提到最多的一条原则。考虑一下 agent 如何看待你的代码库。

每次会话都从零开始。Agent 对你的项目一无所知。你的项目可能有十万行代码。Agent 每次都必须从零开始探索。

"你在抱怨你的蠢机器，但你没有意识到它们从零开始，而你对你的代码库一无所知。你进去一看，你的代码库完全是乱七八糟的命名。然后人们抱怨 agent 不好用。"

他的实用建议：给 agent 一些关于在哪里查找的提示。你有一个可以用一两句话表达的系统级理解。分享它。不要让你的 agent 从头重新发现你的架构。

这直接对应于管理初级工程师。你不会把一个新员工扔到 10 万行代码库面前，在没有任何上下文的情况下说"修复这个 bug"。给 agent 和你给人一样的尊重。

4、不要和命名作对

这一点让我感到惊讶。Steinberger 故意让 agent 选择变量名、文件名和函数名，即使他自己会有不同的选择。

"不要和他们选择的名称作对，因为这个名字很可能就在权重里，是最明显的名字。下次他们搜索时，他们会找那个名字。如果我决定不喜欢这个名字，我只是让他们的工作变得更难。"

他在为 agent 的可导航性设计代码库，而不是为了自己的偏好。这是一个真正的思维转变。你不是在构建一个对你来说完美的代码库。你是在构建一个让 agent 容易工作的代码库。

这需要放手。就像管理一个工程师团队一样，你接受代码不会完全按照你写的方式写出来。它推动项目前进，这才是重要的。

5、用说的，不要用打的

Steinberger 使用语音进行大部分提示。多个终端窗口，用键盘在它们之间切换，但实际的 agent 指令是口头说出的。他曾经有一段时间因为和 agent 说话太多而失声。

除了速度优势，语音改变了你提问的方式。你更健谈。你自然地解释上下文。你会说"嘿，看看认证模块，有一个关于过期令牌的奇怪边界情况"，而不是精心设计的文字提示。

6、对话模式

他与 agent 的工作流遵循一个特定的节奏：

构建之前： 进行讨论。"讨论这个。给我一些选项。先不要写代码。"Agent 探索，你们一起讨论。当你准备好时，说"好，开始构建"，然后让它运行 20 分钟。

审查过程中： 在审查 PR 时，他的第一个问题从来与代码无关。而是"你理解这个 PR 的意图吗？"他希望 agent 在查看实现之前先把握问题。

构建之后： 每次完成一个功能，他都会问："现在你构建了它，你会做得有什么不同？"和"我们可以重构什么？"Agent 在构建过程中发现了痛点，就像人类开发者一样。在这些上下文消失之前利用它。

神奇的问题： "你有什么问题要问我吗？"然后他浏览这些问题。如果它们都可以通过阅读更多代码来回答，他会说"读更多代码来回答你自己的问题。"如果 agent 再次回来，剩下的问题才是真正的问题。

7、绝不回滚，始终前进

Steinberger 不回滚。如果出了问题，他让 agent 修复它，而不是恢复到以前的状态。

"如果我回滚所有东西，只会花更长时间。如果我看到某样东西不好，我们就继续前进。"

Main 分支始终是可发布的。没有功能分支。没有 develop 分支。他保留同一个仓库的多个副本，都在 main 上，这样他就不需要处理分支命名或合并冲突。测试在本地运行。如果通过，他就推送。

这听起来鲁莽，直到你考虑经济性。回滚消耗上下文。Agent 在会话期间建立起了对问题的理解。回滚丢弃了这些。向前修复保留了它。

8、CLI 优先于 MCP，始终如此

他在互联网上构建了最流行的 AI agent 框架，核心却不支持 MCP。这是一种表态。

他的论点简单而技术性。模型是在 Unix 上训练的。它们知道如何调用 CLI。MCP 需要特殊的语法，必须被烘焙到训练中。CLI 是可组合的，你可以通过 jq 或 grep 传递输出。MCP 每次都将完整响应倾倒入上下文中，用 agent 不需要的数据污染它。

"就用 CLI。机器人真的很擅长 Unix。你可以有任意多个，它就能用。"

他构建了一个叫 makeporter 的工具，可以将 MCP 转换为 CLI，让你两全其美而没有开销。

9、Codex 优于 Claude Code（有细微差别）

Steinberger 更喜欢用 Codex 进行构建。他的理由很具体：Codex 在决定修改什么之前会读取更多代码。你不需要那么多"做戏"来获得好的输出。

但这个比较有细微差别。他把 Opus 描述为一个有时有点傻但很有趣的同事，你会留着他们。Codex 是角落里安静古怪的人，你不想和他说话，但可靠且能完成任务。

Claude Code 更具交互性。如果你运行一两个会话，那很好。但 Steinberger 同时运行四到十个 agent。不那么交互的模型，消失 20 分钟后带着结果回来，更适合那个工作流。

他的底线："如果你是一个熟练的驾驶员，你可以用任何工具获得相当好的输出。"在评判任何新模型之前，给它一周时间。

10、情感的现实

当 Steinberger 谈到倦怠时，采访出人意料地坦诚。

他运营 PSPDFKit 13 年。倦怠不是来自工作太多。而是来自人的问题、与联合创始人的冲突、高压客户情况。当他最终卖掉公司离开后，他无法编程了。他坐在屏幕前，感到空虚。

"我就像 Austin Powers 被抽走了魔力一样。它消失了。"

他订了一张去马德里的单程票，停了下来。持续了三年。

他对那些追求"努力工作，提前退休"梦想的人的警告：不要。

"如果你早上醒来没有任何期待，没有真正的挑战，那会变得非常无聊，非常快。然后当你无聊的时候，你会去其他地方寻求刺激，那会把你引向一条非常黑暗的道路。"

恢复来自玩耍。只是摆弄 AI 工具。构建小东西，没有商业计划，没有增长策略，没有压力。为了构建而构建。技能和好奇心的复利最终产生了 OpenClaw。

11、哀悼手艺是可以的

Steinberger 承认了一些大多数 AI 布道者完全跳过的内容。

"今天早上我读到一篇文章，有人说哀悼我们的手艺是可以的。我内心的一部分对此非常认同。我花了很多时间修补，沉浸在心流中，大量产出代码，寻找真正优雅的解决方案。从某种意义上说，这很悲伤，因为那将会消失。"

他没有假装这种转变不伤人。但他也说心流状态并没有消失，只是改变了形态。与 agent 合作、深入思考架构、引导多个会话——这些都产生了自己版本的心流。

他说，我们所知道的编程会变得像 knitting。人们仍然会做，因为他们热爱它。不是因为这是最高效的构建方式。

原文链接: The Agentic Engineering Playbook

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