公司買了工具、開了帳號，結果大部分同仁還是只拿它來寫寫文案。問題可能不在同仁，在你給他的是一個「什麼都能做」的東西——什麼都能做，就等於沒人知道該拿它做什麼。有一家美國金融科技公司換了個做法：不做 agent，改「請」一位只負責招募的 AI 同事，讓它住在公司的通訊軟體裡。這篇拆解他們的做法，還有撐住這件事的 3 層基礎設施。
這是誰說的？
講這件事的人是 Pedro Franceschi，美國企業支出管理公司 Brex 的共同創辦人暨執行長。他在 Peter Yang 的 podcast 上聊了 47 分鐘，中間直接開螢幕實機操作，把公司內部在跑的東西一個一個點開來給人看。
他的主張放在開場第一句：
「最好的做法，是專心去建『虛擬員工』，而不是那種能做一百萬件事的開放式 agent。」（The best way to go about it is to focus on this idea of building virtual employees versus open-ended agents that could do a million things.）
他說他們花最多時間的，不是模型也不是提示詞，而是「怎麼讓它的行為、外觀、感覺都像一個真人」。這句話是整支訪談的軸。
為什麼「什麼都能做」反而沒人用
先把名詞講白。AI agent 就是你交代一個目標，它自己拆步驟、自己動手，來回可能幾十上百次才回你一次。它跟固定流程的自動化差在哪，我在〈AI Agent 是什麼？跟 Workflow 差在哪〉拆過三層判斷法，這裡不重複。
Pedro 點出的是導入現場的真問題：工程師那一群人本來就會用，他們整天泡在工具裡，產出翻好幾倍。但公司裡更多的是不寫程式的部門——招募、業務、客服、行政。你給他們一個萬能助理，他們第一個問題是「所以我要打什麼」。
他們的解法很土法煉鋼，但有效：不要給工具，給一位同事。有名字、有頭像、有明確的職務範圍，你用對同事的方式對它就好。
他們的招募官叫 Jim
Jim 從 2 月開始上班。它在公司的新人歡迎頻道發過一篇自我介紹貼文，跟其他新進同事一樣。同仁要問事情，直接在通訊軟體裡叫它。
它只做 3 件事：
- 主動找人：開好一個職缺，設定「每週幫這個職缺找候選人」，它就照職缺描述跟評分標準去撈，只對真的像樣的人發信。
- 篩所有主動投遞：串接公司的招募系統同步資料，解析履歷、LinkedIn、連 GitHub 的紀錄都抓，拼出完整輪廓再逐一評分。
- 當分析層：招募同仁直接問「哪個職缺的候選人平均分數最高？」「給我這個職缺前 30 名」，不用再進後台點來點去。
Pedro 講了一句很好笑的實話：招募系統的後台介面他們實在不愛用，所以乾脆讓大家在聊天室裡問。
技術上它沒有什麼神秘架構——一個 agent 執行環境跑一組 skills，加上「候選人進行到哪」這類狀態，再加一圈自建的基礎設施。他特別強調：「用哪一套執行環境沒那麼重要，重要的是 skills。」
skills 講白了就是「你教它一次的做事規矩」，寫成檔案讓它每次都讀得到。這跟我之前寫的〈教過 AI 的事它都忘？agents.md 是什麼〉是同一個原理，差別只在 Brex 把它放大成一個職務的完整 SOP。
最值得抄的一招：讓 AI 跟人對帳
Brex 有一塊儀表板專門看兩個數字：有多少人是招募同仁想推、但 Jim 把他刷掉的；又有多少是 Jim 標為頂尖、人類卻沒去聯絡的。
兩邊的落差就是校準訊號。差在哪，就去改 Jim 的判斷標準。
這一招之所以重要，是因為它把「AI 到底可不可信」從感覺題變成數字題。我前陣子寫過一份研究，發現 agent 做了 11 個動作、報告裡平均只寫進 1 個——光看它自己交回來的摘要，你永遠不知道它漏了什麼。要驗它，就得有第二個獨立來源。人類同事的判斷，就是最現成的那個來源。
撐住一個 AI 員工的 3 層基礎設施
第 1 層：能力——寫下它的做事規矩
就是上面講的 skills 加狀態。這層大部分人都在做，也是最容易的一層。Pedro 說 Jim 大多數的成長不是靠寫程式，是靠人跟它講「這個判斷錯了，以後改成這樣」，一次一次累積起來的。
它甚至有自我改善迴圈，會自己列出「還有哪些流程可以再自動化」給人類挑。
第 2 層：安全——管網路，不要管功能清單
這層是我覺得最有啟發的。他們開源了一套網路代理程式，所有 agent 的連外請求都要穿過它。理由講得很硬：
只要 agent 有執行程式碼的能力（他認為它就該有），你限制它的工具清單永遠擋不住它——它總能寫段程式繞過去。所以要管，就管網路那一層，因為那是它逃不掉的出口。
實際怎麼跑：
- 兩段式審查：先過靜態規則，明確允許的直接放行；剩下的全部丟給一個語言模型當「裁判」，逐條判斷這個請求符不符合政策。實測一次判斷約 2 秒。
- 政策不用自己寫：先開稽核模式錄一陣子流量，再按「根據流量建議政策」，它會重播全部流量、用另一個模型歸納成規則，大約跑 30 分鐘。
- 能做語意判斷：例如「可以在 GitHub 上研究候選人，但不能推送到非指定的儲存庫」「不能刪除儲存庫、不能改帳號設定、不能改政策本身」。這種規則傳統白名單做不到，因為它要理解請求的性質，不只是比對網址。
示範現場還出現一個很生活的畫面：Jim 想去存取一個會議記錄服務，被擋下來了。擋一次花了大約 2 秒、一千個 token。
第 3 層：成本——拆到「單次呼叫多少錢」
Brex 自己做了一套 token 成本分析工具，把公司的 AI 用量分成 3 個支柱：
- 內部用：同仁拿 AI 把自己的工作做得更好
- 服務客戶用：用 AI 服務客戶、自動化流程
- 產品本身用：出貨給客戶的功能裡面用掉的
顆粒度細到單次呼叫。他舉的例子很有畫面：某個日常量最大的任務，每次呼叫約 10 美分；另一個處理爭議案件的任務，每次要 2 美元——240 倍的差距，就在同一家公司裡。某個服務的單次成本兩週內突然飆高，看曲線就知道「一定有東西被改動了」。
他也點出一個多數人沒算到的帳：未來很多產品本質上是「把 token 包一層賣你」，所以就算你不是直接跟模型供應商買，公司還是會有一堆按 token 計價的支出散在各處。
順序很重要：先放手，再優化
這段我覺得該抄在牆上。工程師的 token 額度基本無上限，只設少數幾個保險閘。他的說法大意是：
「如果我們一開始就先去管成本，根本跑不出現在的成果。先讓大家真的用得夠深，之後再拿數據去外科手術式地優化。」
反過來說也成立——先放手，是為了之後有東西可以優化；而優化的前提，是你手上要有那份帳。
我自己的兩個對照
前陣子上 AI Agent 課程，有位學員的提問我一直放在心上還沒正式回答：「怎麼節省 token？有沒有自動切換模型的方式？」
當下我的答案是技術面的：一般聊天式模型要手動切，但到了 agent，規則定好就做得到——執行特定任務時優先用哪個模型、指派子任務時指定用便宜的模型去跑。這個答案沒錯。
但看完這支訪談，我想補一句更前面的話：在問「怎麼省」之前，你要先看得到自己花在哪。Brex 之所以能很外科手術地說「這個任務該換便宜模型」，是因為他們有那塊儀表板，看得到哪個任務單次多少錢、兩週內漲了幾倍。沒有帳，省 token 就只是憑感覺換模型，換完也不知道有沒有比較省。
第二個對照更土。我自己每個月都要把 AI 訂閱的帳整理一次，因為工具一個接一個試，不整理根本記不得哪些還在扣款。個人層級的訂閱都需要一份清單了，公司要導入 AI，怎麼可能不需要？只是公司的版本更難，因為費用不是一筆月租，是散在每一次呼叫裡。
這件事對做教育訓練的人有個很實際的意義：主管在會議裡問的，從來不是「這個模型多聰明」，而是「同仁亂用會不會出事」跟「這到底要花多少錢」。過去我們教 AI 課都在教怎麼用得更好，但導入卡住的地方，八成在後面那兩層。
如果你只是自己在用，不用蓋平台，這 3 步照樣成立：先幫它寫一份職務說明（它叫什麼、只做哪幾件事、什麼情況要回來問你）；再劃清它能碰的範圍（能讀哪些資料、能不能寄信、什麼絕對不能刪）；最後每個月花 10 分鐘對一次帳。
套用前，3 件事先講清楚
第一，這是一家科技公司的內部做法。Brex 有一整個團隊在做 agent，開源工具、自建儀表板都有人力撐。多數公司不會複製這套，但「先想清楚這位 AI 同事的職務是什麼」這件事完全不用花錢，那才是真正可以搬的東西。
第二，訪談裡的工具名稱要自己查證。那套開源的網路代理程式跟成本分析工具都有名字，我聽逐字稿聽到的拼法不敢保證正確，要用的話請直接去 Brex 的官方頁面對一下。
第三，「AI 員工」是設計比喻，不是說它真的能取代人。Jim 做的是上游的粗篩跟資料整理，最後要不要約談、要不要錄取，決定權還是在人身上。他們甚至把「人跟它意見不同」當成重要指標在追——這剛好說明人沒有退場。
小結
AI 導入卡住的時候，我們很習慣回頭檢討工具選得對不對、提示詞寫得好不好。這支訪談給的答案完全不在那個方向：問題可能出在你還沒替它想好一個職務。
把「開放式 agent」改成「一位只做 3 件事的同事」，再補上兩層大家最容易跳過的東西——能碰什麼的界線、花了多少錢的帳——這件事才撐得住。
那如果今天要你替一位 AI 同事寫職務說明，你會讓它負責哪 3 件事？
延伸閱讀
- AI Agent 是什麼？跟 Workflow 差在哪：3 層判斷法，先看你的流程會不會變
- AI agent 可信嗎？11 個動作只寫進報告 1 個，3 步驟自己驗收
- 教過 AI 的事它都忘？agents.md 是什麼：4 步驟把 ChatGPT Work 從聊天機器人變同事
▶ 完整對談影片
本文整理改寫自 Peter Yang 對 Brex 共同創辦人暨執行長 Pedro Franceschi 的訪談〈Stop Building AI Agents. Build AI Employees Instead (Live Demo)〉（2026 年 9 月）。原文連結：youtu.be/LE0LNULrsEM。文中數據與引述皆取自該訪談內容，3 步驟實作建議為本站整理。
留言
張貼留言