Chris 筆記｜如何打造一間「Agent-First」公司

我的想法

這又是一篇超長文，作者其實不是真的倡議 Agent-first 的公司運營模式。他提出的更像是在公司既有組織中，去規劃發展 AI native 的團隊。

這其實也是如今許多企業正在嘗試的方式，一方面讓員工使用 AI 輔助既有工作，希望增加效率。另一方面又同時打造原生的 AI 團隊來作實驗對比，看看既有工作能否真正脫離員工人為的參與，真正做到全自動化運行。

我覺得即使公司真的成功打造了 AI native 團隊，企業最終肯定還是會維持用縮減人力的方式走並行雙軌制。讓客戶選擇是否使用 AI 服務，或者排隊等待人工服務。這聽起來是不是很熟悉？沒錯，如今的銀行體系、保險業務或電信服務，早已用這樣的方式讓客戶來幫助自己開刀，最終會走向的是 AI first 模式，並不是企業去拿刀執行的，而是巧妙地將這權力之刃交給消費群體，當第一家 AI first 公司成為市場上能被接受的企業時，同類服務的其它公司，自然也不得不跟上，否則將面臨無法競爭的窘迫。

這也是目前許多海外企業正在積極推動 AI 落地的現況，那些提供 AI 落地服務的 FDE，目前最大的價值就是幫企業規劃這條 AI native 的模式，至於 AI 輔助員工這條路，自始至終都不會是企業的選項，而是有自知之明者的自救手段而已⋯⋯

摘要 / Summary

這篇文章給出一份「打造 agent-first 公司」的完整建置流程，開頭先劃清 AI-enabled 與 AI-native 的界線：把 AI 關掉一天，公司只是變慢，代表還是 AI-enabled；工作直接停擺，才是真正的 AI-native。作者用凌晨兩點客戶回報 bug 的場景具體化這個差異——常駐 agent 接手、記錄事件、轉交給工程 agent 修復並發佈，人類全程不必醒著介入。整套模型靠五件事撐起來：持續存在的角色、可靠的交接、明確的權責邊界、可見的工作進度，以及在特定關卡上的人工審查。

為了驗證這套模型不是空談，作者團隊在協作平台 Raft 上跑了一個縮小版公司：一個統一頻道、一位幕僚長 agent、五個專職 agent，圍繞一款真實的 macOS 貼合瀏海產品運作。第一版成品通過工程檢查卻在視覺 QA 上失敗，接手版本引入動態肩寬規則後，通過了全部 89 項工程檢查、視覺 QA 與產品驗收。文章接著把每個元件拆解成可複製的操作步驟：建立統一頻道當唯一真相來源、加入幕僚長維護優先順序與升級規則、給每個 agent 一份寫清楚擁有範圍與決策權限的合約、在組織邊界處用聯合頻道而非人工轉發、把決策轉成留存的任務、用四狀態看板呈現進度。

最後收在一份五天設置計畫與一組可量測的複利指標（從訊號到決策的時間、升級比率、重工比率、缺陷外流率等），核心主張是人類該「在迴圈之上」而非「在每個迴圈裡」——負責策略、政策與例外，把日常執行與轉發交給 agent。文章把整套方法總結成一句話：不是把 AI 助理外掛到既有公司上，而是打從一開始就把公司設計成能讓 agent 把日常工作從觸發一路承接到結果的樣子。

重點 / Keypoint

「把 AI 關掉一天。如果公司變慢了，代表你是「AI-enabled（AI 賦能）」。如果工作直接停擺，代表你是「AI-native（AI 原生）」。」

「目標不是「沒有人類」，目標是「日常工作不再需要人工轉發」。」

「凌晨 2 點 07 分，這間公司不需要召開全員會議，它需要的是一個常駐 agent、一份可靠的交接、一位具名負責人、一項任務、一次測試、一次審查，以及一個發佈決策。」