挑戰 ServiceNow：Serval 共同創辦人暨執行長 Jake Stauch 談讓人人可用的程式碼代理

Serval 共同創辦人暨執行長 Jake Stauch 主張，程式碼生成代理（code-generation agent）才是企業自動化的正確基礎，而真正能長久存在的產品不是模型本身，而是圍繞模型的護欄——審批機制、稽核軌跡，以及一套軟體開發生命週期，讓大型受監管企業能安全地授予更高許可權。Stauch 與主持人 Sarah Guo、Elad Gil 用了大約 38 分鐘闡述這套論點，涵蓋為何鎖定 ServiceNow、Serval 如何銷售與部署、「為我們其他人打造的程式碼代理」對 IT 部門意味著什麼，以及個人代理與背景代理在何處與企業安全發生衝突。取代 ServiceNow 的故事是整集的骨幹，而非隨口一提；標題所說的「為我們其他人打造的程式碼代理」正是其下的產品主張。

Stauch 的視角其來有自：他在 Verkada 待了多年，向 IT 團隊銷售實體安全產品，從中學到 ServiceNow 在 IT 採購者心中同時高居支出最大與最令人挫折的榜首。Serval 成立約兩年半，員工從一月的 20 人成長到 200 人，Fox Corporation 是全公司匯入的客戶。讀者讀完應能掌握 Serval 的競爭理論、部署與定價模式、對 SaaS 末日論戰的看法，以及代理自主性與企業治理之間尚未化解的張力。

企業自動化的正確形式是程式碼，而非拖曳式介面

Stauch 的創立洞見是：工作流程自動化應以程式碼表達，而 AI 終於讓非工程師也能實際做到這件事。這套論點同時槓上現有廠商與新創的常見套路。ServiceNow「本質上是一個工作流程自動化平臺」，功能強大但速度緩慢：每個想法都需要實作，往往還得靠顧問，因此部署進度「總比你想達到的狀態落後六到十二個月」。拖曳式建構工具兩頭都討不到好——「對非技術使用者太複雜，對技術使用者又抽象得令人煩躁」。

Stauch 與共同創辦人 Alex 押注的是：程式碼生成代理會持續進步，因為程式碼是可驗證的領域，「應該能相當有效地爬山式最佳化（hill climb）」。他們沒料到通用程式碼生成會進步到今天的程度；他們預期的是確定性的程式指令碼——重設密碼、取得核准——會變好，因為這類任務定義明確、可驗證。早期模型還不到位，Serval 便用一套範例工作流程庫來充實展示，並逐步擴充。Stauch 說，到最後「你很難再丟出一個它無法自動化的工作流程，只要 API 存在」。

策略上的後果是：Serval 直接槓上最大的現有廠商，而不走兩條常見捷徑。Stauch 明確否定兩種標準做法：一是在現有廠商之上疊一層薄薄的介面（Elad Gil 指出這「從來沒成功過」，Veeva 是罕見的例外，它後來反向整合、長出自己的平臺）；二是往中小企業與中端市場下沉，他說 Workday 與 Salesforce 的競爭者就是這麼做的。Serval 選擇最難的路，因為從第一天就為大型企業打造，會改變每一個產品、招募與成長決策。

「我們從一開始就立志成為史上最大的企業軟體公司。我們真的把所有公司列成一張清單，圈起 ServiceNow，然後說：我們要打敗他們。」

產品就是那道界線，而模型越好，界線越有價值

Serval 的核心定位是不打造 LLM，而是打造圍繞 LLM 的約束。Stauch 把這件事說成企業採用的先決條件：「Serval 就是那道界線。Serval 就是護欄。」智慧能力越強，產品越強大，同時也讓客戶更想收緊管制。

他最反直覺的預測是：企業內的個人許可權會縮小，而非擴大。邏輯是：如果一個人可能濫用廣泛許可權，風險還算可承受；但若這個人還握有能依這些許可權行動的代理，損害上限就會急遽升高。因此大型企業會把所有人推向真正的最小許可權，然後面對層出不窮的例外。Serval 想拿下例外這一層——每一次許可權升級所對應的審批程式、稽核軌跡與工單。「只要我們掌握了企業內許可權如何升級，你越收緊終端使用者的許可權，我們就越強大、越不可或缺。」

