訊息平台
想在微信、Telegram 或工作群組中使用 Anyy，先確認主模型能在 Dashboard/TUI 正常回答，並讓同一 Profile 的 Gateway 保持執行。訊息帳號、配對授權和工作階段記錄都歸目前 Profile 管理。
先啟動，再設定
anyy gateway start
anyy setup channel
第二個指令在互動終端機中開啟平台選擇精靈。選中平台後，填寫它實際展示的欄位，檢查摘要並寫入。精靈需要從已執行的 Gateway 讀取通訊管道目錄；不要等到填寫完成才啟動服務。沒有互動終端機時，不帶平台名的指令只輸出目錄。
anyy setup channel telegram 這一類帶平台名的指令走非互動設定，需要配合 --set 和敏感輸入參數；它不會開啟 Telegram 專用問答精靈。
Dashboard 的入口是 通訊管道 → 新增。一般帳號表單主要填寫平台識別碼和認證資料；需要修改私訊、群組對話策略時，使用上面的互動精靈。微信已綁定帳號另有傳送者存取設定。
這個版本有哪些接入方式
| 平台 | 接收方式 |
|---|---|
| Telegram | Bot API 長輪詢 |
| Discord | Bot Gateway |
| Slack | Socket Mode |
| Business Cloud API Webhook | |
| Facebook Messenger | Page Webhook |
| IMAP 收信、SMTP 發信，均使用 TLS | |
| SMS | Twilio Webhook 與 REST |
| 釘釘 | Stream 長連線 |
| 飛書 / Lark | 預設長連線；已有 Webhook 帳號可更新 |
| 微信 | 掃描 QR Code 確認後長輪詢 |
| QQ Bot | WebSocket Gateway |
| IRC | TLS 與 SASL |
| LINE | Messaging API Webhook |
可設定不代表已連線。v0.1.107 的目錄開放了這些接入實現，但仍以帳號的實際觀測、診斷及使用者自己的收發測試判斷結果；Preview、能力宣告或本機儲存成功都不能代替真實帳號驗證。目錄中的 unsupported 項目不能靠猜欄位啟用。
目前設定介面按平台處理一個帳號：該平台已有帳號時進入更新，不提供第二帳號建立流程。
先決定誰能存取
平台支援的策略不同，精靈只接受目錄列出的值。常見私訊策略有 pairing、open、allowlist、disabled，群組對話常見 mention、open、allowlist、disabled。
一般平台的策略選擇在 CLI 精靈；Dashboard/TUI 的認證資料表單沒有這些策略輸入。名單編輯也有範圍限制：目前微信已綁定帳號的存取表單和 IRC 的 CLI 精靈提供 allow_from；其他傳送者/群組名單沒有公開條目編輯輸入，不要猜一個 --set allow_from=...。選擇 allowlist 不會自動建立名單；沒有匹配的已存條目時，傳送者不會獲准。支援配對的平台可先保留預設 pairing，不支援配對時不要把 open 當作僅自己可見。
有配對請求時，在 CLI 核對平台、帳號與傳送者後處理：
anyy channel pairing list
anyy channel pairing approve --request REQUEST_ID
anyy channel pairing reject --request REQUEST_ID
anyy channel pairing revoke --grant GRANT_ID --reason "access removed"
Dashboard 通訊管道頁不是配對核准清單。配對授權只決定傳送者能否使用助理；應核對真實身分，不能只看暱稱。
需要輸入一次性配對碼時，使用隱藏輸入：
anyy channel pairing approve --prompt-code --channel telegram --account personal
已知 ID 不在有大小限制的清單結果中時，可在對應 ID 操作後補 --channel 和 --account 選擇帳號；這不會繞過所屬檢查。
工作階段怎樣延續
同一帳號、對話另一端和平台 Thread 路由上的後續訊息可以重複使用已綁定的 Anyy Session。群組對話是共享工作階段環境；不同平台、Profile、帳號執行個體或 Thread 不能只憑同一個暱稱合併。
平台對回覆上下文的表達不同。Slack/Discord 保留 Thread；WhatsApp 與 Email 目前還會把入站訊息識別碼用於回覆路由，因此不能承諾同一聯絡人發來的所有訊息都進入同一個 Anyy Session。微信的回覆 Context Token 由接入層管理，不需要使用者抄寫。
/new 會為目前路由建立新工作階段；/stop 中止目前執行，不會關閉整條通訊管道。指令回覆傳送失敗不會撤銷已經完成的本機動作，重發指令前先檢查目前狀態。
Webhook 平台先開監聽
WhatsApp、Facebook、SMS、LINE 和飛書 Webhook 需要單獨的入站 HTTP 監聽。它預設關閉；在所選 Profile 的 config.yaml 中設定：
channel_webhooks:
enabled: true
listen: 127.0.0.1:8770
然後執行 anyy gateway restart。只執行 anyy channel reload 不會啟動此前關閉的監聽。將各平台文件中的 /channels/平台/账号/webhook 路徑，透過 HTTPS 反向代理轉發到這個監聽，不能誤指向 Dashboard 連接埠。保留原始請求體和平台驗籤所需 Header；Twilio 還需要準確的公開 URL 資訊。
儲存、投遞與重試分別看
帳號操作的 committed / no_op 僅表示本機設定。用 Doctor 檢視目前觀測，修改帳號後需要重新協調時可 Reload：
anyy channel doctor telegram
anyy channel reload
通訊管道支援傳送確認，不代表某條訊息已被閱讀。沒有平台確認時可能只有 sent_unconfirmed；平台接受也不代表收件人已讀。新最終回覆在尚未產生遠端副作用且可安全重試時會保留為待傳送；已部分傳送或結果未知時，不自動整則重送。先檢視平台記錄和診斷，避免重複投遞。Reload 不是重放舊工作階段歷史的指令。
非互動設定與秘密
只改一個已設定好的 Telegram 帳號策略，可使用：
anyy setup channel telegram --set dm_policy=pairing --set group_policy=mention
更新動作只有在欄位允許時才保留已有認證資料。首次建立需要提供必需認證資料，例如透過檔案描述符：
anyy setup channel CHANNEL --set INPUT=VALUE --sensitive-fd SECRET_INPUT=FD
FD 應為已開啟的專用描述符（編號至少為 3）。一般值用 --set；秘密值不要放進指令參數。支援外部認證資料位置的欄位可用 --external-locator-fd。實際輸入 ID 和可選值以目前精靈為準，不直接修改 state.db 或新增猜測的 YAML 通訊管道欄位。