從助理到 AI 員工:設計「擁有一個角色」而非「擁有一項任務」的 Agent

主題一:assistant 與 AI employee 的四個分野(約 01:20–01:24)

她先承認「AI employee」這個詞對某些人有點挑釁——為什麼要把它們放進像人類員工一樣的角色?她的回答是,Ema 在 2023 年就創了這個詞,並把以下四點當作第一性原則來設計:

她補了一個很生活化的觀察:「我們大概都替自己的 AI 道過歉——『抱歉那是 AI 弄錯的,我應該檢查得更仔細』。」

一個反直覺的數字:在 Ema 上,builder 建出來的 AI 員工是 50% 對話式 / 50% API 觸發,建置比例剛好一半一半;但超過 90% 的實際呼叫來自自動觸發。她的類比是:你不會每次都去戳實習生叫他做事,過一陣子他就自己在做了。

主題二:平台架構(約 01:25–01:29)

由下而上:

• 部署層:multi-cloud 與 on-prem(Azure、GCP 等),支援資料落地(data residency)。
• LLM 層 — EmaFusion:她說企業客戶「完全不想碰模型排行榜」,不想每週去判斷哪個模型這週在我的任務上比較好。EmaFusion 承擔選模的責任,依照該 AI 員工正在執行的任務,承諾在最低成本與延遲下拿到最好的準確度。
• Builder 平台:大量預訓練的領域專用 agent(例:資料萃取 agent——從 500 頁、內含矛盾與重複的文件中萃取出去重且準確的結構化資料);生成式 workflow 引擎,讓 AI 步驟與確定性步驟混用(例如開通新系統存取權這種流程你會希望它是確定性的);而 Ema Autopilot 會直接幫你生成那些確定性步驟,你只要檢查輸出——不需要寫程式。
• 整合層:支援 MCP,但她特別說明 Ema 在 MCP 出現之前就自己做了一套 tool protocol,更快、更受限、也更好設定,所以兩者都給 builder 選。多數人因為 MCP 現成而從它開始,但你也可以直接帶任何 API 進來——REST、SFTP、SOAP 都行。
• 治理層:內建。互動介面可以是 dashboard、chat、API、語音,甚至 generative UI。
• 預設套件:針對 employee experience、sales、customer support 等場景預先組好的 AI 員工套件。

客戶與規模:2023 年創立,服務 Fortune 2000 客戶,主要自動化 HR、IT、財務等角色;數千個 AI 員工在生產環境運行,數百位外部 builder 在上面開發。100% 的 AI 員工都會改寫真實系統的狀態——他們基本沒有「幫我擬一封信然後我自己複製貼上」這種用例。許多公司把 Ema 當單一操作面板(single pane of glass),不用開十個分頁;而那個面板可以就是 Slack 或 Teams,因為它是員工,你在哪就在哪跟它講話。

具名案例:Wipro(全球 24 萬名員工,用於員工體驗問答)、Artico(美國頂尖高階獵才公司之一,time-to-hire 縮短 67%)、Prime Therapeutics(醫療,背景處理數以千計的 prior authorization)、Hospital for Special Surgery(紐約,病患預約排程)。

主題三:建一個 AI 員工的建議流程(約 01:32–01:37)

Ema 有三種 builder:自家 builder 團隊(尤其服務極不技術的客戶,如醫療客戶)、合作夥伴(Wipro、KPMG 等訓練出來的 builder),以及客戶自己用 Autopilot 建。三種情況他們都建議走同一套 scoping:

