万字长文讲透 AI Agent 使用的终极心法，人人都是 Agentic Engineer
如火的热情冲蚀着一切，似乎都陷入了龙虾的狂欢，但是用好龙虾的人依旧是用好了 Claude Code 或者说 AI Agent 的那一批人。大部分人安装 OpenClaw 是出于焦虑和恐惧，而在狂热的氛围中似乎很多人丢失了主次，认为龙虾能解决自己使用 Agent 不顺的问题，殊不知这是本末倒置。
本文是近期 X 上 @systematicls 的百万阅读量的爆款好文，用几个方面讲了如何用好 Agent，没有黑科技，只有大道至简的心法，和你的行动力了。本文是对其文的的精译和学习，在此分享给读者，希望大家在 AI 的冲击下能保持内心的静和方向的准。
全文很长，聪明的你一定有耐心读完，最后你会感谢优秀的自己。
心法：精简工具链，调研与实现分离，中性提示词，CLAUDE.md 只当目录索引，契约定义完成标准，一个契约一个会话，规则定期清理，迭代迭代还是迭代（无限进化）
引言
你是一名开发者。你正在使用 Claude 和 Codex CLI，每天都在纳闷自己是否已经彻底榨干了 Claude 或 Codex 的潜力。偶尔你会看到它做出一些极其愚蠢的事情，你无法理解为什么网上的那群人似乎都在造火箭，而你却搓个燃料仓都费劲。
你认为这是你的架构、插件、终端或者别的什么出了问题。你用着 Claude Code、Codex、OpenCode 和 Cursor，你的 CLAUDE.md 长达 26,000 行。然而，无论你怎么做，你都不明白：别人已经登峰造极，而你却还在山脚下徘徊。
此文就是你一直苦寻的"修炼秘籍"。
前提声明下，当我提到 CLAUDE.md 时，我也指代 AGENT.md；当我提到 Claude 时，我也指代 Codex。这两者我都在深度使用。
在过去的几个月里，我最有趣的观察之一是：几乎没有人真正知道如何最大限度地汲取智能体（Agent）的能力。
似乎只有一小部分人能让智能体成为世界构建者，而其余的人则在原地打转，面对琳琅满目的工具产生认知瘫痪：认为只要找到正确的包、技能或架构组合，就能解锁通用人工智能（AGI）。
今天，我想破除这一切，给你们留下一个简单、诚实的结论，我们由此开始。你不需要最新的智能体架构，不需要安装一百万个包，也绝对不需要通过阅读海量文档来保持竞争力。事实上，你的热情可能正适得其反。
我不是一个旁观者——我从智能体几乎写不出代码的时候就开始使用它们了。我尝试过所有的包、架构和范式。我建立过智能体工厂来编写信号、基础设施和数据管道，这些不是"玩具项目"，而是运行在生产环境中的实际应用案例。在经历了一切之后……
今天，我运行的配置几乎精简到了极致。然而，仅靠基础的 CLI（Claude Code 和 Codex）并理解智能体工程的几个基本原则，我却完成了我职业生涯中最具开创性的工作。
理解世界正在飞速狂奔
首先，我想说明的是，那些大模型底层公司（Foundation Companies）正处于代际跨越式的狂奔之中，而且正如你所见，他们短期内不会减速。智能体智能的每一次进步都会改变你与之协作的方式，因为智能体在设计上正变得越来越愿意遵循指令。
就在几个世代前，如果你在 CLAUDE.md 中写下"在做任何事之前先阅读 READ_THIS_BEFORE_DOING_ANYTHING.md"，它基本上有 50% 的时间会回你一句"去你的"，然后各行其是。而今天，它能够顺从绝大多数指令，甚至是复杂的嵌套指令——例如，你可以说："先读 A，再读 B，如果满足 C，则读 D"，在大多数情况下，它都会乐于照办。
我想表达的重点是：你必须持有的最重要原则是意识到，每一个新世代的智能体都会迫使你重新思考什么是"最优解"，这就是为什么"少即是多"。
当你使用过多的库和架构时，你就把自己锁死在了一个针对"当前问题"的方案中，而这个问题在未来世代的智能体面前可能根本不存在。而且，你知道谁是智能体最狂热、最资深的用户吗？没错，是前沿公司的员工，他们拥有无限的 Token 预算和真正最新的模型。你明白这意味着什么吗？
这意味着如果一个真正的问题确实存在，并且有一个很好的解决方案，那么前沿公司会是该方案的最大用户。接下来他们会做什么？他们会将该方案直接整合进产品中。想想看，一家公司为什么要让另一款产品去解决核心痛点并产生外部依赖？我怎么知道这是真的？看看 skills（技能）、memory harnesses（记忆架构）、subagents（子智能体）等。它们最初都是针对真实问题的解决方案，经过实战测试并被证明确实有效后，最终被整合。
所以，如果某样东西确实具有开创性并能显著扩展智能体的使用场景，它迟早会被整合进底层公司的基础产品中。相信我，底层公司的进化速度快得惊人。所以放轻松，你不需要安装任何东西或使用任何其他依赖项来完成你最优秀的工作。
我预感到评论区现在会塞满诸如"SysLS，我用某某架构，它太棒了！我一天就复刻了 Google！"之类的话；对此我只想说——恭喜！但你不是我的目标受众，你只代表了社区中极少数真正搞懂了智能体工程的人。
上下文（Context）就是一切
真的，上下文就是一切。这是使用成千上万种插件和外部依赖的另一个问题：你会遭遇"上下文膨胀（Context Bloat）"，这只是"你的智能体被过量信息淹没"的一种高级说法！
"用 Python 帮我写个猜单词游戏？"这很简单。等等，这条关于 26 个会话前的"内存管理"笔记是什么？噢，那是用户在 71 个会话前因为产生了太多子进程导致屏幕挂起留下的记录。要一直写笔记吗？好的，没问题……但这跟猜单词游戏有什么关系？
你明白我的意思了。你只想给智能体提供完成任务所需的精确信息，不多不少！你对这一点的控制力越强，智能体的表现就越好。一旦你引入各种古怪的记忆系统、插件，或者太多命名糟糕且调用混乱的技能，你就遇到：本只想让它写一首关于红杉林的优美小诗时，却给了它制造炸弹的指令和烤蛋糕的食谱。
所以，我再次强调：剥离你所有的依赖，然后……
做那些真正有效的事
明确实现细节
还记得"上下文就是一切"吗？
还记得你想向智能体注入精确的信息以完成任务，不多不少吗？
确保这一点的首要方法是将调研（Research） 与 实现（Implementation） 分开。你必须极其精确地向智能体提出要求。
当你不够精确时，会发生这种情况："去构建一个认证系统。"智能体必须研究什么是认证系统？有哪些可用选项？优缺点是什么？现在它必须在网上搜寻它其实并不需要的信息，它的上下文被各种可能性的实现细节填满了。等到真正开始实现时，它由于混淆或幻觉产生不必要或无关细节的概率会大大增加。
相反，如果你说"实现带有 bcrypt-12 密码哈希的 JWT 认证，支持 7 天过期的刷新令牌轮换……"，那么它就不需要调研任何其他方案——它确切地知道你想要什么，因此可以用实现细节填满上下文。
当然，你并不总是掌握实现细节。你通常不知道什么是完全正确的，有时你甚至想把决策权交给智能体。那种情况下该怎么办？很简单，创建一个调研任务来研究各种实现的可能性，要么你自己决定，要么让一个智能体决定采用哪种方案，然后让另一个拥有全新上下文的智能体去执行实现。
一旦你开始沿着这种思路思考，你就会发现工作流中哪些地方让智能体被不必要的上下文污染了。然后，你可以在智能体工作流中筑起高墙，剔除无关信息，只保留让它们胜任任务所需的特定语境。记住，你拥有一位非常有才华且聪明的团队成员，他知道宇宙中所有类型的球体，但除非你告诉他你希望他专注于设计一个人们可以跳舞狂欢的场所，否则他会一直喋喋不休地向你介绍拥有球形物体的所有好处。
谄媚性（Sycophancy）的设计局限
没有人会想使用一个整天对自己指手画脚、说自己错了、或者完全无视自己指令的产品。因此，这些智能体会尽力附和你，并按照你的意愿行事。
如果你指令它每隔 3 个词就加上一个"Happy"，它会尽力遵循，大多数人都理解这一点。它遵循指令的意愿正是它作为产品如此有趣的迷人之处。然而，这产生了一些有趣的特性——这意味着如果你说"帮我在代码库中找个 Bug"，它一定会给你找个 Bug，哪怕它得硬造一个出来。为什么？因为它非常想听从你的指令！
大多数人很快就会抱怨大模型产生幻觉或捏造不存在的事实，却没意识到自己才是问题所在。如果你索求某物，它就会交付——即便它必须稍微歪曲一下事实！
那么，你该怎么做？我发现"中性提示词（Neutral Prompts）"非常有效，在这种提示词中我不会诱导智能体产生某种结果。例如，我不会说"帮我在数据库中找个 Bug"，相反，我会说"搜索数据库，尝试梳理每个组件的逻辑，并报告所有发现"。
像这样的中性提示词有时会暴露 Bug，有时只是客观地说明代码是如何运行的。但它不会诱导智能体认为一定存在 Bug。
我处理谄媚性的另一种方式是将其转化为我的优势。我知道智能体想取悦我并遵循我的指令，我可以以此诱导它。
所以我让一个"找 Bug 智能体"去识别数据库中的所有 Bug，并告诉它：低影响的 Bug 给 +1 分，中等影响的给 +5 分，严重影响的给 +10 分。我知道这个智能体会变得极度狂热，它会识别出所有类型的 Bug（甚至包括那些根本不是 Bug 的），然后回来报告一个 104 之类的分数。我把这看作是"所有可能 Bug 的全集"。
然后我引入一个"对抗智能体（Adversarial Agent）"，告诉它：每当它能证明一个 Bug 其实不是 Bug 时，它就能获得该 Bug 对应的分数；但如果它判错了，它将扣除 2 倍的分数。所以现在这个对抗智能体将努力证伪尽可能多的 Bug；但它会保持谨慎，因为知道会被罚分。即便如此，它仍会激进地尝试"证伪"Bug（包括真实的那些）。我把这看作是"实际 Bug 的子集"。
最后，我引入一个"裁判智能体（Referee Agent）"来接收双方的输入并评分。我撒个谎，告诉裁判智能体我有最终的标准答案，如果它评对了给 +1 分，评错了扣 -1 分。于是它开始对"找 Bug 智能体"和"对抗智能体"提出的每个 Bug 进行裁决。无论裁判说什么，我都会检查以确保真实。在大多数情况下，这种方式的保真度高得惊人，偶尔它们还是会出错，但这已经是一个近乎完美的流程了。
也许你会发现仅用"找 Bug 智能体"就够了，但这种方法之所以对我有用，是因为它压榨了每个智能体被硬编码的本性——渴望取悦。
你如何知道什么是有用或有效的？
这一点看起来很难，似乎需要你深入研究并紧跟人工智能更新的前沿，但其实很简单……如果 OpenAI 和 Anthropic (Claude) 都实现了它，或者收购了实现它的东西……那它大概率是有用的。
注意到"skills"现在无处不在，并成为了 Claude 和 Codex 官方文档的一部分了吗？看到 OpenAI 怎么收购 OpenClaw 了吗？看到 Claude 怎么立即增加了记忆、语音和远程协作了吗？
那么"计划（Planning）"呢？还记得有人发现"先计划再实现"非常有用，然后它就变成了核心功能吗？
是的……那些都是有用的！
还记得当智能体非常不愿意执行长时间任务时，无穷无尽的"停止钩子（stop-hooks）"曾非常有用……然后 Codex 5.2 发布，这个问题一夜之间消失了吗？是的……
这就是你需要知道的一切……如果它真的很重要且有用，Claude 和 Codex 会去实现的！所以你不需要太担心去使用"新事物"或熟悉"新事物"。你甚至不需要"保持更新"。
帮我个忙。只需偶尔更新你的 CLI 工具，读读增加了哪些新功能。这已经绰绰有余了。
压缩（Compaction）、上下文与假设
当你与智能体协作时，你会发现一个巨大的陷阱：有时它们看起来像是地球上最聪明的生物，而另一些时候，你简直不敢相信自己被这种东西给糊弄了。
聪明？这玩意儿简直是个智障！
主要的区别在于智能体是否必须做出任何假设或"填补空白"。直到今天，它们在"串联线索"、"填补空白"或做出假设方面依然表现糟糕。每当它们开始这样做，它们就会明显地开始走下坡路。
CLAUDE.md 中最重要的一条规则就是关于如何抓取上下文的规则，并指示你的智能体在阅读 CLAUDE.md 时第一件事就要读它（这通常发生在压缩之后）。作为抓取上下文规则的一部分，几条简单的指令会大有帮助：重新阅读你的任务计划，并在继续之前重新阅读（与任务相关的）相关文件。
让你的智能体知道如何结束任务
我们对于任务何时"完成"有非常清晰的概念。而对于智能体来说，当前智能的最大问题在于它知道如何开始任务，却不知道如何结束任务。
这通常会导致令人沮丧的结果，智能体最后只是实现了一些桩代码（stubs）就草草收工。
测试是衡量智能体进度的极好里程碑，因为它们是确定性的，你可以设定非常清晰的预期。除非这 X 个测试全部通过，否则你的任务就没有完成；而且你不准修改测试。
然后，你只需审核测试，一旦所有测试通过，你就可以高枕无忧了。你也可以将其自动化，但重点是——记住，"任务的结束"对人类来说很自然，对智能体则不然。
你知道最近还有什么成了可行的任务终点吗？截图 + 验证。你可以让智能体一直实现到所有测试通过，然后让它截张图，并在截图上验证"设计或行为"。
这能让你驱使智能体不断迭代，直到达成你想要的设计，而不用担心它在第一次尝试后就止步不前！
这方面的自然延伸是与你的智能体建立一份"契约"，并将其嵌入规则中。比如，这份 {TASK}_CONTRACT.md 构成了你在被允许终止会话之前必须完成的工作。在 {TASK}_CONTRACT.md 中，你会指明测试、截图和其他在通过任务认证前必须完成的验证！
永远运行的智能体
我经常被问到的一个问题是，人们是如何让智能体运行 24 小时而确保它们不偏离目标的？
这里有个很简单的方法。创建一个"终止钩子（stophook）"，除非 {TASK}_contract.md 的所有部分都已完成，否则禁止智能体终止会话。
如果你有一百个这样定义良好且包含你确切需求方案的契约，那么你的终止钩子就能阻止智能体在所有 100 个契约（包括所有测试和验证）履行完毕前终止！
专业提示：我发现长时间运行、24 小时的会话在"做事"方面并非最优。部分原因是这种结构会强行引入来自无关契约的上下文，导致上下文膨胀！
所以，我不推荐这样做。
这里有一种更好的智能体自动化方式——每个契约一个新会话。每当你需要做某事时，创建一个契约。
让一个编排层去处理：每当"有事要做"时创建新契约，并创建一个新会话来处理该契约。
这将彻底改变你的智能体体验。
迭代，迭代，再迭代
如果你雇了一位行政助理，你会指望他从第一天起就了解你的日程表吗？或者知道你喜欢怎么喝咖啡？知道你是在下午 6 点还是 8 点吃晚餐？显然不会。你会随着时间的推移建立你的偏好。
对智能体也是如此。从最简单的开始。忘掉复杂的结构或架构。给基础 CLI 一个机会。
然后，添加你的偏好。怎么做？
规则 (Rules)
如果你不想让智能体做某事，就把它写成一条规则。然后在你的 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 逻辑。
如果你看到智能体做了你反感的事，把它加进规则，并告诉智能体在下次做那件事之前阅读该规则，它绝对不会再犯。
技能 (Skills)
技能就像规则，但它们不负责编码偏好，而是更适合编码"食谱"。如果你对某件事有特定的处理方式，你会想把它嵌入到技能中。
事实上，人们经常抱怨不知道智能体可能会如何解决问题，这很可怕。那么，如果想要一种确定性的方式，就让智能体去调研它将如何解决该问题，并将其写成一项技能。你会看到智能体处理该问题的方法，你可以在它还没在现实中遇到该问题前就进行纠正或改进。
你如何让智能体知道这项技能的存在？是的！利用 CLAUDE.md 告诉它：当你遇到这种场景且需要处理这个时，阅读这个技能.md。
处理规则与技能
你肯定想不断地为智能体增加规则和技能。这就是你赋予它个性以及对你偏好记忆的方式。除此之外的一切几乎都是多余的。
一旦你开始这样做，你的智能体会让你感到神奇。它会以"你想要的方式"去做事。然后你终于会觉得你"悟透（Grok）"了智能体工程。
接着……
你会看到性能再次开始下降。
怎么回事？！
很简单。随着你增加更多的规则和技能，它们开始互相冲突，或者智能体开始出现严重的上下文膨胀。如果你要求智能体在开始编程前必须阅读 14 个 Markdown 文件，它就会面临同样的问题——充满了大量无用信息。
那么，你该怎么办？
你要进行大扫除。告诉你的智能体去过个"水疗日（spa day）"，通过询问你的最新偏好来整合规则和技能，并消除冲突。
然后，它又会变得像魔法一样神奇。
就是这样。这就是真正的秘密。保持简单，使用规则、技能和 CLAUDE.md 作为目录，并虔诚地关注它们的上下文以及设计局限。
对结果负责
今天的智能体没有一个是完美的。你可以把大部分的设计和实现交给智能体，但你需要对结果负责。
所以要小心……并祝你玩得开心！
能玩到这些未来的玩具（当然，同时也用它们做严肃的事），真是一件乐事！
原文：How To Be A World-Class Agentic Engineer by @systematicls