新創創辦人如何用 Claude Managed Agents 打造產品（第 1/3 段）

🧑‍🏫 這支影片請三位創辦人分享他們怎麼用 Claude 的 Managed Agents 做產品。Managed Agents 是一個平台，讓你不用自己從零開始，也能把 agent 做成產品功能；agent 就是能自己分好幾個步驟把事情做完的 AI。三個人各談一個實際問題：怎麼確認 AI 的結果是對的（outcomes）、怎麼讓 AI 越用越懂你們公司（memory）、怎麼安全處理客戶的程式碼（sandboxing）。想知道 AI 助理放進真實工作後會卡在哪裡，這支很值得看。

• 00:07 Sahaj 把會議分成會前、會中、會後三段。大多數人只想到會中，但 agent 最能發揮的是幫你準備會議，以及會後把事情執行完
  ↳ 大家想到 AI 幫忙開會，多半只想到開會的當下。Sahaj 認為 agent 更該用在會前幫你做功課，以及會後幫你把答應的事辦完。
• 00:38 Sahaj 團隊用 Managed Agents 開發新功能，包括會前準備用的 briefs，以及會後的 tasks 與任務自動化
  ↳ 他們用 Managed Agents 補上會前和會後兩段：會前有 briefs，就是見面前給你的重點資料；會後有 tasks（待辦事項），還能自動去執行。
• 00:38 Mihir 的產品是給業務團隊用的 agents，核心是每個客戶帳戶（account）都有一個持續運作的 agent，它會累積 memory，並想辦法推進這個帳戶
  ↳ Mihir 的產品給業務團隊用。每個客戶帳戶（account）都配一個長期運作的 agent，它會累積 memory，也就是記住過去的往來，並主動想辦法推進這筆生意。
• 01:08 業務團隊有很多跨帳戶的工作，例如業務要問今天該先跑哪五個帳戶，主管要問下一季該 forecast 哪些 deals
  ↳ 業務的工作不只看單一客戶。業務每天要決定先跑哪幾家，主管要 forecast（預估）下一季哪些 deals（案子）會成交，這些都得同時看很多帳戶。
• 01:08 他們做了 Watchtower，負責跨帳戶的報表、彙整和 roll-ups。這個 agent 的形態和單一帳戶的 agent 很不一樣，需要不同的工具和功能
  ↳ 所以他們另外做了 Watchtower，專門跨帳戶做報表、做 roll-ups（把分散的結果往上彙總）。它要看全局，需要的工具跟只顧一家客戶的 agent 很不一樣。
• 01:08 Watchtower 用 Managed Agents 兩週就做出來，現在是他們最常被使用的功能之一，也支撐產品的很多其他部分
  ↳ Watchtower 用 Managed Agents 兩週就做出來，現在是他們最常被用的功能之一，產品裡很多其他部分也要靠它才能運作。
• 01:08 Todd 的產品是產品分析方案，會整合進應用程式，記錄使用者實際怎麼用，再把資料回饋出去，讓產品變得更好
  ↳ Todd 做的是產品分析工具。它裝進別人的應用程式裡，記錄使用者實際怎麼點、怎麼用，再把這些數據回饋給團隊，拿來改進產品。
• 01:38 開發速度越來越快，應用程式的埋點（instrument）就越難做，也越難看出分析資料和實際狀況在哪裡出現落差
  ↳ 要記錄使用者的行為，得先在程式裡埋點（instrument），也就是插入記錄用的程式碼。現在產品改得越來越快，埋點容易漏掉，數據跟實際狀況對不上也不容易發現。
• 01:38 Todd 做了一個放在平台前端的新 agent，負責把 codebase 在做的事和實際發生的事連起來
  ↳ 所以 Todd 在平台最前面加了一個 agent，負責對照 codebase（產品的整套原始碼）「寫了什麼」和使用者「實際發生什麼」。
• 01:38 他們用 Managed Agents 對 codebase 拍 snapshot，和應用程式的實際狀況比對，再主動發送洞察，甚至直接送出修正
  ↳ 做法是對原始碼拍 snapshot（某個時間點的完整副本），拿去跟應用程式的實際狀況比對。發現落差就主動通知，甚至直接送出修好的程式碼。
