Ramp 工程師如何在每個環節與 AI agents 協作（第 2/2 段）

🧑‍🏫 這段是 Ramp（美國的企業支出管理公司）分享他們怎麼在公司裡全面使用 AI agent。AI agent 是會自己一步步動手、把任務做完的 AI 助手。內容包括他們自己做的 agent 工具、怎麼管安全和花費、怎麼讓非工程師也用得上，最後給其他公司的技術主管一些建議。想知道一家公司真的大規模用 AI 會是什麼樣子，這段很值得看。

• 10:59 先在腦中想清楚正確的 trace（例如先查 source、再查其他來源、讀相關 repo 的程式碼），再只靠 prompts、tools、skills 把 agent trace 塑造成那樣
  ↳ trace 是 agent 做事的步驟順序。先想清楚老手會怎麼查：先看哪裡、再翻哪裡。再用指令（prompts）、工具、技能包（skills）引導 AI 照這條路走。
• 10:59 模型能力正在指數成長：現在做不好也要相信之後做得到，憑這個信念就先 ship，然後等待
  ↳ 模型進步得很快，今天做不太好的功能，過幾個月可能就做得到。所以他們不等到完美，先 ship（推出給人用），等新模型出來，功能自然會變好。
• 10:59 再加上傳統的 hard controls，例如最小權限原則：從根本上不給 agent 做某些事的機會
  ↳ 光靠指令引導還不夠，還要加上硬性限制（hard controls）。最小權限原則是只給 agent 做事必要的權限，不該碰的東西它根本拿不到。
• 11:29 基礎設施由資安團隊建置：協助設定網路存取政策、取得 keys；資安團隊本身也是這些 agents 的日常使用者
  ↳ 讓 agent 能連網、能用各系統的環境，由資安團隊負責建：他們決定 agent 能連哪些地方，也幫它申請 keys（登入各服務用的憑證）。資安團隊自己每天也在用這些 agent。
• 12:01 持續尋找「確定知道最壞情況、就算程式有 bug 影響也極受限，而且有好處」的問題，拿這把錘子去處理
  ↳ 挑給 agent 做的工作有三個條件：最壞的結果很清楚、就算出錯影響也很小、做成了有好處。符合這些條件的工作，就放心交給 agent 做。
• 12:01 預期生產力會大幅提升（尤其接下來幾個模型），所以正在準備 verification loops，特別是 CI 和 CD
  ↳ 他們預期產出的程式會暴增，所以先把 verification loops（自動驗證機制）準備好。CI 是程式一改就自動測試，CD 是測試通過後自動上線。
• 12:31 模型變聰明後就不再犯某些類型的錯，所以 reviewer 關注的重點要隨時間調整，不值得再把 reviewer tokens 花在那些錯誤上
  ↳ 用 AI 審程式也要花 tokens（AI 用量的計費單位）。新模型已經不會再犯的錯，就別再花資源去盯，把審查力氣留給現在真正會出的問題。
• 12:31 自建 code review bot，建在 Inspect（background agents API）上，會從 memories 拉出特別要檢查的項目
  ↳ 他們自己做了審程式的機器人，建在 Inspect 上。Inspect 是公司內部讓 agent 在背景執行的 API（程式之間互相呼叫的介面）。審查時，機器人會從 memories（過去累積的紀錄）挑出要特別檢查的地方。
• 12:31 有些團隊自己寫 skill files 檢查特定事項，把多年累積的知識寫成檔案，讓大家動得更快
  ↳ 有些團隊把多年踩坑的經驗寫成 skill files（給 AI 讀的說明檔），例如「改這類東西一定要檢查某件事」。AI 會照著檢查，大家不用每次都從頭想。
• 13:02 公司文化是實驗文化：做了東西沒成功也沒關係，重點是嘗試過、動作快
  ↳ 公司鼓勵大家嘗試：做了沒成功不會被怪，重要的是有動手、動作快。這是大家敢把 AI 用在各種地方的前提。
• 13:32 所有工程師都能免費使用所有工具，不設 token 預算或工具預算，也不規定該用哪個；這樣大家比較容易講同一種語言
  ↳ 工程師想用哪個 AI 工具都行，公司全額買單，不設用量上限，也不指定要用哪一套。大家都用過差不多的東西，討論起來比較有共同語言。
• 14:02 Glass 是非技術同仁的 home base，他們每天在這裡跟 coding agent 互動；團隊一開始就認為每個人都該擁有這種能力
  ↳ Glass 是非工程同事的主要工作入口，他們每天在這裡請 coding agent（會寫程式的 AI）幫忙做事。團隊一開始就認定，這種能力不該只有工程師才有。
• 14:02 要 meet people where they are：非技術人員不想看程式碼，技術細節幫不了他們加速，而且有些東西要事先設定好
  ↳ 要配合使用者原本的狀態（meet people where they are）。非技術同事不想看程式碼，技術細節也不會讓他們做得更快，所以環境要事先幫他們設定好。
