教 agent 向你的團隊學習（第 2/2 段） ☕ Buy me a coffee

🧑‍🏫 這段是影片後半，講者分享他們團隊的 agent（會自己判斷、執行多步驟工作的 AI 助手）Buzz，怎麼從團隊平常的工作裡自己學習、越用越好。重點不在把指令一次寫完美，而在設計一個讓 AI 持續進步、團隊又幾乎不用多花力氣的機制。只要你手上有重複性的 AI 工作流程，這套思路都用得上。

• 14:18 教 agent 學習的方法：說明為什麼某個結果比較好，再請它比較自己的產出、使用者的回饋和 instructions，找出差距在哪
  ↳ 別只告訴 agent「對」或「錯」，要講清楚好在哪。再請它對照自己的產出、你的意見和 instructions（寫給它的工作說明），自己找出差在哪裡。
• 14:18 請 agent 想一想：instructions 要怎麼寫，它才會產出跟理想預期結果一樣的東西
  ↳ 與其每次由你幫它修，不如直接問它：「說明要怎麼寫，你下次才會直接做出這種結果？」讓它自己動手改說明書。
• 14:48 把這套學習流程包成另一個 skill，效果很好
  ↳ 這套「比對、找差距、改說明」的步驟本身也寫成一個 skill（agent 可重複使用的能力說明檔）。之後它每次都照同一套方法學習，講者說效果很好。
• 14:48 至此有兩個元件：一是彈性、能套用到新情境的原則（principles），二是讓 agent 能擴充自己 instructions 的學習方式
  ↳ principles 是有彈性的做事原則，遇到沒見過的狀況也能套用。加上會自己擴寫說明的學習方式，agent 就同時具備「知道怎麼做」和「會變強」兩個基礎。
• 15:21 下一個問題是誰來持續教它：來回給資料和回饋很花時間，講者不想再多開會，也不想多一個輪值任務
  ↳ 會學還不夠，總得有人持續給它範例和意見，這很花時間。講者明說不想為此多開會，也不想多排一個輪流教 agent 的班。
• 15:21 目標是讓 agent 從團隊原本就在做的事情學習，用團隊最少的輸入換到 agent 最大的進步
  ↳ 理想做法是不叫團隊額外做事，讓 agent 從大家本來就在做的工作裡撿資訊來學。團隊付出越少越好，agent 進步越多越好。
• 15:52 他們設計了一個回饋迴圈，團隊每天幾乎不用多做事，agent 仍然能向團隊學習
  ↳ 所以他們設計了 feedback loop（回饋迴圈）：每天自動收集團隊的日常動作當作回饋，讓 agent 據此改進，團隊幾乎不用多花力氣。
• 15:52 Buzz 負責監看 mentions 並協助判斷怎麼處理，但真正跟使用者互動時仍由人工處理，以保持真誠、重視使用者體驗
  ↳ Buzz 負責盯 mentions（社群上提到 Warp 的貼文），並建議該怎麼處理。但真正回覆使用者的一律是真人，這樣才顯得真誠、尊重使用者。
• 16:22 Buzz 分流 mentions，幫團隊判斷哪些要處理、哪些不用管，省下很多時間
  ↳ 這就是 triage（分流）。像急診先分輕重，Buzz 先把大量貼文分成「要處理」和「不用管」，團隊只看值得看的，省下大把時間。
• 16:22 Buzz 會在 Slack 頻道發訊息：有哪則 mention、建議怎麼做、為什麼，也會說明它的想法，讓團隊快速進入狀況
  ↳ Buzz 會在 Slack（團隊聊天工具）的頻道貼訊息，寫明是哪則貼文、建議怎麼做、理由是什麼。大家一看就懂來龍去脈，不用自己再查。
• 16:52 團隊把這個頻道當一般團隊頻道來看；訊息大量使用 Slack 的結構化格式，方便快速瀏覽、減少負擔
  ↳ 對團隊來說，這個頻道跟平常的工作頻道沒兩樣。Buzz 的訊息用標題、條列等格式整理好，掃一眼就抓得到重點，讀起來不累。
• 16:52 團隊用 emoji reaction 標示實際採取的行動，例如真的回覆了就加一個打勾
  ↳ emoji reaction 就是在訊息上按表情符號。團隊用它記錄自己實際做了什麼，例如真的回了那則貼文，就在 Buzz 的訊息上按個打勾。
• 17:23 Buzz 比對自己的建議和團隊實際做了什麼，從兩者的差距歸納出心得；團隊也能在 Slack thread 裡留 notes
  ↳ Buzz 會拿「我建議的」對照「大家實際做的」，不一樣的地方就是學習素材。想多說明的人，也可以在 thread（訊息底下的討論串）留話。