• 02:09 Briefs 會告訴你：要見的是誰、為什麼跟你有關、雙方約好談什麼、這場會議要拿到什麼，還有幾週前你可能已經忘記的前情
  ↳ Brief 也叫 pre-read，就是開會前要先讀的資料。內容包括對方是誰、跟你有什麼關係、約好談什麼、這場要拿到什麼，還有你幾週前可能已經忘了的往來。
• 02:41 Briefs 只有內容正確才有價值。如果把另一個同名的 Tom 的資料給你，進了會議反而會讓人更混亂，幾乎是有害的
  ↳ Brief 最怕給錯。如果抓到另一個同名 Tom 的資料，你帶著錯誤印象走進會議，會比完全沒準備還糟。
• 02:41 能判斷 agent 有沒有產出正確結果，錯了就乾脆什麼都不給使用者看，這比給出 false positive 的資訊好太多
  ↳ 所以寧可不給也別給錯。false positive 是指看起來對、其實是錯的資訊。只要能判斷出結果有錯，乾脆不顯示，對使用者反而比較好。
• 03:14 Outcomes 提供一個完全獨立的評估者，檢查 agent 的結果對不對，也確認來源標註正確，讓顯示給使用者的內容都是對的
  ↳ Outcomes 是 Managed Agents 的一個功能：另外安排一個完全獨立的評審，檢查 agent 的結果對不對、資料來源有沒有標清楚，確保使用者看到的都是正確的。
• 03:14 Outcomes 也能帶動 feedback loop。越能即時評估，就越能把這些要求放進最初的 agent loop，讓它一開始就做對
  ↳ 評審也能形成 feedback loop（回饋循環）。評得越即時，就越能把這些要求提早放進 agent loop（agent 做事的流程）裡，讓 agent 第一次就做對。
• 03:14 主持人的定義：outcome 就是給 agent 一份 rubric，讓 agent 反覆修改，直到符合 rubric 為止
  ↳ 主持人的定義：outcome 就是給 agent 一份 rubric（評分標準表）。agent 交出成果後按表打分，沒過就修改，改到符合標準為止。
• 03:44 Rubric 會列出所有影響使用者判斷 pre-read 是否有效的項目。有些可以客觀驗證，例如有沒有抓到那個人正確的 LinkedIn
  ↳ Rubric 會列出所有讓使用者覺得這份 pre-read 有用的條件。有些可以客觀檢查對錯，例如抓到的 LinkedIn 頁面是不是真的是這個人。
• 04:15 Rubric 也評估呈現方式：資訊要容易掃讀和閱讀。會前給五頁的 pre-read 不會有人看
  ↳ Rubric 不只檢查內容，也看好不好讀。開會前丟給人五頁資料，根本沒人會看，所以要讓人一眼就能掃到重點。
• 04:15 呈現順序也很重要：先說這個人是誰，再說為什麼要見他，最後說要做什麼。順序錯了一樣難讀
  ↳ 順序也在評分範圍內：先講對方是誰，再講為什麼要見面，最後講要做什麼。資訊都對但順序亂掉，讀的人一樣抓不到重點。
• 04:46 他們把每一項希望使用者得到的 UX 都轉成 rubric 的一部分，再針對這份 rubric 做 hill climb
  ↳ 他們把希望使用者感受到的每一項 UX（使用體驗），都寫成 rubric 裡的一條，再做 hill climb，也就是對著這份標準一步步改進。
• 04:46 這些在 runtime 執行：會議前 agent 先啟動並產出 brief，然後在會議前的一段時間內，反覆拿 outcomes 評分
  ↳ 這不只是開發時測一測，而是在 runtime（產品實際運作時）進行：會前 agent 先產出 brief，接著在開會前這段時間，反覆用 outcomes 打分、修改。
• 05:16 他們會在會議前 24 小時執行，讓評估有夠長的時間可以做
  ↳ 他們在會議前 24 小時就開始跑，讓評分和修改有足夠的時間。