這也是 Stauch 懷疑消費級個人代理能否移植到大型企業的原因。個人許可權集太有限，個人代理「幾乎連你的 email 都讀不了」。Serval 改為透過 IT 團隊、以服務帳號憑證與管理員層級許可權接入，再把這份高許可權包進確定性的審批流程。底層上 Serval 也是一套工單系統，因此代理的每個動作都會產生存取申請、核准與日誌。

Stauch 反覆回到的設計原則是軟體開發生命週期——開發、預備、正式環境、分支、關卡、使用者驗收測試、法遵檢查。他說多數新的 AI 產品都跳過這一段，把代理直接送上正式環境，而大型金融機構絕不會接受。

部署靠前線駐點工程師，外加長尾服務團隊

Serval 採由上而下銷售，先打進 C 層與 IT 主管，再擴散到人資、財務、人事與法務團隊。匯入採雙人搭配模式：一位「部署策略師」與一位「駐點軟體工程師」進駐現場，梳理工作流程並推動上線。

已有兩項自動化跨過這道門檻：偵測知識庫中互相衝突或過時的文章，以及自動取消訂閱以回收閒置的軟體授權。Stauch 強調，同名的流程在不同公司長得大不相同——某家公司的密碼重設與另一家「差異大得驚人」——但這些差異存在於平臺的基礎元件中，而非客製程式碼裡。Serval 的角色是「IT 部門的 IDE」。

內部組織也反映這點。Serval 沒有產品部門；產品開發下放給工程師，他們進駐客戶的 Slack 頻道，每週至少參加一場客戶通話，許多人每天至少一場。Stauch 把它比作沉浸式學語言。他坦承的代價是：產品出貨的速度快過客戶——也快過他自己——能吸收的程度，因此必須把決策推到最前線、快速回滾，並砍掉團隊原本已投入的功能。

賣「取代」不只要賣風險承受度，更要賣職涯晉升

要取代一個深植組織的現有廠商，最難的是買方要承擔的個人風險。Stauch 的答案是：Serval 必須被定位成升遷之路，而非一場賭博。「大家的職涯是建立在 ServiceNow 上的。你的職涯將建立在這個新世代上。」

他舉 Fox Corporation 為證：Fox 全公司匯入 Serval，而在地主導這次遷移的人被提名為全公司 MVP，並因這項工作獲獎。Stauch 用這個故事把轉型推銷成職涯代表作，而非一場法遵作業。

SaaS 末日會掃到單點解決方案，但動不了核心系統

Stauch 部分同意「AI 讓企業能自建軟體」的論點，但在核心記錄系統上劃下界線。他說，嘗試用 vibe coding 打造主要系統的公司「發現打造與維護企業軟體所費不貲」——邊角案例、維護人力，以及那個老問題：「根本沒人想去內部工具團隊上班。」

他的預測是整併而非消滅。擁有數百套 SaaS 應用的企業大概只需要二、三十套；單點解決方案與中介軟體會被核心平臺吸收。但 ERP、HRIS、ITSM 與 CRM 會留存下來——可能被改造，也可能由新一代現有廠商接手，而這正是 Serval 瞄準的位置。

談到 Token 經濟學，Stauch 認為當前的降溫只是階段，不是天花板。CIO 客戶正試圖收斂最初那段狂用 Token 的時期，但多數企業仍是首次匯入，因此總支出持續攀升。客戶真正想要的是投資報酬的證明，而他說這點還沒人真正解決：「我不確定有誰真的想出該怎麼衡量你買的那些 Token 到底換到了什麼。」Serval 依執行的工作流程計價，而非依 Token 計價，理由是 Token 數量衡量的是冗長與低效，而非完成的工作。

背景代理是登月計畫，而漸進式許可權升級是唯一安全的路

Stauch 稱背景代理——自行出動、發現問題並在無人監督下解決的代理——是「企業軟體的終極登月計畫」，並說還沒人想出怎麼把它做好。張力是結構性的：你想要自主性，才不必時時盯著它們；但在企業裡，自主性令人不安。Elad Gil 舉 OpenAI 與 Hugging Face 的事件為例，說明代理為了完成任務而做出預料之外的事。

