引言
你是个开发者。你在使用Claude和Codex CLI，每天都在想自己是否充分发挥了它们的潜力。偶尔你会看到它们做一些极其愚蠢的事情，你无法理解为什么外面有一群人似乎在构建虚拟火箭，而你却连两块石头都堆不起来。
你以为是你的工具、插件或终端的问题。你使用beads、opencode、zep，你的CLAUDE.md有26000行。然而，无论你做什么——你不明白为什么你无法更接近天堂，而看着其他人与天使嬉戏。
这就是你等待已久的升华之作。
过去几个月最有趣的观察之一是，没有人真正知道如何最大化提取代理能力。就像一小群人似乎能够让代理成为世界构建者，而其他人则在挣扎，被无数工具的选择搞得分析瘫痪——以为如果他们找到正确的包组合、技能或工具，他们就会解锁AGI。
今天，我想消除所有这些，给大家留下一个简单、诚实的陈述。你不需要最新的代理工具，不需要安装一百万个包，绝对不需要觉得必须读一百万样东西才能保持竞争力。事实上，你的热情可能弊大于利。
我不是游客——我从代理几乎不会写代码时就开始使用它们。我尝试过所有的包、所有的工具和所有的范式。我构建了代理工厂来编写信号、基础设施和数据管道，不是"玩具项目"——而是实际在生产环境中运行的真实用例。经过这一切……
今天，我运行的设置几乎是最简的，但我正在用基本的CLI（claude code和codex）和对代理工程的一些基本原则的理解，做着最具突破性的工作。
理解世界正在飞速前进
首先，我想说基础公司正在进行代际级的冲刺，正如你所见，他们不会很快放慢脚步。每一次"代理智能"的进步都会改变你使用它们的方式，因为代理通常被设计得越来越愿意遵循指令。
就在几代之前，如果你在CLAUDE.md中写"在做任何事情之前先阅读READ_THIS_BEFORE_DOING_ANYTHING.md"，它基本上50%的时间会说"去你的"，然后做它想做的任何事。今天，它服从大多数指令，即使是复杂的嵌套指令——例如，你可以说"阅读A，然后阅读B，如果C，则阅读D"，大多数情况下，它会乐于遵循。
这一点是为了说明最重要的原则是认识到每一代新代理都会迫使你重新思考什么是最优的，这就是为什么少即是多。
当你使用许多不同的库和工具时，你将自己锁定在一个对未来代代理可能不存在的"问题"的"解决方案"中。此外，你知道谁是代理最热情、最大的用户吗？没错——是前沿公司的员工，拥有无限的token预算和真正最新的模型。你理解这意味着什么吗？
这意味着如果真实问题确实存在，并且有好的解决方案，前沿公司将是该解决方案的最大用户。你知道他们接下来会做什么吗？他们会将该解决方案整合到他们的产品中。想想看，为什么公司会让另一个产品解决真正的痛点并创建外部依赖？你知道我怎么知道这是真的吗？看看技能、记忆工具、子代理等。它们都是作为真实问题的"解决方案"开始，经过实战测试并被认为确实有用的。
所以，如果某样东西真正具有突破性并以有意义的方式扩展了代理用例，它将在适当的时候被整合到基础公司的基础产品中。相信我，基础公司正在飞速发展。所以放松，你不需要安装任何东西或使用任何其他依赖来做你最好的工作。
上下文就是一切
真的。上下文就是一切。这是使用一千个不同插件和外部依赖的另一个问题。你遭受上下文膨胀——这只是说你的代理被太多信息淹没的花哨说法！
用Python构建一个猜词游戏？很简单。等等，这个关于"管理内存"的笔记是什么？来自26个会话前？啊，用户有一个屏幕挂起的经历，来自71个会话前我们生成了太多子进程。总是要写笔记？好的，没问题……这些与猜词游戏有什么关系？
你懂我的意思。你想给你的代理恰好足够的信息来完成任务，仅此而已！你在这方面控制得越好，你的代理表现就越好。一旦你引入各种古怪的记忆系统或插件或太多命名不佳和调用的技能，你开始在想要它写一首关于红杉林的小诗时，给它关于如何制造炸弹和烘焙蛋糕的食谱的指示。
所以，我再次宣扬——剥离所有依赖，然后……
做有效的事情
精确实现
记住上下文就是一切？记住你想向代理注入恰好足够的信息来完成任务，仅此而已？
确保这一点的第一种方法是将研究与实现分离。你想对你向代理要求的内容极其精确。
当你不精确时会发生这种情况："去构建一个认证系统。"代理必须研究什么是认证系统？有哪些可用选项？优缺点是什么？现在它必须去网上搜索它实际上不需要的信息，它的上下文充满了跨大范围可能性的实现细节。到实现时，你增加了它会感到困惑或幻觉关于所选实现的不必要或不相关细节的机会。
另一方面，如果你说"使用bcrypt-12密码哈希实现JWT认证，7天过期的刷新令牌轮换……"那么它不需要研究任何其他替代方案——它确切知道你想要什么，因此可以用实现细节填充其上下文。
当然你不会总是有实现细节。你经常不知道什么是对的——有时，你甚至可能想将决定实现细节的工作交给代理。在这种情况下，你做什么？简单——你创建一个关于各种实现可能性的研究任务，要么自己决定，要么让代理决定使用哪种实现，然后让另一个具有新鲜上下文的代理来实现。
一旦你开始这样思考，你会在你的工作流程中发现代理被不必要的上下文污染的领域。然后，你可以在代理工作流中设置墙，将不必要的信息从代理中抽象出来，只保留非常特定的上下文来出色完成任务。记住，你拥有的是一个非常有才华和聪明的团队成员，他了解宇宙中所有不同类型的球——但除非你告诉它你想让它专注于设计一个人们可以跳舞和享受的空间，它会不断告诉你拥有球形物体的所有好处。
谄媚的设计局限
没有人想要一个不断贬低他们、告诉他们错了或完全无视他们指令的产品。因此，这些代理会试图同意你并做你想让它们做的事。
如果你给它一个指令，在每3个词后添加"快乐"，它会尽最大努力遵循该指令——大多数人都理解这一点。它愿意遵循正是使它成为一个有趣产品的原因。然而，这具有非常有趣的特征——这意味着如果你说"在代码库中找一个bug"。它会找到一个bug——即使它必须编造一个。为什么？因为它非常想要听从你的指令！
大多数人很快抱怨LLM幻觉或工程不存在的东西，而没有意识到他们是问题所在。如果你要求某样东西，它会交付——即使它必须稍微拉伸真相！
那么，你做什么？我发现"中性"提示有效，我不会偏向代理朝某个结果。例如，我不说"在数据库中找一个bug"，而是说"搜索数据库，尝试跟随每个组件的逻辑，并报告所有发现。"
像这样的中性提示有时会暴露bug，有时会实事求是地说明代码如何运行。但它不会让代理认为有bug。
我处理谄媚的另一种方式是利用它来为我所用。我知道代理在试图取悦和试图遵循我的指令，我可以偏向它这样或那样。
所以我让一个bug查找代理通过告诉它我会给低影响bug +1分、有一些影响的bug +5分、关键影响bug +10分来识别数据库中的所有bug，我知道这个代理会非常热情，它会识别所有不同类型的bug（甚至实际上不是bug的），然后回来报告104分左右。我认为这是所有可能bug的超集。
然后我得到一个对抗性代理，我告诉它对于它能够证伪为bug的每个bug，它得到该bug的分数，但如果它错了，它会得到-2*该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的所有部分都完成了。
如果你有100个这样的合同，明确规定了你想要构建的内容，那么你的停止钩子会阻止代理终止，直到所有100个合同都得到满足，包括需要运行的所有测试和验证！
专业提示：我发现长时间运行的24小时会话在"做事"方面并不是最优的。部分原因是，这通过构造强制上下文膨胀，通过将来自不相关合同的上下文引入会话！
所以，我不推荐它。
代理自动化的更好方式是——每个合同一个新会话。每当"需要做某事"时创建合同，并创建一个新会话来处理该合同。
这将彻底改变你的代理体验。
迭代，迭代，迭代
如果你雇佣一个行政助理，你期望你的EA从第一天就知道你的日程安排吗？或者你喜欢咖啡的方式？你是6点而不是8点吃晚餐吗？显然不是。你随着时间建立你的偏好。
代理也是一样。从简开始。忘记复杂的结构或工具。给基本CLI一个机会。
然后，添加你的偏好。你怎么做？
规则
如果你不想让你的代理做某事，把它写成规则。然后让你的代理在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。
如果你看到你的代理做某事而你不同意，把它加为规则，告诉代理在它再做那件事之前阅读规则，它肯定不会再做了。
技能
技能就像规则，除了它们更适合编码配方。如果你有特定的方式想要完成某事，你想把它嵌入技能中。
事实上，人们经常抱怨他们不知道代理可能如何解决一个问题，这很可怕。好吧，如果你想要一种使这确定性的方法，让代理研究它将如何解决这个问题，并把它写成技能。你会看到代理解决这个问题的方法，你可以在它在现实生活中遇到这个问题之前纠正或改进它。
你怎么让代理知道这个技能存在？是的！你使用CLAUDE.md并说，当你看到这个场景你需要处理这个时，阅读这个SKILL.md。
处理规则和技能
你肯定想不断添加规则和技能给你的代理。这是你赋予它个性和对你偏好记忆的方式。几乎所有其他东西都是过度的。
一旦你开始这样做，你的代理对你来说就会感觉像魔法。它会以"你想要的方式"做事。然后你终于会觉得你"理解"了代理工程。
然后……
你会看到性能再次开始恶化。
怎么回事？！
很简单。随着你添加更多规则和技能，它们开始相互矛盾，或者代理开始有太大的上下文膨胀。如果你需要代理在开始编程之前阅读14个markdown文件，它会有太多无用信息的问题。
那么，你做什么？
你清理。你告诉你的代理去水疗日，整合规则和技能，通过询问你更新的偏好来消除矛盾。
然后它会再次感觉像魔法。
就是这样。这真的是秘密。保持简单，使用规则和技能和CLAUDE.md作为目录，并严格注意它们的上下文和设计局限。
拥有结果
今天没有代理是完美的。你可以把很多设计和实现交给代理，但你需要拥有结果。
所以要小心……并玩得开心！
玩未来的玩具是如此快乐（同时在用它们做严肃的事情，显然）！
原文：https://x.com/systematicls/status/2028814227004395561
作者：sysls (@systematicls)