• 05:16 做事的 agent 和評估的 agent，對「結果正不正確」的判斷通常是彼此獨立的
  ↳ 做事的 agent 和評分的 agent，對「結果對不對」通常是各自判斷的，評分的那個不會只因為做事的 agent 覺得沒問題就放行。
• 05:16 就算是獨立作業的 agent，也能查看 LinkedIn、email 和行事曆邀請，自己判斷結果大概對不對，就像人赴陌生會議前會先查 LinkedIn 一樣
  ↳ 評分的 agent 就算沒參與製作，也能自己去查 LinkedIn、email 和行事曆邀請來核對，就像你赴一場陌生的會議前，會先上 LinkedIn 查對方一樣。
• 05:47 關鍵在於用一個獨立於工作 trace 之外的東西來評估工作。Managed Agents 使用獨立的 context window 和獨立的 verifier agent，這已內建在 outcomes 裡
  ↳ 關鍵是評分時不能參考做事者的 trace（工作過程紀錄）。Outcomes 已經內建這一點：由獨立的 verifier agent（專門驗收的 agent）另外評分。
• 06:17 如果沒有這個機制，評估就只是 agent loop 本身的一部分。完全獨立、乾淨的 context window，讓你在部署時就能評估工作品質
  ↳ 沒有這個機制，就等於 agent 自己改自己的考卷。context window 是 AI 當下能看到的內容；用一份全新、乾淨的來評，上線後才能可靠地檢查品質。
• 06:17 Sahaj 團隊的用法比較簡單：不一定要反覆修到完美，不確定資訊對不對時就不告訴使用者。做主動型的產品時，這樣是可以的
  ↳ Sahaj 團隊的做法比較簡單：不一定要反覆修到完美，只要不確定資訊對不對，就乾脆不告訴使用者。他們做的是主動推送資訊的產品，這樣做是可以的。
• 06:47 Sahaj 的原則：能幫忙時就幫，不要造成傷害或困擾
  ↳ 他的原則是：幫得上忙就幫，幫不上至少別造成傷害或困擾。
• 06:47 難處在於每家公司都有很多自己特有的概念，例如業務團隊怎麼定義 ownership、怎麼做 forecasting、deals 怎麼運作
  ↳ Mihir 碰到的難題是：每家公司都有自己特有的概念，例如怎樣才算負責這個客戶（ownership）、怎麼做預估、案子怎麼推進，外人不容易懂。
• 07:18 原始資料通常很亂，例如每家公司的 Salesforce 都有 30 個意思相同、已經停用之類的欄位
  ↳ 原始資料也很亂。講者形容，每家公司的 Salesforce（常見的客戶管理系統）裡都有 30 個意思一樣、或早就停用的欄位，AI 很難判斷該看哪一個。
• 07:18 像「下一季該 forecast 哪些 deals」這種問題很重要，一定要答對，而且牽涉很多因素
  ↳ 偏偏像「下一季該預估哪些案子」這種問題非常重要，一定要答對，而且要考慮的因素很多。
• 07:18 做法一：使用者跟產品互動時學到這些概念，存進 org-wide memory，讓所有其他人拿到越來越好的結果
  ↳ 做法一：使用者跟產品互動時，順便學會這家公司特有的概念，存進 org-wide memory（全公司共用的記憶），之後其他同事問，都會得到更好的答案。
• 07:49 這樣一開始就不用做一大堆設定，系統能很快學會這些概念。使用者第一次提問時，系統會反問釐清，再把答案存起來
  ↳ 好處是一開始不用花大把時間設定。使用者第一次問到某個概念時，系統會先反問釐清，問到答案就記下來。
• 07:49 做法二（Managed Agents 幫上忙的地方）：有些查詢很複雜，需要跨很多帳戶深入處理
  ↳ 做法二是 Managed Agents 幫上忙的地方：有些問題很複雜，必須一次深入看很多個帳戶。
• 08:21 例如有 500 個 deals 要深入分析，可以先做基本篩選，但系統可能需要更深入，這時它會自己寫程式碼來回答，也能做 programmatic tool calling
  ↳ 例如有 500 個案子要深入分析，可以先粗篩一輪；還需要更深入時，系統會自己寫程式來算，也能用 programmatic tool calling（用寫程式的方式呼叫工具）。
