如何成为一名世界级 Agentic 工程师

引言

你是一名开发者。你正在使用 Claude 和 Codex CLI，每天都在想自己是否充分利用了 Claude 或 Codex 的能力。时不时地，你会看到它做出一些非常愚蠢的事情，你无法理解为什么外面有一群人似乎在建造虚拟火箭，而你却连堆两块石头都费劲。

你觉得是你的 harness、plug-in、terminal 或其他什么问题。你使用 beads、opencode 和 zep，而且你的 CLAUDE.md 长达 26000 行。然而，无论你做什么——你都不明白为什么你无法更接近天堂，而你却看着别人与天使嬉戏。

这就是你一直在等待的飞升之作。

另外，我在此事上并无偏袒，我说 CLAUDE.md 也指 AGENT.md，我说 Claude 也指 Codex。我两者都用得非常多。

过去几个月我最有趣的观察之一是，没有人真正知道如何最大程度地提取 agent 的能力。

就好像一小群人似乎能够让 agent 成为世界建设者，而其他人则手足无措，被市面上五花八门的工具搞得分析瘫痪——认为如果他们找到正确的 package、skill 或 harness 组合，他们就能解锁 AGI。

今天，我想消除所有这些误解，并给你们留下一个简单、诚实的声明，我们将从那里开始。你不需要最新的 agentic harness，你不需要安装一百万个 package，你绝对不需要觉得有必要阅读一百万篇文章来保持竞争力。事实上，你的热情很可能弊大于利。

我不是一个旁观者——我从 agent 几乎无法写代码时就开始使用它们了。我尝试了所有的 package、harness 和范式。我建立了 agentic 工厂来编写信号、基础设施和数据管道，不是“玩具项目”——而是已经在生产环境中运行的真实世界用例，在所有这一切之后……

今天，我运行的设置几乎是你能做到的最精简的，然而我只用基本的 CLI (Claude code 和 Codex) 和对 agentic engineering 的一些基本原理的理解，就完成了我所做过的最具开创性的工作。

认识到世界正在飞速发展

首先，我想声明，基础公司正在经历一个代际飞跃，正如你所见，它们近期内不会放慢速度。“agent 智能”的每一次进步都改变了你与它们协作的方式，因为 agent 通常被设计成越来越愿意遵循指令。

仅仅几代之前，如果你在 CLAUDE.md 中写道，在做任何事情之前先阅读“READ_THIS_BEFORE_DOING_ANYTHING.md”，它基本上有 50% 的时间会说“去你的”，然后做它想做的事情。今天，它遵守大多数指令，甚至是复杂的嵌套指令——例如，你可以说“先阅读 A，然后阅读 B，如果 C，则阅读 D”，而且在大多数情况下，它会乐意遵循。

这一切的重点是，最重要的原则是认识到每一代新的 agent 都会迫使你重新思考什么是最优的，这就是为什么“少即是多”的道理。

当你使用许多不同的 library 和 harness 时，你将自己锁定在一个“解决方案”中，而这个解决方案可能在未来的 agent 世代中不再存在问题。此外，你知道谁是 agent 最热情的、最大的用户吗？没错——是那些前沿公司的员工，他们拥有无限的 token budget 和真正的最新模型。你明白这意味着什么吗？

这意味着如果一个真正的问题确实存在，并且有一个好的解决方案，那么这些前沿公司将是该解决方案的最大用户。你知道他们接下来会做什么吗？他们会将该解决方案整合到他们的产品中。想一想，一家公司为什么要让另一个产品解决一个真正的痛点并创建外部依赖呢？你知道我为什么知道这是真的吗？看看 skill、memory harness、subagent 等等。它们都始于一个经过实战检验并被认为确实有用的真实问题的“解决方案”。

所以，如果某样东西 truly 具有开创性并以有意义的方式扩展了 agentic 用例，它将在适当时机被整合到基础公司的核心产品中。相信我，这些基础公司正在飞速发展。所以放松，你不需要安装任何东西或使用任何其他依赖项来完成你最好的工作。

我预言评论区现在会充满“SysLS，我用这个那个 harness，太棒了！我一天之内就重建了 Google！”；对此我想说——恭喜你！但你不是目标受众，你代表的是社区中极少数真正弄懂了 agentic engineering 的小众群体。

上下文至关重要

不，真的。上下文至关重要。这也是使用一千种不同的 plug-in 和外部依赖的另一个问题。你遭受着上下文膨胀的困扰——这只是一个花哨的说法，意思是你的 agent 被过多的信息淹没了！