• 17:56 團隊本來就用 emoji reaction 避免重工、追蹤哪些已處理，Buzz 就直接從這些「麵包屑」學習
  ↳ 按表情本來就是團隊的習慣，用來標示「這則處理過了」，避免兩個人重複回覆。Buzz 只是順手讀這些既有的痕跡，所以團隊不用多做任何事。
• 17:56 Buzz 歸納出怎麼改進 instructions 後會開 pull request；所有 skills 都放在 Git repo，當成程式碼管理，團隊每天看這些 PR
  ↳ Buzz 想好怎麼改說明後，會開 pull request（PR，提出修改、等人審核的請求）。所有 skill 都放在 Git repo（保留每次修改紀錄的檔案庫），像程式碼一樣管理。
• 18:26 心得一：保持簡單。設計回饋迴圈最難的是人，太複雜、太花時間或偏離日常流程，人就不會做
  ↳ 設計回饋機制最難的不是技術，而是人。只要步驟太多、太花時間，或要離開平常的工作流程，大家就會懶得做，迴圈也就斷了。
• 18:57 心得二：讓 agent 感覺像隊友。有名字、有點個性和趣味，人跟它的互動會更有意義，給的回饋也更有價值
  ↳ 幫 agent 取名字、給它一點個性，大家會把它當同事而不只是工具。互動時比較願意把話講清楚，給的回饋品質也就更高。
• 18:57 最後補上缺口的是這個每日迴圈，讓 agent 持續變好、結果持續改善，也省下更多時間和心力
  ↳ 前面已經有原則和學習方法，但還缺持續的資訊來源。每天自動跑的迴圈補上了這塊，agent 才能不斷變好，團隊省下的力氣也越來越多。
• 19:28 三者缺一不可：principles 讓 agent 知道要做什麼、教它學習讓它越來越好、每日回饋迴圈提供改進所需的資訊
  ↳ 三件事各管一段：principles 決定怎麼做事，學習方法讓它會自我修正，每日迴圈提供修正所需的真實資料。少了任何一個，整套就轉不起來。
• 19:59 實例：Buzz 的 skill 檔放在一般的 GitHub 介面，大約 15 個 skills，而且會因為一直加新功能而持續增加
  ↳ Buzz 的 skill 檔就放在一般的 GitHub（常見的程式碼存放網站）頁面上，目前大約 15 個。因為一直在加新功能，數量還會繼續增加。
• 19:59 warp reply skill 負責草擬訊息，並決定哪些要回覆、哪些跳過、哪些按讚
  ↳ warp reply skill 專門處理回覆：幫忙擬草稿，並判斷每則貼文該回覆、跳過，還是按個讚就好。
• 20:31 這個 skill 寫的是原則，不是「某人提到某功能就說 ABC、附某個文件連結」這種規則，讓它能讀懂 Twitter thread，判斷使用者需要什麼
  ↳ 它寫的是判斷原則，不是「提到某功能就回某句話、附某個連結」的死規則。這樣它才讀得懂整串推文的脈絡，推測使用者真正需要什麼。
• 21:06 Slack 頻道中的「建議回覆」附有推理（使用者想要什麼）和草稿；團隊以它為基礎，通常會再改成自己的話
  ↳ Slack 裡的「建議回覆」會附上兩樣東西：它推測使用者想要什麼，以及一份草稿。團隊拿草稿當底，通常會再改成自己的說話方式。
• 21:37 草稿先備好正確的語氣、風格、資訊和內容，等於省下 90% 的工夫，留給團隊最有價值的 10%
  ↳ 語氣、風格和該給的資訊，草稿大多已經備好，團隊只需要做最後的潤飾和把關。講者形容省掉九成工夫，把人力留給最有價值的那一成。
• 21:37 「跳過的回覆」是講者最喜歡的：對方在跟別人說話或聊別的事，團隊完全不必看、也不必插話
  ↳ 很多提到產品的貼文，其實是別人在跟朋友聊天，或在講別的事。Buzz 直接標「跳過」，團隊連看都不用看，也不會硬插話顯得尷尬。
• 22:08 也可能只建議按讚：例如使用者說 Warp 很酷，不一定要回話，按讚表示感謝就很有價值
  ↳ 有時候不必回話。例如有人說 Warp 很酷，按個讚表示「我們看到了、謝謝」就夠了，既有溫度又不打擾對方。
• 22:38 回饋範例：講者在 thread 留 note 給 Buzz，說在這種情況下不該糾正使用者（使用者只是問功能在哪）
  ↳ 實際例子：使用者只是問某個功能在哪裡，Buzz 卻想糾正他。講者就在 thread 留言告訴 Buzz 這種情況不該糾正，這則留言就成了它的學習素材。