• 08:21 系統會先縮小候選範圍，再 fan out 給每個帳戶各一個獨立的 agent 去處理，最後把回饋 roll up 回來
  ↳ 流程是先縮小候選範圍，再 fan out：每個帳戶各派一個獨立的 agent 去細查，最後把各自的結果彙整回來。
• 08:53 總結：一是學會各組織的商業邏輯，而且能套用到做法各不相同的團隊；二是寫程式碼，處理跨大量帳戶的複雜查詢
  ↳ Mihir 總結兩件事：一是學會每家公司的商業邏輯，而且能套用到做法各不相同的團隊；二是靠寫程式處理橫跨大量帳戶的複雜問題。
• 08:53 主持人整理 Mihir 產品的架構：account executive 假設有 100 個帳戶，就為每個帳戶開一個 agent，形成服務這位業務的一組 agents
  ↳ 主持人整理架構：一位 account executive（手上負責一批客戶的業務）如果有 100 個客戶，就開 100 個 agent，組成專門服務這位業務的一組助理。
• 09:24 互動時會學到個人偏好或整個組織的偏好。新產品會看過這組 agents 收集到的所有 memory 並提出建議，主持人稱之為「dreaming」
  ↳ 互動時會學到個人或整個公司的偏好。新產品會把這組 agent 累積的所有記憶看過一遍，再從中提出建議，主持人把這叫做 dreaming。
• 09:24 第一類 memory：每個帳戶的 agent 會一直跑下去，跟著帳戶走完整個生命週期，一邊累積帳戶脈絡，一邊學到可以 roll up 的概念
  ↳ 第一類記憶：每個客戶的 agent 會一直跑，從頭陪著這個客戶走完整個生命週期，一邊累積來龍去脈，一邊學到可以往上彙整的概念。
• 09:54 第二類 memory：做跨帳戶工作時學到的跨帳戶概念，例如 forecasting 或組織內其他流程怎麼運作。這類對 Watchtower 比對單一帳戶更有用
  ↳ 第二類記憶：做跨帳戶工作時學到的規則，例如公司怎麼做預估、內部流程怎麼運作。這類記憶對看全局的 Watchtower，比對單一客戶的 agent 更有用。
• 09:54 Memory 可以想成一個二乘二：單一帳戶 vs 跨帳戶、使用者層級 vs 組織層級。這些用不同方式學到，再拿來強化產品的各個部分
  ↳ 記憶可以畫成四格：一個客戶 vs. 很多客戶、個人 vs. 全公司。每一格學到的方式不同，再各自拿去強化產品的不同部分。
• 10:24 Todd 談 sandboxing：他們會對客戶的原始碼拍 snapshot，這種情況一般都應該放進 sandbox
  ↳ Todd 談 sandboxing，就是把程式放在隔離的環境裡跑，出事也不會波及外面。他們會對客戶的原始碼拍 snapshot，這種情況照理都該放進隔離環境。
• 10:54 使用者和 agent 互動時，agent 如果拿得到原始碼，可能會碰到 secrets
  ↳ 因為使用者跟 agent 互動時，agent 如果讀得到原始碼，就可能碰到 secrets，也就是密碼、金鑰這類不能外流的機密。
• 10:54 要仔細考慮開放哪些工具去碰原始碼、送了哪些資料給它、會發生哪些動作
  ↳ 所以要想清楚三件事：開放哪些工具去碰原始碼、傳了哪些資料給 agent、agent 會做出哪些動作。
• 10:54 互動的最後結果通常是產生一個 pull request，推到實際的 repository
  ↳ 互動最後通常會產生一個 pull request（修改程式的提案，要有人審核後才會正式採用），送進客戶真正的 repository（存放原始碼的地方）。
• 11:29 他們曾花時間自己做 sandbox，但要處理所有 edge case，這不是他們的核心價值主張，只要能正常運作就好
  ↳ 他們花過時間自己做隔離環境，但要處理各種 edge case（少見的特殊狀況）。這不是他們的核心價值，對他們來說只要能正常運作就好。

Mihir 團隊用 Managed Agents 做出跨帳戶報表產品 Watchtower，花了多少時間？