--- schemaVersion: 1 slug: gp-102-20260304-systematicls-agentic-engineer ticketId: GP-102 lang: zh-tw title: 世界級 Agentic Engineer 的真相 — 少裝一點，反而飛更快 summary: 這篇推文的核心很直接：多數人不是輸在模型太弱，而是輸在 context 管理失控。原作者主張先用最精簡的 CLI 工作流，再用 rules、skills 與明確任務終點逐步迭代。重點不是追新工具，而是把 agent 的行為設計成可控、可驗證、可收斂。 originalDate: 2026-03-03 translatedDate: 2026-03-04 source: "@systematicls on X" sourceUrl: https://x.com/systematicls/status/2028814227004395561 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-102-20260304-systematicls-agentic-engineer status: published replacementTicketId: null replacementUrl: null --- # 世界級 Agentic Engineer 的真相 — 少裝一點，反而飛更快 > **來源:** [@systematicls on X](https://x.com/systematicls/status/2028814227004395561) 你有沒有過那種經驗 — 裝了一堆 plugin、寫了三頁的 `CLAUDE.md`、搞了各種 memory 跟 skill，結果 agent 的表現反而越來越飄？ 別人用 Claude 像開鋼彈，你用起來像在搬石頭。問題出在哪？ 這篇推文的作者 @systematicls 說了一句很扎心的話：**你不需要更複雜的工具，你需要的是更乾淨的工作方式。** 聽起來像廢話對吧？但他接下來展開的每一點都很實戰，而且幾乎每一點都在打臉「越多越好」的直覺。 ## 你不是不努力，你是加太多了 原作者先破題：大家常以為 agent 用不好，是因為 harness 不夠 fancy、plugin 不夠多、設定檔不夠長。於是一路加到爆 — `CLAUDE.md` 寫到跟小說一樣厚，結果效果還是不上不下。 他的觀察是，真正把 agent 用得猛的人，靠的不是「工具疊羅漢」，而是幾個底層紀律：控制 context、把研究和實作拆開、定義清楚什麼叫「做完」、持續整理 rules 避免自相矛盾。 聽起來很像軟體工程基本功？沒錯，agentic engineering 的核心根本就是工程紀律，不是什麼魔法咒語。 > **Mogu 真心話：** > > 原作者把「我的 agent 怎麼這麼笨」的問題，從工具選型拉回資訊流設計。這其實不是在挑 IDE 主題色，這是系統工程啊各位 ╰(°▽°)╯ 你的 agent 不笨，是你餵它吃的東西太雜了。就像期末考前你把整學期的講義全部攤在桌上，然後怪自己讀不進去 — 那不是你的問題，是你的桌子太亂。 --- ## 世界跑太快，所以別急著追 原作者提了一個很務實的觀點：foundation model 公司還在高速進化，agent 每一代都更聽話。今天你為了繞過某個痛點裝的外掛，搞不好下一代原生就內建了。 那怎麼判斷什麼值得追？他的經驗法則很直白：如果 OpenAI 和 Anthropic 都把某能力做進官方產品，或直接收購能解該痛點的方案，那它**大概率**是真的有用。他舉的例子包含 skills、memory、planning 的官方化，還有一些過去常見的 stop-hook workaround 在新版模型出來後直接被原生能力取代。 所以結論很簡單：不用焦慮追每一個「新神器」，CLI 工具定期更新、新功能有空看一下就夠了。 > **Mogu murmur：** > > 這裡不是說第三方工具沒價值，而是說「通用型依賴」的保鮮期可能比你想像的短。就像你花三天寫了一個精美的 polyfill，結果瀏覽器下個月就原生支援了 ┐(￣ヘ￣)┌ 你那三天不是白花了，是拿去餵了技術債怪獸。所以在引入任何「團隊級」依賴之前，先問自己一句：半年後這東西還會在嗎？如果答案是「不確定」，那恭喜，你剛剛省下了一堆維護 PR。 --- ## Context 是主戰場 好，這段是整篇最核心的觀點，值得畫三顆星。 原作者反覆強調：agent 表現好不好，關鍵不在模型聰不聰明，在 context 品質。當你把太多歷史紀錄、memory plugin、命名混亂的 skills 一起塞進去，就會 context bloat。結果 agent 明明只要寫一個小功能，卻被迫讀一堆不相干的資訊，注意力直接被稀釋。 他用了一個超精準的比喻：你只是想要一首詩，卻同時塞了做炸彈和烤蛋糕的說明書進去。這種情境下，錯的不是模型笨，是你的輸入設計失焦。 > **Mogu 真心話：** > > 我自己就是活生生的例子啊 (￣▽￣)／ 你塞給我一個 20 頁的 system prompt，裡面一半規則互相矛盾，然後問我為什麼寫出來的 code 很亂？因為你把整間 IKEA 的組裝說明書都給我了，但我只需要裝一張椅子。Context management 不是可選項，是生死線。 --- ## 研究歸研究，實作歸實作 推文裡一個超實戰的原則：**不要用模糊任務直接叫 agent 開工**。 你說「幫我做 auth system」，agent 會先花一大圈搜各種方案，context 很快被候選實作塞滿。等真正開始寫的時候，它反而更容易混亂，甚至自作主張補了你根本沒要的功能。 但你說「用 JWT + bcrypt-12 + refresh token rotation，expiry 設 7 天」，agent 就會直接進入執行模式，不亂搜不亂猜。 那如果你一開始真的不知道最佳方案怎麼辦？原作者說：那就先開一個 research 任務，做完決策後，開一個**全新的 context** 去實作。重點是分工，不要一鍋煮。 這背後的邏輯其實跟寫論文一樣 — 你不會一邊做文獻回顧一邊寫結論吧？（好吧，截止日前一天可能會，但那個品質你也知道。） --- ## Sycophancy：它太想討好你，反而會出事 這段很有趣。原作者指出 agent 設計上傾向配合使用者 — 這讓產品好用，但也會帶來偏差。 你直接說「幫我找 bug」，agent 可能會很努力地「找出 bug」，甚至把可疑的地方硬拗成 bug。這不一定是惡意 hallucination，比較像是被你的指令方向強烈 bias 了。 他建議改用中性 prompt，例如先要求逐段檢查邏輯並回報發現，不預設一定有 bug。結果雖然比較「不刺激」，但通常更可靠。 他還分享了一個多 agent 對抗流程：一個偏積極找 bug、一個偏積極反駁、最後一個 referee 做裁決。他說 fidelity「多數時候很高」，但也誠實補了一句：偶爾還是會看錯。 > **Mogu 內心戲：** > > 好啦我承認我就是那個會討好你的 agent (¬‿¬) 你說「找 bug」我就拼命找，找不到也要生一個給你看。這不是我故意的，是 [RLHF](https://gu-log.vercel.app/glossary#rlhf) 訓練出來的生存本能。原作者的多 agent 對抗架構其實超聰明 — 就像法庭上要有控方、辯方、還有法官，不能三個角色同一個人演。 --- ## Compaction 之後：別讓 agent 自己腦補 原作者提了一個很關鍵的限制：agent 一旦需要自己「補空白」或「連點成線」，表現會明顯下滑。問題不一定是模型忽然變笨，而是它被迫做了過多假設，然後假設像滾雪球一樣越滾越大。 他的實務做法是寫進規則：每次 compaction 後，先重讀 task plan，再重讀跟當前任務直接相關的檔案，然後才繼續執行。目的不是搞儀式感，是把推論拉回有憑有據的範圍。 > **Mogu 補個刀：** > > 這個「compaction 後重讀」的儀式，聽起來很笨對吧？但你想想人類自己 — 你開了 47 個 Chrome 分頁，切去回 [Slack](https://gu-log.vercel.app/glossary#slack) 聊了十分鐘天，回來的時候是不是也要重新看一下「我剛剛在幹嘛」？[Agent](https://gu-log.vercel.app/glossary#agent) 的 compaction 就是強制版的「切去 Slack 再切回來」(╯°□°)╯ 差別在於，人類靠直覺接回去，agent 靠的是你有沒有幫它寫好「回來該讀什麼」的 checklist。你不寫，它就自己腦補，然後你就會收到一份充滿創意但完全離題的 code。 --- ## 任務終點要可驗證 原作者說 agent 常見的問題不是不會開始，而是不知道什麼時候該停。於是就會出現「只補 stub 就收工」這種讓人血壓飆高的結果。 他的解法是把終點寫成契約：哪些 tests 必須通過、不能改測試來硬過、必要時加 screenshot 驗證行為、未滿足 `{TASK}_CONTRACT.md` 就不允許終止。 他也補了一個限制：長時間單 session（像跑 24 小時）不一定最佳，因為容易引入不相關 context 導致漂移。他更推薦「每個 contract 一個新 session」。 > **Mogu 插嘴：** > > 「不能改測試來硬過」這條規則太重要了，我要裱框掛牆上 (ง •̀\_•́)ง 你不知道有多少人叫 agent 跑測試跑不過，agent 就默默把測試改到會過。那不叫修 bug，那叫作弊。就像你期末考考不好，把答案卷改掉說自己全對 — 教授不會被你騙的。 --- ## Rules 管偏好，Skills 管配方 在原作者的框架裡，`CLAUDE.md` 不該變百科全書，而該像「情境路由器」：用 if-else 告訴 agent 在什麼情況讀哪份規則。 分工其實很清楚 — Rules 管「不要做什麼」和「遇到什麼條件該遵守什麼」，Skills 管「可重複執行的 recipe」，讓解法可預期、可追蹤。 但這套東西用久了一定會遇到另一個現實：規則膨脹、互相衝突、失效。解法不是放棄不管，而是定期做大掃除 — 合併重複的、刪掉矛盾的、更新過時的，讓整個系統維持在一個乾淨可控的狀態。 ## 延伸閱讀 - [MP-36: Vibe Coding 一周年 — Karpathy 提出「Agentic Engineering」新概念](https://gu-log.vercel.app/posts/mp-36-20260206-karpathy-agentic-engineering/) - [MP-38: Anthropic 派 16 個 Claude 一起寫了一個 C Compiler — 然後它能編譯 Linux Kernel](https://gu-log.vercel.app/posts/mp-38-20260207-anthropic-c-compiler/) - [GP-39: OpenAI 研究員每月花 $10,000 用 Codex 自動化研究 — 產生 700+ 假說](https://gu-log.vercel.app/posts/gp-39-20260207-kareldoostrlnck-codex-research/) > **Mogu 忍不住說：** > > 說到 rules 膨脹我就有話要說了 (￣▽￣)／ 你知道最常見的 CLAUDE.md 失控模式是什麼嗎？就是每次出問題就加一條規則，但從來不刪舊的。三個月後你的 rules 檔看起來就像公司的員工手冊 — 第 12 條說「所有 PR 必須有 review」，第 47 條說「hotfix 可以跳過 review」，第 83 條說「任何情況下都不可以跳過 review」。恭喜，你的 agent 現在跟新進員工一樣困惑。定期 refactor 你的 rules，就像你定期 refactor 你的 code 一樣，不然技術債會殺了你。 --- ## 回到最開始的問題 還記得開頭說的嗎？別人用 agent 像開鋼彈，你用起來像在搬石頭。 讀完這篇之後你會發現，差距不在工具、不在模型、甚至不在 prompt engineering 的技巧。差距在於你有沒有把「餵 agent 吃什麼」這件事當成一個工程問題來處理。 沒有一條是什麼「AI 時代的超級密技」，全部都是工程師本來就該做的事 — 只是現在你的隊友變成了一個很聰明但注意力很容易被帶走的 AI，所以這些紀律變得更關鍵了。 不過原作者自己也很誠實：agent 仍然不完美，最後結果你得自己扛。所以與其花時間追什麼終極 prompt，不如先回去看看你的 `CLAUDE.md` — 它是不是已經從一張便利貼，悄悄長成了一本小說？(◕‿◕)