為知識工作打造安全的 agents（第 2/3 段） ☕ Buy me a coffee

🧑‍🏫 這支影片請 Every 團隊分享他們怎麼在 Slack 裡做出一個全公司共用的 AI 同事，以及為什麼最後改用 Claude Managed Agents，不再自己搭底層。內容有實戰踩過的坑，也講了怎麼評估 AI 好不好用、怎麼讓它越用越懂你，對想把 AI 帶進團隊的人很實用。

• 11:18 他們開始替 vibe check 加上量化的一層。形式看起來像 benchmark，但量的是自己真正在意的事，也就是依自己的品味判斷模型在實際工作上做得好不好。
  ↳ vibe check（憑感覺試用、看順不順手）原本很主觀，他們想替它打分數。形式像 benchmark（用統一考題跑分），但題目換成自己的真實工作，照自己的標準評。
• 11:50 一開始採用每人一個 agent 的模式，agent 放在每個人想用的介面上，例如 Telegram、Slack。
  ↳ 一開始每人各有一個 agent（能自己動手完成任務的 AI 助理），放在各自習慣的地方，有人用 Telegram，有人用 Slack（公司常用的聊天工具）。
• 11:50 後來從 multi-agent 改成單一 agent。原因是 agent 投入越多就越好，但個人在自己 agent 上的投入成果沒有擴散到團隊其他人。
  ↳ 後來從 multi-agent（每人各養一個）改成 single agent（全公司共用一個）。原因是誰花心思調教，只有他自己受惠，別人用不到。
• 12:20 agent 真正能做實際工作的情況，是有多人一起投入：做出更好的 skills、給更好的指引。所以大家共同投入同一個 agent 比較合理。
  ↳ agent 要能做正事，得靠很多人一起投入：寫 skills（教 agent 某類工作怎麼做的說明包）、給更清楚的指引。大家合力養同一個，成果才會累積。
• 12:20 選 Slack 是因為大家本來就在那裡對話。用個人 agent 協作時，要把內容複製到 Claude Cowork 再把回應貼回來，非常麻煩。
  ↳ 選 Slack 是因為大家本來就在那裡聊天。用個人 agent 時，得把內容複製到 Claude Cowork 去問，再把回答貼回 Slack，來回搬很麻煩。
• 12:51 在同事和 agent 都在的同一個地方直接對話容易得多。
  ↳ 同事和 agent 在同一個地方，直接在對話裡叫它就好，大家看得到同一段內容，不用再來回搬。
• 12:51 Every Agent 建在 Claude Managed Agents 上。第一版「一個 agent 給所有人」學到的痛苦教訓之一是：基礎設施很難。
  ↳ Every Agent 蓋在 Claude Managed Agents（替你代管 agent 底層的服務）上。第一版自己搭，才發現 infra（讓系統穩定運作的伺服器等底層設施）很難。
• 13:24 他們想專注在工作的未來、做出更好的產品，不想把時間花在如何編排 sandbox 這類問題上。
  ↳ 他們想把力氣花在產品和工作的未來，不想研究怎麼安排 sandbox（隔離的執行空間，agent 在裡面操作不會弄壞外面）這類工程細節。
• 13:24 第一版很快就變得難以駕馭，因為要一邊改善產品，一邊維持底下強固耐用的 infra 層。教訓之一是：不想當 infra 團隊。
  ↳ 第一版很快就顧不來：一邊要改產品，一邊要顧底層穩不穩。結論是他們不想變成專門維護伺服器的團隊。
• 13:54 Claude Managed Agents 提供 sandbox、memory、session control 等 primitives，讓團隊能專注在下一層：如何為 agent 做互動設計，也不必再被警報打擾。
  ↳ 這服務提供 primitives（現成的基礎零件），像 sandbox、memory（agent 的記憶）、session control（管理每段對話）。團隊能專心設計互動，不再被警報打擾。
• 14:24 新創常見的迷思是覺得 infra 不難，讓 Claude 開一堆伺服器並代為管理就好。講者原本這麼想，Willie 說很難，一個月後講者也承認確實很難。
  ↳ 新創常以為 infra 簡單，叫 Claude 開幾台伺服器順便管就好。講者原本也這麼想，Willie 說很難，一個月後講者也認了。
