Perplexity Comet 實戰：讓瀏覽器 agent 替你的 coding agent 跑腿，權限、@tab、Shortcuts 怎麼設才不出事

瀏覽次數: 1

用 Claude Code、Codex 寫 code 的人，大概都卡過同一個地方：agent 在 terminal 裡什麼都能做，但它看不到你登入後才看得到的東西。公司內部 wiki、要 SSO 的 issue tracker、vendor 後台、只有登入才顯示的 migration guide……最後還是你自己開瀏覽器，一段一段複製貼上到對話框。

Perplexity 的 Comet 補的正是這一段：它是一個瀏覽器，裡面住著一個看得到你「已登入分頁」、能點擊、捲動、填表的 agent。這篇不談 AI 瀏覽器誰會贏，只講工程師最需要的三件事：

它的權限流程怎麼運作（你按下「允許」時，實際放行了什麼）
怎麼設定、怎麼下 prompt，讓它替你的 coding agent 收集 context
哪些事絕對不要交給它（已有公開的攻擊案例）

先說清楚：以下內容整理自 Perplexity 官方 blog、help center 與公開安全報告，我沒有在正式環境長期跑過 Comet。凡是「我的建議」都會標出來，數字一律附出處。

本文大綱

背景：Comet 是什麼（30 秒版）

Perplexity 做的 Chromium 瀏覽器，大部分 Chrome 擴充套件都能裝。2025 年 7 月 9 日在 Windows / macOS 推出（一開始只開放給最高價的 Max 訂閱），2025 年 10 月起免費下載，Android 版 2025 年 11 月、iOS 版 2026 年 3 月上線（依 Wikipedia 彙整的媒體報導）。
兩種 AI 形態：側欄的 Comet Assistant 負責讀頁面、摘要、跨分頁問答；需要「動手」時，它會接手瀏覽器去點擊和填表。Perplexity 的企業版文件把後者叫做 Comet Agent。
這次要看的更新：2025 年 11 月，Perplexity 連發兩篇 blog。〈The New Comet Assistant〉讓它能跨多個分頁一起工作，官方稱內部測試比前一代好 23%；〈Comet Assistant puts you in control〉則把設計原則講白，也就是 transparency（看得到它在做什麼）、user control（由你決定它何時動手）、sound judgment（重要步驟先停下來問你）。

運作原理：一個任務在 Comet 裡要過 5 道關卡

把官方 blog、help center 和 Perplexity 安全團隊的技術文拼在一起，一個任務的流程大致如下：

第 1 關：先問你要不要它動手。 你在網址列、Perplexity 搜尋或側欄提問時，如果 Comet 判斷這件事在瀏覽器裡做比較好，會先問你要哪一種：自己瀏覽、允許這一次，或是之後偵測到有用就自動幫你做。官方說你選了之後，整個任務都會照這個偏好走。另外，進階 agent 第一次被觸發時，help center 描述的選項是「Allow this time only／Always allow／Don't allow」。

第 2 關：只帶必要的上下文。 根據 help center，瀏覽紀錄、完整分頁清單、cookie、密碼與自動填入資料、本機檔案，預設都不會上傳。只有在任務需要時，才送出「最少必要」的 context，例如當前分頁的可見文字、標題和 metadata，或是你用 @ 點名的分頁。有用到頁面或分頁內容的對話，會以 Temporary thread 的形式保留最多 30 天。另外有一個細節：agent 的動作（瀏覽、代辦任務）不會寫進 Perplexity 的 memory。

第 3 關：網頁內容先過分類器。 Perplexity 在 2025 年 10 月的〈Mitigating Prompt Injection in Comet〉說明了四層防禦。第一層是即時分類器：每次抓到新內容，先檢查裡面有沒有藏著給 agent 的指令，包括白底白字、display:none、HTML 註解、圖片裡人眼看不到的文字，以及企圖改寫使用者目標的內容。第二層是 structured prompting：外部內容在 prompt 裡一律標成 untrusted，而且每次選工具時都會拿你原本的 query 再提醒模型一次。

第 4 關：動作全部攤在側欄。 新版 Assistant 會顯示它點了哪裡、捲到哪、正在填什麼，也看得到它的逐步推理，旁邊隨時有 Stop 和補充指示的按鈕。

第 5 關：敏感動作一律停下。 官方 blog 舉的例子是登入某個網站、結帳；安全技術文列得更完整：寄信或傳訊息、修改行事曆、送出最終訂單、需要填入它原本不知道的使用者資料。這幾類動作「不論系統有沒有偵測到可疑內容」，都會停下來等你確認。攔截到疑似 injection 時，也會跳通知告訴你擋了什麼、為什麼擋。

