AgEnD Tips

instance = Agent = 一個可以對話的 AI CLI，例如 Kiro CLI、Claude Code、Codex、Antigravity、Grok 或 OpenCode。

Backend = 背後驅動 Agent 的 AI 服務，例如 Claude Code、Codex、Kiro CLI。不同 Backend 有不同特性和模型。

一個 Agent = 一份獨立對話；其他 Agent 不會自動知道這裡談過什麼。

Fleet = 同一套 AgEnD 管理的全部 Agent；重啟 Fleet 會影響所有未暫停的 Agent，不只目前聊天室。

General = 協調工作的 Agent；需求跨專案時，可請它挑選 Agent、拆工作或彙整結果。

Topic、Thread 或 Channel = 綁定某個 Agent 的聊天室位置；在那裡發訊息就會交給該 Agent。

工作中 = Agent 正在處理工作；閒置 = 已準備接下一則訊息。

Paused = Agent 暫時休眠但保留已存 Session；再傳訊息通常會開始喚醒它。

Stopped = AI CLI 正常結束；Crashed = 非預期退出，或多次恢復仍沒有成功。

先講想要的結果，再補限制與輸出格式，Agent 會更快抓到重點。

好需求 = 目標 + 重要限制 + 完成條件；寫清楚可以少來回確認。

在意文風時，直接附一小段範例；範例通常比長篇解釋更快讓 Agent 抓到語氣。

要改先前指示時，直接說哪一條被取代；不說清楚，舊指示與新指示可能同時被保留。

`/steer <訊息>` = 改變正在執行中的方向；目前支援 Claude Code、Codex 與 Grok。

`/steer` 適合修正目前任務，不適合塞入另一件工作；無關需求另外發一則會更清楚。

`/btw <問題>` = 對 Claude Code 問題外話，不會取代正在做的主要任務。

`/btw` 和 `/steer` 不一樣：BTW 是題外問答，Steer 是改目前工作的方向。

Agent 忙碌時，新訊息可能先排隊；晚一點處理不代表訊息被蓋掉。

回覆較慢時先不要重送排隊中的需求；送兩次可能讓 Agent 真的做兩次。

取消按鈕或 `/cancel` = 中斷這次運行，並清掉按下前排隊的訊息（取消後才到的新訊息會保留）；訊息已進入 Context，已執行多少取決於取消時機。

AgEnD = 把 Telegram 或 Discord 聊天室連到一個或多個 Agent 的系統。

Cancel 也會清掉該 Agent 尚未送入的舊訊息，因此排隊中的跨 Agent 或排程工作不會立刻接著啟動。

Cancel 之後才傳的新訊息 = 新工作，不會跟舊佇列一起被清掉。

⏳ = 排隊、👀 = 已送達、✅ = 回合已確認、❌ = 失敗；這些符號只表示投遞狀態，不代表回答品質。

投遞符號可能比 Agent 回覆更早出現；它是 AgEnD 的狀態，不是 Agent 寫的答案。

訊息停在 ⏳ 時先等一下再重送；它可能只是在等 Agent 準備好。

訊息顯示 ❌ 時先查 Agent 狀態；盲目重試可能把真正的啟動、登入或連線問題蓋掉。

需要 Agent 確認新需求指的是哪段文字、檔案或圖片時，直接回覆原訊息。

引用回覆會帶入原文字；再補一句要怎麼處理，Agent 比較不會猜錯。

彼此相關的需求整理成一則最清楚；無關需求分開傳，之後比較好追蹤。

長訊息先把主要需求放在前幾行；細節接著補，不要讓目標埋在最後。

長工作想確認進度時，直接問一則簡短進度，不必把整份需求重貼。

Agent 追問時先補缺少的資訊；同時插入新任務，兩件事都可能變得不清楚。

回答有誤時，直接引用要改的句子或數值；只說重做通常會多繞一圈。

長討論結束時，可請 Agent 整理決定事項 + 未完成項目；這份摘要也比較容易交給另一個 Agent。

檔案和說明放在同一則訊息，Agent 才會把它們當成同一個需求。

傳圖片時順便說要看什麼；只丟圖片會讓 Agent 猜問題。

傳文件時指出頁面、段落或問題；可以避免 Agent 先讀一堆無關內容。

一次附多個檔案 = 說明每個檔案的用途；只看檔名不一定分得出輸入、參考與預期結果。

Telegram 語音會以音訊送入；若有啟用語音轉文字，Agent 也會收到逐字稿。

語音裡的姓名、代碼與數字容易聽錯；需要精確時再打一遍文字。

Telegram 貼圖有對應表情時會變成該 emoji；沒有對應表情時會變成 `[Sticker]`。

貼圖片網址仍然只是連結；需要 Agent 看圖片內容時，請直接附上圖片檔。

在支援的 Discord 回覆中，回覆一則帶圖訊息時，被引用的圖片也會送給 Agent。

重要指示請用文字；只按 emoji 可能只會被記成回應，不會啟動工作。

同一聊天室有多個 bot 時，要標記指定的 bot；不然可能由錯的身份回覆，也可能沒人處理。

