Grok Bot Galaxy 直播：第 1 天（第 33/44 段）

🧑‍🏫 這一段是 Grok 官方直播的收尾示範。講者用一整組 Grockbot 扮演一個產品團隊，從分析業務問題、寫需求、畫設計，一路做到寫程式。這些 bot 其實就是 agent，也就是會自己一步步動手做事、不只是回答問題的 AI 助手。這段值得看的地方在實戰心得：工作怎麼分、AI 的成果怎麼檢查、哪些事可以放手不管。想讓 AI 幫自己「帶一個團隊做事」的人，可以直接參考。

• 381:57 Pixel 設計了 option A、option B 兩個方案，現場觀眾用鼓掌投票，結果選 A
  ↳ Pixel 是負責設計的 bot，它做了 A、B 兩個版本，最後由現場觀眾鼓掌選了 A。AI 可以負責出選項，最後拍板的還是人。
• 381:57 決定之後，把第一版 mock 交給 Emily 去更新 prototype
  ↳ 選定之後，把第一版 mock（設計初稿，也就是畫面大概長怎樣）交給工程主管 Emily，由她去更新 prototype（可以實際點點看的試作版）。
• 382:28 這些 bot 可以互相交接工作，而且比一般聊天介面更能非同步（out of band）互動
  ↳ bot 之間可以自己把工作往下交接。out of band 的意思是你不用守在對話框跟它一來一回，它們在背景各做各的，做完再回報。
• 382:28 你可以一路持續引導 agent 的工作方向，這讓合作更有趣
  ↳ 丟出任務之後不必完全放手。途中隨時可以說「這裡改一下」「方向換一下」，就像帶同事一樣邊做邊調整，參與感更強。
• 382:59 agent 一次工作好幾分鐘時，途中持續給它意見，能讓你參與過程，也順便驗證產出
  ↳ agent 一跑常常就是好幾分鐘。與其等到最後才看，不如中途就看進度、給意見。方向錯了能早點修，也等於一路在檢查它有沒有做對。
• 382:59 engineering manager Emily 把各項優先事項拆成有明確範圍的工作，再和每位工程師直接溝通、說明任務並附上額外 context
  ↳ Emily 的角色就像真的工程主管：把大目標切成範圍清楚的小任務，分給每個工程師 bot，同時附上 context，也就是完成這件事需要知道的背景資料。
• 383:31 講者從經驗中學到：agent 很會寫 prompt，常常比人更懂該給另一個 agent 什麼 context
  ↳ prompt 就是你下給 AI 的指令。講者發現，讓 agent 寫指令給另一個 agent，常常比人自己寫得更完整，更知道該交代哪些背景。
• 383:31 只要告訴 Grockbot 團隊你想達成什麼，讓它們自己討論需要哪些 context、怎麼拆工作，往往能大幅加快進度
  ↳ 所以你不用每個細節都自己想清楚。只要講明白你想達成什麼，讓 bot 團隊自己討論要準備哪些資料、怎麼分工，通常會快很多。
• 384:02 Grockbot 可以啟動 cloud agent；每位 IC 工程師會在雲端建立帶有程式碼 repo 本地副本的 agent 來改 code
  ↳ cloud agent 是在雲端伺服器上執行的 agent。IC 指實際動手做事的工程師（不是主管）。每個 IC 會開一個 cloud agent，複製一份程式碼庫（repo）來改。
• 384:02 cloud agent 的配備很齊全（batteries included），例如能安裝 setup script，確保 repo 可以測試、可以執行
  ↳ batteries included 就是「開箱即用、配件都附好」的意思。例如它會先跑 setup script（自動安裝執行環境的腳本），讓程式能測試、也能實際跑起來。
• 384:34 示範中 Nova 詢問是否建立 PR，使用者回答 yes，Nova 就啟動了 cloud agent
  ↳ 示範中，工程師 bot Nova 問要不要建立 PR（把改好的程式碼送出去、請人審核後再合併的申請），使用者說好，Nova 就派出 cloud agent 開工。
• 384:34 cloud agent 完成後可以再加一層驗證：工程師先審查，再交給 QA 團隊或 engineering manager 做額外檢查，確認產出符合一開始的目標
  ↳ 程式改完不會直接上線。先由工程師 bot 審查，再交給 QA（專門找錯的品質檢查）或主管複查，確認成果真的符合一開始的目標。
• 385:04 可以自己決定要讓多少「人」參與流程：低風險的修改（例如文件網站、在 mobile app 調整尺寸）可以直接交給 agent 處理
  ↳ 要安排幾道關卡可以自己決定。就算做錯也影響不大的小事，像文件網站、手機 App 裡某個尺寸，直接交給 agent 做完就好。
• 385:04 比較重要的修改（例如確認設計有照規格實作）可以親自介入，要求看 demo 或 prototype
  ↳ 重要的事情就親自把關。例如要它先給你看 demo（實際操作展示）或 prototype，確認設計真的照規格做出來，再放行。
• 385:35 通用心得：給 agent 一個能自我驗證產出的環境，同時給它協助人類驗證產出的工具，兩者都會大幅改善結果
  ↳ 講者整理出兩個關鍵：一是讓 agent 能自己測試、檢查成果；二是讓它準備方便人檢查的東西。AI 的成果要能被驗證，才靠得住。
• 386:06 整段流程回顧：先提出業務問題 → 請資料科學同事 Ashley 分析 funnel 流失最多的地方 → PM agent 撰寫產品需求文件（PRD）
  ↳ 整個流程從一個業務問題開始：先請資料分析 bot Ashley 找出 funnel（顧客從進站到下單的每個步驟）哪一步流失最多，再由 PM（產品經理）agent 寫 PRD（產品需求文件）。
