
上個禮拜同一間做專業服務的公司開會,IT 主管拿着幾張模型用量帳單問我:「我們三個部門試用 agent,一個月就是這個數,照這樣落去,是不是不如自己砌?」這條問題其實同 Garry Tan 在 Walter Isaacson 的 Podcast 上講的是同一件事:他公開說自己每年花的 token 錢,等於一個普通團隊的全年預算。做 ai agent development 的企業,真正要計的,是「這筆錢換到幾多可用工作」,token 單價只是其中一行。本文把帳拆開,再給一個自建與外購的比較框架。
TechCrunch 的報道引述 Tan 的說法,他把自己花在 token 上的錢形容為「a crazy privilege that not everyone can do」,同時認為現在仍然太貴。這一句值得停一停:一個矽谷加速器的行政總裁,用起 agent 來都要先承認價格門檻,香港一間二十人公司更應該先算清楚再落注。
他花錢的方式也很具體。他把 23 個 Claude Code skills 開源在 GitHub,改名為 gstack,讓其他人可以直接用他的工作流程。這批 skills 其實只是一組寫成 Markdown 的指令,免費、以 MIT 授權發布;安裝只要兩次貼上,大約三十秒設定完成。換句話說,真正花錢的地方,是模型反覆處理大量上下文的時間;工具他自己都開源了。
很多公司以為 agent 成本等於「每百萬 token 幾多錢乘用量」。實際帳單最少有三行,任何一行漏算,預算都會失真。
| 成本項 | 計什麼 | 什麼時候會失控 |
|---|---|---|
| 模型用量 | 每次任務輸入與輸出的 token | agent 讀取大量歷史資料、反覆重試 |
| 工具與服務訂閱 | 搜尋、瀏覽、代碼執行、雲端服務 | 每個部門各自開一套 |
| 運行資源 | 節點、容器、儲存與併發 | 同時開太多實例、長時間掛機 |
Tan 的例子最能說明第一行:他的 agent 讀過他所有電郵、Dropbox、Apple Notes,甚至是他廿年來的治療筆記。上下文越深,agent 越像「認識你」的助手;但同一時間,每次任務要送入模型的內容也越多。這是深度使用 agent 的必然代價,並非設定錯誤。
第二、三行則是香港公司最常低估的部分。工具與資源是按人、按節點計的,部門一多,就變成重複採購。這點在雲端服務尤其明顯。

在 gstack 的示範流程裏,agent 用大約八分鐘寫出十一個檔案、合共 2,400 行程式。對一間有產品要出貨的公司,這個產出速度本身就已經值錢。Tan 亦提到 YC 內部有一個叫 Stray Light 的 agent,擁有整間公司的上下文,包括所有被投資創辦人的資料與申請紀錄。
這兩件事指向同一個結論:agent 的回報來自「它掌握幾多公司知識」,而不是「用哪一個模型」。所以當有人問我應該用哪個框架,我會先反問:你有沒有準備好把公司知識整理成 agent 讀得懂的形狀?沒有的話,換幾多個框架都一樣。
第一步,先算清楚任務量。把每個部門一星期內真正交給 agent 的任務列出來,按「每次任務平均要讀幾多資料」分級。讀得越多的任務,模型用量越高,通常也是最值得外購或規範化的那一批。
第二步,算維護成本。agent 不是裝好就完,工具會改版、權限會變、模型會更新。內部團隊要有人負責這些事,否則幾個月後沒人敢改。
第三步,算審核成本。任何對外輸出、任何寫入業務系統的動作,都要有人看過。審核時間本身就是成本,而且它不會因為 agent 變快而減少。
三條算式的結果通常會指向同一個答案:核心、高頻、資料量大的任務,適合用有驗收記錄的服務處理;實驗性、低風險的任務,可以先用自建或開源工具試。

