Assign It To Amp：在 Linear 把 issue 指派給 coding agent，設定、路由與 issue 寫法全攻略

瀏覽次數: 3

你一定遇過這種 issue：「設定頁的時區下拉選單少了 Asia/Taipei」「CSV 匯出欄位順序跟文件不一致」。要修，五分鐘的事。但要先切 branch、開 editor、叫出 coding agent、把 issue 內容貼進去、交代是哪個 repo，這一套儀式比修 bug 本身還久。結果就是這類小 issue 永遠躺在 backlog 底部。

Amp（最早由 Sourcegraph 團隊推出的 coding agent）在 2026 年 10 月 19 日的 changelog〈Assign It To Amp〉裡，把這段儀式直接拿掉：在 Linear 把 issue 指派給 Amp，或在留言裡 @Amp，它就會在雲端開一台機器開工，進度和結果回寫到同一個 Linear 頁面。

這篇不談「agent 會不會取代工程師」，只講三件事：這個整合實際怎麼運作、怎麼設定才不會踩雷、以及怎麼把 issue 寫成 agent 接得住的樣子。以下內容來自 Amp 官方 changelog 與 integrations 文件；我沒有在自己的 Linear workspace 實際跑過，所以凡是文件沒寫清楚的地方，我會直接標出來。

本文大綱

一、它到底做了什麼：一句話版本

官方 changelog 的原文很短：

Assigning an issue to Amp starts a new Agent Session in Linear and spawns a new orb. You can also mention @Amp to kick off a session.

拆開來有三個關鍵名詞：

Agent Session：Linear 這邊的概念。Linear 對外開放的 agent 機制，讓第三方 agent 能以「成員」身分被指派、被 @，並在 issue 裡開一個專屬的對話串，顯示進度與回覆。
Orb：Amp 這邊的概念。官方文件定義是「Amp agent 工作用的遠端機器，不佔用你的電腦」，每個 orb thread 都拿到一個全新、隔離的環境，裡面有你的程式碼、plugins 和開發工具。
Thread：Amp 的對話紀錄。從 Linear 啟動的 session，也會出現在你的 Amp 側欄，可以點 Open in Amp 進去看完整過程。

所以這不是「Linear 裡多了一個聊天機器人」，而是 Linear issue 變成了遠端 coding agent 的觸發器與回報面板。

二、運作原理：從指派到回報的五個步驟

照官方 integrations 文件，把整條路徑拆成五步：

1. 觸發。 兩種方式：把 issue 指派（assign / delegate）給 Amp，或在任何留言裡寫 @Amp。兩者都會開一個 Linear Agent Session，並在 Amp 那邊開一個 orb thread。

2. 身分。 這點很重要：orb 以「啟動 session 的那個人」的身分執行。 它讀寫 Linear issue、存取 repo，用的都是你的權限。所以前提是：你必須是安裝 Amp 的那個 Amp workspace 成員，而且在 Amp 裡用「同一個 Linear 帳號」完成連結。缺任何一個，Amp 會直接在 Linear 裡告訴你。

3. 路由：決定要在哪個 repo 工作。 Linear issue 本身沒有「repo」欄位，所以 Amp 要自己判斷。官方文件給了明確的優先順序（下一節詳細講）。

4. 執行。 orb 是一台全新的隔離機器，拉下對應 repo 開始工作。過程中如果需要你批准某個工具呼叫，或者出錯停下來，Linear 的 session 會顯示出來。

5. 回報與追問。 Amp 把回應送回同一個 session，而且會回覆過程中收到的訊息。文件特別寫：agent session 是在 session 內回覆，不是另外發一則留言，所以 issue 的留言區不會被洗版。

誰能追問、誰能喊停

這是文件裡容易被忽略、但協作上很關鍵的規則：

只有啟動 session 的人能在 session 裡回覆、追加指示。 其他同事想介入，要自己在新留言 @Amp，開一個屬於自己的 session。
任何看得到 session 的人都能把它停掉。 Amp 會中斷 thread，並在 Linear 裡確認已停止。

換句話說，一個 session 的「方向盤」只在一個人手上，但「緊急煞車」是大家都有的。這個設計很合理：orb 用的是啟動者的權限，讓別人隨便下指令等於借用了他的身分。

三、路由規則：Amp 怎麼決定在哪個 repo 開工

這是整個整合最值得仔細看的部分。官方文件列出的順序是：

這張 issue 所屬 Linear project 有設定的路由
所屬 Linear team 有設定的路由
issue 上連結的 GitHub／GitLab PR、issue 或 commit，如果全部指向同一個 Amp project，就用那個 repo
Linear 自己建議的 repository，在它有把握、且對得上單一 Amp project 時採用
這個安裝設定的 Default Project
都沒有：orb 不帶任何 repository 啟動

兩個細節要注意：

手動設定的路由永遠優先。 如果路由指到的 project，啟動者沒有權限，session 會「直接在 Linear 報錯停下」，而不是自己猜另一個 repo。這是好事：寧可失敗，也不要在錯的 repo 改程式碼。
第 6 層是陷阱。 沒 repo 的 orb 還是會跑，但它手上沒有你的程式碼，能做的大概只剩查資料、整理 issue。如果你常看到 agent 回一堆「我需要更多資訊」，先檢查是不是掉到這一層。

實戰建議： 不要依賴第 3、4 層的自動推斷。多 repo 的團隊，直接在 Agent Routing 幫每個 Linear team 綁一個 repo；monorepo 團隊，設一個 Default Project 就夠。路由設定在 Workspace Settings 的 Linear 卡片底下，每個 installation 下面有 Default Project 和 Add Route。

四、手把手設定：管理員一次、成員各一次

