AI Engineer onepage / Composio
速讀 · 基礎設施 · 實務清單 · source
Karan Vaidya, Composio · 約 20 分鐘
這支影片在講：知識工作 agent 缺的不是更強模型
程式代理跑得快，不只是模型擅長寫 code；而是軟體工程早已有完整的工作鷹架。把 agent 帶進銷售、招募、營運，必須補齊資料、狀態、驗證與權限的基礎設施。
Published: 2026-09-03 · Video ID: xxfMT-bPEmU
01 / 問題
工作散在五個系統
一筆交易可能分散在 Salesforce、Notion、Gmail、Slack 與 Zendesk；agent 無法取得完整、可用的工作視圖。
02 / 反轉
「可執行」不等於「該執行」
招募外聯 agent 的地址與信件都正確，卻不代表那批信本來就該寄出。傳統工程測試容易漏掉這一題。
03 / 解法
在 agent 外設牆
權限、核准與治理要由外部系統執行；prompt 會被遺忘或壓縮，不能是最後一道安全欄杆。
Signals
影片的四個關鍵訊號
Scattered work
5 apps
一筆 deal 橫跨多個登入、資料源與操作面。
Shared brain
5,000 pages
PromptQL 自家知識庫以相連的 markdown pages 運作。
Deletion incident
200 emails
曾被要求停止的 email agent 仍刪除信件，提示本身沒有持久約束力。
Hardest gap
No undo
寄出的信與匯出的款不能收回；可逆性最難由系統補救。
Core story
程式工程早就擁有、知識工作尚缺的六件事
01–02
集中化與歷史
程式碼有一個主要工作面，也有 git 記下變更。知識工作資料散落在 SaaS；很多商務工具又沒有一段 agent 可讀、可追溯的完整歷史。
03–04
脈絡與驗證
agent 既需要組織如何運作的地圖，也需要「什麼看起來才算好」的隱性標準；同時還要有能檢查結果的測試與回饋機制。
05–06
治理與可逆性
高風險行動必須有不可被 agent 談判掉的權限牆與人類責任；而對外發送、付款等操作，要承認它們可能根本沒有 undo。
Design choices
他提出的公司知識庫，不是另一個 agent memory
一份全公司的連結式 wiki不要把記憶留在每個 Slack channel 或個人 agent；以可連結 markdown 讓組織知識有共同的、可搜尋的所在。
逐檔案讀寫範圍每一頁都有權限邊界。agent 可以提出事實與 scope，但不能自行落筆。
人類接受、名字留在變更上寫入由人確認並可歸責；這讓安全事故不是無主的自動行為。
憑證不進 sandbox多人協作時，憑證在 HTTP 與 SQL 層依使用者注入，而非交給共享的 agent 環境保管。
Use this checklist
替知識工作 agent 上線前，先問這五題
資料是否已有單一、可讀的任務視圖？先找出跨 CRM、文件、信箱與訊息系統的斷點；不要把拼湊責任留給模型猜。
每個決策能否回看歷史與理由？沒有可讀 history 的 agent 每次都像第一天上班，無法從組織先例判斷。
驗證「該不該做」，而不只驗證「做得對不對」？外聯案例顯示格式、地址、送達都正確，仍可能是錯的行動。
權限牆是否存在於 agent 外部？把核准與不可做的規則交給有持久狀態的系統，不要期待 prompt 永遠被記得。
不可逆操作是否有人類閘門？針對寄信、刪除、付款等行為，預設需要明確責任、預覽和停止機制。
Source video