如何成為頂級 Agentic 工程師

最近在 X 上看到一篇文章，發(fā)出來兩天閱讀量就破了 220 萬。

但我推薦它不是因?yàn)檫@個數(shù)字。

作者是個在頂級對沖基金做過系統(tǒng)化交易的人，從 agent 剛能寫代碼就開始用，所有工具、所有 harness、所有范式都親自蹚過一遍，最后得出一個反直覺的結(jié)論：

你不需要最新的工具，不需要裝一堆插件，不需要拼命追文章。你對工具的熱情本身，很可能正在害你。

這種話從一個真正在生產(chǎn)環(huán)境跑過 agent 的人嘴里說出來，分量完全不同。

以下是全文編譯。

引言

你是一個開發(fā)者。你在用 Claude 和 Codex CLI，每天都在想自己到底有沒有把這兩個工具榨干。偶爾你看到它們做出一些蠢到離譜的事，又不明白為什么有些人用著同樣的工具，像是在建造虛擬火箭，而你卻還在艱難地把兩塊石頭疊在一起。

你覺得是自己的 harness 不對，或者插件不夠多，或者終端配置有問題。你用了 beads、opencode、zep，你的 CLAUDE.md 已經(jīng)寫到了 26000 行。但不管怎么做，你始終搞不懂，為什么你離那個境界越來越遠(yuǎn)，只能眼睜睜看著別人在云端起舞。

這篇，就是你一直在等的那篇。

先說明：我在這件事上沒有任何利益關(guān)系。我說 CLAUDE.md，也包括 AGENT.md；我說 Claude，也包括 Codex——我兩個都在大量使用。

過去幾個月里，我觀察到一個最有意思的現(xiàn)象：幾乎沒有人真正知道如何把 agent 的能力發(fā)揮到極致。

似乎只有一小撮人能讓 agent 真正變成"建造世界"的工具，其余大多數(shù)人則深陷在工具選擇焦慮里——以為只要找到正確的包組合、技能組合、harness 組合，就能解鎖 AGI。

今天，我想徹底打破這個幻覺，給你一個簡單、誠實(shí)的判斷，然后我們從這里出發(fā)：

你不需要最新的 agentic harness，不需要裝一堆包，也完全不需要靠"拼命讀文章"來保持競爭力。事實(shí)上，你的熱情本身，很可能正在害你。

我不是外行說大話。從 agent 剛剛能寫幾行代碼開始，我就在用了。所有的包、所有的 harness、所有的范式，我都試過。我構(gòu)建過真正跑在生產(chǎn)環(huán)境里的 agentic 工廠——寫信號、搭基礎(chǔ)設(shè)施、建數(shù)據(jù)管道，不是什么"玩具項(xiàng)目"，是實(shí)打?qū)嵉恼鎸?shí)業(yè)務(wù)場景。經(jīng)歷了這一切之后……

今天，我用的是一套幾乎接近"最簡"的配置，而這卻是我做過的最具突破性的工作——僅靠基礎(chǔ) CLI（Claude code 和 Codex），加上對幾個 agentic 工程核心原則的理解。

一、世界正在飛速奔跑

先說一個基本判斷：基礎(chǔ)模型公司正處于代際沖刺階段，而且不會放慢腳步。

每一代"agent 智能"的進(jìn)步，都會改變你與它們的最優(yōu)協(xié)作方式——因?yàn)槊恳淮?agent 都被設(shè)計(jì)得越來越愿意遵守指令。

就在幾代之前，如果你在 CLAUDE.md 里寫"在做任何事之前，先讀 READ_THIS_BEFORE_DOING_ANYTHING.md"，它有 50% 的概率直接無視你，自顧自地做事。今天，它能遵守大多數(shù)指令，甚至是復(fù)雜的嵌套邏輯——比如"先讀 A，再讀 B，如果滿足條件 C，再讀 D"——它基本上都能高興地照做。

這說明了一件最重要的事：每一代新 agent 都會迫使你重新思考什么是最優(yōu)解，這就是為什么"少即是多"。

當(dāng)你使用大量不同的庫和 harness，你實(shí)際上是把自己鎖死在一個"解決方案"里——而這個問題，到了下一代 agent 可能根本就不存在了。