管理員（做一次）

到 Amp 的 Workspace Settings → Integrations & MCP（ampcode.com/workspace），在 Linear 卡片點 Install Amp in Linear。
由 Linear 管理員核准 Amp app。注意：一個 Linear workspace 只能屬於一個 Amp workspace。
有私有 team 的話，要另外讓 Linear 管理員授權 Amp app 存取該 team。如果卡片顯示 Permissions Update Required，Amp 管理員點 Update Permissions，再由 Linear 管理員核准。
在 Agent Routing 設好 Default Project，以及各 team／project 的路由（照上一節的建議）。

每位成員（各做一次）

到個人的 Settings → Integrations & MCP（ampcode.com/settings/integrations#linear），點 Connect Linear。
這一步會用 Linear 登入，同時把 Linear 加進你的 MCP servers。之後不管是從 Linear 觸發的 orb，還是你平常在 Amp 裡開的 thread，都能以你的權限搜尋、讀取、建立、更新 issue 和留言。

只有你自己一個人的 Linear workspace，可以選 Personal 模式：session 和訂閱都只以你的身分、只在你自己的 project 裡跑。

順便要接 GitHub

文件在 GitHub 整合段落提到，連上 GitHub 之後 orb 可以「以你的身分 push branch、開 pull request」。不過我讀到的文件沒有寫明「從 Linear 指派就一定會自動開 PR」。比較穩的做法是：在 issue 或 @Amp 的指示裡，直接寫明你要它做到哪一步（只分析？開 draft PR？）。

五、把 issue 寫成 agent 接得住的樣子

整合裝好只是開始。agent 拿到的輸入就是那張 issue，issue 寫得模糊，結果一定模糊。以下是我會建議團隊採用的 issue 模板，可以直接存成 Linear 的 issue template：

## 目標
設定頁時區下拉選單要包含 Asia/Taipei，預設值依瀏覽器時區帶入。

## 位置提示
- 前端：apps/web/src/settings/TimezoneSelect.tsx
- 時區清單來源：packages/shared/timezones.ts

## 驗收條件
- [ ] 清單含 Asia/Taipei，顯示為「(GMT+8) 台北」
- [ ] 既有單元測試全過，新增一個 Asia/Taipei 的測試
- [ ] `pnpm lint && pnpm test --filter web` 通過

## 不要做
- 不要改動時區清單的資料格式
- 不要升級任何套件

## 交付
開 draft PR，PR 描述列出改了哪些檔案、怎麼驗證。

幾個重點：

「位置提示」省掉 agent 大量的探索時間。 orb 每次都是全新環境，沒有上次的記憶，給檔案路徑是最便宜的加速。
「驗收條件」寫成可執行的指令。 agent 能自己跑 lint／test 驗證，你審 PR 時也能照表檢查。
「不要做」防止 scope 膨脹。 coding agent 最常見的失誤不是做錯，而是順手做太多。
「交付」寫明終點。 因為文件沒保證預設行為，明講最保險。

@Amp 的三種用法

指派適合「整張 issue 交給你」；@Amp 適合在討論中途叫它出來做一件具體的事。幾個值得試的寫法：

@Amp 先不要改程式碼。讀一下 repo，評估這個 bug 可能的根因，
列出 2–3 個假設和各自要看的檔案，回在這裡就好。

@Amp 照上面 issue 的驗收條件實作，開 draft PR。
如果發現需要改 API schema，先停下來問我。

@Amp 把這張 issue 拆成 3–5 張可以獨立完成的子 issue，
每張寫清楚驗收條件，建在同一個 project 下。

第三種用的就是 Linear MCP 的寫入能力：它能以你的身分建立 issue。這很適合在 grooming 會議前先讓 agent 打草稿，人再來修。

六、進階：Event Subscription，讓新 issue 自動派工

文件還提到一個更積極的模式：事件訂閱。對某個 Linear team 設訂閱後，每張新 issue 都會啟動一個 orb。預設是一次性執行，而且除非指示裡要求，否則不會回寫。

這功能很強，但文件自己也警告了風險，原文大意是：不加 label 篩選的話，任何能在該 team 建 issue 的人，都能啟動以你身分執行的 orb。 所以一定要：

設 label 篩選，例如只處理標了 amp-triage 的 issue。label 名稱要完全一致（不分大小寫）。
知道 label 要在建立時就帶上；文件寫明事後才加 label 不會觸發。
記得 Agent Routing 只套用在 session，不套用在 subscription，訂閱要自己指定 repo。

一個好上手的用法：訂閱「bug 回報」team，篩 amp-triage label，指示寫「重現問題、找出可能相關的檔案、把分析回寫成留言，不要改程式碼」。這樣工程師打開 issue 時，初步調查已經做好了。

七、成本與限制：先知道再導入

從官方文件看到的幾個硬限制：

Orb 依分鐘計費。 pricing 頁寫明：agent 停止工作 5 分鐘後、或你最後一次互動 20 分鐘後（取較晚者），orb 會暫停。付費方案內含一定的 orb 用量；免費的 Hobby 方案是 orb 隨用隨付，或接自己的 runner。方案細節和價格可能變動，導入前請以 pricing 頁為準。
啟動節流。 文件寫：每位使用者可以一次爆發啟動 20 個計費 orb，之後每 5 分鐘才能再開一個。想用訂閱一口氣清掉 100 張 issue，會被這條擋住，這其實也是一道安全閥。
只有啟動者能追問。 交接工作時要注意：同事接手，要自己重開 session。
權限跟人走。 啟動者沒權限的 repo，orb 也碰不到。這是安全設計，但也代表不能用一個「高權限帳號」幫全團隊跑。