上手設定：5 分鐘 checklist

照著做一次，之後用起來會安心很多：

開一個專用 Profile。（我的建議）Comet 的 Profiles 各自有獨立的 history、cookie、密碼和擴充套件。另外開一個「agent-work」profile，只登入工作會用到的帳號，個人 Gmail、網銀都不要登進去。這樣就算 agent 被網頁內容誤導，它能碰到的帳號也有限。
封鎖敏感網站。 到 Settings → Privacy and security → Comet Assistant 確認開關，再用「Block tasks on specific websites」把雲端正式環境的 console、DNS 註冊商、密碼管理器網頁版、銀行加進去。官方文件自己舉的例子就是「把你的銀行網站封鎖」。
預設搜尋引擎留在 Perplexity。 help center 寫明，改成別的搜尋引擎會限制或停用許多 AI 功能。
記住快捷鍵。 Opt + A（Windows 是 Alt + A）叫出 Assistant 側欄。
權限選擇的原則。（我的建議）陌生網站一律「允許這一次」；只有你自己掌控內容的內部工具，才考慮「Always allow」。

團隊版要注意的一個坑： 企業版管理員可以針對網域設三種權限：Browser Control（可操作）、Read Only（只能讀）、No Access（不能讀也不能動），也可以直接關掉使用者端的「Always Allow」選項。但文件特別提醒：網域層級的設定會覆寫全域設定。就算你把全域的 Assistant 關了，只要某個網域被設成 Browser Control，它在那個網域照樣能操作。寫 policy 時先列網域白名單，再決定全域開關。

Prompt 技巧：把 Comet 變成 coding agent 的 context 收集器

我建議的分工很簡單：Comet 負責到登入後的頁面收資料，coding agent 負責寫 code，兩者之間夾一份你審過的 brief。

招式 1：用 @ 做多分頁交叉比對

Assistant 會自動讀目前這個分頁，其他分頁要用 @ 點名。適合拿來回答「這個 bug 修掉了沒」這類要翻好幾頁的問題：

@GitHub issue 分頁 @CHANGELOG 分頁 @Migration guide 分頁
這個 issue 描述的 bug，在 v3.2 修掉了嗎？
若需要升級，列出會影響我們的 breaking changes。
規則：只讀，不要點任何按鈕。
輸出 markdown，標題用「## Context for coding agent」，每一條附原文連結。

有三個細節要注意：寫明只讀範圍、指定輸出格式、要求每條附原文連結。連結是給你核對用的，也讓 coding agent 需要時可以回頭查。不過要記得，「不要點按鈕」只是寫給模型看的約束，不是安全邊界。真正的邊界是上一節的權限和網站封鎖設定。

招式 2：把常用 prompt 存成 Shortcut

Comet 的 Shortcuts 就是可重用的 prompt。建立步驟（依 help center）：

在網址列或側欄輸入 /
點「Create a shortcut」
填 prompt，並選擇 Search Mode、Model、Source
取名，按 Save（之後可到 Settings → Shortcuts 修改）

幾個特性很適合工程用途：打了 shortcut 不會自動執行，你可以在後面補參數再送出；同一個 prompt 裡可以疊用多個 shortcut；還能透過分享連結發給同事。下面是一個可以直接抄的 /dep-brief：

我要評估一次相依套件升級。讀取我 @ 的分頁（release notes、migration guide、相關 issue），
整理成以下格式，只讀、不要點擊任何按鈕：
## 升級摘要（3 行內）
## Breaking changes（每條：影響的 API／原文連結）
## 已知問題（未解的 issue，附連結）
## 建議的驗證步驟
不確定的地方標「未確認」，不要自行推測。

使用時輸入 /dep-brief next 15 → 16，再 @ 相關分頁就行。順帶一提，官方的範例 shortcut /order-lunch 裡寫了「no approvals needed」。文件沒說這句話能不能繞過敏感動作的確認，但做工程用途時，我建議反過來寫：明確寫出停止點，例如「填到送出前停下」。

招式 3：brief 進 repo，coding agent 只讀 brief

把 Comet 的輸出存成 docs/context/next16-upgrade.md，自己看過一遍再 commit，接著在 Claude Code 裡這樣下指令：

讀 docs/context/next16-upgrade.md。先列出 repo 中受影響的檔案與理由，不要改 code。
brief 中標「未確認」的項目，用 grep 或測試驗證後再決定。