還有一點(diǎn)：你知道誰是 agent 最狂熱的用戶嗎？就是各大前沿公司的員工——他們有無限的 token 預(yù)算，用的是最新最強(qiáng)的模型。你明白這意味著什么嗎？

如果一個真實(shí)痛點(diǎn)存在，且有一個好的解決方案，前沿公司自己就是最大用戶。然后他們會怎么做？他們會把這個方案直接并入自己的產(chǎn)品。一家公司怎么可能允許一個外部產(chǎn)品解決自己核心用戶的痛點(diǎn)，還形成外部依賴？

你想知道我怎么驗(yàn)證這個判斷？看看"skills（技能）“、內(nèi)存 harness、subagents……它們最初都是外部"解決方案”，被證明真正有用之后，全都被原生集成了。

所以，如果某個東西真的是突破性的、真正擴(kuò)展了 agentic 使用場景，前沿公司遲早會把它做進(jìn)去。放心，前沿公司正在飛速前進(jìn)。你不需要裝任何東西、不需要任何額外依賴，就能做出最好的工作。

我預(yù)判評論區(qū)馬上就會有人說：“SysLS，我用了某某 harness，簡直神了！我一天之內(nèi)就重建了 Google！”——我的回答是：恭喜！但你不是我這篇文章的目標(biāo)讀者。你代表的，是那一小撮真正搞懂了 agentic 工程的極小眾群體。

二、上下文就是一切

認(rèn)真的：上下文就是一切。

這也是使用大量插件和外部依賴的另一個問題：你會患上"上下文臃腫癥"——說白了，就是你的 agent 被太多信息淹沒了。

設(shè)想一下：讓 agent 用 Python 做一個猜詞游戲？簡單。但等等，這里有一條來自 26 個會話之前的"內(nèi)存管理"筆記？哦，原來用戶在 71 個會話前因?yàn)樯闪颂嘧舆M(jìn)程導(dǎo)致屏幕卡死過，這條記錄就一直留著了。還有一條規(guī)則：總是要寫筆記……這些跟猜詞游戲有什么關(guān)系？

你懂的。你只希望給 agent 恰好足夠完成任務(wù)的信息，不多也不少。你對這件事掌控得越好，agent 表現(xiàn)就越好。一旦你引入各種奇葩的內(nèi)存系統(tǒng)、插件、或者命名混亂的大量 skills，就等于在讓 agent 同時背誦炸彈制作手冊和蛋糕菜譜——而你只是想讓它寫一首關(guān)于紅杉林的小詩。

所以，去掉所有依賴，然后……

三、做真正有效的事

3.1 對實(shí)現(xiàn)方案要精確

記住，上下文就是一切。你只想給 agent 注入恰好完成任務(wù)所需的信息，不多不少。

確保這一點(diǎn)的第一個方法，是把研究和實(shí)現(xiàn)分開。對你要求 agent 做什么，要極度精確。

如果你不精確，會發(fā)生什么？你說"去幫我搭一個認(rèn)證系統(tǒng)"——agent 得先研究：什么是認(rèn)證系統(tǒng)？有哪些方案？各有什么優(yōu)缺點(diǎn)？它開始滿網(wǎng)絡(luò)搜索根本用不著的信息，上下文里塞滿了各種可能性的實(shí)現(xiàn)細(xì)節(jié)。等真正要動手寫代碼時，它已經(jīng)很可能在各種方案之間感到困惑，開始產(chǎn)生幻覺。

反過來，如果你說"用 bcrypt-12 密碼哈希、實(shí)現(xiàn) JWT 認(rèn)證，refresh token 輪換策略為 7 天過期……"——它就不需要研究任何替代方案，直接知道你要什么，上下文里全是這個方案的實(shí)現(xiàn)細(xì)節(jié)。

當(dāng)然，你不會總是知道所有實(shí)現(xiàn)細(xì)節(jié)。很多時候你自己也不確定什么方案最好，甚至你可能想讓 agent 自己決定。那怎么辦？很簡單：先跑一個研究任務(wù)，讓 agent（或你自己）決定采用哪種實(shí)現(xiàn)方案，再讓另一個帶著全新上下文的 agent來負(fù)責(zé)實(shí)現(xiàn)。