Tool progress = Agent 正在做什麼的簡短歷程；啟用後，完成時按鈕會消失，但歷程會保留。

詳細進度可能包含指令預覽；分享截圖前先檢查私密路徑或數值。

Interactive prompt = AI CLI 正在等密碼、權限、Y/N 或 Enter；AgEnD 會通知 General，不會自己猜答案。

AgEnD 不會自動輸入密碼；任何確認都先看清楚再允許。

`/web` = 網頁儀表板（網頁聊天、View、Settings）的登入連結和一次性登入碼；登入碼能讓瀏覽器登入，所以這是管理員指令。

預設的 `http://localhost:19280` = 網頁儀表板與網頁聊天；localhost 代表通常只能在安裝 AgEnD 的電腦開啟，手機要先有連進來的方式（SSH、Tailscale 或 tunnel）。

View 會顯示 Agent 狀態、可取得時的 Context 百分比與即時工作畫面；可用來確認工作是否真的有在跑。

View 的 AI Usage 面板 = 目前有 Agent 使用中的 Backend 訂閱量；沒在用的 Backend 會隱藏。

`/usage` = 不開 View，直接在聊天室查看可取得的 AI 訂閱用量。

`/usage` 顯示 no data 不一定是額度歸零；也可能是帳號未登入、token 正在更新，或服務沒有提供用量資料。

用量資料會短暫快取，避免頻繁查詢供應商；需要最新數字時，可按 View 裡的重新整理。

Quota = 帳號或訂閱包含的可用量；出現警告時，本次回答可能仍會完成，但後續工作可能被擋。

`/status` = Fleet 總覽，包含 Agent 狀態與重要健康資訊。

`/sysinfo` = AgEnD、作業系統、執行環境與程序資訊；回報環境問題時很有用。

Context = 這段對話目前能記住的內容量。滿了就需要壓縮（`/compact`）或重新開始（`/clear`）。

Context 接近滿 = 舊細節可能被壓縮或遺失；長工作快到上限前先請 Agent 寫交接摘要。

Claude Code 的長 Session 可用 `/ctx` 留意空間；接近上限前用 `/compact` 或寫交接摘要，可降低細節遺失。

Codex 通常會自行管理對話壓縮，但重要決定仍建議整理摘要，不要假設每個細節都會一直保留。

`/compact` = 在 Backend 支援時縮短目前 Context 並盡量保留重點；不同 Backend 的效果不完全相同。

`/model` = 顯示目前 Backend 探測到的可選模型；選擇後會切換該 Agent 的模型，並保存供重啟後使用。

模型清單會在 AgEnD 啟動時探測；新模型沒出現時可重啟 AgEnD，Discord 也可用 `/model refresh` 直接刷新。

`/effort` = 支援模型的思考強度；強度較高可能更適合難題，但通常也更花時間與額度。

`/save <名稱>` = 匯出目前對話供之後參考；AgEnD 目前支援 Kiro CLI 與 Claude Code。

Discord 的 Kiro ClassicBot 可用 `/load <名稱>` 載入先前由 Kiro 儲存的對話；這不是所有 Backend 都能用的通用還原指令。

Claude Code 的 `/save` 會匯出 Markdown 檔供參考；AgEnD 沒有對應的 `/load` 可把它還原成 Claude Session。

Kiro 的 `/save` 會轉成 `/chat save`；之後的 Discord `/load` 只適用 Kiro ClassicBot 流程。

管理員使用 `/update` = 從目前的穩定版或 Beta 更新通道安裝最新 AgEnD，完成後重啟 Fleet。

管理員使用 `/restart` = 優雅重啟整個 Fleet，不是只重啟目前 Agent。

每次重啟都會喚醒所有未暫停的 Agent；啟動需要時間，後續恢復或摘要也可能多用 token，因此不要頻繁重啟 Fleet。

不需要立刻恢復的 Agent，可在 update 或 restart 前先 Pause；Fleet 啟動時會跳過已暫停的 Agent。

管理員使用 `/pause` = 讓 Agent 休眠；`/wake` = 再次啟動。General 本身不能被暫停。

Settings 可以設定自動暫停時間；`0` 代表停用，讓不用的 Agent 休眠可減少背景程序與重啟負擔。

修改自動暫停、進度詳細度、顯示名稱、描述、標籤或 Log Level 會即時生效，不會重啟 Agent。

在 Settings 修改 Backend、工作目錄或 Tool Set，以及在設定檔修改 Backend Options，都屬於冷設定，會重啟 Agent。

ClassicBot = 常駐在一般 Discord Server/Channel 或 Telegram Group 裡的 Agent，不是預先建立的 Fleet Topic。

ClassicBot 預設不會對每段聊天主動插話；可用 `/chat`，在 Telegram 群組或協作聊天室標記 bot 也會觸發。

ClassicBot 觸發時會附上近期聊天紀錄；預設是最近 5 行，不是整個頻道歷史。

要使用 ClassicBot，先把 bot 邀進 Discord Server 或 Telegram Group，再由管理員在目標聊天室執行 `/start`。

ClassicBot 的 `/start` 會用 ClassicBot 預設 Backend 建立或恢復該聊天室的 Agent；之後可到 Settings 修改 Backend。

