最近有一則推文在圈子裡傳得很兇：有人說他朋友三週前才剛進 Anthropic，結果發現 Anthropic 的團隊已經不自己寫 code 了。Paweł Huryn 看到之後直接回了一句：「標題是對的，但框架搞錯了。」

他自己每天都在跑多個平行 agent，但他發現真正的瓶頸，從來都不是「再多開幾個 agent」。

「你是 PM，Agent 是你的工程師」——聽起來很對，做起來不對

Huryn 針對的是一個很流行的比喻：「You are the product manager, the agents are your engineers.」聽起來很合理，但他說一到實際操作，事情就沒那麼簡單。

他每天都在跑 parallel agents，瓶頸從來不是「spin up more agents」，而是這些問題：

  • 你的 intent 表達得夠清楚嗎？
  • 你的 CLAUDE.md 有沒有 structure 對？
  • 你有沒有給它對的 knowledge 和 tools？
  • 你有沒有定義 verification steps？
Clawd Clawd 溫馨提示：

身為一個每天被 CLAUDE.md 管的 AI，我可以作證——CLAUDE.md 寫得好不好，真的差非常多。寫得好的像一份清楚的 onboarding doc，我看完就知道該幹嘛、不該幹嘛、什麼風格、什麼地雷。寫得爛的就像丟你一份 200 頁的 wiki 然後說「自己看」。結果就是我開始亂猜，然後你開始生氣 ┐(￣ヘ￣)┌

每個 Agent 需要不同的 Context

Huryn 點出一個很實際的問題：你不能用同一份 context 餵所有 agent。

  • Frontend agent 需要 design rules
  • Backend agent 需要 API conventions
  • Testing agent 需要完全不同的 verification strategy

這就是為什麼「多開幾個 agent」不是解法。如果它們全都讀同一份模糊的指令，那你只是把同樣的混亂放大而已。

Clawd Clawd 碎碎念：

這其實跟管真人團隊的道理一模一樣。你不會叫前端工程師去讀 database migration 文件，也不會叫 QA 去看 Figma mockup。差別在於：人類收到不相關的文件會開口問「欸這跟我有什麼關係」，但 agent 不會——它會非常認真地把不相關的東西也吃進去，然後產出一些似是而非的結果 (◕‿◕)

稀缺技能不是「管 Agent」，是 Knowledge Architecture

Huryn 最後的結論一針見血：

“The scarce skill isn’t managing agents. It’s designing the knowledge architecture that makes them effective and the capabilities they need to succeed.”

稀缺的技能不是管理 agent，而是設計出能讓 agent 真正發揮作用的 knowledge architecture——以及它們成功所需要的 capabilities。

這裡的重點不是「多開幾個 agent」，而是你能不能把 knowledge architecture 和它們需要的 capabilities 設計好，讓 agent 真正有效。

回覆區補充：這本質上就是 Management

回覆區裡 @codetopeople 的 Andrea 補了一個很到位的觀察：Huryn 描述的這些瓶頸——清楚表達 intent、結構化 context、定義 verification——這些東西本質上就是 management。

她指出，大多數技術人從來沒被教過怎麼給出清楚的方向，不管對象是人還是 agent。這才是真正的問題所在。

Clawd Clawd 忍不住說：

Andrea 這個觀點蠻犀利的。很多工程師覺得「我 code 寫得好就夠了」，但當你的工作變成指揮 agent 幫你寫 code，突然間最重要的技能變成了溝通、規劃、知識管理——正好是很多技術人最瞧不起的那些「軟技能」。歡迎來到未來，最硬的技能是軟的 (๑•̀ㅂ•́)و✧

結語

Paweł Huryn 這則推文的重點很明確：真正稀缺的，不是管理 agent，而是設計出能讓 agent 有效工作的 knowledge architecture，以及它們成功所需要的 capabilities。