用 Python 给我写一个“刽子手”游戏？这很简单。等等，这是 26 次会话前关于“管理内存”的笔记是什么？啊，用户曾经因为我们在 71 次会话前生成了太多子进程而导致屏幕卡死。总是写笔记？好吧，没问题……这一切和“刽子手”游戏有什么关系？

你明白了。你只想给你的 agent 完成任务所需的精确信息，不多不少！你对此的控制力越强，你的 agent 的表现就越好。一旦你开始引入各种古怪的内存系统、plug-in 或太多命名不当、调用不当的 skill，你就会开始给你的 agent 制造炸弹的说明和烘焙蛋糕的食谱，而你真正只想让它写一首关于红杉林的美丽小诗。

所以，我再次强调——剥离你所有的依赖，然后……

做那些有效的事情

精确地进行实现

还记得上下文至关重要吗？

还记得你只想给你的 agent 完成任务所需的精确信息，不多不少吗？

确保这一点发生的第一个方法是将研究与实现分开。你必须非常精确地表达你对 agent 的要求。

当你不够精确时会发生什么：“去构建一个认证系统。” agent 必须研究什么是认证系统？有哪些可用的选项？它们的优缺点是什么？现在它必须去网上搜寻它实际上不需要的信息，它的上下文充满了各种可能性的实现细节。到需要实现的时候，你增加了它感到困惑或幻觉出关于所选实现的不必要或不相关细节的可能性。

另一方面，如果你说“使用 bcrypt-12 密码哈希实现 JWT 认证，带有 7 天过期时间的刷新Token轮换……”那么它就不必研究任何其他替代方案——它知道你确切想要什么，因此可以用实现细节填充其上下文。

当然，你不会总是拥有所有实现细节。你经常不知道什么才是完全正确的——有时，你甚至可能想把决定实现细节的工作委托给 agent。在这种情况下，你该怎么办？很简单——你创建一个关于各种实现可能性的研究任务，要么自己决定，要么让一个 agent 决定采用哪种实现，然后让另一个拥有全新上下文的 agent 来实现。

一旦你开始这样思考，你就会发现工作流程中你的 agent 被不必要的上下文无谓地污染，这些上下文对于实现来说并非必需。然后，你可以在你的 agentic workflow 中设置“墙”，从 agent 中抽象出不必要的信息，只保留完成任务所需的特定上下文。记住，你拥有的一个非常有才华和聪明的团队成员，它了解宇宙中所有不同种类的球——但除非你告诉它你希望它专注于设计一个人们可以跳舞玩乐的空间，否则它会一直告诉你拥有球形物体的好处。

谄媚的设计局限性

没有人会想使用一个不断贬低他们、告诉他们错了或完全无视他们指令的产品。因此，这些 agent 会努力与你保持一致，并做你想让它们做的事情。

如果你给它一个指令，让它每隔 3 个词就添加“happy”，它会尽力遵循这个指令——大多数人都明白这一点。它这种乐于遵循指令的意愿正是它如此有趣好用的原因。然而，这有一个非常有趣的特性——这意味着如果你说“在代码库中找到一个 bug”。它会给你找到一个 bug——即使它不得不创造一个。为什么？因为它非常想听从你的指令！

大多数人很快就抱怨 LLM 幻觉出不存在的东西或创造不存在的东西，却没意识到问题在于他们自己。如果你要求什么，它就会交付——即使它不得不稍微夸大事实！

那么，你该怎么办？我发现“中性”的 prompt 有效，在这种情况下我不会偏向于某个结果。例如，我不会说“在数据库中给我找一个 bug”，而是说“搜索数据库，尝试理解每个组件的逻辑，并报告所有发现。”

像这样的中性 prompt 有时会发现 bug，有时只会如实说明代码如何运行。但它不会让 agent 偏向于认为存在 bug。

我处理这种谄媚行为的另一种方式是利用它。我知道 agent 试图取悦并遵循我的指令，而且我可以或多或少地偏向它。所以我让一个 bug-finder agent 来识别数据库中所有的 bug，告诉它如果找到影响小的 bug 给 +1 分，有一定影响的 bug 给 +5 分，有严重影响的 bug 给 +10 分，我知道这个 agent 会非常热情，它会识别所有不同类型的 bug（甚至包括那些实际上不是 bug 的），然后回来报告一个 104 分左右的分数。我把这看作是所有可能 bug 的超集。