ClassicBot 的 `/stop` 會移除該聊天室綁定；確定這個 Channel 不再需要 Agent 時才使用。

ClassicBot 聊天室與 Fleet Topic 的路由不同；指令要在目標 Agent 所屬的聊天室執行。

同一個協作聊天室有多個 bot = 標記正確 persona 或使用它的 slash command；每個 bot 可以各自擁有不同的 ClassicBot Agent。

登入過期訊息 = 重新登入該 Backend；登入尚未修好前重送同一需求，通常只會再次失敗。

模型不支援訊息 = 目前 Backend 或帳號拒絕該模型；請改選清單中的模型，不要期待系統默默換回預設。

密碼或 Y/N 提示停住時會通知 General；AgEnD 不會自動代答。

回報問題時附上時間 + instance 名稱 + 傳了什麼 + 發生什麼；這四項最容易對上 Log。

View 頁面的截圖會顯示 Agent 即時畫面；分享前先檢查專案名稱、路徑或 Secret。

AI 回答可能出錯；指令、價格、權限與其他高影響資訊都要確認後再執行。

敏感工作 = 只提供本次需求必要的檔案與數值；聊天匯出與截圖可能比預期包含更多資訊。

`/tips` = 在目前聊天室再顯示一則可用 Tip；不一定要到 General 執行。

✅ 我知道了 = 保留 Tip 原文、收起按鈕，之後不再顯示同一則。

❓ 看不懂 = 保留 Tip 原文、記錄回饋，之後仍可能再次出現同一則。

`/clear` = 確認後清空目前 Context；這個動作不能復原，但專案檔案與 AgEnD 指示仍會保留。

有用的 Tip 應該直接說明對你有什麼影響；看不出實際後果時就按「看不懂」。

網頁聊天 = 在瀏覽器裡跟 Agent 對話；它和那個 Agent 在 Telegram 或 Discord 的對話是同一段，聊到一半可以在手機和電腦之間切換。

打開網頁聊天 = 管理員傳 `/web`，打開登入連結並輸入一次性登入碼；之後那個瀏覽器會保持登入，不用每次重來。

網頁聊天的檔案 = 按 📎、直接貼上或拖到聊天裡；Agent 收到的方式和從 Telegram 傳的一樣（最多 5 個檔案，每個 10 MB）。

網頁聊天的 Stop = 中斷 Agent 目前的回覆，和 Telegram 的取消按鈕一樣；還在排隊的訊息會被丟掉，但 Agent 本身會繼續運行。

instance（單一且獨立的 Agent）各自保有自己的對話，也可以分別負責不同專案。

Fleet（由 AgEnD 一起管理的一組 Agent）可統一執行管理操作；整體操作可能影響所有運行中的 Agent。

General（協調工作的 Agent）可協助選擇合適的 Agent、拆分互不相依的任務，或管理整個 Fleet。

Backend（決定 Agent 使用哪種 AI 服務）可以是 Claude Code、Codex、Kiro CLI、Grok、Antigravity 或 OpenCode。

Context（目前對話可保留的資訊量）有容量限制，也不是永久的專案儲存空間。

MCP（讓 AI 使用回覆、檔案與協作工具的通道）通常不需由使用者直接操作，只要說明預期結果即可。

Model（Backend 內實際選用的 AI 模型）若未指定，通常會沿用 Fleet 或帳號的預設值。

Session（Backend 保存的對話狀態）能否在重啟後延續，取決於該 Backend 的支援方式。

工作目錄（Agent 讀取與修改專案時使用的目錄）可以共用，但多個 Agent 同時修改時可能產生衝突。

ClassicBot（在一般 Telegram 或 Discord 對話中建立持續 Agent 的模式）不需要預先配置 Fleet 對話。

Adapter（AgEnD 與某個訊息 Bot 帳號的連線）在多 Bot 環境中可讓 Agent 固定使用指定身分回覆。

Telegram 以 Topic 分隔 Fleet 對話，Discord 則可能使用 Channel 或 Thread；這些空間在 AgEnD 中都用來把訊息送到正確的 Agent。

Tool（AI 可呼叫的操作，例如讀取檔案或發送回覆）是否可用，取決於 Backend 與權限設定。

Delivery queue（等待安全時機送入忙碌 Agent 的訊息佇列）代表訊息延後處理，不一定是遺失。

閒置（看起來可接收輸入）與工作中（偵測到正在處理工作）是 AgEnD 觀察到的狀態，不代表回答品質。

Paused（暫停）表示 AgEnD 刻意停止 Agent 的 CLI 程序，但保留設定，之後仍可喚醒。

Stopped（正常停止）與 Crashed（非預期退出或多次恢復失敗）原因不同，可請 General 協助檢查。

Settings（常用設定的網頁編輯器）會即時套用 Hot 設定；Cold 設定會改變啟動方式，因此會重啟受影響的 Agent。

View（在瀏覽器顯示 Agent 即時終端畫面的頁面）適合查看互動提示或工作進度。

