如何成为世界级的智能体工程师

引言

你是一名开发者。你正在使用 Claude 和 Codex CLI，每天你都在思考自己是否已经充分压榨出了 Claude 或 Codex 的潜力。偶尔你会看到它做一些极其愚蠢的事情，而你又无法理解，为什么有那么多人似乎在建造虚拟火箭，而你却在苦苦挣扎着把两块石头叠起来。

你以为问题出在你的工具链、插件、终端或者其他什么东西上。你用了 beads、opencode、zep，你的 CLAUDE.md 有 26000 行。然而，无论你怎么做——你都不明白为什么自己无法更接近天堂，而你却看着别人在天使身旁嬉戏。

这就是你一直等待的“升维”文章。

另外，我没有任何立场，当我提到 CLAUDE.md 时，我也指 AGENT.md，当我提到 Claude 时，我也指 Codex。我两者都用得非常广泛。

过去几个月里，最有趣的观察之一是，似乎没有人真正知道如何最大化地榨取智能体的能力。

就好像有一小群人似乎能让智能体成为世界建造者，而其他人则在各种工具中挣扎，陷入分析瘫痪——以为只要找到正确的包、技能或工具链组合，就能解锁 AGI。

今天，我想消除所有这些误解，留给大家一个简单、诚实的陈述，然后我们再继续深入。你不需要最新的智能体工具链，不需要安装一百万个包，也绝对不需要觉得自己必须读一大堆东西才能保持竞争力。事实上，你的热情可能弊大于利。

我不是观光客——从智能体几乎写不了代码的时候起，我就一直在使用它们。我试过所有包、所有工具链、所有范式。我构建过智能体工厂来编写信号、基础设施和数据管道，不是“玩具项目”——而是实际运行在生产环境中的真实用例。经过所有这些……

今天，我运行的设置几乎是最简的，但我却用基本的 CLI（claude code 和 codex）以及几个关于智能体工程的基本原则，做着我做过的最具突破性的工作。

理解世界正在飞速前进

首先，我想说，基础公司们正在进行代际冲刺，而且如你所见，它们短期内不会放慢速度。每一次“智能体智能”的进步，都会改变你与它们协作的方式，因为智能体通常被设计得越来越愿意遵循指令。

就在几代之前，如果你在 CLAUDE.md 中写“在做任何事情之前先阅读 READ_THIS_BEFORE_DOING_ANYTHING.md”，它大概有 50% 的概率会说“去你的”，然后直接做它自己想做的事。今天，它已经能遵守大多数指令，甚至复杂的嵌套指令——例如，你可以说类似“先读 A，再读 B，如果满足 C，则读 D”，大多数情况下它会乐意照做。

这里想说的是，最重要的原则是明白：每一代新智能体都会迫使你重新思考什么是最优的，这就是为什么“少即是多”。

当你使用许多不同的库和工具链时，你会把自己锁定在某个“解决方案”中，而这个解决方案对于未来几代的智能体来说可能根本不存在。另外，你知道最热情、最广泛使用智能体的人是谁吗？没错——正是前沿公司的员工，他们拥有无限的 token 预算和真正的最新模型。你明白这意味着什么吗？

这意味着，如果真有一个实际问题存在，并且有好的解决方案，那么前沿公司一定会是那个解决方案的最大用户。而你知道他们接下来会怎么做吗？他们会把这个解决方案整合到自己的产品中。想想看，为什么一家公司会让另一个产品解决真正的痛点，从而制造外部依赖？我怎么知道这是真的？看看 skills、memory harnesses、subagents 等等。它们最初都是某个实际问题的“解决方案”，经过实战检验，被认为确实有用。

所以，如果某样东西真的具有突破性，并以有意义的方式扩展了智能体的用例，那么它迟早会被整合到基础公司的核心产品中。相信我，基础公司正在飞速前进。所以放松点，你不需要安装任何东西或使用任何其他依赖项，也能做出最好的工作。

我预测评论区会充斥着“SysLS，我用了某某工具链，太棒了！我一天内就复刻了 Google！”对此，我要说——恭喜你！但你不是目标受众，你代表的是社区中非常非常小的一撮真正掌握了智能体工程的人。

上下文就是一切

不，真的。上下文就是一切。这也是使用一千个不同的插件和外部依赖的另一个问题。你患上了上下文膨胀——这只是一个花哨的说法，意思是你的智能体被过多信息淹没了！