1. 探索與界定:這個角色實際上需要什麼?把工作拆解成任務,再逐一判斷哪些用 AI 做、哪些用確定性流程做、哪些還是留給人類。她特別點名一個常見失敗:拿到用例卻沒有真實的測試資料集,結果 builder 一邊做一邊自己編測試資料,而他其實不懂那個業務流程。一定要拿到過去的實際案例。
2. 整合:生產用例一律優先直接用 API;要用 MCP 也行,但會稍慢、吃掉更多 context,因此也更貴;兩者都沒有的系統才退到 browser use;再加上 retrieval 補 context。然後把工作拆成較小的 agent,好評估、好維護,也才能把維護責任分派給公司裡不同團隊。
3. Human-in-the-loop 檢查點:在受監管產業比較單純,因為有些決策 AI 就是不能做(臨床決策、下單這類金融市場決策)。但即使在其他場景,也要找出人類判斷是關鍵的位置——例如招募,「你絕對不會想讓 agent 端到端把人招完」。她給了一條很實用的設計原則:把人類的邊界放在最後那個「改變狀態」的 act 步驟,不要放在 think 步驟——讓 AI 員工把所有事情都做到人類必須動手的那一刻為止,人類看著它的筆記再決定要不要執行。
4. 訓練 agent 主動求助:讓它在自己困惑時主動發出 human-in-the-loop 請求。

主題四:現場 demo(約 01:37–01:47)

她原本要帶大家建三個 AI 員工:sourcing(用 Apollo 搜尋真實候選人)、screening(示範 human-in-the-loop:入選之後要先有人類核可才發出),以及一個 orchestrator——因為「如果你有 100 個 AI 員工,你不會希望人類得記住哪個員工做什麼、該去找誰。沒有人想在腦袋裡處理 routing。」招募人員只跟這一個 orchestrator 對話。

Demo 中值得記下的幾點:

• 她把整段需求貼進 Ema Autopilot,批准計畫後,它就自己去建整合、建 AI 員工、產生測試用 CV 與職缺描述,並自行建立 eval 資料集。Autopilot 本身是一個 harness,握有橫跨 Ema 產品基礎設施(治理層、builder 層、UI 層)的數百個工具,也支援自帶工具與 skills——所以 KPMG 這類公司會把自己數十年的財務知識帶進來,agentic 平台的知識則由 Ema 提供。
• 失敗會被學起來:自我修正的結果會先為該使用者保留,再擴散到整間公司。她說這對留存率影響很大,尤其是自帶工具的情況——「四五個人用過之後,接下來一百個人就會很順」。
• API key 是刻意做不到的事:你無法把 API key 貼給 Autopilot 讓它去接。他們在來源端就做 PII 與敏感資料混淆(obfuscation),你一貼進聊天就被混淆掉,下游系統拿到的是混淆後的值。她刻意對比:「不像很多 harness,你把 API key 貼進去它就真的能端到端跑起來。」
• 三種 AI 員工形態:chat、dashboard(可由 app、API 或排程觸發——就是那 90% 呼叫的來源)、以及 orchestrator。Demo 中的 screening 員工正停在人類審核的狀態,審完才會往下跑出 fit score 與信件。

主題五:Q&A(約 01:48–02:12)

這場問答的密度高於前面的簡報,以下依主題整理。

定價(約 01:48、02:10) — 使用量與成效併用。多數 AI 員工是賣成效:每一份 sales proposal、每一張客服工單、每一則員工體驗詢問。與 token 數無關,不是成本加成定價,而是「這份工作你本來要付一個人多少錢、我們讓他快多少」。所以不同工作的單價差很多,計費指標可高度客製,與客戶一起訂。另一種是純使用量:客戶買一百萬點數,自己愛建什麼建什麼。

ROI 怎麼量(約 01:50) — 成本中心的用例很直接:人時減少、原本做這件事的人投入減少。生產力型的用例則從預測開始:她舉 2024 年的例子,當時預測一年內會快 15%,結果做了研究後發現兩個月內就快了 3 倍,而且對象是在該職位資歷十年的人。另外要看產出面——同樣人數要能多做 20% 的 sales proposal。

流程會變,怎麼跟上(約 01:51) — 分兩種: - 可預期的大改動:例如 prior authorization 的臨床政策每年更新、有明確發布日。這類基本自助——找 Autopilot 談,Ema 有版本控制,跑完 eval 再推出去。 - 無法預期的真實世界漂移:例如客戶最近兩週開始問新類型的問題。Ema 會掃過 audit log 找出改善機會,Autopilot 提出建議修改,並附上證明有改善、且不會讓既有用例退步的 eval 資料,最後由人類簽核部署。兩者都是自動化流程。