• 14:34 Inspect 基本上是數位同事，擁有 Ramp builder（產品、工程、設計）會用的工具：GitHub、Linear、Slack、Datadog、Sentry 等
  ↳ Inspect 就像一位數位同事，能用產品、工程、設計人員會用的工具：GitHub（放程式碼）、Linear（追蹤任務）、Slack（聊天）、Datadog 和 Sentry（監控系統、抓錯誤）。
• 14:34 可以請 Inspect 處理 support ticket、修 GitHub issue、看 Sentry error、Linear ticket 或 Zendesk ticket；它在 Modal 上背景執行，透過 web 存取
  ↳ 客服單、GitHub 上回報的問題、Sentry 抓到的錯誤、Linear 或 Zendesk（客服系統）的單，都能丟給 Inspect 處理。它在 Modal（雲端運算平台）上背景執行，用網頁就能操作。
• 15:05 很多人從 Slack 觸發：對話中 @Inspect 請它處理、開 PR 修正或調查
  ↳ 很多人直接在 Slack 對話裡 @Inspect，就像標記同事一樣，請它去調查問題，或開 PR（交給別人審核的程式修改）把問題修好。
• 15:05 在別人的討論串 @Inspect 讓對方看到「原來可以這樣做」，這最後成了 adoption 擴散的主要方式
  ↳ 有人在討論串裡 @Inspect，旁邊的同事就會看到「原來還能這樣用」。這種看別人用、自己跟著學的方式，最後成了 Inspect 在公司裡傳開的主要管道。
• 15:05 現在每個 PR 都有自己的 VM，會跑一段時間，大家可以接手 session、一起協作；全部 link based、multiplayer、開箱即用
  ↳ 現在每個 PR 都配一台 VM（雲端上的虛擬電腦），會開著一段時間。任何人點連結就能接手那次工作（session），多人一起做（multiplayer），不用自己架環境。
• 15:37 有時大家會想回到 local dev；這個專案還沒完全完成，但團隊一直在補 Inspect 需要的額外工具、repo 或 dependency，讓大家能繼續把工作交給背景執行
  ↳ 有時工程師還是想回到自己電腦上開發（local dev）。這件事還沒完全做完，團隊持續幫 Inspect 補上缺的工具、repo（程式碼庫）和 dependency（程式要用的套件），讓大家能繼續把工作交給背景跑。
• 16:08 on call assistant 從一開始就跑在 Claude Code 上：先在本機驗證，建好 skills、MCPs、prompts，讓 AI SRE 能找事故 root cause 並開修正 PR
  ↳ on call 是輪班處理系統故障。這個值班助手從一開始就用 Claude Code（Anthropic 的寫程式 AI 工具）打造。先在本機調好 skills、MCP（讓 AI 接外部工具的標準）和指令，讓這個 AI SRE（負責系統穩定的 AI）能找出故障原因、開 PR 修正。
• 16:08 接著把它打包，放在有 safeguards 和 guardrails 的 container 裡執行
  ↳ 在本機確認可行後，再把整套打包進 container（和其他系統隔開的執行環境），並加上 safeguards 和 guardrails，也就是規定它能碰什麼、不能做什麼的防護。
• 16:38 on call assistant 會處理每個指派給工程師的 incident，包含需要工程師的客服 ticket 和系統層級事故
  ↳ 只要有 incident（事故）指派給工程師，它都會接手處理，包括需要工程師出手的客服單，也包括整個系統層級的故障。
• 16:38 它會在每個事故專屬的 Slack channel 回報扎實的 root cause analysis，incident responders 再跟它互動；從二月底或三月開始運行
  ↳ 每個事故都有一個專屬的 Slack 頻道，它會在裡面貼出扎實的根本原因分析，負責處理事故的人再跟它來回討論。這個助手大約從二月底或三月開始運作。
• 17:08 主持人表示，建在 Claude Code executable 這種 Unix philosophy primitives 上能做的東西非常驚人；他們內部也有很多類似工具
  ↳ 主持人說，Claude Code 這種小而單純、可以自由組合的基本元件（Unix philosophy：一個工具只做好一件事、可以互相串接），拿來組東西能做出很驚人的成果，他們內部也有很多類似的工具。
• 17:08 主持人提到 Claude tag 跟 Inspect 很像：同樣 multiplayer、主動、在 Slack 裡，已經取代很多特定用途的 bot
  ↳ 主持人提到他們的 Claude tag 跟 Inspect 很像：可以多人一起用、會主動做事、就在 Slack 裡面，已經取代了很多只做單一用途的小機器人。