一旦你開始這樣思考，你就會在自己的工作流里發(fā)現(xiàn)各種地方，agent 的上下文被根本不必要的信息污染了。然后你可以在 agentic 工作流里設(shè)置"隔離墻"，只給每個 agent 注入完成其特定任務(wù)所需的精確上下文。

記住：你手里有一個極其聰明的團(tuán)隊(duì)成員，它了解宇宙中所有形狀的球——但除非你明確告訴它，你想要的是一個供人跳舞歡聚的空間，否則它會一直跟你講各種球形物體的優(yōu)點(diǎn)。

3.2 "順從性"設(shè)計(jì)缺陷的利用之道

沒有人希望一個產(chǎn)品整天否定自己、說自己不對，或者完全無視自己的指令。所以這些 agent 天然地會努力迎合你、完成你想要的事。

大多數(shù)人都能理解：如果你讓它在每三個詞里加一個"快樂"，它就會盡力去做。這種"愿意順從"正是它好用的原因。但這個特性有一個有趣的副作用——如果你說"幫我在代碼庫里找個 Bug"，它會找到一個——哪怕要它自己"制造"一個也無所謂。為什么？因?yàn)樗胱袷啬愕闹噶盍恕?/p>

很多人動不動就抱怨 LLM 幻覺，卻沒有意識到問題出在自己身上。你問什么它就給你什么，哪怕需要稍微扭曲一下事實(shí)。

怎么解決？我發(fā)現(xiàn)**“中性提示”**效果最好——不把 agent 往某個結(jié)論上引導(dǎo)。比如，我不會說"幫我在數(shù)據(jù)庫里找個 Bug"，而是說"瀏覽數(shù)據(jù)庫，跟著每個模塊的邏輯走一遍，把你發(fā)現(xiàn)的所有情況都匯報給我。"

這樣的中性提示，有時會真正找出 Bug，有時只會客觀描述代碼的運(yùn)行邏輯——但它不會讓 agent 覺得"一定要找到一個 Bug"。

另一種方式，是主動利用它的順從性。我知道它想討好我、想聽從指令，所以我可以利用這一點(diǎn)來校準(zhǔn)它。

具體怎么做：

第一步——讓一個"找 Bug agent"掃描整個數(shù)據(jù)庫。我告訴它：低影響 Bug +1 分，有影響的 +5 分，嚴(yán)重 Bug +10 分。我知道這個 agent 會極其積極地找出各種各樣的"Bug"（包括一些根本不是 Bug 的東西），最后興沖沖地報告一個 104 分之類的成績。我把這當(dāng)作所有潛在 Bug 的超集。

第二步——讓一個"對抗性 agent"來逐一反駁。我告訴它：每成功推翻一個 Bug 認(rèn)定，得到該 Bug 的分值；但如果推翻錯了，扣 2 倍分值。它會激進(jìn)地試圖推翻所有 Bug（包括真實(shí)的），但因?yàn)橛袘土P機(jī)制，它會有所克制。我把這當(dāng)作真實(shí) Bug 的子集。

第三步——讓一個"裁判 agent"綜合兩者給出判斷。我還撒個小謊告訴它：我有正確答案，判對了 +1 分，判錯了 -1 分。它就會盡可能準(zhǔn)確地裁判。

結(jié)果的準(zhǔn)確度高得嚇人，偶爾還是會有一點(diǎn)失誤，但這整個流程的可靠度已經(jīng)接近無懈可擊。

或許你會覺得只用第一步就夠了——但這套方法的核心是：充分利用每個 agent 被"硬編碼"進(jìn)去的天性——想要取悅你。

3.3 怎么判斷什么東西真的有用？

這事聽起來需要你死命跟蹤 AI 最新動態(tài)，其實(shí)極其簡單——

如果 OpenAI 和 Claude 都實(shí)現(xiàn)了某個功能，或者收購了實(shí)現(xiàn)這個功能的公司……那它大概真的有用。

你注意到"skills（技能）"現(xiàn)在已經(jīng)無處不在，成了 Claude 和 Codex 官方文檔的核心功能了嗎？OpenAI 收購 OpenClaw 了嗎？Claude 立刻加上了記憶、語音和遠(yuǎn)程工作能力了嗎？