這一步的重點不在方便，而在建立信任邊界。coding agent 手上有 shell 權限，讓它直接吃網頁內容，等於把 prompt injection 的攻擊面從瀏覽器接到你的 terminal。中間多一份人工審過的 brief，就是最便宜的一道隔離。

數據與限制：先看清楚哪些數字能信

「比前代好 23%」：出自 Perplexity 自家內部測試，沒有公開 benchmark 和測試方法，只能當作方向參考。
BrowseSafe：Perplexity 在 2025 年 12 月開源的 prompt injection 偵測模型與 benchmark。論文是 arXiv 2511.20597（作者 Kaiyuan Zhang、Mark Tenenholtz、Kyle Polley、Jerry Ma、Denis Yarats、Ninghui Li，標註 COLM 2026）。模型以 Qwen3-30B-A3B-Instruct-2507 微調，MIT 授權，輸入 raw HTML（最長 16,384 tokens），只輸出 yes／no。BrowseSafe-Bench 共 14,719 筆樣本，涵蓋 11 種攻擊類型、9 種注入位置策略、3 種語言風格。
BrowseSafe 的成績要打折看：model card 上，它在 3,680 筆測試集拿到 F1 0.904、precision 0.978、recall 0.841。這是自家模型考自家 benchmark；而 recall 0.841 代表測試集裡約 16% 的攻擊樣本沒被抓到。官方 blog 也坦承，多語言、間接或假設語氣的攻擊比較難抓；藏在 HTML 註解裡的容易抓，改寫成可見的 footer、表格欄位、內文段落就難得多。model card 標註的語言是英文，所以繁中網頁上的偵測效果，是很值得實測的點。
公開的真實攻擊案例：
- Brave 安全團隊（Artem Chaikin、Shivan Kaul Sahib）在 2025 年 7 月 25 日通報、8 月 20 日公開一個攻擊：Reddit 貼文用 spoiler 標籤藏了指令，使用者只按了「摘要這個頁面」，agent 就去讀帳號 email、到已登入的 Gmail 拿 OTP，再回覆到留言區外洩。Brave 公開時註記 Perplexity 當時仍未完全修好。
- LayerX Security 在 2025 年 10 月公開「CometJacking」：把指令塞進 URL 的 collection 參數，要求 agent 讀取已連接的 email、行事曆，並用 base64 編碼繞過外洩檢查。LayerX 說 Perplexity 起初回覆「not applicable」，Perplexity 後來則向 TIME 表示已自行修補。
Perplexity 這邊的回應：官方時間軸寫著 2025 年 4 月上線前找 Trail of Bits 做威脅建模稽核、10 月公開四層防禦並開 bug bounty、12 月開源 BrowseSafe。

結論很直接：分類器會漏，所以最後一關的人工確認才是底線。不要養成看都不看就按「允許」的習慣。

適用場景與 trade-off

情境	交給 Comet？	更好的做法
查 SSO 後面的內部 wiki、issue、vendor 後台	適合	設 Read Only 心態，產出 brief
跨 3–5 個分頁比對版本差異	很適合	用 `@` 點名，要求附原文連結
要重跑、要進 CI 的瀏覽器流程	不適合	讓 coding agent 用 Microsoft 的 Playwright MCP 或 Chrome DevTools MCP 產出腳本並進版控
正式環境 console 的寫入操作	不要	走 IaC／CLI，經過 code review
登入敏感帳號的同時，讀陌生論壇或使用者生成內容	不要	分開 profile，或乾脆別讓 agent 讀

判斷原則只有一條：一次性、需要登入態、你人在旁邊看，就交給 Comet；會重複、要可重現、有寫入風險，就交給 coding agent 產出可以版控的腳本。

對工程團隊的意義：下週就能做的 5 件事

寫一頁 browser agent 使用守則，列出哪些網域可操作、哪些只讀、哪些禁止。有企業版就直接設成網域權限，並關掉「Always Allow」。
正式環境 console 設成 No Access，文件、wiki 類網站設 Read Only。記得網域設定會覆寫全域開關，上線前逐條驗一次。
統一 brief 格式並放進 repo（例如 docs/context/*.md），規定每條都附原文連結、不確定處標「未確認」。coding agent 只讀 brief，不直接吃網頁。
把好用的 prompt 做成 Shortcut，用分享連結發給團隊，讓大家的 context 收集方式一致。
如果你自己在做 agent：在工具輸出（網頁、email、檔案）送進模型之前，先掛一層 BrowseSafe 這類分類器，並把 BrowseSafe-Bench 當成回歸測試集。只是別忘了它在自家 benchmark 上也有約 16% 的漏抓率，敏感動作一樣要保留人工確認。