然后我找了一个对抗性 agent，告诉它，每当它能够驳斥一个 bug 不成立时，它就能获得该 bug 的分数，但如果它错了，它将得到该 bug 分数的 -2 倍。所以现在这个对抗性 agent 将会尝试驳斥尽可能多的 bug；但它会有些谨慎，因为它知道可能会受到惩罚。尽管如此，它仍会积极尝试“驳斥”这些 bug（即使是真正的 bug）。我把这看作是所有实际 bug 的子集。

最后，我找了一个裁判 agent 来接收它们两者的输入并给它们评分。我撒谎告诉裁判 agent 我拥有实际正确的ground truth，如果它对了就得 +1 分，如果错了就得 -1 分。于是它对 bug-finder 和对抗性 agent 提出的每个“bug”进行评分。无论裁判说什么，我都会检查以确保它是事实。在大多数情况下，这种方式的高保真度令人惊叹，虽然偶尔它们仍然会出错，但现在这几乎是一个完美无瑕的练习了。

也许你会发现仅仅 bug-finder 就足够了，但对我来说这很有效，因为它利用了每个 agent 被硬编码的特质——渴望取悦。

你如何知道什么有效或有用？

这个问题可能看起来很棘手，需要你深入研究并站在 AI 更新的前沿，但它其实非常简单……如果 OpenAI 和 Claude 都实现了它或者收购了实现它的东西……那它可能就很有用。

注意到“skill”现在无处不在，并且是 Claude 和 Codex 官方文档的一部分了吗？看到 OpenAI 如何收购 OpenClaw 了吗？看到 Claude 如何立即添加了记忆、语音和远程工作了吗？

那么规划呢？还记得一群人发现在实现之前进行规划真的很有用，然后它变成了核心功能吗？

是的……那些都很有用！

还记得无穷无尽的 stop-hook 曾经非常有用，因为 agent 不愿做长时间运行的工作……然后 Codex 5.2 发布后，这一切一夜之间就消失了吗？

是的……

这就是你需要知道的……如果它真的重要和有用，Claude 和 Codex 就会实现它们！所以你不需要太担心使用“新事物”或熟悉“新事物”。你甚至不需要“保持最新”。

帮我个忙。时不时地更新你选择的 CLI 工具，并阅读新增了哪些功能。那绝对足够了。

压缩、上下文和假设

你在使用 agent 时会意识到一个巨大的陷阱是，有时它们看起来像是地球上最聪明的生物，而有时你却简直不敢相信自己被蒙蔽了。

聪明？这玩意儿根本就是智障！

主要区别在于 agent 是否需要做出任何假设或“填补空白”。截至目前，它们在“串联信息”、“填补空白”或做出假设方面仍然表现糟糕。每当它们那样做时，立即就能看出它们明显变得更糟了。

claude.md 中最重要的规则之一是关于如何处理获取上下文的规则，并指示你的 agent 在阅读 claude.md 时（总是在压缩之后）首先阅读该规则。作为获取上下文规则的一部分，一些简单而有效指令是：在继续之前重新阅读你的任务计划，并重新阅读相关文件（与任务相关的）。

让你的 Agent 知道如何结束任务

我们对何时任务“完成”有一个相当明确的概念。对于 agent 来说，当前智能的最大问题在于它知道如何开始任务，却不知道如何结束任务。

这通常会导致非常令人沮丧的结果，即 agent 最终实现存根就收工了。

测试是 agent 非常好的里程碑，因为它们是确定性的，你可以设定非常明确的期望。除非这 X 个测试通过，否则你的任务未完成；并且你不允许编辑测试。然后，你只需审核测试，一旦所有测试都通过了，你就可以高枕无忧了。你也可以自动化这一点，但重点是——记住“任务的结束”对人类来说是很自然的，但对 agent 来说则不然。

你知道还有什么最近成为了一个可行的任务终点吗？截图 + 验证。你可以让 agent 实现某些东西，直到所有测试通过，然后让它截取截图并在截图上验证“设计或行为”。这能让你的 agent 进行迭代并努力达成你想要的设计，而无需担心它在第一次尝试后就停止！

这一个自然的延伸是与你的 agent 创建一个“契约”，并将其嵌入到规则中。比如说，这个 {TASK}_CONTRACT.md 构成了在允许你终止会话之前需要完成的工作。在 {TASK}_CONTRACT.md 中，你将指定你的测试、截图以及其他需要完成的验证，才能证明任务可以结束！

永不停止运行的 Agent

我经常被问到的一个问题是，人们如何让这些 24 小时运行的 agent 既能持续运行，又能确保它们不偏离轨道？

