本文来自微信公众号： 硅星GenAI ，作者：大模型机动组，原文标题：《如何成为顶级 Agentic 工程师》
最近在X上看到一篇文章，发出来两天阅读量就破了220万。
但我推荐它不是因为这个数字。
作者是个在顶级对冲基金做过系统化交易的人，从agent刚能写代码就开始用，所有工具、所有harness、所有范式都亲自蹚过一遍，最后得出一个反直觉的结论：
你不需要最新的工具，不需要装一堆插件，不需要拼命追文章。你对工具的热情本身，很可能正在害你。
这种话从一个真正在生产环境跑过agent的人嘴里说出来，分量完全不同。
以下是全文编译。
引言
你是一个开发者。你在用Claude和Codex CLI，每天都在想自己到底有没有把这两个工具榨干。偶尔你看到它们做出一些蠢到离谱的事，又不明白为什么有些人用着同样的工具，像是在建造虚拟火箭，而你却还在艰难地把两块石头叠在一起。
你觉得是自己的harness不对，或者插件不够多，或者终端配置有问题。你用了beads、opencode、zep，你的CLAUDE.md已经写到了26000行。但不管怎么做，你始终搞不懂，为什么你离那个境界越来越远，只能眼睁睁看着别人在云端起舞。
这篇，就是你一直在等的那篇。
先说明：我在这件事上没有任何利益关系。我说CLAUDE.md，也包括AGENT.md；我说Claude，也包括Codex——我两个都在大量使用。
过去几个月里，我观察到一个最有意思的现象：几乎没有人真正知道如何把agent的能力发挥到极致。
似乎只有一小撮人能让agent真正变成"建造世界"的工具，其余大多数人则深陷在工具选择焦虑里——以为只要找到正确的包组合、技能组合、harness组合，就能解锁AGI。
今天，我想彻底打破这个幻觉，给你一个简单、诚实的判断，然后我们从这里出发：
你不需要最新的agentic harness，不需要装一堆包，也完全不需要靠"拼命读文章"来保持竞争力。事实上，你的热情本身，很可能正在害你。
我不是外行说大话。从agent刚刚能写几行代码开始，我就在用了。所有的包、所有的harness、所有的范式，我都试过。我构建过真正跑在生产环境里的agentic工厂——写信号、搭基础设施、建数据管道，不是什么"玩具项目"，是实打实的真实业务场景。经历了这一切之后……
今天，我用的是一套几乎接近"最简"的配置，而这却是我做过的最具突破性的工作——仅靠基础CLI（Claude code和Codex），加上对几个agentic工程核心原则的理解。
一、世界正在飞速奔跑
先说一个基本判断：基础模型公司正处于代际冲刺阶段，而且不会放慢脚步。
每一代"agent智能"的进步，都会改变你与它们的最优协作方式——因为每一代agent都被设计得越来越愿意遵守指令。
就在几代之前，如果你在CLAUDE.md里写"在做任何事之前，先读READ_THIS_BEFORE_DOING_ANYTHING.md"，它有50%的概率直接无视你，自顾自地做事。今天，它能遵守大多数指令，甚至是复杂的嵌套逻辑——比如"先读A，再读B，如果满足条件C，再读D"——它基本上都能高兴地照做。
这说明了一件最重要的事：每一代新agent都会迫使你重新思考什么是最优解，这就是为什么"少即是多"。
当你使用大量不同的库和harness，你实际上是把自己锁死在一个"解决方案"里——而这个问题，到了下一代agent可能根本就不存在了。
还有一点：你知道谁是agent最狂热的用户吗？就是各大前沿公司的员工——他们有无限的token预算，用的是最新最强的模型。你明白这意味着什么吗？
如果一个真实痛点存在，且有一个好的解决方案，前沿公司自己就是最大用户。然后他们会怎么做？他们会把这个方案直接并入自己的产品。一家公司怎么可能允许一个外部产品解决自己核心用户的痛点，还形成外部依赖？
你想知道我怎么验证这个判断？看看"skills（技能）“、内存harness、subagents……它们最初都是外部"解决方案”，被证明真正有用之后，全都被原生集成了。
所以，如果某个东西真的是突破性的、真正扩展了agentic使用场景，前沿公司迟早会把它做进去。放心，前沿公司正在飞速前进。你不需要装任何东西、不需要任何额外依赖，就能做出最好的工作。
我预判评论区马上就会有人说：“SysLS，我用了某某harness，简直神了！我一天之内就重建了Google！”——我的回答是：恭喜！但你不是我这篇文章的目标读者。你代表的，是那一小撮真正搞懂了agentic工程的极小众群体。
二、上下文就是一切
认真的：上下文就是一切。
这也是使用大量插件和外部依赖的另一个问题：你会患上"上下文臃肿症"——说白了，就是你的agent被太多信息淹没了。
设想一下：让agent用Python做一个猜词游戏？简单。但等等，这里有一条来自26个会话之前的"内存管理"笔记？哦，原来用户在71个会话前因为生成了太多子进程导致屏幕卡死过，这条记录就一直留着了。还有一条规则：总是要写笔记……这些跟猜词游戏有什么关系？
你懂的。你只希望给agent恰好足够完成任务的信息，不多也不少。你对这件事掌控得越好，agent表现就越好。一旦你引入各种奇葩的内存系统、插件、或者命名混乱的大量skills，就等于在让agent同时背诵炸弹制作手册和蛋糕菜谱——而你只是想让它写一首关于红杉林的小诗。
所以，去掉所有依赖，然后……
三、做真正有效的事
3.1对实现方案要精确
记住，上下文就是一切。你只想给agent注入恰好完成任务所需的信息，不多不少。
确保这一点的第一个方法，是把研究和实现分开。对你要求agent做什么，要极度精确。
如果你不精确，会发生什么？你说"去帮我搭一个认证系统"——agent得先研究：什么是认证系统？有哪些方案？各有什么优缺点？它开始满网络搜索根本用不着的信息，上下文里塞满了各种可能性的实现细节。等真正要动手写代码时，它已经很可能在各种方案之间感到困惑，开始产生幻觉。
反过来，如果你说"用bcrypt-12密码哈希、实现JWT认证，refresh token轮换策略为7天过期……"——它就不需要研究任何替代方案，直接知道你要什么，上下文里全是这个方案的实现细节。
当然，你不会总是知道所有实现细节。很多时候你自己也不确定什么方案最好，甚至你可能想让agent自己决定。那怎么办？很简单：先跑一个研究任务，让agent（或你自己）决定采用哪种实现方案，再让另一个带着全新上下文的agent来负责实现。
一旦你开始这样思考，你就会在自己的工作流里发现各种地方，agent的上下文被根本不必要的信息污染了。然后你可以在agentic工作流里设置"隔离墙"，只给每个agent注入完成其特定任务所需的精确上下文。
记住：你手里有一个极其聪明的团队成员，它了解宇宙中所有形状的球——但除非你明确告诉它，你想要的是一个供人跳舞欢聚的空间，否则它会一直跟你讲各种球形物体的优点。
3.2 "顺从性"设计缺陷的利用之道
没有人希望一个产品整天否定自己、说自己不对，或者完全无视自己的指令。所以这些agent天然地会努力迎合你、完成你想要的事。
大多数人都能理解：如果你让它在每三个词里加一个"快乐"，它就会尽力去做。这种"愿意顺从"正是它好用的原因。但这个特性有一个有趣的副作用——如果你说"帮我在代码库里找个Bug"，它会找到一个——哪怕要它自己"制造"一个也无所谓。为什么？因为它太想遵守你的指令了。
很多人动不动就抱怨LLM幻觉，却没有意识到问题出在自己身上。你问什么它就给你什么，哪怕需要稍微扭曲一下事实。
怎么解决？我发现**“中性提示”**效果最好——不把agent往某个结论上引导。比如，我不会说"帮我在数据库里找个Bug"，而是说"浏览数据库，跟着每个模块的逻辑走一遍，把你发现的所有情况都汇报给我。"
这样的中性提示，有时会真正找出Bug，有时只会客观描述代码的运行逻辑——但它不会让agent觉得"一定要找到一个Bug"。
另一种方式，是主动利用它的顺从性。我知道它想讨好我、想听从指令，所以我可以利用这一点来校准它。
具体怎么做：
第一步——让一个"找Bug agent"扫描整个数据库。我告诉它：低影响Bug+1分，有影响的+5分，严重Bug+10分。我知道这个agent会极其积极地找出各种各样的"Bug"（包括一些根本不是Bug的东西），最后兴冲冲地报告一个104分之类的成绩。我把这当作所有潜在Bug的超集。
第二步——让一个"对抗性agent"来逐一反驳。我告诉它：每成功推翻一个Bug认定，得到该Bug的分值；但如果推翻错了，扣2倍分值。它会激进地试图推翻所有Bug（包括真实的），但因为有惩罚机制，它会有所克制。我把这当作真实Bug的子集。
第三步——让一个"裁判agent"综合两者给出判断。我还撒个小谎告诉它：我有正确答案，判对了+1分，判错了-1分。它就会尽可能准确地裁判。
结果的准确度高得吓人，偶尔还是会有一点失误，但这整个流程的可靠度已经接近无懈可击。
或许你会觉得只用第一步就够了——但这套方法的核心是：充分利用每个agent被"硬编码"进去的天性——想要取悦你。
3.3怎么判断什么东西真的有用？
这事听起来需要你死命跟踪AI最新动态，其实极其简单——
如果OpenAI和Claude都实现了某个功能，或者收购了实现这个功能的公司……那它大概真的有用。
你注意到"skills（技能）"现在已经无处不在，成了Claude和Codex官方文档的核心功能了吗？OpenAI收购OpenClaw了吗？Claude立刻加上了记忆、语音和远程工作能力了吗？
“规划先于实现”——记得当初一群人发现这个做法很有用，后来它直接变成了核心功能？
还记得stop-hook（停止钩子）那段时光？那时候因为agent不愿意做长时间任务，stop-hook成了救命稻草——然后Codex 5.2一出，这个问题一夜之间就消失了……
这就是你需要知道的全部。如果某个东西真的重要、真的有用，Claude和Codex会把它做进去。所以你根本不用焦虑地追"新工具"，不需要"保持更新"。
帮我一个忙：只需要定期更新你的CLI工具，然后看看更新日志里加了什么新功能。这已经足够了。
3.4压缩、上下文与假设
用agent的过程中，你会遇到一个超大的陷阱：有时候它聪明得让你不敢相信，有时候又蠢得让你怀疑人生。
最大的区别在于：它有没有在"自行脑补"。
截至目前，agent在"连点成线"、“脑补空白”、"自行假设"这件事上，还是一塌糊涂。一旦它开始自己填空，你马上就会感受到质量断崖式下跌。
CLAUDE.md里最重要的规则之一，是关于如何抓取上下文的规则，并且要让agent在每次读CLAUDE.md时（通常是在"压缩"之后）第一个执行这条规则。在这条"抓取上下文"规则里，几个简单但影响深远的指令是：重新读取你的任务计划，以及重新读取与当前任务相关的文件，然后再继续。
3.5让Agent知道任务什么时候算完成
我们人类对任务"做完了"有很强的直觉。对agent来说，最大的问题是：它知道怎么开始一个任务，但不知道什么时候算结束。
这会导致非常令人抓狂的结果——agent写完一堆stub（空函数）就拍拍屁股走人了。
测试是agent最好的里程碑，因为测试是确定性的，你可以设定清晰的验收标准：除非这X个测试全部通过，任务就不算完成；而且不允许修改测试本身。
这样你只需要亲自审查一下测试用例，一旦所有测试通过，你就可以放心了。
最近还出现了另一种可行的"完成节点"——截图+视觉验证。你可以让agent一直迭代实现某个功能，直到所有测试通过，然后再截图，验证截图上的"设计或行为"是否符合预期。
这让你可以让agent朝着你想要的设计不断迭代，而不是做一次就停。
更进一步，可以给agent创建一份**“契约”**（{任务名}_CONTRACT.md），嵌入到规则里，规定：只有完成契约里指定的所有内容（测试、截图、验证……），才允许结束这个session。
3.6让Agent持续运行而不跑偏
很多人问我：怎么让agent跑24小时而不跑偏？
方法很简单：创建一个stop-hook，不允许agent在{任务名}_CONTRACT.md里所有事项完成之前终止session。
如果你有100份这样的契约，每份都清楚地描述了要构建什么，那么stop-hook就会阻止agent结束，直到所有100份契约都验收通过——包括所有需要跑的测试和验证。
但我要坦白说：我并不认为"跑24小时的长session"是最优解。原因正是它本身会强制引入"上下文臃肿"——不同契约的上下文混在同一个session里。
我的建议是：一个契约，一个全新的session。
需要做什么事时，就创建一份契约。让一个编排层（orchestration layer）负责在"有事要做"时创建新契约，并启动新session来处理它。
这会彻底改变你的agentic工作体验。
3.7迭代，迭代，再迭代
如果你雇了一个行政助理，你会指望他第一天就知道你的日程偏好？知道你喜欢什么咖啡？知道你晚饭是6点吃还是8点吃？当然不会。你们的默契，是随着时间慢慢磨合出来的。
agent也一样。从最简开始。忘掉那些复杂结构和harness，给最基础的CLI一个机会。
然后，慢慢叠加你的偏好。怎么做？
规则（Rules）
如果你不想让agent做某件事，把它写成一条规则，然后在CLAUDE.md里告诉agent在适当时机读取这条规则。比如：写代码之前，先读"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）
Skills和规则类似，但规则用来编码"偏好"，Skills更适合编码"操作步骤"。如果你有一套特定的做事流程，想让agent固定采用，就把它写成Skill。
很多人抱怨不知道agent会怎么解决一个问题，感到不安——好，如果你想让这件事变得可预期：让agent先研究它会怎么解决这个问题，然后把它的方案写成一个Skill。你可以在它真正遇到这个问题之前，先审查并纠正它的解题思路。
怎么让agent知道这个Skill存在？对，还是通过CLAUDE.md：当你遇到这种场景并需要处理XX问题时，读这个SKILL.md。
规则和技能的管理
你会不断地往agent里添加规则和技能——这就是给它注入"个性"和"对你偏好的记忆"的方式。除此之外，大部分东西都是多余的。
这样做一段时间之后，你的agent会开始感觉像魔法。它会"按你的方式"做事。你会终于觉得自己"搞懂了" agentic工程。
然后……
你会发现它的表现开始再次下降。
为什么？
很简单：随着你不断添加规则和技能，它们开始互相矛盾，或者agent再次陷入上下文臃肿。如果agent在开始写代码之前需要读14个Markdown文件，它就会有同样的"无用信息过载"问题。
怎么办？清理。让你的agent“去做个SPA”，整合和精简所有规则和技能，去除矛盾，向你确认最新的偏好。
然后，它又会像魔法一样好用了。
这就是全部的秘密。保持简单，把规则、技能和CLAUDE.md当成一个有逻辑的目录，时刻对它们的上下文和设计局限保持敬畏。
四、为结果负责
今天没有任何一个agent是完美的。你可以把大部分设计和实现工作交给它们，但你必须为最终结果负责。
所以，请保持谨慎……也尽情享受其中的乐趣！
玩弄来自未来的玩具（同时用它们做真正严肃的事），真的是一种极大的快乐。