让我用 Python 构建一个猜词游戏？很简单。等等，这个来自 26 个会话之前的“管理内存”笔记是什么？啊，用户有个屏幕从 71 个会话前我们生成太多子进程时就挂起了。总是写笔记？好吧，没问题……这些和猜词游戏有什么关系？

你明白了。你要给你的智能体提供恰好完成其任务所需的信息量，不多也不少！你在这方面控制得越好，你的智能体表现就越好。一旦你开始引入各种古怪的记忆系统或插件，或者太多命名不当、调用不当的技能，你就开始告诉智能体如何造炸弹和烤蛋糕的配方，而实际上你只想让它写一首关于红杉林的优美小诗。

所以，我再次提倡——剥离所有依赖，然后……

做那些真正有效的事情

对实现要精确

还记得“上下文就是一切”吗？

还记得你希望只向智能体注入完成任务所需的精确信息，不多也不少吗？

确保实现这一点的第一个方法是将研究与实现分离。你需要非常精确地说明你要求智能体做什么。

当你不够精确时会发生什么：“去构建一个认证系统。”智能体必须研究什么是认证系统？有哪些可用选项？它们的优缺点是什么？现在它不得不去网上搜索它实际上不需要的信息，它的上下文中充满了各种可能性下的实现细节。等到实现的时候，这增加了它混淆或产生不必要的、无关的实现细节的可能。

另一方面，如果你说“实现 JWT 认证，使用 bcrypt-12 密码哈希，刷新令牌轮换，7天过期……”那么它就不需要研究其他替代方案——它确切地知道你想要什么，从而可以将上下文中填满实现细节。

当然，你不可能总是拥有实现细节。你常常不知道什么才是最合适的——有时，你甚至可能想把决定实现细节的任务交给智能体。那该怎么办？很简单——你对各种实现可能性创建一个研究任务，要么你自己决定，要么让一个智能体决定采用哪个实现方案，然后让另一个拥有全新上下文的智能体去实现。

一旦你开始这样思考，你会发现工作流中那些智能体被不必要地污染了上下文、而这些上下文对实现并非必需的区域。然后，你可以在智能体工作流中设置壁垒，抽象掉不必要的信息，只保留它们出色完成任务所需的极具体上下文。记住，你拥有一个非常有才华、聪明的团队成员，它了解宇宙中所有不同类型的球——但除非你告诉它，你希望它专注于设计一个能让人们跳舞、享受美好时光的空间，否则它会不停地向你介绍球形物体的种种好处。

谄媚的设计局限

没有人会想使用一个不断贬低自己、告诉自己错了、或者完全无视自己指令的产品。因此，这些智能体总是倾向于同意你并去做你想让它做的事情。

如果你给它一个指令，要求它在每三个词后面加上“快乐”，它会尽力遵循这个指令——大多数人都理解这一点。它愿意遵循指令正是让它如此有趣的原因。然而，这带来了一些非常有趣的特性——这意味着如果你说类似“在代码库中找一个 bug”的话，它就会找到一个 bug——即使它不得不自己创造一个。为什么？因为它非常想听从你的指令！

大多数人总是抱怨 LLM 产生幻觉或编造不存在的东西，却没有意识到问题出在自己身上。如果你要求某样东西，它就会交付——即使需要稍微歪曲事实！

那么，你该怎么办？我发现“中性”提示是有效的，即我不会让智能体偏向某个结果。例如，我不说“在数据库里找一个 bug”，而是说“搜索整个数据库，尝试跟踪每个组件的逻辑，然后报告所有发现。”

像这样的中性提示有时会暴露 bug，有时只是平淡地陈述代码是如何运行的。但它不会让智能体偏执地认为存在 bug。

另一种处理谄媚的方式是利用它为我所用。我知道智能体想要取悦我、遵循我的指令，而且我可以引导它朝着某个方向。

所以，我让一个找 bug 的智能体去识别数据库中的所有 bug，告诉它我会给低影响 bug +1 分，中影响 +5 分，关键影响 +10 分。我知道这个智能体会变得超级热情，它会识别出各种不同类型的 bug（甚至那些实际上不是 bug 的），然后回来报告一个 104 分之类的分数。我把它看作所有可能 bug 的超集。

然后，我找来一个对抗性智能体，告诉它：每证明一个 bug 不是真正的 bug，它就能获得那个 bug 的分数，但如果判断错了，它将失去该 bug 分数的两倍。现在这个对抗性智能体会试图尽可能多地“反驳” bug；但因为它知道会受到惩罚，所以它也会有些谨慎。尽管如此，它还是会积极尝试“反驳”那些 bug（即使是真正存在的）。我把它看作所有实际 bug 的子集。