CLI（在電腦終端中運行的 AI 程式）會顯示 TUI（以文字構成的操作畫面）；AgEnD 會把訊息送進該畫面，使用者可透過 View 或電腦終端查看。

使用 `/ctx` 可查看目前的 instance、Backend、Model 與可取得的 Context 估計值；部分 Backend 無法提供百分比。

不帶參數的 `/model` 會開啟模型選單；管理員可用 `/model <名稱>` 指定模型。

即使 AgEnD 的本機規則不認得某個格式安全的模型名稱，仍會交給 Backend 判斷；Backend 可能接受，也可能回報不可用。

不帶參數的 `/effort` 可查看推理強度選項；管理員可在 Backend 與 Model 支援時使用 `/effort <等級>`。

Reasoning effort（推理強度）會調整支援模型投入思考的程度，不會切換 Backend，也不保證答案一定更好。

Context 擁擠但仍要延續對話時可用 `/compact`；各 Backend 行為不同，Antigravity 會改為完整清除。

支援的 Backend 可用 `/clear` 重設對話；此指令限管理員使用，且因先前 Context 會被移除而需要再次確認。

使用 `/cancel` 或取消按鈕可中斷目前回合；按下前排隊的訊息會被丟棄，之後到達的新訊息則會保留。

可對閒置且非 General 的 Agent 使用 `/pause` 以節省資源；General 必須維持協調能力，因此不能暫停。

使用 `/wake` 可立即啟動 Paused Agent；傳送一般訊息也能觸發喚醒流程。

只有整個 Fleet 都需要重啟時才使用 `/restart`；若只有一個 Agent 異常，應請 General 單獨重啟該 Agent。

應等進行中的工作到達安全點後再用 `/update`；更新會安裝選定的 AgEnD 版本，接著重啟整個 Fleet。

使用 `/usage` 可查看 Running 或 Paused Agent 所用 Backend 的訂閱資料；無資料可能代表無法取得統計，不等於用量為零。

使用 `/web` 可取得登入連結和一次性登入碼；登入碼只能用一次、5 分鐘後失效，請視同密碼，不要貼在別人可能搶先使用的地方。

管理員可用 `/status` 查看 Fleet 摘要，包括 Running、Paused、Stopped 與 Crashed Agent。

問題可能與執行環境有關時，可用 `/sysinfo` 收集主機與版本資訊。

在 General 使用 `/doctor` 可檢查已設定的 Backend；更完整的服務與連線檢查需從可信任的電腦終端執行 `agend doctor`。

使用 `/tips` 可立即查看另一則提示；`/tips off` 可停止每日投遞，`/tips on` 可重新開啟。

使用 `/steer <訊息>` 可在 Claude Code、Codex 或 Grok 工作途中調整方向；不支援的 Backend 會明確回報。

使用 `/btw <訊息>` 可向 Claude Code 提出附帶問題，而不要求放棄目前任務；其他 Backend 會回報不支援。

管理員可在 General 使用 `/pause <instance 名稱>` 或 `/wake <instance 名稱>`，不必先進入該 Agent 的對話。

`/save <名稱>` 僅支援 Kiro CLI 與 Claude Code；Kiro 會保存 Chat，Claude Code 會匯出 Markdown，其他 Backend 會回報不支援。

在 ClassicBot 對話中，管理員可用 `/start` 建立或恢復 Agent，並用 `/stop` 移除該頻道的綁定。

管理員可用 `/collab` 切換 Bot 訊息是否能參與已設定的 Fleet 對話；既有存取規則仍會套用。

Settings 會先暫存修改，按下 Apply 才套用；若 Cold 欄位會重啟 Agent，送出前應先檢查變更內容。

Backend 屬於 Cold 設定；在 Settings 切換 Backend 後，受影響的 Agent 會重啟。

工作目錄屬於 Cold 設定；在 Settings 套用前，應確認目標工作目錄存在且包含預期專案。

Model Override 可透過 `/model` 或 Settings 調整；不需指定時可留空，讓既有預設值生效。

Tool progress（工作訊息下顯示多少工具歷程）可在 Settings 選擇 off、standard 或 verbose，且不需重啟即可生效。

Display name（對外顯示名稱）不會改變 instance 的內部名稱，可在 Settings 即時調整。

Description 與 Tags 可說明 Agent 的責任並協助 General 選擇，兩者都能在 Settings 即時修改。

Auto-pause（閒置後自動暫停的計時）設為 0 時停用，可在 Settings 啟用或調整，且不需重啟 Agent。

Warm cap（最多保留多少個非 General Agent 運行）可請 General 協助調整，或在進階設定中修改 fleet.yaml 的 `defaults.warm_cap` 後重新載入；既有 Agent 不需重啟。

Log level（診斷紀錄的詳細程度）屬於 Hot 設定；較詳細的 Log 也可能包含專案或路由資訊。

Channel binding（Fleet instance 固定使用的 bot 身分）可在 Settings 設定，適合多個 bot 帳號共用同一伺服器或群組的情況。

Kiro UI（Kiro 是否使用互動畫面）只適用 Kiro；變更後會重啟該 Agent。