• 14:55 相較自己手刻 harness，最誠實的答案是：它讓 primitives 可以組合，也讓團隊有更多時間在困難的領域做實驗。
  ↳ 比起自己手刻 harness（包在模型外、負責給工具和安排流程的那層程式），好處是零件能自由組合，省下的時間拿去試真正難的問題。
• 15:27 可以隔離出一個 managed agent 當 staging（前沿測試環境），把 production 的 memories 和 durable state 複製過去做實驗，例如研究如何降低客戶的 token 成本。
  ↳ 可另開 staging（測試用分身），複製 production（大家在用的正式版）的記憶和 durable state（長期保存的資料）去實驗，例如研究怎麼幫客戶省 token（AI 計費的文字單位）。
• 15:27 有大量對話上的 edge case 要處理，尤其是灰色地帶的情況。
  ↳ 對話裡有一大堆 edge case（少見、規則沒寫到的狀況），最難的是灰色地帶：做或不做都說得通的那種。
• 15:57 打造 AI 同事時，大家預設同事會做出好的判斷，但這很難教給模型。所以他們同時跑 evals，也做「感覺像不像真同事」的 vibe 式實驗。
  ↳ 大家預設同事懂得拿捏分寸，但這很難教給 AI。所以他們一邊跑 evals（用固定題目測表現），一邊實際試用，看它像不像真同事。
• 16:27 實驗能獨立進行而不影響主要的 production instance，同時又跑在與 production 相同的 infra 上。這加快了團隊速度，也讓產品更好。
  ↳ 測試分身和正式版跑在同一套底層，但彼此隔開。實驗出錯不影響大家，測出的結果又貼近真實，所以進度快、產品也變好。
• 16:27 安全方面主要靠內建的隔離機制，可以輕易隔離 sandbox、tool calls、環境與 memories 的所在位置。
  ↳ 安全主要靠隔離：sandbox、tool call（agent 呼叫外部工具去查資料、拿文件）、執行環境、記憶放在哪，都能輕鬆分開。
• 17:03 因為這些都能控制，就能決定誰在何時能存取什麼，session management 在這方面很好用。例如 Dan 提出請求時，拿到的東西是否和講者提出時一樣。
  ↳ 因為能分開控制，就能決定誰在什麼時候能看到什麼。session management 在這裡很好用，例如 Dan 問和講者問，該不該拿到一樣的東西。
• 17:03 底層要調整的 primitives 包括：這個請求要附上哪些 memories、使用的 sandbox 相同還是不同。
  ↳ 實際要調的是：這次請求要帶上哪些記憶、用同一個 sandbox 還是另開一個。這決定 agent 回答時知道多少、碰得到什麼。
• 17:33 模型和 harness 之間已經沒有清楚的分界。模型如果沒有一台它懂得使用的電腦，表現就不會那麼好。
  ↳ 模型本身和外面那層 harness 已經分不太開。就像再聰明的人，沒有一台他會用的電腦，也做不出好成績。
• 17:33 由同一個供應商把這些都建在同一處，可以確保模型很會使用這些東西。這同時關乎安全與效能。
  ↳ 模型和底層都由同一家供應商做在一起，能確保模型很會用這些工具。這同時關係到安全，也關係到表現好不好。
• 18:05 錄影當天剛好有新模型發布。prompting guide 裡有團隊需要注意的 breaking changes，但在 Claude Managed Agents 上只要改一行。
  ↳ 錄影當天剛好有新模型推出。prompting guide（教你怎麼下指令的說明）列了 breaking changes（會讓舊做法失效的改動），但在這平台上只要改一行。
• 18:05 Anthropic 方面表示，發布模型時會把這些 breaking changes 和發揮 Claude 最佳表現的做法一併放進 Claude Managed Agents 的 harness。
  ↳ Anthropic 表示，推出新模型時，會把這些改動和讓 Claude 發揮最好的做法直接放進平台的 harness，使用者不用自己追。
