網站如何在整個工作階段中持續為滑鼠軌跡、按鍵節奏、焦點變化與頁面可見性評分，藉此抓出能通過單次靜態檢查點、卻在整段行為上露出馬腳的機器人。
一個執行真實瀏覽器、能執行 JavaScript、偶爾還能過驗證碼的機器人，幾乎能通過網站設下的所有靜態檢測。它難以偽造的，是整個造訪過程中的行為方式——真實的手在真實滑鼠上留下的那種受物理規律約束的細微雜訊，從第一次點擊持續到最後一次。行為機器人偵測評分的正是這個：在整個工作階段中持續蒐集的互動訊號，而不是單一檢查點。
關鍵要點
- 偵測正從單一檢查點轉向整個工作階段。2026 年 7 月，Cloudflare 推出了 Precursor，一套用戶端、以工作階段為基礎的驗證系統，會在整個造訪過程中持續蒐集行為訊號，而不是只在某次登入或結帳時評一次分。
- 行為訊號是時序與動作，而非內容本身。指的是滑鼠移動、按鍵節奏、焦點變化與頁面可見性狀態——而不是按了哪些鍵或輸入了什麼內容。
- 跨訊號相關性才是真正的偵測機制。偵測系統會核對各條獨立訊號流是否彼此吻合——滑鼠活動是否與可見焦點同步？按鍵事件是否只在欄位取得焦點時出現？——而不是單看某一條訊號流是否「看起來可疑」。
- 「不像人類」有著具體的形態：線性內插而非自然弧線、數學上完美的曲線、恆定速度，以及缺少真實手部會有的那種「過衝後修正」的微小動作。
- 這是一種偽陽性取捨，而非已解決的問題——行為評分需要足夠的互動資料才能生效，在純觸控行動裝置上表現會下降，還可能誤判使用輔助技術或僅用鍵盤操作的使用者。
從單一檢查點到整個工作階段
我們在機器人偵測技術指南中介紹的大多數機器人訊號——自動化標誌、無頭瀏覽器洩漏、網路指紋——都只在單一時刻被評估：頁面載入、表單送出，或結帳那一刻。這對付不夠老練的自動化很有效，但一個資源充足的機器人只需要在那一個瞬間看起來乾淨就夠了。正如 Cloudflare 在 2026 年 7 月推出 Precursor 時所說，「如今的自動化程式越來越能在短時間內表現得很像合法使用者」——它們跑的是真實瀏覽器、會執行 JavaScript，還能一步步磨過單次挑戰。
據 Cloudflare 描述，Precursor 的因應方式是不再把驗證當成一次性的判斷，而是注入輕量、經過混淆的 JavaScript，在整個工作階段期間持續擷取互動訊號——指標移動、鍵盤活動、焦點變化與可見性狀態，先在本機緩衝，再定期送到評估伺服器。工作階段執行得越久，行為特徵就累積得越多，這改變了攻擊者面對的成本結構：機器人無法只靠重新整理頁面，就重置自己已經暴露的資訊。本文討論的是這一層技術的普遍原理——什麼是行為訊號、為什麼貫穿整個工作階段的評分能奏效、以及它的局限在哪裡——Precursor 只是這個趨勢的一個具體、近期的例子，而不是一份可供逆向工程的規格。
行為訊號究竟是什麼
行為訊號說的是一個動作「是怎麼發生的」，而不是「發生了什麼」。瀏覽器本身已經暴露了原始事件：用來擷取指標位置與壓力的 PointerEvent、用於鍵盤時序的 keydown/keyup、焦點事件，以及用來判斷分頁是否真正處於可見狀態的 Page Visibility API。偵測腳本監聽的正是任何互動式頁面本就依賴的那些事件；蒐集它們並不需要任何特殊權限。
最常出現的四類訊號：
| 訊號 | 擷取的內容 | 為何難以偽造 |
|---|---|---|
| 指標移動 | 游標在兩點之間移動的路徑、速度與壓力 | 真實的移動受手腕／前臂的物理機制約束，既非直線也非理想曲線 |
| 按鍵節奏 | 按鍵按下與放開之間的時間，以及按鍵之間的間隔 | 時序上的雜訊反映的是運動控制能力，與按了哪些鍵無關 |
| 焦點變化 | 某個元素何時取得或失去輸入焦點 | 腳本化的輸入常常直接設定值，卻從未真正觸發欄位的焦點事件 |
| 頁面可見性 | 分頁是否真的處於前景（document.hasFocus、可見性狀態） | 自動化經常操縱一個從未被置於前景的頁面，或乾脆以無頭模式執行，根本不存在真正的「畫面」 |
這四種訊號，單獨看沒有一種能證明什麼。一次異常快的按鍵，或一次直線滑鼠移動，真實使用者身上同樣會發生。訊號的價值來自這種模式在一次工作階段內的成百上千個微小事件中持續保持一致。
跨訊號相關性才是真正的偵測機制
真正把機器人和人類區分開的，從來不是某一條訊號流本身，而是這些獨立的訊號流之間是否彼此吻合。偵測系統會核對的幾個例子：
- 按鍵事件是否只在對應欄位真正取得焦點時才出現，還是值直接出現卻從未觸發過焦點事件？
- 指標活動是否與頁面確實可見同步，還是「滑鼠移動」在一個被切換到背景或以無頭模式執行的分頁上依然持續？
- 從看到目標到點擊目標之間的延遲，是否符合反應時間——從視覺處理到動作反應所需的可量測滯後——還是點擊幾乎與頁面變得可互動同時發生？
一段能夠以程式填寫表單的腳本，完全可以偽造 mousemove 和 keydown 事件來「裝作在場」。真正難以令人信服地偽造的，是讓這些偽造的訊號流在整整一次工作階段中，始終以真實相關的人類輸入才會呈現的方式互相吻合，且不露出一絲破綻。
「不像人類」的具體形態
螢幕上兩點之間真實的游標移動很少是直線。它是一條由手腕和前臂的實際轉動方式塑造出來的弧線，上面疊加著來自不自主手部震顫的微小起伏，而且通常會在到達目標前輕微過衝，再修正回來——這種收尾處特有的小幅「晃動」很難令人信服地偽造。自動化的指標路徑往往會在以下幾種常見方式中露出馬腳：
- 在兩個座標之間做線性內插，而非自然弧線
- 數學上理想的貝茲曲線——比真實的神經肌肉雜訊更平滑、更一致
- 整個移動過程速度恆定，而真實的手會有加速與減速
- 精準落在目標上，沒有過衝後修正的晃動
- 按鍵時序的變異幾乎為零——每個鍵按住的時長完全一致，每次按鍵間隔也完全相同
認知負荷同樣會留下痕跡：從目標出現到真實使用者點擊它之間，存在一段可量測的延遲，反映的是真正去看、去判斷、去行動所需要的時間。一次幾乎在元素剛變得可點擊就立即觸發的點擊，本身就是一個破綻，與游標究竟是怎麼走到那裡的無關。
為什麼會出現這一層偵測
靜態破綻往往只需一次修補就能被隱藏。一旦像 navigator.webdriver 或某個具體的無頭瀏覽器痕跡之類的偵測手法被公開，它就會被修補或掩蓋，就像基於 CDP 的自動化偵測已經經歷過幾輪「發現—修補」的循環一樣。一個必須在整整一次真實工作階段中持續、正確地「演出來」的訊號，與一個只需要在頁面載入時「宣告」一次正確即可的訊號，對攻擊者來說是完全不同量級的難題。這正是行為評分即使在各類靜態檢測不斷被磨平之後，依然持續擴大陣地的結構性原因。
代價的一面：偽陽性才是真正的矛盾
行為評分並非已解決的問題，坦白說，它在這些地方會承受壓力：
- 它需要足夠的互動資料才能生效。一次幾乎沒有滑鼠或鍵盤活動的工作階段——使用者開啟、閱讀、然後離開——無論往哪個方向評分，模型能拿到的資訊都不多。
- 在純觸控輸入下會退化。行動裝置上的點按與滑動並不會產生滑鼠才有的那種指標弧線訊號，因此圍繞游標物理特徵建構的行為模型，需要為觸控建立完全不同的基準。
- 可能誤判輔助技術與純鍵盤使用者。開關輔助裝置、語音控制與鍵盤導覽，產生的互動模式本來就與典型的滑鼠加鍵盤工作階段不同——而這種「不同」，正是一個粗糙的行為模型天生就會標記的對象。
以上這些並非 Precursor 獨有；這是任何行為評分系統一旦開始把「異常」當作「自動化」的代理指標，就必然要承擔的取捨。
同樣的訊號，指向人類而非機器人
行為機器人偵測與工作階段回放腳本（如 FullStory、Hotjar）取自完全相同的一口井——滑鼠移動、按鍵時序、捲動與焦點事件。差別在於目的：一個系統為這些訊號流評分，判斷訪客是不是人；另一個系統記錄這些訊號流，讓分析人員日後回放某個真實訪客的工作階段。同樣的瀏覽器 API，相反的意圖。
查看網站能看到你哪些資訊
行為評分發生在伺服器端、貫穿整個工作階段，因此不像檢查一次靜態指紋那樣能被直接觀察到。你能看到的，是它所依賴的用戶端可觀測層：BrowserInsight 的機器人偵測工具會顯示你的 navigator.webdriver 狀態、無頭與自動化痕跡，以及指紋一致性訊號——這些是檢查點層面的破綻，在一套完整的行為偵測體系裡，它們只是與上述所有內容一起被持續評分的眾多輸入之一。
常見問題
行為機器人偵測和驗證碼是一回事嗎？
不是。驗證碼是一次主動的、一次性的挑戰，需要訪客去解答。行為偵測是被動且持續的——它為訪客正常使用頁面時自然產生的互動訊號評分，不需要訪客額外做任何事。
機器人能偽造滑鼠移動和按鍵嗎？
它能產生單獨看起來還算可信的合成事件。真正困難的是，讓指標移動、按鍵時序、焦點變化、可見性這幾條訊號流在整整一次工作階段中始終彼此內在一致，而不出現那種線性、恆速、零變異的模式——這類模式正是腳本化輸入露餡的地方。
行為評分會取代 navigator.webdriver 這類靜態偵測嗎？
不會，它是疊加在靜態偵測之上的。navigator.webdriver、無頭渲染異常、網路層指紋這些靜態檢測仍然會被評估；行為評分額外增加了一層貫穿整個工作階段的訊號，比任何單一檢查點都更難以令人信服地偽造。
為什麼行為偵測還要在意頁面可見性，而不只是滑鼠移動？
因為可見性狀態是一種成本很低的手段，能捕捉一大類從未真正渲染出人類看得到的前景頁面的自動化——包括部分無頭方案——並且它能讓偵測系統核對其他訊號（例如按鍵）是否與頁面確實被檢視這件事相吻合。
