Agent 走進 Slack 之後，聊天訊息不能直接等於工作授權
「把活動頁日期改成週五，Instagram 圖也調一下，準備好就開 PR。」
PM 在 Slack 留下這句話，同事大概知道他指的是哪個活動、哪一張圖，以及 PR 應該開到哪個 repo。前一天的討論、頻道成員、過往合作經驗，都在替這句話補空白。
換成在雲端執行的 coding agent，它可能把這句話當成一份已經足夠完整的工作單。它讀得懂句子，也有能力改檔案、跑測試、開 PR，於是很快就開始工作。麻煩在於，讀懂需求和取得授權，本來就是兩件事。
GitHub 最近把 Copilot cloud agent 接進 Slack 與 Microsoft Teams，讓團隊能從既有對話建立任務，再由 agent 非同步執行並產出 PR。OpenAI 的 Codex cloud GitLab beta 也把 issue 與 merge request 變成 agent 的工作入口。Coding agent 正在離開個人的 IDE 面板，進入團隊本來就用來提需求、討論與交接的地方。
這類入口省下了幾次切換，也把一個缺口帶到眼前。團隊需要在執行前加上一個很薄的轉換步驟：先把對話裡的意圖整理成可以核對的工作授權，再讓 agent 動手。
對話很適合開始工作，卻不適合獨自承擔權限
聊天的優點是快。人可以用一句不完整的話喚起共同背景，也能在幾個來回裡修正方向。這種模糊對協作未必是缺點，因為團隊成員知道什麼可以自行補齊，什麼需要再問。
Agent 面對的情況不同。它可能擁有一組長效憑證，可以讀取多個 repo，也可能在所有人下線後繼續執行。頻道裡的一個 mention、emoji，或一句「可以」，不該自動擴張成寫入預設分支、合併 PR、部署，甚至對外發布的權限。
身分也不會因為 agent 加入頻道就變簡單。提出需求的人可能有權建立候選任務，卻沒有權批准正式上線；agent 使用的 service identity 可能看得到更多 repo，但不代表請求者可以動用那些能力。多人頻道還會出現互相矛盾的指令。上午有人說改週五，下午另一個人回覆「先照原定時間」，兩句話都留在同一段對話裡。
Slack 或 Teams 可以接收意圖，權限判斷仍應交給 repository 與組織既有的規則。聊天訊息保留了請求來源，不能取代權限本身。
在 conversation 與 execution 之間放一個任務封套
我會把這個中介物叫做「任務封套」。它不必是一套新標準，也不需要逼 PM 改用複雜的 ticket 表單。系統可以先根據原始訊息產生草稿，再請人核對少數關鍵欄位。
一份能用的任務封套，至少要固定以下內容：
原始訊息連結、請求者與建立時間
目標 repo、branch，以及允許修改的檔案或交付物
驗收標準、deadline、時間或成本上限
遇到哪些情況必須停止，哪些副作用要另外取得確認
預計交付的 PR、測試結果與最後負責的人
這份紀錄的價值不在於欄位齊全，而是把原本散在聊天語境裡的假設變成可見的決定。Agent 若無法判斷「Instagram 圖也調一下」是修改既有檔案、重新裁切，還是重新產生主視覺，就應該在任務封套裡標成未決問題。系統不能因為模型能猜，就把猜測當成需求。
任務封套也讓 request、execution 與 review 三種責任分開。PM 可以提出任務，agent 在受限 branch 上執行，具備相應權限的 reviewer 再決定是否合併。實務上，三者經常是不同身分，所以要明寫。
把「圖也調一下」改成能驗收的工作
回到活動頁的例子。比較安全的流程，是先建立一份候選任務：將指定頁面的活動日期改為週五，只允許修改活動頁與社群素材目錄，在新 branch 工作，完成後開 PR，不得自動 merge 或發布。
社群圖片則需要更具體。任務應指向核准的原始檔，寫明輸出檔名、版位、尺寸，以及可以裁切多少。若設計者希望保留整張構圖，可以先用 Resize Image for Instagram 選定對應版位並檢查 Fit 或裁切結果，再把確認過的標準檔案附進任務。這樣 agent 接到的是明確的輸入與輸出，不必自行決定人物能否被切掉，也不會把「看起來差不多」當成視覺驗收。
接著，agent 在 branch 上修改日期、替換素材、跑既有檢查。若頁面測試通過，但它無法可靠判斷圖片中的安全區域，就應停止在 PR，留下待人工確認的項目。可逆性比自動化程度重要。能從 Slack 開 PR，不表示 Slack 可以繞過既有的必要審核。
完成之後，把收據送回原本的訊息串
Agent 工作最令人不安的時刻，往往不是它報錯，而是它沒有再說話。頻道裡的人知道任務「好像開始了」，卻不知道是否仍在執行、已經失敗，或正在等待某個批准。
每次執行都應把收據回寫到原始訊息串。內容可以很短，但要讓後來加入對話的人直接看懂：
task ID 與 PR 連結
修改過的檔案與測試結果
實際用掉的時間或預算
尚未解決的決定與停止原因
接下來由誰 review、merge 或發布
權限不足、需求衝突、預算用完，或視覺結果無法驗證，也都應留下收據。失敗不是空白狀態。Agent 應說明自己停在哪裡，等誰做決定，而不是靜默重試、擴大範圍，或挑一個最像答案的選項繼續做。
有了這份收據，團隊不必翻完整段聊天紀錄來猜工作是否完成。原始訊息保留人的語境，任務封套保存執行邊界，PR 留下程式碼變更，收據則把結果帶回協作現場。幾個物件各自負責不同的事，責任才不會全部塞進一次模型對話。
別只數 agent 開了多少 PR
Chat-native agent 上線後，最容易看到的數字會是建立了多少任務、跑了多少次、開了多少 PR。活動量很高，協作仍可能很差。
更值得追的是，任務封套建立後有多少被退回補資料、scope drift 發生幾次、等待批准花多久、PR 因需求誤解而重工多少，以及多少任務最後沒有 owner。從原始訊息到執行收據的完成率，也比單純的 PR 數量更接近團隊是否真的把事情做完。
如果大批任務都卡在同一個欄位，不必急著責怪使用者不會下 prompt。很可能是產品沒有把那個決定放在正確的時間點，或 agent 取得的組織 context 不足。任務封套既是控制面，也是觀察協作摩擦的位置。
Agent 進入團隊對話，的確讓開始一件事變得很容易。省下幾次切換，不等於可以省略責任。好的入口會保留自然語言的速度，也會在工作離開訊息串之前，固定它的目標、邊界、驗收方式與負責的人。
聊天訊息適合當起點，工作授權仍需要成為一個大家都能核對的物件。