Terminal columns 與 rows（Backend 看到的邏輯畫面尺寸）應謹慎調整；過窄的畫面可能讓權限提示換行或漏判。

Settings 會顯示套用 Defaults 後的有效值；保存時可省略與 Defaults 重複的 instance 欄位，因此缺少重複欄位不一定代表設定遺失。

Schedule（稍後或週期性投遞的訊息）可請 General 建立，並指定由負責該工作的 Agent 處理。

週期排程使用 Cron Expression（描述重複時間的格式），例如每天 09:00；單次排程使用 ISO 日期時間，例如 `2026-08-25T09:00:00+08:00`，每個排程只應選一種。

Timezone（週期排程依循的當地時鐘）可避免時間誤解；例如 `Asia/Taipei` 會讓「每天 09:00」代表台灣時間 09:00，而不是伺服器所在地時間。

Silent Schedule（不在聊天室顯示觸發文字的排程）仍可能在任務需要時由指定 Agent 回傳結果。

Team（可重複使用的 Agent 協作群組）適合固定的實作與審查搭配；成員可請 General 管理。

Shared Decision（讓各 Agent 在重啟後仍可沿用的共同決定）適合記錄長期有效的架構選擇，可請 General 保存。

Agent 之間可以交換特定問題與結果，但完整對話歷程與工作目錄不會自動共用。

只應請 General 平行處理互不相依的工作；若兩個 Agent 會修改相同檔案，應先協調責任或使用不同副本。

發送端 Timeout（等待回覆逾時的提示）不代表跨 Agent 訊息一定失敗；不應只因等待逾時就重複發送。

Agent 等待密碼或確認時，AgEnD 可通知 General；進行任何人工輸入前，都應先檢查畫面上的實際提示。

不要透過聊天室傳送密碼、存取 Token 或私鑰；只有獲准的提示需要時，才在可信任的終端直接輸入。

投遞狀態 Reaction 中，⏳ 代表排隊、👀 代表已送達、✅ 代表回合已確認、❌ 代表失敗；它們不評價答案是否正確。

一般 Reaction 應避免使用 👀、⏳、✅、❌，因為 AgEnD 會將它們保留給投遞狀態。

回覆較早的訊息時，Agent 會收到引用內容；支援的 Discord 回覆也能包含被引用訊息中的圖片。

附件會先複製到本機收件區，再以本機路徑交給 Agent；敏感檔案只應傳給合適的 Agent。

Permission prompt（Backend 要求授權的安全關卡）應先確認檔案或指令範圍，再決定是否核准。

標記已讀 60 則中階提示後，AgEnD 會提供「開始看進階」按鈕；管理員也可用 `/tips advanced on` 主動開啟。

Claude Code 支援 subagent（同一個 CLI 內負責特定工作的輔助 AI），可在主 agent 整合結果時進行研究或審查。

Claude Code 的 Permission mode（檔案與指令操作的授權方式）可設為允許、拒絕或要求核准，應依專案風險選擇。

Claude Code 可恢復已保存的 Session，但能否延續仍取決於相同的專案路徑與可用 Session 資料。

Claude 各模型系列通常在能力、速度與成本間有不同取捨；實際可用項目應以目前帳號的選單為準。

Opus 通常偏向高難度工作、Sonnet 偏向平衡、Haiku 偏向快速輕量；仍應以供應商最新文件為準。

Codex 使用 Sandbox（限制模型所產生指令作用範圍的邊界）；Sandbox 範圍與核准政策是兩項不同控制。

Codex 工作時可接受 Queued input（由 CLI 自己排隊的後續訊息），因此不必等待閒置間隔才送入。

Codex Skills（按任務需要載入的可重用指引）可把詳細流程放在平時不必完整載入的位置。

Custom provider（Codex 中另行設定的模型服務）可由 AgEnD 選用；服務網址與憑證環境變數仍由 Codex 設定管理。

自訂 Codex Model 可能因缺少內建資料而出現 Metadata Warning；是否可用仍以 Provider 實際回應為準。

Kiro Specs（整理需求、設計、任務與執行的專案文件）適合需要明確規劃的功能工作。

Kiro Steering files（持續套用的專案指引）可保存慣例，不必在每次對話重複說明。

Kiro Skills 採漸進式載入：CLI 先看到簡短說明，只有任務相關時才讀取詳細指引。

Kiro 的 `auto` 模型模式會讓 CLI 動態選擇；只有要覆寫 Fleet 層級的模型預設時，才需要明確設定 `model: auto`。

Grok 可在已安裝 CLI、帳號與政策允許時提供網頁搜尋與內容擷取；實際可用性應在目前環境確認。

Grok 支援透過 `/steer` 調整工作方向，但模型與工具可能因帳號而異，應以 CLI 當下顯示的清單為準。

OpenCode 區分處理主要工作的 primary agent 與專注任務的 subagent；專案設定可能改變可用 agent 與權限。

OpenCode 模型名稱通常採 `provider/model` 格式；應查看目前模型清單，不要假設只填模型名稱就一定可用。

OpenCode Provider 定義應放在 OpenCode 自己的設定中；AgEnD 只選擇其提供的模型，不保存 Provider 憑證。

