如何成為頂級 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 是完美的。你可以把大部分設計和實現工作交給它們，但你必須為最終結果負責。

所以，請保持謹慎……也盡情享受其中的樂趣！

玩弄來自未來的玩具（同時用它們做真正嚴肅的事），真的是一種極大的快樂。

x.com/systematicls/status/2028814227004395561

編譯說明：

本文保留原文所有核心論點與操作建議，部分口語化表達做了本土化處理，技術術語（Skills、harness、stop-hook、CLAUDE.md 等）保留原文寫法以便對照查閱。