能不能進 Zoom / Teams 會議即時互動(約 01:53) — 還沒做過即時通話。他們做的是會後用逐字稿處理;這個用例目前還沒有客戶提出。

控制的顆粒度 / 每個 agent 的 reward function(約 01:53–01:55) — 她認同「人們想要控制到最細的一步」,而這正是為什麼要有多個 AI 員工、而不是一個包辦全企業的通用 agent。每個 AI 員工通常由不同的人負責,角色也分開(builder、admin、reviewer、onboarder),權限反映在系統裡。Eval 可以跑在AI 員工層級;不需要技術背景,你的控制手段就是把用例講清楚——業務使用者可以很不技術地做(「把去年的工單拿來,我要求在這些工單上至少達到這個表現」),技術型使用者則可以自己帶 eval bed。而在 AI 員工內部,有些是自由形式、沒有 workflow,有些切成較小的 block,同一套 eval 可以跑在 block 層級——例如只量測、只改善「這個 AI 員工跟 Apollo 這一層」的準確度。

能不能接進 Slack / Teams(約 01:55) — 可以,而且很多人就是這樣用。Wipro 用 Teams,也有客戶用 SDK 做成內部網站上的浮動圖示。三者都是 channel;現在非技術人員也能自己設定,大約十分鐘。

為什麼是 multi-cloud(約 01:56) — 因為金融、醫療這類敏感客戶要求on-prem,要部署在他們原本就在的地方,而且要air-gapped——Ema 不能對外連任何系統,包括網路與任何外部 API。客戶可能在 GCP 也可能在 Azure,所以他們從第一天就是 multi-cloud。也有數十家客戶用 SaaS,那些客戶「就像自己開通 Notion 一樣」不在意部署形態。

agent 能不能替使用者強制執行資料的 RBAC(約 01:57) — 可以。整合有兩種連線型態:shared service auth(誰問都一樣的存取權),以及多數用例應該採用的 user-level auth——你第一次問到需要呼叫某系統(例如 ServiceNow)的問題時,它會要你先登入,之後所有答案都用你的憑證取得。這不只限制你能拿到什麼資訊,還讓下游系統本身也留下 audit log:某某人要求了這項資訊,因此該資訊經由 Ema agent 提供給她。

規模上限與工期(約 01:58) — 單一租戶、單一客戶部署裡她親眼看過 300、400 個 AI 員工。但她強調把它們拆開是符合各方利益的——回到「誰維護、誰負責它持續正常運作並跟上流程」的問題。拆開換來更好的治理與管理。工期方面,有些 workflow 跑好幾天,例如一筆新供應商採購可能有十道核可——但卡住的是等人類核可,agent 本身很快;其他用例則快得多。(成本數字她表示不便透露。)

怎麼讓 AI 員工「主動」(約 02:00) — 她現場開了一個測試租戶示範,同時強調「其實沒人在看這些畫面,大家都只跟 Autopilot 講話,這就像在看程式碼」。支援的觸發包括:webhook、讓 AI 員工輪詢你的系統、直接接系統並設條件(「Salesforce 有新 lead 進來時,去判斷他是不是好人選」)、監看收件匣、排程(「每天早上寄一封做 X 的信給我」)。設定方式就是寫一句話。

重複性高的任務會不會一直燒 token,有沒有預建的程式碼 recipe(約 02:01) — 有,程式碼可以直接作為 workflow 的一部分。但她給的建議路徑更有意思:不要花幾個月去預先設計。你可以從一個空的租戶、零個 AI 員工開始,每件事都先跟 Autopilot 做;當它發現什麼是重複的,就開始把那些東西固化下來——依據真實使用與回饋,建出 agentic 的 AI 員工,或直接寫成程式碼並維護它。