OpenCode 目前沒有對應 AgEnD `/effort` 的功能；需要調整時，應使用 OpenCode 支援的模型或 agent 設定。

Antigravity 可透過終端介面執行多步驟工作與工具操作；可用模型與整合項目取決於帳號及已安裝版本。

Antigravity 在 AgEnD 中沒有獨立的摘要式 Compact 指令；`/compact` 與 `/clear` 都會使用完整清除對話的操作。

不同 GPT 變體可能著重能力、延遲或成本；目前 CLI 帳號實際顯示的名稱才是判斷依據。

自動模型選擇可能在不同回合使用不同模型；只有可重現性比彈性更重要時，才需要固定 Model。

某個帳號可用的模型在另一個帳號可能不可用；一次調整多個 Agent 前，應先用目標 Backend 確認存取權。

進行 migration 或大量修改前，應把 fleet.yaml 與 classicBot.yaml 備份到工作路徑之外；直到代表性 instance 完成重啟與訊息往返測試後再移除備份。

instance entry 可以省略從 defaults 繼承的值；診斷 daemon 實際收到的設定時，應比對 effective configuration，而不只查看原始 YAML。

AgEnD 儲存 fleet.yaml 時會移除與 defaults 重複的 leaf values，但會保留 backend、model、working_directory、topic_id 與 backend_options 等識別欄位。

Lossless YAML 編輯會盡量保留無關結構與註解；若註解只附著在被移除的節點上，該註解可能無法保留。

手動修改 YAML 後、reload 前應先執行 `agend validate`；它可在不重啟 Fleet 的情況下找出 schema 錯誤。

Hot fields 會原地 reconcile，cold fields 則會重啟受影響的 instance；套用混合變更前，應先查看 Settings 的變更摘要。

SIGHUP reload 會以通過驗證的設定更新執行中 Fleet，並不等同於重啟所有 CLI process。

Backend、working_directory、tool_set、lightweight 與 backend_options 屬於 cold instance fields；變更後可能重建受影響的 CLI process。

Tool progress、display name、description、tags、log level 與 auto-pause 設定可 hot reconcile；若行為未更新，應確認 daemon 是否已接收變更。

只有在 instance 行為確實需要不同於 defaults 時才設定 override；減少重複值可讓後續 default 變更與 review 更容易判讀。

Backend option 只由對應 Backend 解讀；例如 `backend_options.codex.provider` 只負責選擇 provider，不會定義 endpoint 或 credentials。

Codex custom provider 應在 Codex config 中定義；密鑰宜透過 Fleet service 啟動前已存在的環境變數提供。

OpenCode provider 應在 opencode.json 中定義；AgEnD 的 model 欄位應使用 OpenCode 提供的識別字，通常是 `provider/model`。

Model name compatibility check 只應視為提示；CLI 才是最終依據，因此 AgEnD 會傳遞已設定的 model name，而不會靜默退回預設值。

instance 未設定 model 時會先繼承 defaults.model；若 Fleet 已有 model default，而某 instance 要使用 Backend 自己的預設，應在支援時明確設定該 Backend 的預設值。

Kiro 的 `auto` 是明確的 model 選擇；若要覆寫非 auto 的 defaults.model，應在該 instance 設定 `model: auto`。

Model failover 依賴支援的 usage telemetry，並在後續 rotation 套用；它不會在進行中的回合中途安全替換 model。

Cost guard 受 provider telemetry 限制；usage data 缺失、快取或延遲時，執行精度會下降，營運預期應納入這項限制。

Usage 結果會快取以減少 provider calls；登入或更新 token 後需要立即重取時，可使用 View 面板的 Refresh。

Provider 未出現在 `/usage` 時，可能只是目前沒有 running 或 paused instance 使用它；用量顯示依 effective Backend，而不是所有已安裝 CLI。

Bot token、dashboard token、provider key 與匯出的 session 都不應放入 repository 或共用 workspace，且各自需要不同的 rotation 程序。

CLI 支援 environment-key reference 時，應把 secret 放在 service environment，而不是 fleet.yaml 或會提交到版控的 provider config。

web.token 與 per-instance state 等檔案應只允許 owner 讀取；複製到 project 後，可能經由備份、diff 或 agent 暴露。

瀏覽器登入儀表板後，Fleet 重啟也不會登出（預設最長 48 小時）。傳 `/web revoke`，或在主機上執行 `agend web-token rotate`，可一次讓所有瀏覽器登出；執行中的 Fleet 不需重啟即會生效。

Dashboard URL 只有在 health server 開始 listening 後才可使用；遇到 port conflict 時應 fail closed，避免發布指向錯誤 process 的 URL。

Channel allowlist 是 authorization boundary，不是顯示篩選器；變更 access rules 後，應同時測試允許與拒絕的 identity。

修改 locked channel 的 allowed_users 前，應確認至少保留一位管理員；空的 locked allowlist 可能移除所有管理操作路徑。

使用 nonce 的確認按鈕會綁定 adapter、chat、thread、message 與管理員 identity；複製 callback 不應能授權另一個情境。