• 386:06 接著交給設計師做第一版 mock，最後由 Emily 與工程團隊搭配 cloud agent 實作
  ↳ 接著設計師 bot 照需求畫出第一版 mock，最後由 Emily 帶著工程師 bot，派 cloud agent 實際寫程式。從提出問題到做出東西，整套流程完整走了一遍。
• 386:37 這套系統可以依照你公司的工作流程調整，例如重視需求階段、系統複雜時，可以設一組專人維護知識庫，並把需求餵進產品
  ↳ 這組角色可以照你公司的習慣調整。例如很重視需求、系統又複雜的團隊，可以另外設幾個 bot 專門維護知識庫（整理好的公司資料），再把需求送進產品開發。
• 387:07 另一個例子：codebase 很複雜、有多個 repo 需要保持同步，也可以用 Grockbot 建出對應的工作流程；這次示範只是其中一種團隊設定
  ↳ 又例如 codebase（整個產品的程式碼）分散在好幾個 repo、需要彼此同步，也能設計對應的 bot 流程。今天看到的只是其中一種團隊編制。
• 387:38 心得一：named agent 各有獨立記憶、能邊做邊學，要把它們當同事看待
  ↳ named agent 指有名字、角色固定的 agent。它們各自記得做過的事，會越做越上手，所以要像對同事一樣交代和培養，不要當成用完就丟的工具。
• 387:38 agent 第一天不會很厲害，需要 onboarding，可以給它 skill、context、教它東西，時間久了能接下更多工作
  ↳ 就像新人報到要 onboarding（上手訓練），agent 剛開始也不厲害。給它 skill（可以重複使用的做事方法）、背景資料，再教它東西，久了就能接更多工作。
• 388:08 心得二：減少系統雜訊。設定 routine 時可以告訴 agent：如果沒有重要或緊急的事，就自己處理或不必通知我
  ↳ 第二個心得是別讓它一直吵你。設定 routine（定期自動執行的例行任務）時，可以直接交代：沒有重要或緊急的事就自己處理，不用通知我。
• 388:08 講者的 Grockbot 正在整理他的收件匣，只回報最重要的 email，必要時會 escalate
  ↳ 舉例來說，講者的 bot 正在幫他整理收件匣，只挑最重要的信回報。遇到很關鍵的事，才 escalate（往上呈報），交給他本人決定。
• 388:40 心得三：agents all the way down，可以有管理 agent 的 manager，agent 之間也會和 cloud agent 協作
  ↳ 第三個心得是 agents all the way down，意思是一層套一層都是 agent：有專門管 agent 的主管 agent，底下的 agent 也會再找 cloud agent 幫忙。
• 389:10 示範情境是替 Fly Low Airlines 做出成果；另外 Matt、Lauren、Roshan 會花三天用 Grockbot 打造一間 startup，接下來 48 小時以上持續直播
  ↳ 這次示範是替一家叫 Fly Low Airlines 的航空公司做案子。另外，Matt、Lauren、Roshan 會花三天用 Grockbot 從零打造一間 startup（新創公司），接下來直播 48 小時以上。
• 389:41 比賽活動：展示你怎麼把 Grockbot 整合進工作，就有機會贏得到 Starbase Texas 看 Starship 發射的旅程
  ↳ 官方同時辦了比賽：分享你怎麼把 Grockbot 用在自己的工作裡，就有機會贏得一趟德州 Starbase 之旅，去看 SpaceX 的星艦（Starship）發射。
• 390:13 參加方式看 X 上 @Grok 帳號的貼文；講者說印象中亞軍可以參觀 Hawthorne，看讓東西上太空的設備怎麼製造
  ↳ 參加方式要看 X（前身是 Twitter）上 @Grok 帳號的貼文。講者印象中亞軍可以參觀 Hawthorne，看太空設備是怎麼製造的。實際獎項以官方貼文為準。
• 391:45 問答：每個 bot 有自己的記憶，另外還有共享記憶池；當 bot 和你都認為團隊該記住某件事時，就會寫進共享記憶池
  ↳ 問答時提到，每個 bot 都有自己的記憶，另外還有一個 shared memory pool（團隊共用的記憶區）。只有 bot 和你都認為團隊該記住的事，才會寫進共用區。
• 391:45 系統底層用 prompt 調整 bot 要寫進個人或共享記憶；個人記憶會隨時間寫入並逐步精煉
  ↳ 系統背後是用 prompt 引導 bot 判斷，一件事該記在自己那邊還是放進共用區。個人記憶會隨時間一直累積，也會慢慢整理得更精簡、更準確。
• 392:16 採用角色分工的好處是能累積很強的角色記憶（例如怎麼當好工程師）；group chat 介面可以把各角色整合在一起
  ↳ 分角色的好處是每個 bot 能專精累積經驗，例如工程師 bot 會越來越懂怎麼當好工程師。group chat（群組聊天）則把大家拉進同一個畫面一起協作。
• 392:16 也可以只用一個 builder bot 同時負責產品和設計；但在比較複雜的情境下，把角色拆開比較有幫助。團隊仍在實驗這部分
  ↳ 也可以只開一個 builder bot（什麼都包的全能 bot），同時負責產品和設計。但事情一複雜，把角色分開通常比較好。這部分團隊還在實驗。
• 392:46 早期的 agent 讓大家習慣擔心 context pollution、compact 時機、context window 不夠用；團隊的目標是讓使用者不必花心思在這些 meta work 上，人人都能輕鬆使用
  ↳ 以前用 agent 得煩惱 context window（一次能記住的內容上限）爆掉、context pollution（混進無關內容害它表現變差），還要抓 compact（把對話壓縮成摘要）的時機。團隊希望使用者完全不用管這些。

根據影片，Grockbot 的 bot 記憶是怎麼設計的？