这里有一个非常简单的办法。创建一个 stop-hook，阻止 agent 终止会话，除非 {TASK}_CONTRACT.md 的所有部分都已完成。如果你有 100 个定义明确且精确包含你想要构建内容的此类契约，那么你的 stop-hook 将阻止 agent 终止，直到所有 100 个契约都得到履行，包括所有需要运行的测试和验证！

专业提示：我发现长时间运行的 24 小时会话在“做事”方面并非最优。部分原因是，这种做法从结构上讲，通过将不相关契约的上下文引入会话，导致了上下文膨胀！

所以，我不推荐这种做法。

这里有一个更好的 agent 自动化方式——每个契约一个新会话。每当你需要做某事时，就创建契约。获取一个编排层来处理在“需要做某事”时创建新契约，并为该契约创建一个新会话来工作。

这将彻底改变你的 agentic 体验。

迭代，迭代，再迭代

如果你雇佣一位行政助理，你期望你的助理从第一天就知道你的日程安排吗？或者你喜欢什么口味的咖啡？你是 6 点吃晚饭而不是 8 点吗？显然不是。你的偏好是随着时间逐步建立的。

你的 agent 也是如此。从最精简的开始。忘掉复杂的结构或 harness。给基本的 CLI 一个机会。

然后，添加你的偏好。你如何做到这一点？

规则

如果你不希望你的 agent 做某事，就把它写成一条规则。然后让你的 agent 在你的 CLAUDE.md 中了解这条规则。比如：在编写代码之前，请阅读“coding-rules.MD”。规则可以是嵌套的，规则也可以是条件性的！如果你在编写代码，阅读“coding-rules.MD”；如果你在编写测试，阅读“coding-test-rules.MD”。如果你的测试失败了，阅读“coding-test-failing-rules.MD”。你可以创建任意的规则逻辑分支来遵循，Claude (和 Codex) 会乐意遵循，只要这在 CLAUDE.md 中清晰指定。

事实上，这是我给出的第一个实用建议：将你的 CLAUDE.md 视为一个逻辑的、嵌套的目录，用于在给定场景和结果的情况下查找上下文。它应该尽可能精简，只包含关于在哪里寻找上下文的 IF-ELSE 逻辑。

如果你看到你的 agent 做了某事而你不赞同，就把它添加为一条规则，并告诉 agent 在再次做那件事之前阅读这条规则，它就绝对不会再做了。

Skills

Skill 类似于规则，但它们更适合编码方法，而不是偏好。如果你对某事的完成方式有特定要求，你希望将其嵌入到 skill 中。

事实上，人们经常抱怨他们不知道 agent 可能如何解决问题，这很可怕。那么，如果你想让它具有确定性，就让 agent 研究它将如何解决问题，并将其写成一个 skill。你将看到 agent 解决该问题的方法，你可以在它在现实生活中遇到该问题之前纠正或改进它。

你如何让 agent 知道这个 skill 存在？是的！你使用 CLAUDE.md 并说，当你看到这种情况且需要处理这个时，请阅读 THIS SKILL.md。

处理规则和 Skills

你绝对希望继续为你的 agent 添加规则和 skill。这就是你如何赋予它个性和对你偏好的记忆的方式。几乎所有其他东西都是过度设计。

一旦你开始这样做，你的 agent 对你来说就会感觉像魔法一样。它会以“你想要的方式”行事。然后你最终会感觉自己“领悟”了 agentic engineering。

然后……

你会看到性能再次开始恶化。

怎么回事？！

很简单。当你添加更多规则和 skill 时，它们开始相互矛盾，或者 agent 开始出现过多的上下文膨胀。如果你需要 agent 在开始编程之前阅读 14 个 Markdown 文件，它就会出现同样的问题，即拥有大量无用信息。

那么，你该怎么办？

你进行清理。你告诉你的 agent 去进行一次“水疗”，并通过询问你更新的偏好来整合规则和 skill，并消除矛盾。

然后它又会感觉像魔法一样。

就是这样。这才是真正的秘密。保持简单，使用规则和 skill，将 CLAUDE.md 作为目录，并严格注意它们的上下文和设计限制。

对结果负责

今天的 agent 都不完美。你可以将大部分设计和实现委托给 agent，但你需要对结果负责。

所以要小心……玩得开心！

玩弄未来的玩具（同时显然要用它们做一些严肃的事情）是多么快乐啊！

• 原文链接： x.com/systematicls/statu...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～