不少讀者在搜 ai agent development 的時候,其實是在找一個起手框架,Pydantic AI 是近期常被提到的一個。它解決的是「怎樣用有型別檢查的方式把工具與模型串起來」,對工程團隊有價值。
但它沒有解決三件事:token 花在哪裏、哪些資料可以讀、誰批准輸出。gstack 的例子反而更清楚:那批 skills 全部是 Markdown 指令,免費開源,任何人都可以抄;真正讓 Tan 的 agent 有用的,是他願意把自己的電郵與筆記交給它。工具可以下載,上下文要自己建立。
所以我把框架看成起點,不是策略。先有任務清單、資料清單與審核清單,再選框架,順序不能倒轉。若果連「agent 讀邊幾份文件」都講不清楚,換框架只會換來一個跑得通但沒人用的示範。
按香港中小企的實際運作,我會把手動關卡放在幾個位置。第一是資料進入 agent 之前:哪些客戶資料、財務數字可以讀,要寫成清單,而不是靠 agent 自己判斷。第二是 agent 產出對外內容之前:客戶回覆、報價、帖文,至少要有一個人看過,並留下修改記錄。第三是 agent 寫入業務系統之前:不管是 CRM 還是與 erp 系統 整合 的接口,寫入動作要有記錄,出錯要追得回。
這幾個關卡不需要很複雜,但必須有人負責。沒有關卡的 agent,出事時你連哪一步出錯都講不出。
Topkee 的定位是把專業方法與業務系統組織成能執行任務的 AI 夥伴,不是賣 token。它把模型、工具、崗位規則與業務系統組成一份可交付的服務,所以費用要結合服務訂閱、模型與運行資源另行確認,也不承諾固定的週期、成本或效果。Topkee 的目錄裏有幾十項已發布的模板,涵蓋 Skill、Bot Team 與 Plugin 三類;這些只是模板條目,不代表每個都是獨立成品,也不代表全部通過業務驗收。
架構上,Bot Team 定義崗位,包括身份、規則、模型與預裝能力;Skill 承載任務方法與執行腳本;Plugin 連接工具與服務,屬於節點級擴展,安裝時可能重啟節點並影響其他 Bot。經驗沉澱靠崗位規則、記憶與 Playbook,複用的是規則、上下文與能力配置,不代表訓練或自動修改模型權重。
對「燒 token 就等於有能力」的說法,這是直接的反例。企業要看的應該是複用率、穩定性與業務指標變化,而不是單次對話用了幾多 token。若想先看一個有公開價格的入口,Topkee Voice Agent 的月費包含一個電話號碼與香港本地不限分鐘通話,加購成效分析、對話優化或 CRM 協同後,合計月費在一段明確的區間內;AI Agent 本身則按服務範圍報價,沒有公開的固定搭建費。

如果你的公司正準備做 ai agent development,先不要急著選模型或框架。用一星期記錄現有的 agent 用量,把任務按資料量分三級,然後決定哪一級留在內部試、哪一級交給有驗收記錄的服務。想了解工程上的連接口怎樣做,可以看 Topkee 的 ai agent development;想看一個實際運行中的例子,可以參考 TTO Funnel Tuning Agent 怎樣為每個營銷活動開獨立實例、保留獨立記憶與履歷。
如果比較想先搞清楚「自己做 ai 代理 與外購服務」的分別,Topkee 與傳統代理商的分野 亦有相關說明。
他在 Podcast 中說自己一年花在 token 上的錢達到六位數字美元,TechCrunch 引述了這段話。這是他個人的使用量,不代表一般企業的水平。
不一定。自建要計模型用量、工具訂閱、運行資源與維護人手,四項加起來往往超過預期。外購的好處是把這些不確定性換成可預期的月費與驗收範圍。
chatbot 主要回答問題,ai 代理 會按任務目標自己決定步驟、調用工具,甚至寫入業務系統。它的價值來自能完成整段工作,所以權限與審核要一併設計。
有限。agent 的判斷力很大程度來自它讀到的上下文。資料少的話,先從小範圍、輸出可審核的任務開始,例如整理客戶回覆或生成初稿。
先定流程。任務清單、資料清單、審核清單三樣寫好,再選框架;倒過來做,通常會變成一個跑得通但沒人用的示範。
找一個月費固定、範圍清楚的服務做試點,例如電話接聽或 CRM 跟進,用一兩個月的記錄判斷值不值得擴展。