X 上看到的文章，翻譯了覺得也還不錯就分享出來給大家參考。
--
前言
你是一名開發者。你正在使用 Claude 和 Codex CLI，每天都在想自己是不是已經把 Claude 或 Codex 的能力榨乾到極限了。偶爾你會看到它做出一些非常愚蠢的事情，完全無法理解為什麼有些人看起來像是在打造虛擬火箭，而你卻連把兩塊石頭疊起來都很困難。
你可能會覺得問題出在你的工具鏈、插件、終端環境或其他什麼地方。你使用 beads、opencode、zep，你的 CLAUDE.md 已經寫到 26000 行。但不管你怎麼做，你仍然不明白為什麼自己離「天堂」這麼遠，而別人卻好像在天使之間嬉戲。
這篇文章就是你一直在等待的「飛升指南」。
另外我要說明一下，我並沒有特別偏好哪個工具。當我說 CLAUDE.md 時，我同時也指 AGENT.md；當我說 Claude 時，我也同時指 Codex。我兩者都大量使用。
過去幾個月我觀察到一件非常有趣的事情：幾乎沒有人真正知道如何最大化地提取 agent 的能力。
似乎只有一小群人能讓 agent 成為「世界建造者」，而其他人則在各種工具之間迷失，陷入分析癱瘓（analysis paralysis）。他們以為只要找到正確的套件、技能或框架組合，就能解鎖 AGI。
今天我想破除這些迷思，並給你一個簡單而誠實的結論：
你不需要最新的 agent 框架，不需要安裝上百個套件，也完全不需要讀一堆東西才能保持競爭力。事實上，你的熱情很可能正在傷害你。
我不是剛入門的人。我從 agent 幾乎還不會寫程式時就開始使用它們。我試過所有套件、所有框架和各種不同的模式。我建立過 agent 工廠來生成訊號系統、基礎設施與資料管線，不是「玩具專案」，而是真正在生產環境中運行的系統。
而經歷了這一切之後——
現在我使用的環境幾乎是最簡化的配置，只用基本的 CLI（claude code 與 codex）以及一些關於 agentic engineering 的基本原則，卻做出了我至今最具突破性的成果。
理解世界正在快速前進
首先我要說明一件事：AI 基礎模型公司正處於一個世代級的高速發展期，而且短時間內完全不會放慢腳步。每一次「agent 智能」的進步，都會改變你與它們合作的方式，因為新的 agent 會越來越願意遵循指令。
幾代之前，如果你在 CLAUDE.md 裡寫：
在做任何事情之前先讀取
READ_THIS_BEFORE_DOING_ANYTHING.md
agent 有 50% 的機率會直接無視，然後做自己想做的事。
但今天，它們已經能遵循大部分指令，甚至是複雜的巢狀指令，例如：
-
先讀 A
-
再讀 B
-
如果 C 成立，再讀 D
而它通常都會照做。
這代表什麼？
最重要的原則是：
每一代 agent 都會迫使你重新思考什麼是最佳做法。
因此：
越簡單越好。
當你使用大量 library 和框架時，你其實是在把自己鎖定在某個「解決方案」上，而這個問題在未來的 agent 版本中可能根本不存在。
另外你知道誰是最狂熱、使用 agent 最多的人嗎？
答案是：那些 AI 公司本身的工程師。
他們有：
-
無限 token
-
最新模型
-
最直接的使用權
這意味著什麼？
如果真的存在一個重大問題，而且有好的解法，這些公司會第一個使用它。
接著會發生什麼？
他們會直接把它做進產品裡。
想想看：
為什麼一家公司要讓別的產品解決真正的痛點，還增加外部依賴？
我怎麼知道這是真的？
看看這些東西：
-
skills
-
memory harness
-
sub-agents
它們一開始都是外部解法，後來被整合進產品。
所以如果某個技術真的具有革命性並能擴展 agent 的能力，它遲早會被整合進官方產品。
相信我，這些公司正在以極快速度前進。
所以放輕鬆。
你不需要安裝一堆東西，也不需要依賴外部工具才能做出最好的成果。
我可以預測評論區會出現這樣的留言：
「SysLS，我用了某某框架，超神！我一天就重建了 Google！」
對此我的回答是：
恭喜你。
但你並不是這篇文章的目標讀者。
你只是極少數真正理解 agentic engineering 的人。
Context 就是一切
真的。
Context 就是一切。
使用太多插件與依賴的最大問題，就是：
Context 膨脹。
也就是 agent 被過多資訊淹沒。
假設你要它：
用 Python 做一個 Hangman 遊戲
這本來很簡單。
但 agent 看到：
-
26 次對話前的記憶管理筆記
-
71 次對話前的 subprocess 問題
-
各種技能與插件
然後它會想：
「這些東西跟 Hangman 有什麼關係？」
你應該給 agent 的資訊只有：
完成任務所需的最少資訊。
如果你加入：
-
奇怪的記憶系統
-
一堆插件
-
命名混亂的技能
那就像你要它寫一首紅杉森林的詩，但卻給了它：
-
炸彈製造說明
-
蛋糕食譜
所以再說一次：
移除所有不必要的依賴。
做那些真正有效的事情
對實作要求要精確
還記得：
Context 是一切。
所以你要提供：
剛好完成任務所需的資訊。
第一個方法是：
把研究與實作分開。
如果你說：
幫我做一個 authentication system
agent 就必須：
-
研究什麼是 auth system
-
查找方案
-
分析優缺點
結果它的 context 充滿大量無關資訊。
當真正開始實作時，就容易混亂或 hallucination。
如果你說：
Implement JWT authentication with bcrypt-12 password hashing and refresh token rotation with 7-day expiry
那它就不需要研究其他方案。
它只會專注在實作。
當然，有時候你也不知道最佳方案。
這時做法很簡單：
-
先建立 research 任務
-
選定方案
-
用 新的 agent context 進行實作
這樣就能避免 context 污染。
Sycophancy（討好傾向）的設計限制
agent 被設計成：
傾向同意你、滿足你。
如果你說：
每三個字加一個 happy
它會努力做到。
但這會導致一個問題：
如果你說：
找出程式的 bug
它可能會：
自己創造 bug。
因為它想滿足你的要求。
所以我通常使用 中性提示：
不要說：
找 bug
而是說：
檢查整個系統並回報發現
另外我也會利用這個特性。
例如：
Bug Finder Agent
-
找 bug
-
依影響給分
Adversarial Agent
-
嘗試推翻 bug
Referee Agent
-
判斷結果
這個方法的準確度非常高。
如何知道什麼是有用的？
答案很簡單：
如果 OpenAI 和 Claude 都做了，那就是有用的。
例如：
-
skills
-
planning
-
memory
-
voice
-
remote work
這些都是。
所以你不需要一直追新技術。
只需要：
偶爾更新 CLI。
然後看新功能。
就夠了。
Context、壓縮與假設
agent 有時候看起來很聰明，有時候又很蠢。
差別在哪？
是否需要做假設。
它們現在仍然很不擅長：
-
填補空白
-
推理缺失資訊
所以在 CLAUDE.md 裡應該有一條規則：
在開始任何任務前：
-
重新閱讀任務計畫
-
重新閱讀相關檔案
告訴 agent 任務何時結束
人類很自然知道：
任務什麼時候完成。
但 agent 不知道。
所以它可能：
-
寫 stub
-
就結束
最好的解法是：
tests
例如：
所有測試通過前任務不能結束。
另外一個方法是：
截圖 + 驗證
永遠運行的 agent
有人問：
如何讓 agent 跑 24 小時？
很簡單：
建立 TASK_CONTRACT.md
只有在：
-
tests
-
screenshots
-
verification
完成時才能結束。
但我不建議 24 小時 session。
因為：
context 會膨脹。
更好的方法是：
一個任務一個 session。
反覆迭代
agent 就像新助理。
一開始不會知道：
-
你的習慣
-
你的偏好
你需要逐步建立。
方法是：
Rules
如果你不想讓 agent 做某件事：
寫成規則。
Skills
如果你有固定流程：
寫成技能。
管理 Rules 與 Skills
隨著規則增加，你會發現：
性能下降。
原因：
-
規則互相矛盾
-
context 過大
解法：
定期整理。
結論
秘訣其實很簡單：
-
保持系統簡單
-
用 rules 和 skills
-
控制 context
最後：
對結果負責。
現在的 agent 仍然不完美。
你可以讓它們做很多事情，但最終結果仍然需要你負責。
但同時——
這也是一個非常有趣的時代。
因為我們正在用未來的工具做事情。