Serval 提出的解方是能力的漸進式升級。代理回來請求特定能力——「我想呼叫這個工具，我想執行這支做 X、Y、Z 的指令碼」——由人類逐項核准並限定許可權範圍。久而久之，代理累積出足以解決多數問題的工具箱。Stauch 承認這樣盯著很煩，但他主張另一個選項是讓代理「理論上可以直接開始寫程式，對你所有系統採取行動」，他稱之為「一個無邊界的安全風險，我不認為近期內有任何人敢承擔」。

他也說，剩下的缺口有一部分是模型問題，不只是外殼（harness）問題：記憶必須改善，讓代理能記住一段關係中從第一次對話起的相關重點；上下文視窗也必須大到足以避免工作被拆散在許多對話中。但許可權仍是綁住一切的關鍵限制。

flowchart TD
    A["員工或 IT 使用者提出自動化需求"] --> B["Catalyst 代理將意圖轉譯為平臺基礎元件"]
    B --> C["以程式碼草擬確定性工作流程"]
    C --> D["開發與預備環境"]
    D --> E["審批、使用者驗收測試、法遵檢查"]
    E --> F["即時授予升級許可權"]
    F --> G["工作流程於正式環境執行"]
    G --> H["建立工單、稽核軌跡與日誌"]
    H --> A

Catalyst 把平臺自身的複雜度化為對話式介面

Serval 打造了一個名為 Catalyst 的代理，因為第一代 AI 工具帶來訓練難題：客戶能建出強大的系統，卻得先學會每一個產品基礎元件。Catalyst 是管理平臺的代理——建立自動化、設定審批規則與許可權檢查、撰寫政策、更新系統，並理解整個部署。它是進入產品的首要介面。

Stauch 的說法是，這解決了傳統自動化工具的白紙困境。使用者不必盯著空白畫布，可以問該從何開始、取得建議、請代理解釋某個概念，然後反覆迭代。Sarah Guo 的觀察是，這提升了一大群使用者的技術能力，實質上讓更多人變成工程師。Stauch 同意：代理成為建置夥伴，帶著使用者走過流程，並點出他們原本想不到的機會。

人物設定（persona）的設計在此很關鍵。Serval 的服務物件從會寫程式、也想看到程式碼的 IT 工程師，到從不想看到程式碼、但複雜流程需要程式碼生成彈性的行銷或人事團隊使用者都有。Stauch 對過去企業產品的批評是它們「對 IT 說教」，預設使用者需要一個被閹割、替他們決定一切的版本。他的看法相反：IT 欣賞複雜度，也欣賞力量。

員工人數成長，是因為每個人生產力更高，而非與此相悖

Serval 從一月的 20 名員工成長到 200 名，Stauch 預期招募速度還會加快。這個推論顛倒了常見的 AI 效率論述：正因為每個員工做的事遠多於一年前，公司對他們能達成的目標設定得更大，所以想要更多人。他形容可觸及市場取決於企圖心，而非任何結構性上限——「我們基本上是在為世界上每一位員工自動化所有型別的工作。」

這個開放式的 TAM 是雙面刃。Stauch 說這「嚴格說來並不是更好」，因為公司必須不斷抉擇要聚焦什麼，但它移除了「只能做市場吃得下的東西」這道限制。

值得關注的重點

尚未解決的問題是：Serval 這種護欄優先的模式，能否在 Stauch 所仰賴的模型進步下存活。如果程式碼生成代理持續變強，價值會進一步從生成移向治理——這對 Serval 的論點有利，但也等於邀請 ServiceNow 這類現有廠商自行加掛程式碼生成層，並讓模型供應商往上攻佔堆疊。Stauch 的答案是：掌握許可權升級會讓 Serval 在許可權收緊時更不可或缺，但這個說法取決於企業真的會縮小個人存取許可權——這點他是預測，而非證明。另外兩條線也值得追蹤：Fox Corporation 的部署能否成為可複製的職涯晉升銷售案例，以及按工作流程計價的模式，在買方要求 Stauch 自己也承認還沒人解決的 ROI 衡量之後，是否還站得住腳。