AI Engineer onepage/ Superconductor
Arjun Singh, Superconductor · 18:44
這支影片在講：讓多個人與 agent 共用同一個工程工作空間
Superconductor 的主張不是讓 agent 自動把會議內容直接上線，而是把散在客戶訪談、Slack、桌面與 GitHub 的訊號，放進可追蹤、可審核且有隔離邊界的共同工作迴路。
Published: 2026-08-10Video ID: OL7kfezynJM
01 / 訊號
會議不再只是筆記
常駐 Meet 的 bot 從一句未被建單的需求抓到機會，建立 ticket、補上驗收條件，並能產出可審查的結果。
02 / 反轉
共享的是 agent session
同一個 session 可在 Slack、桌面與 GitHub 被接續；同事可直接在工作 thread 問 agent，而非等待原作者回來交接。
03 / 邊界
隔離是能力前提
雲端 sandbox、最小權限與可配置網路，讓非工程職能也能安全觸發真正的工程工作。
Signals
影片中最關鍵的四個訊號
Listening
4 小時
expo booth 的 Meet bot 持續聆聽，從自然對話撿出未被建檔的產品需求。
Usage
10.5B
一個月內處理的 token 規模；量級提升後，測量與權限變成產品核心。
Runs
3,300
約等於 Claude Code 的執行次數，估計 token 價值約 10,000 美元。
Benchmark
4×
Codex session 數約為前者四倍、成本更低；比較基礎是自家 PR replay，而非通用榜單。
Core story
多人 agent 工程要先解開的三件事
一
別讓上下文鎖在某個人的聊天視窗
若只有原作者看得到 agent 的推理與工作目錄，協作仍得靠人肉交接。把 session 暴露在 Slack、桌面與 GitHub，才能讓 review、追問與接手直接發生在工作脈絡內。
二
別把「能執行」誤當成「能安全執行」
Agent 可能為了完成指令，在開發者機器找到通往 production 的 token。隔離環境、最小權限與新網路目的地的確認，降低外洩與越權的空間。
三
別用別人的 benchmark 代替自己的品質判斷
SWE-bench 的語言與任務分布未必像你的產品。重播自家 repository 裡已知的好 PR，才可以同時比較品質、時間與成本，並看見不同模型真正的取捨。
Design choices
這不是「自動化更多」，而是重新設計工作流
把客戶對話接到可驗收工作讓 agent 從訪談與 onboarding 提取候選想法可以減少轉抄，但 ticket、驗收條件與成果截圖應保留成可審核的交接物。
讓非工程人員能觸發、不能越權支援與 growth 團隊可以提出或啟動工作；真正的執行放在帶有檔案系統與網路政策的 sandbox，不借用某位工程師的本機權限。
把觀測改成任務的一部分多人使用的 agent 需要可追溯的 session、工作狀態與產出，否則「協作」只是在更多地方產生難以還原的自動化。
以 repo 特有的真實工作做評估以可接受的歷史 PR 形成 replay suite，將品質、延遲與成本連在一起；不同模型可依任務而非品牌被分派。
Checklist
導入多人 agent 前，先問團隊這五題
誰能看見並接續同一個 agent session？至少要讓作者、reviewer 與相鄰職能在原工作脈絡追問與驗證，而不是靠轉貼摘要。
agent 的憑證與網路邊界在哪裡？把 production token、檔案系統與未知網路目的地視為明確的權限問題，而非模型是否「聽話」的問題。
從對話擷取的需求，如何變成可驗收項目？要求 agent 留下 ticket、acceptance criteria 與可重現的證據；不讓一句話直接變成無人負責的變更。
你們的品質基準是否來自自己的 codebase？建立代表真實好工作的 PR replay，量測完成品質、時間與成本，不把通用 benchmark 當成唯一答案。
每次執行是否能回溯決策與產出？多人協作放大速度也放大不可見性；保留 session、變更與驗證紀錄，才有治理與改善的依據。
Source video