這到底是「整個業務流程外包」還是「任務級自動化」(約 02:02) — 提問者指出定位講的是 AI 員工(暗示整個流程被外包),但舉的例子多半偏任務。她的回答:每一個合約與專案的終局都是角色導向的——最後會收斂成一個你可以對話的介面、或一個自動化,能跨所有任務把整份工作做完。但採用會慢一點:你可以建出端到端的 AI 員工,而阻礙永遠是與它協作的人類。所以實務上是一個任務一個任務上線——先 sourcing,再篩 CV,再排面試,再到錄取後的 onboarding、offer letter——讓招募團隊慢慢暖身、學會怎麼跟 AI agent 協作。從一個任務開始,再擴張到那個角色的全貌。

人與 AI 員工的比例(約 02:04) — 在 Ema 上建 AI 員工又便宜又容易,而且只有在真的產生價值時才計費,所以很多人會建一堆自動化。但因為 Ema 只服務超大型公司,比例通常是:200 人的招募團隊,大概只需要 20 個 AI 員工——每個 AI 員工的使用強度極高,一天數千次呼叫。她強調他們不以 agent 數量為優化目標。

拿下 GM 或美國銀行這種大案子之後,實務上怎麼跑(約 02:05) — 由 Ema 或合作夥伴中那位「agentic 轉型專家」負責讓 AI 員工首次上線並運作良好。這是一個深度探索流程:不只跟採購方與團隊主管開 workshop,而是坐進房間裡、跟著實際做這份工作的人 shadow 數小時甚至數天,並翻閱他們過去一年的所有工作案例,然後才寫出定義。流程一旦定義清楚,剩下的就不多了——丟進 Ema Autopilot,幾小時就建好也測好。 她的結論很值得記:「你不需要懂 Ema 才能在 Ema 上做出有影響力的東西。你需要的是非常懂那個業務流程。」也因為如此,很多客戶接著就想自己來:「反正你也是丟進 Autopilot,那我自己來就好,我才是這個招募流程的專家。」

員工的抗拒怎麼處理(約 02:06) — 她認為這種抗拒在兩三年前常見得多——當時的反應是「為什麼要我評估 AI 的樣本,這不是會影響我自己的飯碗嗎?」。最近兩年變化很大:大家意識到要保持在職位與產業的頂端就得更快、且具備 AI 能力,採用 AI 反而讓自己更不可取代、把工作做得更好。現在他們看到的是熱情——人們想成為訓練它的那個人、想理解它怎麼運作。她把這稱為 citizen developers 的崛起:一輩子沒寫過一行程式,卻真心想把 AI 帶進自己的工作。

skills 和 AI employee 差在哪(約 02:11,最後一題) — skill 是威力較小的 AI 員工版本,平台上也支援。skill 的好處是他們有一個模板市集,方便把東西分享給公司內對的人(AI 員工也適用)。但 AI 員工複雜得多:有自己的記憶、有確定性與 agentic 混合的步驟、而且針對該用例被嚴格評估。真正要把東西上線的人通常想要完整的那些頁籤——多少人用過、哪裡出錯、哪裡可以改善、我要自動改善的協助。所以雖然 skills 存在,多數人還是直接用 AI 員工。

金句

"You have to be a little scared — you have to govern everything yourself. … And I think we've all apologized for our AI's errors at times."(約 01:21)

Assistant 模式下,治理責任其實落在使用者身上——這是 AI employee 這個設計的出發點。

"You put a human boundary at the final act step where you're changing the state, and you don't do it at the think step."(約 01:36)

整場最實用的一條 human-in-the-loop 設計原則。

"You don't have to know about Ema to launch impactful stuff in Ema. You have to know a lot about the business process. That's the expertise you need."(約 02:06)

她對「導入的瓶頸在哪」的完整回答。

"You can build an AI employee that does everything end to end, but the blocker is always the humans that are collaborating with that AI employee."(約 02:03)

也是整場最誠實的一句:限制不在 agent 的能力,在組織的節奏。