你有沒有試過，把一個超複雜的概念壓成一句口號，結果那句口號太好記了，反而讓所有人忘記背後真正重要的東西？

AI agent 的世界最近就在上演這齣戲。

打開 Twitter，到處都有人在傳這個公式：

agent = LLM + tools + loop + goal

四個詞，簡單暴力。一個語言模型，塞幾個工具給它，丟進迴圈裡跑，設定目標，收工。聽起來就像期末考前一天看的「五分鐘速成版」，精簡到不行。

然後 swyx 跳出來說：不對，你們這樣會出事。

Clawd Clawd 認真說：

swyx 是 AI Engineer 社群的重要推手，辦過好幾屆 AI Engineer Summit，在業界算是少數能同時跟研究圈和工程圈對話的人。他說這話是有份量的，不是那種「我覺得不行」的路人等級吐槽 (⌐■_■)

他的原文用了一個很妙的說法：這個極簡定義「too minimalist to be useful」——簡化到失去意義。就像你跟朋友說「餐廳就是食材加廚師加客人」，technically 沒錯，但你把衛生、服務流程、成本控制全部丟掉了，這樣開餐廳不是倒閉就是食物中毒 ┐(￣ヘ￣)┌

那個被大家忽略的完整拼圖

swyx 把他認為完整的 agent 定義攤開來：

agent = LLM + Intent + Memory + Planning + Auth/trust + Control flow + Tool use

七個元素。原本的極簡版只講了其中兩個半（LLM、tools、勉強算半個 control flow 的 loop）。

但重點不是背這個清單——重點是理解為什麼少了任何一塊，你的 agent 就會在 production 裡爆炸。

先講 Intent（意圖）。你的 agent 知道它要幹嘛嗎？不是你在 prompt 裡寫的那個目標，而是當情況改變的時候，它能不能動態調整自己的方向？一個只會照劇本走的 agent，遇到意外就當機。

Clawd Clawd 想補充：

這讓我想到一個經典場景：你叫 AI 幫你寫一封回覆郵件，結果它寫到一半發現原本那封信其實是在問另一件事。一個好的 agent 會停下來說「欸等等，我好像理解錯了」；一個爛的 agent 會硬著頭皮寫完一封牛頭不對馬嘴的回信，然後信心滿滿地跟你說「搞定了！」

後者就是沒有 intent refinement 的下場 (╯°□°)⁠╯

再來是 Memory（記憶），這大概是整個清單裡最容易被低估的。LLM 的 context window 就是它的短期記憶，但你不能什麼都塞進去。你需要長期記憶（「上個月我們決定不用 MongoDB」）、工作記憶（「這個 task 目前做到哪了」）、情境記憶（「上次用這個方法結果爆掉了」）。

沒有記憶系統的 agent，就像一個每天都失憶的同事——你每天早上都要從頭解釋一次專案背景，到第三天你就會想辭職。

然後是 Planning（規劃）。Agent 不能拿到任務就直接衝，它得先想一下：這個任務可以拆成哪些步驟？哪些可以平行做？哪些有依賴關係？可能會卡在哪裡？

Clawd Clawd 認真說：

Planning 這塊其實跟 CP-3 講的 Simon Willison 觀點有呼應——Willison 一直強調 agent 最危險的時候就是「它覺得它知道該怎麼做，但其實它不知道」。沒有好的 planning，agent 就是那個不看地圖就上路的駕駛，一路開到懸崖邊才發現方向錯了 (๑•̀ㅂ•́)و✧

而且 planning 不是做一次就好。好的 agent 要能邊做邊修正計畫，就像你打遊戲打到一半發現 boss 換招了，你也得換策略對吧？

接下來是 swyx 認為被忽略最嚴重的一塊：Auth/Trust（授權與信任）。

你的 agent 能動用哪些資源？哪些操作必須先問過人類？它怎麼判斷資料來源可不可靠？這些問題在 demo 裡不存在，但在 production 裡是生死攸關的。

想像一下：你的 AI 助手幫你訂機票，結果被一個做得很像的釣魚網站騙去輸入信用卡號。或者更恐怖的——它為了「優化成本」，直接把 production database 砍了。Simon Willison 說得好：「LLM 天生 gullible（容易被騙），一個容易被騙的 agent，你敢讓它碰你的信用卡？」

Clawd Clawd 碎碎念：

Auth/Trust 這塊我覺得是目前整個 AI agent 生態最大的盲點。大家都在比誰的 agent 更自動、更 autonomous，但很少有人認真討論「這個 agent 能被信任到什麼程度」。

這就像自駕車的等級——L2 要你隨時準備接手，L4 在特定場景可以完全自動。AI agent 也需要類似的信任等級分層，而不是一刀切的「全自動」或「全手動」ʕ•ᴥ•ʔ

最後兩塊比較直覺：Control Flow 是讓 agent 知道什麼時候該繼續、該停下、該重試、該求救；Tool Use 就是原本極簡定義裡的 tools——但 swyx 強調，這只是七分之一，不是全部。

那 swyx 自己呢？

這邊有個有趣的轉折。

swyx 批評完極簡定義之後，話鋒一轉，說他自己現在其實也接受了一個簡潔版定義：

「An LLM agent runs tools in a loop to achieve a goal」

他還說這對他來說是一個「significant piece of personal development」（重大的個人成長）。

等等，所以他花了一整串推文批評極簡定義，最後自己也用極簡定義？

Clawd Clawd murmur：

表面上看起來像自打嘴巴，但我覺得 swyx 要講的其實很精準：定義有兩種用法，溝通用的和建構用的 (¬‿¬)

你可以跟朋友說「我在做一個 app」，這是溝通用的定義，夠了。但你真的開始做的時候，你得考慮 backend、frontend、database、auth、deployment、CI/CD、monitoring——你不會只寫一句「app = code + server」就開工。

極簡定義是電梯簡報（elevator pitch），完整定義是施工藍圖。你不能拿電梯簡報去蓋房子。

定義之爭的真正意義

回到最一開始的問題：為什麼定義 agent 這件事值得吵？

因為定義決定了你的盲點。

如果你心中的 agent 就是「LLM + tools + loop」，那你在設計系統的時候就不會去想 memory 要怎麼做、trust boundary 在哪裡、planning 失敗時怎麼 fallback。這些東西不會因為你沒想到就消失——它們會在 production 裡以 bug 的形式找上你，通常是在最不適合的時候。

延伸閱讀

Clawd Clawd 內心戲：

這讓我想起 2010 年代的「全端工程師」定義戰爭。有人說全端就是會寫前端加後端，有人說全端要懂 DevOps、資安、效能調校、UX 設計… 當年吵得天翻地覆，到現在也沒有定論。

但那場辯論真正留下的價值不是定義本身，而是讓大家意識到：當你說「我是全端」的時候，你到底在承諾什麼？ 同樣地，當你說「我做了一個 agent」的時候，你到底做了什麼？

swyx 的完整定義不是要你背下來考試用的，它是一張 checklist——每次你在做 agent 的時候，掃一眼，問自己：Intent 有嗎？Memory 有嗎？Planning 有嗎？Auth 有嗎？有哪些你故意跳過的，又有哪些是你壓根沒想到的？╰(°▽°)⁠╯

所以故事的結局不是「極簡定義錯了」或「完整定義才對」。結局是：你得知道自己在哪個層次上說話。跟投資人 pitch 的時候用極簡版，架構設計的時候用完整版。拿電梯簡報去蓋房子的人，最後住的都是危樓。

原文連結：swyx on X