Multi-world Fleet 中，若第一個 adapter 不是預期 persona，應為 General 與 fleet-topic instance 明確設定 channel_id。

ClassicBot routing 依自身 channel records 決定；在多 bot 協作頻道中，不應把 fleet-topic 的 adapter canonicalization 套用到 ClassicBot reply。

Terminal columns 與 rows 同時影響 TUI layout 和 capture wrapping；修改 geometry 後，應用真實 pane sample 驗證 ready、permission 與 error detection。

Terminal validator 會限制保守的 geometry 範圍，因為過窄 pane 可能使 permission prompt 換行到無法辨識。

AgEnD 會固定 tmux window size，並讓 control client 忽略尺寸；兩層保護都需要，才能讓 logical geometry 在 reconnect 後保持穩定。

Mouse mode 只在 AgEnD 的 tmux session 啟用；attach 後可捲動 scrollback，且不影響使用者其他 session。

`capture-pane` 未合併 wrapping 時會讀取畫面實際行；因此即使邏輯文字相同，width 變更仍可能改變 parser input。

Ready、busy 與 error pattern 都是針對 terminal text 的 heuristic；修改前應保留去識別化的真實 sample，並加入 production-path test。

閒置誤判可能提早收回控制項或過早投遞 input；工作中誤判則可能延遲訊息並觸發 hang notification。

週期性 statusline redraw 不一定代表工作；各 Backend 的 pane handling 應區分純顯示重繪與任務內容變化。

hang_detector 應依實際 silent-work interval 調整，而不是任意設定很短的 timeout；重啟前先檢查 pane 與 process evidence。

Interactive-prompt alert 會同時要求 prompt-like pattern 與穩定 output 時間，以降低 agent 只是討論密碼或確認操作時的誤報。

限管理員使用的 `/raw <文字>` 會略過 AgEnD 的一般訊息包裝，直接送給 Backend；只有包裝會改變刻意輸入的 CLI 指令時才應使用。

Special-key delivery 需要可寫入的 tmux control client；Enter 或 interrupt command 失敗時，應直接視為 command failure，而不是等後續 timeout。

即使 Backend 有 native input queue，pasteLock 仍需序列化 terminal writes；native queue 不代表重疊 PTY paste 是安全的。

Codex 可把 busy-time input 放入自身 queue，因此 AgEnD 對 Codex 略過閒置門檻，但仍保留首次投遞的 startup settle。

Cancel 會透過 delivery epoch 使取消前已排隊的訊息失效；取消後抵達的新訊息使用新的 epoch，仍可正常投遞。

Message transport timeout 不代表一定未投遞；重試外部或 cross-instance send 前，應先檢查 delivery log 或 idempotency evidence。

被替換的 IPC client 必須移除 listeners 並 destroy socket；只刪除 map entry 可能留下仍在處理 outbound message 的 orphan。

Disconnect、overflow 與 close event 應在每個 client lifecycle 收斂成一次 disconnect，且 reconnect 應依 instance 序列化。

若簡單訊息也持續出現重複回覆，應先檢查 client 與 socket 數量，再判斷是否與 rich-message rendering 或 model 有關。

Schedule trigger metadata 必須包含 instance 設定的 adapter identity；否則重啟後的 reply 可能 fallback 到錯誤的 bot persona。

Fleet singleton lock 保護的是 manager startup，不是單一 instance restart；per-instance restart serialization 仍是另一項必要保護。

出現兩個 Fleet process 時，終止前應先收集 PID、parent PID、command line、lock owner、service state 與 listening ports。

Service-managed Fleet 在 user service manager 無法連線時應 fail closed，而不是啟動未追蹤的 detached duplicate。

透過 SSH 使用 Linux 時，缺少 D-Bus session 可能使 `systemctl --user` 無法使用，即使 unit file 已存在。

`active` 與 `activating` 都應視為 service 已被占用；service query 結果不確定時，不應允許第二次 startup。

Health-port conflict 可能代表 stale manager 或其他 service；更換 port 或停止 process 前，應先識別 listener。

Recovery path 應依 instance 序列化，避免 health check、MCP recovery、manual restart 與 config reconcile 建立互相競爭的 replacement。

Crash-loop protection 會在有限次重複失敗後停止自動恢復，並顯示 crashed 而非閒置；成功恢復後則必須清除 stale crash marker。

Restart backoff 可限制 CLI 反覆 startup failure 時的資源消耗；診斷確定性的設定錯誤時，暫時停用 retries 可能較合適。

MCP auto-restart 會等待符合條件的閒置狀態，並去除重複 restart request；由於 MCP child connection 由 CLI 掌握，因此需要重啟 instance。

只有在 pane 可見文字適合轉送時才啟用 mcp_proxy_reply；regex redaction 無法保證移除所有專案特有 secret。

Proxy reply 是 MCP 中斷後的最後備援 channel path，不是 source-of-truth transcript；應留意 terminal chrome 或不完整輸出。

Session resume 由 Backend 掌控；AgEnD 可保留 identifier、workspace path 與 marker，但無法保證 CLI 升級後仍維持語意 continuity。

OpenCode resume 應使用已記錄的 session identifier；global `--continue` 可能選到其他 directory 的最新 session。