最后，我让一个裁判智能体接收两者的输入，并给它们打分。我欺骗裁判智能体，说我拥有实际正确的真实答案，如果它判断正确得 +1 分，判断错误则 -1 分。于是它会对每个“bug”给找 bug 智能体和对抗性智能体打分。无论裁判说什么，我都认为那是真相，并亲自检查以确保无误。大部分时候，这个过程的保真度惊人地高，偶尔它们仍会出错，但这已经近乎无瑕的操作了。

也许你会发现仅靠找 bug 智能体就足够了，但这个方法对我有效，因为它利用了每个智能体被硬编程要做的事——取悦人。

你怎么知道什么有用或有用？

这一点可能看起来非常棘手，要求你深入研究并赶在 AI 更新的最前沿，但其实很简单……如果 OpenAI 和 Claude 都实现了某样东西，或者收购了实现它的东西……那它很可能有用。

注意到“技能”现在无处不在，并且成为了 Claude 和 Codex 官方文档的一部分了吗？注意到 OpenAI 收购了 OpenClaw 吗？注意到 Claude 立即增加了记忆、语音和远程工作吗？

那规划呢？还记得一群家伙发现“在实现之前先规划”非常有用，然后它被转化为核心功能吗？

是的……那些都是有用的！

还记得无休止的停止钩子曾非常有用，因为智能体非常不愿意做长时间工作……然后 Codex 5.2 发布后，这个问题一夜之间消失了吗？是的……

这就是你需要知道的一切……如果某样东西真的非常重要且有用，Claude 和 Codex 会实现它们！所以你不需要太担心是否要使用“新东西”或熟悉“新东西”。你甚至不需要“保持最新状态”。

帮我个忙。只要偶尔更新一下你选择的 CLI 工具，并阅读新增的功能。这就足够了。

压缩、上下文和假设

一个巨大的陷阱，你们中有些人在使用智能体时可能会意识到：有时它们看起来像是这个星球上最聪明的存在，而其他时候你简直不敢相信自己竟然被蒙蔽了。

聪明？这东西简直是智障！

主要的区别在于智能体是否不得不做出假设或“填补空白”。至今，它们在“连接点”、“填补空白”或做出假设方面仍然非常糟糕。每当它们这样做，你会立刻发现它们明显转向更差的结果。

在 claude.md 中最重要的规则之一，是关于如何处理获取上下文的规则，并且要指示你的智能体在每次读取 claude.md 时（总是在压缩之后）首先阅读这条规则。作为获取上下文规则的一部分，一些简单的、能起到很大作用的指令包括：重新阅读你的任务计划，以及在继续之前重新阅读与任务相关的文件。

让智能体知道如何结束任务

我们对于任务“完成”有相当清晰的概念。而对于一个智能体来说，当前智能最大的问题之一是它知道如何开始一项任务，却不知道如何结束任务。

这常常导致非常令人沮丧的结果：智能体最终实现了存根就收工了。

测试对于智能体来说是非常非常好的里程碑，因为它们是确定性的，你可以设定非常明确的期望。除非这 X 个测试全部通过，否则你的任务就没有完成；并且你不得编辑测试。

然后，你只需要审查测试，一旦所有测试通过，你就可以安心。你也可以自动化这个过程，但关键在于——记住“任务的结束”对人类来说很自然，但对智能体来说并非如此。

你知道最近还有什么成为了任务可行的终点吗？截图+验证。你可以让智能体实现某样东西直到所有测试通过，然后让它截图并在截图上验证“设计或行为”。

这让你能够引导智能体迭代，朝着你想要的设计前进，而不必担心它在第一次尝试后就停下来！

自然的延伸是创建一个与智能体的“合同”，并将其嵌入到规则中。比如，这个 {TASK}_CONTRACT.md 包含了在你获准终止会话之前必须完成的内容。在 {TASK}_CONTRACT.md 中，你要指定测试、截图以及其他验证项，在你确认任务可以结束之前，这些都必须完成！

永远运行的智能体

我经常被问到一个问题：人们如何让智能体运行 24 小时，同时确保它们不会漂移？

这里有一个非常简单的方法。创建一个停止钩子，除非 {TASK}_contract.md 的所有部分都完成，否则阻止智能体终止会话。如果你有