• 23:09 Buzz 每天執行一次，檢視 emoji reaction 的差異和各個 thread，歸納心得、開 PR，並簡短說明改了什麼、附上 PR 連結
  ↳ Buzz 每天自動跑一次：比對大家按的表情和自己的建議差在哪、讀過討論串留言，整理出心得並開 PR，再貼一段簡短說明和 PR 連結。
• 23:09 資訊是主動推送給團隊的，不用自己去拉；而且都在 Slack，跟團隊原本的工具和流程一樣，摩擦極低
  ↳ 團隊不用主動去查 Buzz 學了什麼，它會自己把結果送到面前。而且都在大家每天本來就開著的 Slack 裡，不用多開工具，幾乎沒有阻力。
• 23:39 每天早上點連結審 PR，大約 60 秒就能看完，因為只有幾行英文，團隊也清楚它做了什麼
  ↳ 講者每天早上點連結看 PR，大約一分鐘就看完。因為改動通常只有幾行英文說明，一看就知道 Buzz 改了什麼。
• 24:13 Buzz 不會只在清單最後隨便加一條規則，而是看過目前的 instructions，在最適合的地方調整
  ↳ Buzz 不會在說明最後面一直堆新規則，而是先讀過整份現有說明，再把修改放進最適合的段落，說明才不會越改越亂。
• 24:13 透過一般的 PR 審查流程，沒問題就 merge；講者也喜歡直接快速修改措辭，保有一些掌控
  ↳ 審查走一般的 PR 流程，沒問題就 merge（把修改正式併進去）。講者也常自己順手改幾個字，保留一點主導權。
• 24:49 要人工審查，是因為不想讓 agent 隨意改自己的 instructions、往奇怪方向偏移又越陷越深，團隊要知道它在做什麼
  ↳ 一定要有人審，是怕 agent 自己亂改說明，每次偏一點，累積下來越走越歪卻沒人發現。有人工把關，團隊才知道它正在變成什麼樣子。
• 24:49 數據：每月約幾千則 mentions，其中 50% 被跳過，省下大量時間，這很適合交給 agent
  ↳ 他們每個月有幾千則 mentions，其中一半根本不用處理。這種量大、重複、又需要一點判斷的篩選工作，很適合交給 agent。
• 25:20 15 個 skills 涵蓋分流、寫貼文、報告、分析等工作
  ↳ 目前約 15 個 skill，工作範圍不只分流，還包括寫貼文、做報告、做分析等。
• 25:20 例如講者每天會收到 Buzz 的 DM，裡面有它產生的圖表：各種行動的分布、誰回覆了多少，當作健康指標
  ↳ 例如 Buzz 每天會私訊講者，附上自己畫的圖表：各種處理方式各占多少、每個人回了幾則。講者用這些數字判斷整個流程有沒有正常運作。
• 25:51 每月有幾千次 cloud agent 執行，全部在雲端背景跑；使用的是 Oz，Warp 用來執行 cloud agents 的 orchestration 平台
  ↳ cloud agent 是在雲端自己執行、不需要你開著電腦的 agent，他們每月跑幾千次。用的是 Oz，也就是 Warp 用來調度（orchestration）這些 agent 的平台。
• 26:22 它依排程和各種 trigger 執行，概念跟昨天介紹的 routines 相似：API 呼叫、webhook、cron job 等觸發 agent 在雲端執行，不用跟它對話就能完成工作
  ↳ agent 會依排程或觸發條件自動開工，例如別的程式呼叫、webhook（其他系統有動靜就通知它）、cron job（定時執行）。概念跟昨天介紹的 routines 類似，不用跟它對話就能完成工作。
• 26:56 重點是依自己的使用情境設計合適的回饋迴圈，而不是一開始就想把 prompt 寫到完美
  ↳ 與其花大把時間把 prompt（給 AI 的指令）一次寫到完美，不如依自己的工作情境，設計一個能持續收集回饋、讓它自我修正的機制。
• 27:30 全場只記一件事：專心設計回饋迴圈。初始 prompt 夠好就行，不必完美
  ↳ 講者要大家只記住一件事：把力氣花在設計回饋迴圈上。一開始的指令夠用就好，不完美也沒關係，之後會靠迴圈慢慢補齊。
• 28:02 讓 agent 隨著你對問題的理解演進、新狀況出現而自行改進，不必你回頭手動修改
  ↳ 問題會變、新狀況會冒出來，你自己的理解也會加深。有了回饋迴圈，agent 能跟著一起調整，你不必每次都自己回頭改指令。

根據影片，Buzz 如何得知團隊對某則 mention 實際採取了什麼行動？