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

🧑‍🏫 這是三位創辦人對談的最後一段，談三件事：怎麼評估 AI 產品做得好不好（eval，就是一套拿來幫 AI 打分數的測試題）、新模型推出時怎麼換過去，以及用 Claude Managed Agents 要付出多少成本、交出多少控制權。Claude Managed Agents 是 Anthropic 提供的服務，幫你把 agent 的執行環境都架好。想把 AI 做成正式產品的人，可以從這段看到真實團隊踩過的坑，以及他們怎麼取捨。

• 23:08 PR merge 後，會判斷要不要更新 analytics、補 instrumentation，並在對方剛送出的 PR 上再發自己的 PR
  ↳ PR（工程師提交程式修改、請人審核的單子）合併後，agent 會判斷新功能要不要補 instrumentation（記錄使用行為的程式），讓數據分析準確，並直接再發一張修改單補上。
• 23:08 夜間流程檢查前一天的狀況：funnel 轉換率有沒有一夜下滑，或 30 天內有沒有週對週的輕微退化
  ↳ 每天晚上自動檢查前一天的數據：funnel（漏斗，使用者從進來到完成目標、一路流失的比例）有沒有一夜之間掉下去，或近 30 天有沒有每週都退步一點。
• 23:38 發現退化時，回頭看 4 週前改了什麼，再開始建議修正
  ↳ 抓到數據變差時，不只看昨天，而是回頭查 4 週前改過哪些東西，找出可能的原因，再提出修正建議。
• 23:38 也評估 agentic conversations：人和 agent 的對話進行得如何、錯誤率是否比平常高，必要時建議修改 prompt
  ↳ 除了數字，也檢查使用者跟 agent（能自己執行多步驟任務的 AI）的對話順不順、出錯是否比平常多；需要時會建議修改 prompt（給 AI 的指令文字）。
• 23:38 目標是 self-healing software：大家快速提交變更時，觀察真實使用者的行為（eval set 也要有），進而理解並建議修正
  ↳ 目標是「會自我修復的軟體」：團隊改得再快也不怕，因為系統會觀察真實使用者怎麼用，再搭配 eval set（評估用的案例集），自己看懂問題並建議怎麼修。
• 24:11 主持人的經驗：精心整理的 eval set 若不符合使用者的實際分布，就算 hill climb 上去也沒意義，使用者不在乎
  ↳ 主持人提醒：精心挑選的測試題如果跟使用者實際會碰到的情況比例不一樣，就算 hill climb（針對測試一步步把分數拉高）也沒用，使用者根本不在乎。
• 24:41 Phase zero 靠 vibes；等東西好到自己喜歡了，才用 hill climb 讓它在所有情境的分布上都表現好
  ↳ 最早期先憑 vibes（感覺）調，調到自己用起來滿意為止；之後才靠測試分數逐步優化，讓它在各種情境下都表現好，而不只是自己常用的那幾種。
• 24:41 先在內部收集回饋很容易，但有過度貼合自家公司使用者的風險，接下來要向外部使用者收集資料和回饋
  ↳ 先讓公司同事試用、給回饋最容易，但有 overfitting（過度貼合）的風險，變成只合自己人的口味；所以下一步要去收外部使用者的資料和回饋。
• 25:12 用 thumbs up／thumbs down 蒐集使用者對功能結果的回饋；使用者夠多時，很快就能整理出不錯的 eval set
  ↳ 在功能結果旁邊放讚／倒讚按鈕收回饋；用的人一多，這些實際案例很快就能整理成一套像樣的測試題。
• 25:12 eval 分成幾個 cohort：regression 用、困難情境與不同資料切分用、依 agent 被指派的任務類型分；每一組再配上 rubrics
  ↳ 測試題分成幾組（cohort）：一組專抓 regression（原本好好的功能被改壞），一組放刁鑽情境和不同資料，一組按 agent 的任務類型分；每組各配一套 rubric（評分標準）。
• 25:44 offline evals 的 rubrics 最好盡量和實際 outcomes 對齊
  ↳ offline eval（上線前用固定題目做的離線測試）的評分標準，要盡量對準使用者實際得到的結果，不然分數再高也不代表真的好用。
