AI Engineer onepage/ Warp Oz
Safia Abdalla, Warp · 約 17:14
這支影片在講：把 agent 放進工程流程，不是放任它寫碼
Warp 的 Oz 雲端 agent 平台把複雜度留在平台內：開發者可保有自己的 agent harness，團隊可選 managed 或 self-hosted sandbox，而 issue triage、PR review 與升級人工的門檻則被做成一條可治理的工作流。
Published: 2026-08-22Video ID: L173Z8DpaJg
01 / 問題
Agent 不能脫離流程
讓 agent 直接產碼會把 triage、驗證與不明確需求重新丟回工程師，並沒有真的降低團隊的認知負荷。
02 / 反轉
平台應吸收複雜度
執行環境、conversation state、artifacts 與 review queue 應是平台能力，而不是每個使用者或 agent 自己拼裝。
03 / 解法
保留選擇，統一邊界
同時支援 managed／self-hosted sandbox 與任意 harness，但用一致的狀態、API 和審查路徑把它們收斂。
Signals
影片裡最重要的四個訊號
Open source
20k → 60k
Warp 開源約三個月後，GitHub stars 大幅成長，外部貢獻湧入。
Scale
數千 PR
大量貢獻需要先被 agent triage、研究與提問，而非直接打斷人。
Architecture
多 harness
允許開發者保留慣用 agent，但統一保存對話狀態與產物。
Org leverage
SDK
非工程團隊也能用 API 組出 Slack 社群提問分流等自己的工具。
Core story
Oz 平台拆開的三個工程難題
01
執行環境要可控，也要能遷就既有基礎設施
雲端 agent 需要 sandbox；但嚴肅團隊常已有自己的基礎設施。平台同時提供代管與 self-hosted 選項，把彈性放在執行面，避免把所有人鎖進單一運算模型。
02
開發者可換 harness，脈絡不能跟著碎裂
團隊不必放棄熟悉的 harness；真正的共用層是 conversation state 與 artifacts。如此換工具或多人接手時，工作脈絡仍可被追蹤、重用和治理。
03
把 agent 放進 repository 的既有節奏
Issue 進來先由 agent triage、研究並在需求抽象時反問；PR 先進 agent-managed review。人不是每一步都被 ping，而是在 agent 通過後才看到高訊號工作。
Design choices
從單一 agent 到可組合的工作站
一個 agent 通常不夠真實工程任務跨研究、執行、驗證和回覆；平台需要能把子 agent 串起來，而非把一切塞進一個 prompt。
編排有兩個入口既可用 prompt 協調子 agent，也可經由 API 呼叫堆疊中的 primitives，讓產品團隊能把能力嵌進自己的流程。
Review 是訊號濾網agent 承擔第一輪審核並非取代責任，而是壓低低價值中斷，讓人把注意力留給真正需要判斷的變更。
不要把組織比成工廠講者以 pottery workshop 為喻：要有工位、材料、驗證與明確 owner，且系統會隨工作持續被打磨。
Use this
給 agent platform 團隊的實務 checklist
把「可選的基礎設施」與「不可碎裂的工作脈絡」分開設計Sandbox、harness 可以多元；task state、artifacts、審計與交接格式應一致。
讓 agent 在需求仍便宜時提問Issue triage 階段就要求補充上下文，比產出一段錯誤實作後再返工更有效。
把人工介入當成稀缺資源來路由建立 agent-first review 與升級準則；量測人收到的是否真是高訊號，而非只量測自動化次數。
把 primitives 做成可被非工程團隊使用的 API當平台能力可安全組合，最貼近業務問題的人也能建立自己的 triage 或營運工具。
Source video