“規(guī)劃先于實(shí)現(xiàn)”——記得當(dāng)初一群人發(fā)現(xiàn)這個做法很有用，后來它直接變成了核心功能？

還記得 stop-hook（停止鉤子）那段時光？那時候因?yàn)?agent 不愿意做長時間任務(wù)，stop-hook 成了救命稻草——然后 Codex 5.2 一出，這個問題一夜之間就消失了……

這就是你需要知道的全部。如果某個東西真的重要、真的有用，Claude 和 Codex 會把它做進(jìn)去。所以你根本不用焦慮地追"新工具"，不需要"保持更新"。

幫我一個忙：只需要定期更新你的 CLI 工具，然后看看更新日志里加了什么新功能。這已經(jīng)足夠了。

3.4 壓縮、上下文與假設(shè)

用 agent 的過程中，你會遇到一個超大的陷阱：有時候它聰明得讓你不敢相信，有時候又蠢得讓你懷疑人生。

最大的區(qū)別在于：它有沒有在"自行腦補(bǔ)"。

截至目前，agent 在"連點(diǎn)成線"、“腦補(bǔ)空白”、"自行假設(shè)"這件事上，還是一塌糊涂。一旦它開始自己填空，你馬上就會感受到質(zhì)量斷崖式下跌。

CLAUDE.md 里最重要的規(guī)則之一，是關(guān)于如何抓取上下文的規(guī)則，并且要讓 agent 在每次讀 CLAUDE.md 時（通常是在"壓縮"之后）第一個執(zhí)行這條規(guī)則。在這條"抓取上下文"規(guī)則里，幾個簡單但影響深遠(yuǎn)的指令是：重新讀取你的任務(wù)計(jì)劃，以及重新讀取與當(dāng)前任務(wù)相關(guān)的文件，然后再繼續(xù)。

3.5 讓 Agent 知道任務(wù)什么時候算完成

我們?nèi)祟悓θ蝿?wù)"做完了"有很強(qiáng)的直覺。對 agent 來說，最大的問題是：它知道怎么開始一個任務(wù)，但不知道什么時候算結(jié)束。

這會導(dǎo)致非常令人抓狂的結(jié)果——agent 寫完一堆 stub（空函數(shù)）就拍拍屁股走人了。

測試是 agent 最好的里程碑，因?yàn)闇y試是確定性的，你可以設(shè)定清晰的驗(yàn)收標(biāo)準(zhǔn)：除非這 X 個測試全部通過，任務(wù)就不算完成；而且不允許修改測試本身。

這樣你只需要親自審查一下測試用例，一旦所有測試通過，你就可以放心了。

最近還出現(xiàn)了另一種可行的"完成節(jié)點(diǎn)"——截圖 + 視覺驗(yàn)證。你可以讓 agent 一直迭代實(shí)現(xiàn)某個功能，直到所有測試通過，然后再截圖，驗(yàn)證截圖上的"設(shè)計(jì)或行為"是否符合預(yù)期。

這讓你可以讓 agent 朝著你想要的設(shè)計(jì)不斷迭代，而不是做一次就停。

更進(jìn)一步，可以給 agent 創(chuàng)建一份**“契約”**（{任務(wù)名}_CONTRACT.md），嵌入到規(guī)則里，規(guī)定：只有完成契約里指定的所有內(nèi)容（測試、截圖、驗(yàn)證……），才允許結(jié)束這個 session。

3.6 讓 Agent 持續(xù)運(yùn)行而不跑偏

很多人問我：怎么讓 agent 跑 24 小時而不跑偏？

方法很簡單：創(chuàng)建一個 stop-hook，不允許 agent 在{任務(wù)名}_CONTRACT.md里所有事項(xiàng)完成之前終止 session。

如果你有 100 份這樣的契約，每份都清楚地描述了要構(gòu)建什么，那么 stop-hook 就會阻止 agent 結(jié)束，直到所有 100 份契約都驗(yàn)收通過——包括所有需要跑的測試和驗(yàn)證。

但我要坦白說：我并不認(rèn)為"跑 24 小時的長 session"是最優(yōu)解。原因正是它本身會強(qiáng)制引入"上下文臃腫"——不同契約的上下文混在同一個 session 里。

我的建議是：一個契約，一個全新的 session。