• 25:44 另一位講者：他們曾經很難做出好的 eval；由銷售團隊 dogfood 雖然有幫助，但不能代表真實客戶
  ↳ 另一位講者說他們以前很難做出好的測試；讓銷售團隊 dogfood（自己人拿自家產品來用）雖然有幫助，但業務的用法代表不了真實客戶。
• 26:14 有效的做法：看真實客戶的查詢，直接問那位使用者為什麼這樣下、想找什麼、想要什麼，再據此建立 eval，避免 eval 太抽象
  ↳ 有效的做法：看真實客戶下了什麼查詢，直接去問本人為什麼這樣問、想找什麼，再照這些來出題，測試才會貼近實際需求、不會太空泛。
• 26:45 有 live memory、高度 stateful 的系統還沒找到好的 eval 方法：可以做 trajectory evals，但依賴外部狀態的 offline 結果 eval 仍未解決
  ↳ 有 live memory（會持續記住、更新資訊）的系統，狀態一直在變（stateful），很難評。可以檢查過程步驟（trajectory eval），但結果取決於外部狀態的離線評估還沒解。
• 26:45 MCP 呼叫第三方服務、狀態會隨時間改變（例如依賴 Slack MCP），很難建立不會漂移的系統化 eval；全部 mock 工程太大，mock 客戶的 Slack 不太可行
  ↳ 透過 MCP（讓 AI 連接外部工具的標準介面）讀 Slack 這類第三方服務時，內容天天在變，測試結果會漂移；要整個 mock（假造模擬）客戶的 Slack，工程太大、不實際。
• 27:16 主持人問 model migration：新的 Opus 推出時怎麼辦、要不要改 prompt、怎麼測試新模型
  ↳ 主持人問：新版 Opus（Claude 最強的模型系列）推出時你們怎麼換？要改 prompt 嗎？怎麼確認新模型真的比較好？
• 27:47 回答：有好的 eval suite 就直接做 migration，前提是 prompt 過去沒有對特定 model family 過度最佳化
  ↳ 回答：有一套好的測試，就直接換過去、跑測試看結果；前提是 prompt 過去沒有特別遷就某一代模型的習性，不然一換就容易出問題。
• 27:47 新模型常有各自的 gotcha，例如 five series 模型的寫作 AI 痕跡更明顯：em dash 更多、句構難讀
  ↳ 每個新模型都有自己的小地雷（gotcha）。例如 5 系列模型寫出來的東西「AI 味」更重：破折號（em dash）變多、句子結構繞口難讀。
• 28:20 對他們最有價值的是知道新模型特有、需要避開的 failure modes；從 prompt 榨出最後 1% 則沒那麼在乎，因為每一代都會進步
  ↳ 他們最想知道的是新模型特有、要避開的毛病（failure mode）；至於把 prompt 調到再多擠出 1% 的表現，不太在意，反正每一代模型都會進步。
• 28:51 做 agent 的人都會在意成本；完全不在意成本，很難建立能長期擴展的永續商業模式
  ↳ 做 agent 的人都得顧成本；如果完全不管花多少錢，就很難做出能長期撐下去、規模變大也還能賺錢的生意。
• 28:51 內部常討論：要依賴 Claude Managed Agents 多久？成本、價值與控制權的取捨到什麼程度，就該改成自建
  ↳ 他們內部常討論：Managed Agents 要用到什麼時候？成本、價值和控制權的取捨，要到什麼程度才該改成自己架？
• 29:23 Managed Agents 在基礎設施 CPU overhead 上的加價看起來不高；但目前不容易跑 batch mode，若能提前 24 小時執行，可能省下 50%–75%
  ↳ Managed Agents 在運算資源上加收的費用看起來不高；但目前不太能用 batch mode（不急的工作排隊處理、換取較低價格），如果能提前 24 小時跑，可能省 50%–75%。
• 29:23 現階段優先為使用者創造價值；成本上要成熟、有意識、花得值得，細節之後再慢慢優化
  ↳ 現階段最重要的是先替使用者創造價值；花錢要有意識、花在刀口上，細部的省錢之後再慢慢做。
• 29:53 成本 attribution 問題：成本到底在 agent harness 的哪個環節累積
  ↳ 成本 attribution（歸屬）的問題：一次任務的錢，到底是花在 agent harness（包住模型、負責呼叫工具和控管流程的那層框架）的哪一個環節？