• 18:36 身分與授權的難處：agent 一放進公司內部，大家就把它當人看待，會要求它做灰色地帶的事。
  ↳ 身分和權限很難處理：agent 一進公司，大家就把它當成同事，會請它做一些模稜兩可、該不該做說不太準的事。
• 19:06 人類知道「讓我看這份報告沒有害處」，但這很難寫進 agent 邏輯。他們的 North Star 是讓 agent 在 Slack 裡盡可能像人一樣行動。
  ↳ 人知道「給你看這份報告沒關係」，這種判斷卻很難寫成程式規則。他們的 North Star（最終方向）是讓 agent 在 Slack 裡盡量像人一樣做事。
• 19:06 在 Slack 中，agent 是一個獨立的實體，你是在和它互動。底層它有隔離的 memories，也了解你是誰、你在公司內能存取什麼。
  ↳ 在 Slack 裡，agent 是一個獨立的成員，你是在跟它對話。背後它的記憶是隔開的，也知道你是誰、你在公司有權限看哪些東西。
• 19:38 當你請它透過 tool call 或連線去拿文件、查資料時，它大多以你的身分行事，是你的延伸。使用者也能接受這種內部與外部的界線。
  ↳ 請它去拿文件、查資料時，它多半是用你的身分去做，等於你的延伸。哪些算內部、哪些算外部，這條界線使用者也能接受。
• 20:09 持續改進：agent 能看到你在請求中加入品味的每個小時刻，例如「這寫得不好」。今天的例子是 agent 講了個爛笑話，講者要它再講一個。
  ↳ agent 看得到你每次挑剔的瞬間，例如說「這寫得不好」。像當天它講了個爛笑話，講者就叫它重講一個。
• 20:40 這些小小的修正是品味的基礎。品味很難一次講清楚，但很容易從一千個例子中提煉出來，這也是他們建立 skills 的基礎。
  ↳ 這些小修正累積起來就是品味。品味很難一次講清楚，但從上千個例子裡很容易歸納出來，他們就拿這些來做 skills。
• 20:40 例如經常做編輯的人，agent 變得更會編輯的方式，就是看你的 30,000 次編輯，從中提煉出你的編輯品味。
  ↳ 例如常改稿的人，agent 看過你三萬次修改，就能抓出你喜歡怎麼改，之後越改越像你。
• 21:13 同樣的思路適用於 PowerPoint 生成、email，coding 也有。對許多非 coding 的知識工作來說，累積例子是新的前沿，而 agent 就是這些例子的儲存庫。
  ↳ 做簡報、寫 email、寫程式都是同樣道理。對很多非寫程式的工作來說，累積例子是新方向，而 agent 正好把這些例子都存下來。
• 21:44 他們開始把使用 agent 想成招募一個職位。benchmark 分數就像求職者的 SAT 成績，大致方向上有幫助：1600 分和 300 分，會選 1600 分的人。
  ↳ 他們把用 agent 想成招人。benchmark 分數像 SAT（美國大學入學考試）成績，能粗略篩人：1600 分和 300 分，當然選 1600。
• 21:44 但如果大家都拿 1600 分（目前模型就是這種狀況），就需要做更多評估。
  ↳ 但現在的模型幾乎都考到最高分，分數拉不開差距，就得用其他方法比。
• 22:15 真正想要的不是 SAT 分數，而是推薦人查核（reference check）和試用期工作（work trial）。
  ↳ 真正有用的是 reference check（問推薦人對他的評價）和 work trial（先讓他試做一段時間），看實際做事的樣子。
• 22:15 模型進公司的第一天就像聰明、讀了很多書的新鮮人，但不知道你們怎麼工作。目標是建立一套系統，讓它隨經驗累積而成長（本段字幕到此中斷）。
  ↳ 模型第一天上班，像書讀很多、卻不懂你們做事習慣的新人。目標是建一套系統，讓它邊做邊累積經驗。（本段字幕到此中斷）

Every 為什麼從「每人一個 agent」改成「單一 agent」？