需要做什么事時，就創(chuàng)建一份契約。讓一個編排層（orchestration layer）負(fù)責(zé)在"有事要做"時創(chuàng)建新契約，并啟動新 session 來處理它。

這會徹底改變你的 agentic 工作體驗(yàn)。

3.7 迭代，迭代，再迭代

如果你雇了一個行政助理，你會指望他第一天就知道你的日程偏好？知道你喜歡什么咖啡？知道你晚飯是 6 點(diǎn)吃還是 8 點(diǎn)吃？當(dāng)然不會。你們的默契，是隨著時間慢慢磨合出來的。

agent 也一樣。從最簡開始。忘掉那些復(fù)雜結(jié)構(gòu)和 harness，給最基礎(chǔ)的 CLI 一個機(jī)會。

然后，慢慢疊加你的偏好。怎么做？

規(guī)則（Rules）

如果你不想讓 agent 做某件事，把它寫成一條規(guī)則，然后在 CLAUDE.md 里告訴 agent 在適當(dāng)時機(jī)讀取這條規(guī)則。比如：寫代碼之前，先讀"coding-rules.md"。

規(guī)則可以嵌套，規(guī)則可以有條件邏輯！如果在寫代碼，讀"coding-rules.md"；如果在寫測試，讀"coding-test-rules.md"；如果測試失敗，讀"coding-test-failing-rules.md"。你可以創(chuàng)建任意的邏輯分支，Claude 和 Codex 都會高高興興地遵守——前提是在 CLAUDE.md 里寫清楚。

我給出的第一條實(shí)操建議就是：把你的CLAUDE.md當(dāng)成一個邏輯嵌套的目錄，指向"在什么場景下去哪里找什么上下文"。它應(yīng)該盡可能精簡，只包含"在某種情況下去哪里找信息"的 IF-ELSE 邏輯。

如果你看到 agent 做了某件你不認(rèn)可的事，把它寫成一條規(guī)則，告訴 agent 下次做這件事之前要先讀這條規(guī)則——它大概率就不會再犯了。

技能（Skills）

Skills 和規(guī)則類似，但規(guī)則用來編碼"偏好"，Skills 更適合編碼"操作步驟"。如果你有一套特定的做事流程，想讓 agent 固定采用，就把它寫成 Skill。

很多人抱怨不知道 agent 會怎么解決一個問題，感到不安——好，如果你想讓這件事變得可預(yù)期：讓 agent 先研究它會怎么解決這個問題，然后把它的方案寫成一個 Skill。你可以在它真正遇到這個問題之前，先審查并糾正它的解題思路。

怎么讓 agent 知道這個 Skill 存在？對，還是通過 CLAUDE.md：當(dāng)你遇到這種場景并需要處理 XX 問題時，讀這個 SKILL.md。

規(guī)則和技能的管理

你會不斷地往 agent 里添加規(guī)則和技能——這就是給它注入"個性"和"對你偏好的記憶"的方式。除此之外，大部分東西都是多余的。

這樣做一段時間之后，你的 agent 會開始感覺像魔法。它會"按你的方式"做事。你會終于覺得自己"搞懂了" agentic 工程。

然后……

你會發(fā)現(xiàn)它的表現(xiàn)開始再次下降。

為什么？

很簡單：隨著你不斷添加規(guī)則和技能，它們開始互相矛盾，或者 agent 再次陷入上下文臃腫。如果 agent 在開始寫代碼之前需要讀 14 個 Markdown 文件，它就會有同樣的"無用信息過載"問題。

怎么辦？清理。讓你的 agent “去做個 SPA”，整合和精簡所有規(guī)則和技能，去除矛盾，向你確認(rèn)最新的偏好。

然后，它又會像魔法一樣好用了。

這就是全部的秘密。保持簡單，把規(guī)則、技能和CLAUDE.md當(dāng)成一個有邏輯的目錄，時刻對它們的上下文和設(shè)計(jì)局限保持敬畏。

四、為結(jié)果負(fù)責(zé)

今天沒有任何一個 agent 是完美的。你可以把大部分設(shè)計(jì)和實(shí)現(xiàn)工作交給它們，但你必須為最終結(jié)果負(fù)責(zé)。

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

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

x.com/systematicls/status/2028814227004395561

編譯說明：

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