• 30:24 使用 Managed Agents 等於讓出部分控制權，但目前仍是最佳方案；希望有更細緻的 telemetry，知道每個呼叫花了多少
  ↳ 用 Managed Agents 等於交出部分控制權，但目前仍是最好的選擇；他們希望有更細的 telemetry（系統回報的運作數據），看得出每次呼叫各花了多少錢。
• 30:24 晚間的大型 batch 流程處理大量資料，可能很貴；目前可以用很低的工程成本處理，例如降低頻率、少送資料；規模和成熟度到了會想要更多控制
  ↳ 每晚處理大量資料的批次流程可能很貴；現在用很簡單的方法就能壓低成本，例如少跑幾次、少送點資料。等規模變大、產品成熟，就會想要更多掌控。
• 31:25 改進期望有兩項：成本、使用者體驗。需要 frontier intelligence 的部分用 Opus 等模型，價格算合理；有些部分不需要那麼高的智慧，或用量太大用不起
  ↳ 他們希望改進兩件事：成本和使用體驗。需要 frontier intelligence（最頂尖的 AI 能力）的部分用 Opus，價格算合理；但有些環節不需要那麼聰明，或用量大到用不起。
• 31:25 Watchtower 例子：協調搜尋的主 agent 需要 frontier intelligence，但 fan out 到 500 個帳戶時不能照做，改用便宜很多的模型
  ↳ Watchtower 的例子：負責統籌搜尋的主 agent 要用頂尖模型；但要 fan out（同時分派出去）到 500 個帳戶執行時，不能照樣用，改用便宜很多的模型。
• 31:55 Claude Managed Agents 的產品結構讓成本優化很受限，某種程度是 all or nothing，能調整成本的手段不多
  ↳ Managed Agents 的產品設計讓省錢的空間很有限，有點「全用或全不用」的味道，可以調整成本的方法不多。
• 32:26 主持人：現有手段有 effort、multi-agent、多種模型；講者：flex 或 batch mode 會很有幫助，直接省 2X、50%
  ↳ 主持人說現在能調的有 effort（模型要花多少力氣思考）、multi-agent（拆給多個 agent 做）、換用不同模型；講者說如果有 flex 或 batch 這種慢一點換便宜的模式，直接省一半。
• 32:26 UX 方面：在 latency 敏感的功能，想用各種巧妙方式 pre-warm sandboxes，降低 cold start latency
  ↳ 體驗方面：對反應速度敏感的功能，他們想用各種方法預先把 sandbox（agent 做事的隔離環境）準備好，減少 cold start latency（從零啟動要等的時間）。
• 32:56 Managed Agents 最適合：需要 frontier intelligence、對價格較不敏感、任務難到要跑好幾分鐘、不在乎幾秒差距，能讓他們很快上線；其他情境改善 UX 或降價的手段不多
  ↳ Managed Agents 最適合：需要頂尖智慧、對價格不敏感、任務本來就要跑好幾分鐘、多等幾秒也無所謂，能讓團隊很快上線；其他情況下，能改善體驗或降價的手段不多。
• 33:29 如果優化成本或取得控制權能讓你做出原本做不到的東西，就很值得；成本不降 90% 就做不出的功能，就得想辦法解決
  ↳ 判斷標準：如果省錢或自己掌控，能讓你做出原本做不到的東西，就值得投入；像成本不降 90% 就做不出來的功能，就一定得想辦法解決。
• 33:29 例如打造 Jarvis 語音控制的 chief of staff，很可能得自己做 harness；但不代表所有東西都要自建
  ↳ 例如想做一個像 Jarvis（鋼鐵人電影裡的 AI 管家）那樣用聲音指揮的「幕僚長」，大概得自己打造 harness；但這不代表所有東西都要自己做。
• 33:59 系統本來就是有些部分完全自建、有些部分依賴外部服務
  ↳ 實際的系統本來就是混搭：有些部分完全自己做，有些部分交給外部服務，不必二選一。
• 33:59 在 Mihir 提的三個準則之外，另一位講者補第四個：驗證可行性（validating viability）時，實驗的成本在於學習所花的時間，這時也很適合用
  ↳ Mihir 提了三個適合用的情境，另一位講者再補第四個：還在驗證點子可不可行的階段，實驗最貴的是學習花掉的時間，這時用 Managed Agents 快速試最划算。

在 Watchtower 的例子中，agent 要 fan out 到 500 個帳戶時，講者怎麼控制成本？