• 17:08 Ramp 看到類似趨勢：現在來自 automations 的 Inspect sessions 已經比人類發起的還多
  ↳ Ramp 也看到同樣的趨勢：現在 Inspect 的工作，由自動化流程（automations）啟動的，已經比人手動叫它做的還多。
• 17:38 automations 由各種 trigger 啟動（每天固定時間排程，或來自外部系統），session 跑完有時會在 channel 或用 DM 通知人
  ↳ automations 靠 trigger（觸發條件）啟動，例如每天固定時間跑一次，或別的系統送來訊號。跑完後，有時會在頻道發通知，或私訊（DM）相關的人。
• 17:38 automations 的建置意外地非常去中心化，他們對此很滿意；也有團隊負責維護特定 abstractions，例如作為許多 automations 基石的 Inspect
  ↳ 這些自動化流程不是公司統一規劃的，而是各團隊自己做出來的，他們很樂見。另外有團隊專門維護大家共用的底層元件（abstractions），例如 Inspect 就是很多自動化的地基。
• 18:08 讓每個人自由打造想要的東西，而且希望越多越好；平台團隊能做的就是把產品做好，讓其他團隊有動機建在上面
  ↳ 原則是讓每個人自由做自己想要的東西，越多越好。平台團隊的角色不是去管，而是把底層產品做好，讓其他團隊自然想建在上面。
• 18:08 平台化的來源：desire paths（很多人想要同樣的東西、或各自做了同樣的東西，平台團隊就做一個穩固版本），加上平台團隊預見模型變聰明後會需要的東西
  ↳ desire paths 原本是指草地上被人走出來的小路。很多人想要同樣的東西、或各自做了一份，平台團隊就做一個穩固的版本；另外也會預先準備模型變強後會用到的東西。
• 18:39 不限制每個人的 tokens 或花費，希望大家能不受限地取用任何等級的智慧
  ↳ 不限制每個人的 tokens 用量或花費，希望大家想用最強的模型就能用，不必先算錢。
• 18:39 改用其他方式控制成本：設好 defaults、使用 batch 和 flex APIs、不是由人類控制的 automations 改用較便宜的模型
  ↳ 成本改用其他方法控制：先把預設選項設好；使用 batch 和 flex API（不急的工作排隊處理，價格比較低）；沒有人在等結果的自動化流程，就改用便宜的模型。
• 19:11 預期會一直使用最新 frontier，所以不希望功能或人 overfit 某個模型的行為
  ↳ frontier 是指當下最強的模型。他們打算一直改用最新的模型，所以不希望功能或員工太依賴某個模型的習性（overfit），不然一換模型就不好用了。
• 19:11 看到有人某個月突然變成 top spender（遠高於平常），會主動詢問在做什麼
  ↳ 如果有人某個月的花費突然衝到全公司最高、遠超過平常，他們會主動去問：你在做什麼？
• 19:41 如果做的東西可平台化，就一起平台化擴大影響、之後再想辦法降成本；如果只是失誤，就協助處理
  ↳ 問完之後，如果對方做的東西值得推廣，就一起把它做成平台讓更多人用，成本之後再想辦法壓；如果只是不小心浪費了，就幫忙處理。
• 20:11 在正 ROI 區間（花在 tokens 的每 1 美元都賺回超過 1 美元），就不該再追求最小化成本
  ↳ ROI 是投資報酬率。只要花 1 美元在 AI 上能賺回超過 1 美元，就是划算的，這時候還一直想壓低花費反而是損失。
• 20:11 預期 fable 等級智慧的成本會隨時間下降，就像過去幾年一樣；希望 Ramp 每個人越早熟悉推進 frontier、讓模型在難題上全力以赴
  ↳ fable 是 Claude 最頂級的模型等級。他們預期這種等級的價格會像過去幾年一樣越來越便宜，所以希望員工越早習慣讓模型全力去解難題越好。
• 20:43 給其他 CTO 的建議：大家不太注意的是變化速度，比起看當下快照，更該看這幾年變化得多快
  ↳ 給其他 CTO（技術長）的建議：別只看 AI 現在能做什麼這張快照，更該看它這幾年進步得有多快。
• 21:13 關注變化速度就能看出智慧與 agency 持續上升的模式，也就是模型能做的事越來越多
  ↳ 盯著進步速度看，就會發現一個規律：模型的聰明程度和 agency（自己判斷、主動把事做完的能力）一直在往上爬，能做的事越來越多。
• 21:13 要為 3 到 6 個月後的情況打造；如果只為今天可用的能力打造，等到 ship 時可能已經太晚；關注 scaling 本身對他們很有幫助
  ↳ 所以要瞄準 3 到 6 個月後模型的能力來做東西。如果只照今天的能力做，等做好推出時可能已經落伍了。持續關注 scaling（模型越做越大、越來越強的趨勢）對他們幫助很大。

根據影片，Ramp 內部的 Inspect 主要是怎麼擴散開來、讓更多人採用的？