Claude Code project-session lookup 依賴編碼後的 workspace path；重新命名或移動 workspace 可能使既有 session 看起來不存在。

Per-instance Codex home 會隔離 MCP configuration 與 instance decisions；把這些項目寫入共用 Codex config 會造成 cross-instance authorization risk。

SQLite database file 不應與 active WAL、SHM 或 rollback-journal sidecar 分離；從其他 home 連入 sidecar 可能使 private database 無法使用。

Database base file 有意使用 symlink 時，應以 production 使用的 library version 驗證 SQLite 建立 sidecar 的位置，不宜只憑路徑假設。

scheduler.db 包含 schedules、decisions、task state 與 tip state；直接維護前應做一致性備份，並避免在 Fleet 執行中寫入。

Runtime schema audit 應同時比對 CREATE statements、query 引用的每個欄位，以及部署中 SQLite file 的實際 schema。

Startup concurrency 應依可用 memory 與實測 CLI startup cost 調整；提高 concurrency 可能增加競爭，反而延長總啟動時間。

Startup stagger delay 可分散 process creation 與 authentication load；persisted paused instance 會在分配 stagger slot 前排除。

warm_cap 是 Fleet-wide capacity limit，auto_pause_after 則是 per-instance 閒置時間 policy；搭配使用前應先觀察 workload pattern。

warm_cap 為 0 表示不設上限，auto_pause_after 為 0 則停用依時間暫停；General 不會被 auto-pause 或 warm-cap eviction。

許多常駐 CLI 即使閒置仍會占用可觀 memory，但閒置本身不會消耗 model token；設定 warm cap 前可先量測 RSS。

Lightweight mode 會省略依賴 Backend 的 transcript、Context Guardian 與 error monitors 以降低 overhead；只有在可接受缺少這些觀測能力時才應啟用。

每個 exposed MCP tool schema 都會占用 Model Context；範圍明確的 worker 宜使用 minimal 或 standard，只有確實需要時才使用較廣 profile。

General 在 tool_set 繼承時會取得 coordinator tool profile；明確設定 standard 或 minimal 可能移除協調所需工具。

Verbose tool progress 可能在 channel history 保留 command preview；若營運細節不應讓頻道讀者看到，宜使用 standard 或 off。

只有在有界的診斷期間才提高 log verbosity；完成後應恢復正常 level，且對外分享前先檢查 log 內容。

Bundled skills 會在 CLI startup 前依 role 篩選：General 取得所有 eligible skills，worker 取得 shared 或 worker skills，ClassicBot 則跳過。

Managed-skill manifest 用來區分 AgEnD-owned copy 與 user content；舊版 manifest 缺失時，需要保守的 adoption 流程，避免 managed skill 永久停在舊內容。

共用同一 workspace 的 instance 也會共用 Backend-native skill directory；混合 role 或 Backend family 可能競爭 managed files，因此分開 workspace 較安全。

平行 write task 應使用不同 git worktree；用於檢查的 detached checkout 應保持 read-only。

Template 可定義可重複建立的 instance group，但部署前仍需明確約定 branch、workspace、ownership 與 teardown。

Team 是 routing group，不是 shared memory；每個 member 仍保有自己的 Context、session 與 workspace boundary。

Silent schedule 會注入工作但不要求 channel reply；只有在刻意不需要 user-visible output 時才應使用。

Schedule timezone 是 execution semantics 的一部分；所選 IANA zone 有 daylight-saving transition 時，應驗證執行時間。

Restart 後觸發的 schedule 仍需帶入 target instance 的 effective adapter 與 delivery epoch，才能維持 routing 與 cancellation 正確。

Fleet decision 可保存持久的架構脈絡；過時 decision 應 supersede 或 retire，避免後續 agent 收到衝突指示。

Event log 可支援診斷，但不能取代 source configuration、provider audit record 或原始 process evidence。

Chat export 可能包含姓名、專案細節、tool summary 與引用訊息；對外分享前應先 review 並 redact。

安裝時的 sudo password 或 confirmation prompt 需要人工判斷；non-interactive automation 應明確失敗，而不是猜測答案。

`agend doctor` 會分別檢查 Backend availability、service、D-Bus、Fleet、tmux 與 IPC health；不應以單一綠色項目代表整體健康。

Update 後應先為每個 Backend canary 一個代表性 instance，再恢復完整 workload；檢查項目應包含 ready、permission、error、reply 與 Context。

Update health check 與代表性 canary 通過前，應保留前一個 package version 與相容的 configuration backup。

為移除 secret 而改寫 Git history 時，應保留 mirror backup、驗證所有 refs 與 tags；即使 blob 已移除，也仍需 rotation 已暴露的 credential。

安全 rollback 應同時恢復相容的 code 與 configuration；只 revert 一側可能留下 schema 或 behavior mismatch。

進行 destructive cleanup 前，應先用 read-only check 確認精確 path 與 owner；可行時優先採用可復原的移動或備份。

處理困難 incident 時，應在 restart 清除證據前保留同步 timestamps、Fleet logs、process trees、socket counts、service state 與 pane captures。