標籤: Cloudflare

  • Kitesurf:讓 AI 真的會自己上網的瀏覽器

    Kitesurf:讓 AI 真的會自己上網的瀏覽器

    📌 本文重點

    • Kitesurf 是專給 AI 用的雲端 headless 瀏覽器
    • 可與 Cloudflare Workers 深度整合做自動化腳本
    • 很適合把重複的網頁操作交給 Agent 執行

    一句話先說清楚:Kitesurf 是一個給 AI 用的雲端 headless 瀏覽器,讓你可以把「打開網頁、點按鈕、抓資料」這種重複操作,交給 Agent 自己跑。

    官方介紹與新聞:
    – Kitesurf 技術新聞報導(TechCrunch):https://techcrunch.com/2026/08/07/cloudflare-launches-kitesurf-a-browser-built-for-ai-agents/
    – Cloudflare 產品首頁(可留意 Kitesurf 區塊):https://www.cloudflare.com/


    核心功能:給 Agent 用的瀏覽器長什麼樣

    1. 雲端托管,資源比傳統瀏覽器省

    一般你要讓 AI 幫你「用瀏覽器」,有兩種常見做法:

    • 在本機或伺服器跑一個 Chrome + Puppeteer / Playwright
    • 用第三方爬蟲平台代抓資料

    問題在於:瀏覽器超吃資源,一開幾十個 tab,CPU、RAM 都會爆;而且部署、維護都很麻煩。

    Kitesurf 的做法:

    • 在 Cloudflare 雲端托管瀏覽器實例,不用自己維護機器
    • 專門為「自動化任務」優化,比 Chromium 跑同樣任務用更少資源(來源:TechCrunch 報導)

    💡 關鍵: 把瀏覽器搬上 Cloudflare,能在不爆 CPU/RAM 的前提下,大量並行跑 Agent 任務。

    你可以直接採取的行動:

    1. 先盤點手上「需要瀏覽器、但完全不需要人眼看」的任務,例如每天打開 10 個網站抓價格、每週登入後台匯出報表。
    2. 把這些任務列成清單,準備遷移到 Kitesurf(後面教你怎麼寫最小範例)。

    2. 為 AI agent 打好的控制介面:DOM、截圖、表單填寫

    Kitesurf 的定位不是「給人看的瀏覽器」,而是給程式和 LLM 控制的瀏覽器實例。

    實際可用的能力大致包含:

    • 打開網址、導頁(類似 page.goto(url))
    • DOM 操作與查詢(抓特定元素文字、點按鈕、選擇下拉選單)
    • 截圖與元素截圖(讓 LLM 用圖像理解頁面)
    • 表單填寫與送出(登入、填問卷、提交後台表單)

    這對你有什麼實作上的意義?

    • 可以把「在某個 SaaS 後台點 10 次才能拿到報表」寫成腳本,交給 Agent 每天自動跑
    • 可以讓 LLM 不是只「看 API」,而是真的去打開你指定網站、看 DOM、再整理成結論

    💡 關鍵: Kitesurf 把「點按鈕、填表單、抓文字」這種人類動作,變成 LLM 可以直接呼叫的程式接口。

    你可以直接採取的行動:

    1. 準備一個你最常手動重複操作的網站,例如:電商後台、競品官網、資料庫查詢頁。
    2. 把你平常「人類操作步驟」拆成:打開哪個網址、點哪個按鈕、複製哪段文字,待會用 DOM 操作重現。

    3. 和 Cloudflare Workers / KV / Queues 的組合

    Kitesurf 最大的優勢之一,是長在 Cloudflare 生態系裡,可以直接跟既有服務串起來:

    • Cloudflare Workers:用 JavaScript / TypeScript 寫邏輯,呼叫 Kitesurf 打開頁面、抓資料、回傳給前端或 API 使用者
    • KV / D1 / 專用儲存:把抓到的結果存起來,做快取或歷史紀錄(例如價格走勢)
    • Queues / Cron Triggers:排程定期跑瀏覽任務,例如每天 9 點跑一次、每 5 分鐘抓一次競品價格

    你可以直接採取的行動:

    1. 如果你還沒有 Cloudflare 帳號,先到 https://dash.cloudflare.com/ 註冊免費帳號。
    2. 打開 Workers 介面,建立一個新的 Worker 專案,準備寫 Kitesurf 腳本。

    適合誰用?三種具體場景

    1. 競品與價格監控(行銷、電商營運)

    需求長這樣:

    • 每天要看 5–10 個競品頁面,記錄價格、折扣、是否有新品
    • 有 API 的就調 API,沒有 API 的就只好人工看

    用 Kitesurf + Workers,你可以:

    • 寫一個 Worker,定期叫 Kitesurf 打開競品頁面
    • 用 DOM 抓出「商品名稱、價格、標籤(如:限時優惠)」
    • 存到 Cloudflare KV / D1 或打回自己的後端

    可立即行動:

    • 選 3 個最關鍵的競品頁面,先做一版「只抓價格、標題」的最小腳本,之後再慢慢擴充。

    2. 批次表單填寫、報表下載(營運、後勤)

    典型情境:

    • 每週要登入 3 個系統,下載 CSV 報表
    • 或每天要在某個後台幫客戶批次建立任務 / 建案

    用 Kitesurf 可以:

    • 自動登入(在安全前提下,密碼用 Workers 的 secret 管理)
    • 用表單填寫 API 一次送出多筆資料
    • 把下載的檔案直接丟到你自己的儲存或觸發後續流程

    可立即行動:

    • 選一個「最痛」的後台操作流程,先嘗試只自動完成前 2 步(登入 +進入報表頁),驗證 Kitesurf 能正常操作,再慢慢接續。

    3. 讓客製 chatbot / agent「會自己上網」

    你可能已經有這些東西:

    • 一個幫你回答內部 FAQ 的 chatbot
    • 一個幫你寫 Email 的小 agent

    但它們通常只:

    • 用向量資料庫 + 你給的文件
    • 無法自己上網查新的資訊或打開內部 web 工具

    用 Kitesurf 時,你可以:

    • 在 agent 的工具集中,多加一個「瀏覽器工具」
    • 當使用者問的是需要去網站查的問題,LLM 會先呼叫 Kitesurf 打開指定網站
    • 讀取 DOM / 截圖後再整理成回答

    可立即行動:

    • 先選一個固定網站,例如公司的內部儀表板或公開文檔站,做一個「專門會查這個站」的小 agent,實驗效果。

    Kitesurf vs 其他「瀏覽器 Agent」怎麼選?

    市面上也有其他主打「瀏覽器自動化 Agent」的工具,例如 Hark、Rindler。這裡簡單用表格幫你比:

    名稱 核心功能 免費方案 適合誰
    Kitesurf 雲端 headless 瀏覽器,深度整合 Cloudflare Workers / KV / Queues 依 Cloudflare 定價,通常有免費級別 開發者、想在既有 Cloudflare 架構中加入 Agent 的團隊
    Hark 成品型瀏覽器 Agent,幫你在瀏覽器內完成任務 依產品方案,偏 SaaS 想直接用「會自己操作瀏覽器的助手」的終端使用者
    Rindler 團隊 web 工作流程自動化,偏向表單填寫、資料整理等場景 有試用方案(參考 Product Hunt:https://www.producthunt.com/products/rindler) 行銷、業務、資料分析團隊,想快速自動化重複網頁操作

    延伸閱讀:
    – Hark 報導:https://techcrunch.com/2026/08/05/hark-previews-its-browser-use-agent-for-completing-tasks/
    – Rindler Product Hunt:https://www.producthunt.com/products/rindler

    選擇原則:

    • 如果你 會寫 JS/TS,而且已經或打算用 Cloudflare Workers,選 Kitesurf
    • 如果你只是想要一個「幫你用瀏覽器的成品助手」,不想寫程式,優先看 Hark、Rindler 這類 SaaS

    💡 關鍵: 能寫程式就選 Kitesurf 自建流程,不想碰程式碼就用 Hark / Rindler 這種成品 SaaS。


    怎麼開始:用 Workers 寫一個最小 Kitesurf 範例

    以下示範一個「最小可行」的流程:

    • 在 Cloudflare Workers 用 TypeScript 呼叫 Kitesurf
    • 打開某個網站(比如一個公開新聞頁)
    • 抓特定 DOM 資料(例如標題)並回傳 JSON

    注意:目前 Kitesurf 仍偏新產品,實際 API 介面可能會調整,下方程式碼屬概念示意,重點在於「整體串接思路」。

    1. 建立 Worker 專案

    在終端機:

    npm install -g wrangler
    wrangler init kitesurf-demo
    cd kitesurf-demo
    

    在 wrangler.toml 中設定好帳號等基本資訊。

    2. 在 Worker 中呼叫 Kitesurf

    假設 Cloudflare 為 Kitesurf 提供一個 REST API,可以透過 fetch 呼叫,示意程式碼如下:

    export default {
      async fetch(request: Request, env: any, ctx: ExecutionContext): Promise<Response> {
        const url = new URL(request.url)
        const target = url.searchParams.get('target') ?? 'https://example.com'
    
        // 呼叫 Kitesurf 建立瀏覽器工作,打開頁面、抓指定 selector
        const kitesurfResp = await fetch('https://api.cloudflare.com/kitesurf/sessions', {
          method: 'POST',
          headers: {
            'Content-Type': 'application/json',
            'Authorization': `Bearer ${env.KITESURF_API_TOKEN}`,
          },
          body: JSON.stringify({
            url: target,
            actions: [
              // 這裡描述要做的事:打開頁面後抓某個元素文字
              {
                type: 'extract',
                selector: 'h1',
                name: 'title',
              },
            ],
          }),
        })
    
        const data = await kitesurfResp.json()
    
        // 回傳整理過的結果給使用者
        return new Response(JSON.stringify({
          target,
          title: data.results?.title ?? null,
        }), {
          headers: { 'Content-Type': 'application/json' },
        })
      },
    }
    

    使用方式:部署 Worker 後,打:

    curl "https://你的-worker-url/?target=https://news.yoursite.com/article"
    

    就會得到類似:

    {
      "target": "https://news.yoursite.com/article",
      "title": "某某新聞標題"
    }
    

    你可以直接採取的行動:

    • 把上面的範例改成抓你自己常看的網站標題或價格欄位,驗證 DOM 抽取是否正常。

    延伸:接上 OpenAI / Claude / DeepSeek,做一個「會查網站」的小 Agent

    有了 Kitesurf,就可以把「查網站」變成 LLM 的一個工具。流程示意:

    1. 使用者對你的 API / 前端聊天介面提問
    2. 你的後端(或 Worker)判斷:這題需要上網查,則
    3. 先呼叫 Kitesurf,打開指定網站、抓到 DOM / 截圖
    4. 把抓到的資料丟給 LLM(OpenAI / Claude / DeepSeek 等),請它整理成易讀回答

    範例流程簡化(概念)

    // 1. 先用 Kitesurf 抓資料
    const siteData = await callKitesurf({ url: 'https://example.com/pricing' })
    
    // 2. 把資料丟給 LLM
    const llmResp = await fetch('https://api.openai.com/v1/chat/completions', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'Authorization': `Bearer ${env.OPENAI_API_KEY}`,
      },
      body: JSON.stringify({
        model: 'gpt-4o-mini',
        messages: [
          {
            role: 'system',
            content: '你是幫使用者讀網頁並整理重點的助理。',
          },
          {
            role: 'user',
            content: `以下是某網站的價格資訊 DOM 內容,請幫我整理成 3 點重點:\n${siteData.text}`,
          },
        ],
      }),
    })
    
    const answer = await llmResp.json()
    

    你可以直接採取的行動:

    • 選擇你慣用的 LLM(例如 OpenAI、Claude、DeepSeek),先在 Worker 中寫好「接收資料、整理成簡單 summary」的基礎流程,再把 Kitesurf 的結果接進去。

    安全提醒:不要把敏感憑證丟進 Agent 上下文

    讓 AI Agent 可以自己上網,很容易踩到安全雷,這裡列幾個實務注意事項:

    1. 憑證管理用 Workers secrets,不要硬寫在程式碼或 prompt 裡
    2. 例如 KITESURF_API_TOKEN、網站登入密碼,都用 wrangler secret put 管理
    3. 限制 Agent 能操作的網域與行為
    4. 只允許它打你指定的幾個網域,避免亂逛整個網路
    5. 嚴格控管「可以送出表單的頁面」,避免 Agent 誤發郵件或誤改設定
    6. 對輸入做驗證
    7. 使用者輸入的 URL 要做白名單檢查,不要讓任何人用你的 Agent 當跳板亂爬網站

    你可以直接採取的行動:

    • 在寫第一版 Kitesurf + LLM agent 時,就先實作「允許的網域列表」與 secrets 管理,避免之後擴充時重構成本過高。

    總結:先從一個小任務開始,讓 Kitesurf 幫你接手瀏覽器

    Kitesurf 的本質就是:把瀏覽器變成一個可程式化的雲端元件,讓你的 Agent 能確實「會自己上網做事」。

    建議上手順序:

    1. 在 Cloudflare 建立 Worker,寫一個最小範例:打開網址、抓一段文字
    2. 接上你慣用的 LLM,做一個「會讀特定網站並整理重點」的小 Agent
    3. 再把你每天或每週的重複瀏覽器操作,一個個搬到 Kitesurf 上

    從一個最小任務開始,你會很快感受到差別:原本要人盯著螢幕點 20 次的流程,變成一支 Worker + 一個 Agent 就能搞定。

    🚀 你現在可以做的事

    • 到 Cloudflare 註冊帳號並建立一個 kitesurf-demo Worker 專案
    • 挑一個每天重複造訪的網站,照文中範例寫 DOM 抽取腳本
    • 選一個 LLM(如 gpt-4o-mini),把 Kitesurf 抓到的資料接進去做摘要 Agent
  • Cloudflare AI 一鍵開站實戰指南

    Cloudflare AI 一鍵開站實戰指南

    📌 本文重點

    • Cloudflare + AI Agent 把建站流程變成一條指令
    • Agent 幫你自動處理帳號、網域、DNS 與部署
    • 透過細分工具與沙盒權限控制降低風險

    用一句話講清楚:這套 Cloudflare + AI Agent 的做法,就是讓「註冊帳號、買網域、設 DNS、部署前端/反向代理」整包變成一條指令搞定的自動流程。

    參考:Cloudflare 官方示範 AI Agent 如何創建帳號、購買網域並部署專案:https://blog.cloudflare.com/agents-stripe-projects/


    核心功能:AI 幫你做掉的「雲端雜事」

    把這個 Agent 想成會上 Cloudflare 幫你跑腿的「小助理」,它擅長三件事:


    1. 自動開帳號與綁付款

    能做什麼:

    • 依照你的輸入,幫你在 Cloudflare 建新帳號或登入既有帳號
    • 透過 API 綁定 Stripe 等付款方式(在 Cloudflare 文中是 demo Stripe)

    你可以立刻做的事:

    • 先準備一組「測試用帳號 + 測試信用卡」(例如:Stripe test mode)
    • 在 Agent 的設定檔裡,只給它測試環境的 API Key,避免直接動到正式金流

    2. 自動買網域 + DNS 設定

    能做什麼:

    • 搜尋可用網域,根據你描述的站點主題幫你推薦(如:blog、landing page)
    • 幫你在 Cloudflare Registrar 購買網域
    • 自動建立對應 DNS 記錄(A、CNAME、TXT 等)

    你可以立刻做的事:

    • 先選一個你願意「當實驗品」的便宜網域(.dev、.xyz)
    • 把「搜尋網域」「購買網域」拆成兩個獨立步驟,先讓 Agent 只做搜尋與列出候選,購買時再由你點選確認

    3. 一鍵部署 Pages / Workers / 反向代理

    能做什麼:

    • 建立 Cloudflare Pages 專案,從 GitHub/GitLab 拉前端程式碼並自動部署
    • 建立 Workers 當 API gateway 或反向代理,轉發到你的後端
    • 將網域 CNAME / A 設到對應的 Pages 或 Workers,整站自動串起來

    你可以立刻做的事:

    • 先準備一個最簡單的範例 repo:只有 index.html 的靜態站
    • 在 Agent 裡把「部署 Pages」設計成可重複執行的腳本,之後要開新站只換 repo URL 與網域即可

    適合誰用:幾個實際場景


    1. 產品團隊:十個 Landing Page 反覆 A/B test

    • 你只需要寫清楚:產品描述、目標市場、想測的方案數
    • Agent 幫你:
    • 從模板庫挑版型
    • 幫你生成靜態文案 + 分版本
    • 各建一個 Pages 專案 + 子網域(如 v1.、v2.、v3)

    2. 個人開發者:接案每次都要幫客戶開新站

    • 預先寫好「開新客戶站」腳本:
    • 建 Cloudflare 帳號 + Project
    • 關聯 Git repo
    • 設 DNS + SSL
    • 真正接案時,只要把客戶資訊填進表單,Agent 幫你跑完流程

    3. 小團隊 SRE / DevOps:想把「開新環境」變成自助服務

    • 把目前手動 run 的 Terraform / CLI 流程,包成幾個固定步驟
    • 用 Agent 把這些步驟串成「對話式自助開環境」,讓工程師只回答幾個問題就能有 dev / staging 站

    怎麼設計安全的 Agent 流程與權限

    這類 Agent 一旦拿到金流與 DNS 權限,風險就很實際,所以要先設計好「它能做什麼」與「什麼一定要人按確認」。

    💡 關鍵: 把高風險操作拆成小工具並加人類確認,是在維持自動化效率下控管金流與 DNS 風險的核心做法。


    步驟 1:把任務拆成幾個明確能力(tools)

    建議至少拆:

    1. search_domains:搜尋可用網域
    2. purchase_domain:購買指定網域
    3. create_cf_account:建立 Cloudflare 帳號
    4. deploy_pages_project:建立 + 部署 Pages
    5. create_worker_and_route:建立 Worker 並設定路由
    6. update_dns_record:新增 / 修改 DNS

    每個能力對應一個 API client 或 script,Agent 只能呼叫這些「包裝好」的函式,不直接拿到 raw API key。


    步驟 2:為每個能力標示「是否需要人類確認」

    一個簡單實作方式:在工具定義中加一個 flag:

    {
      "name": "purchase_domain",
      "human_approval_required": true,
      "max_amount": 20
    }
    

    然後在你的 Agent orchestrator 裡:

    • 若工具標示 human_approval_required,就把呼叫參數(例如網域名稱、價格)顯示在後台或發 Slack/Email
    • 只有當你點「批准」後,才真的讓後端執行這個工具

    步驟 3:使用「細分 API Key」與沙盒環境

    實務上避免「一把鑰匙開全公司」。

    • Cloudflare:
    • 建一個 專門給 Agent 用的 Account,只能管特定 zone
    • 使用 Scoped API Tokens,只開啟 DNS / Workers / Pages 所需權限
    • 金流(如 Stripe):
    • 一開始只給 test mode key
    • 等流程穩定後,再引入正式金流 + 嚴格人類審批

    實際腳本示範:從一句話需求到站點上線

    下面是一條「可複製」的流程。假設你在自建的 Agent 平台上,給模型這個任務:

    幫我開一個介紹 AI 工具評測的個人網站,用最便宜的可用網域,前端用現成靜態模板,掛在 Cloudflare Pages,上線後回報網址與部署細節。

    可以拆成以下幾步(你在 orchestrator 裡實作):


    1. 理解需求(LLM 自己完成)

    • 抽取:主題(AI 工具評測)、語言(繁中)、預算(便宜網域)、託管方式(Pages)

    2. 搜尋網域(需人確認)

    • Agent 呼叫 search_domains,傳入關鍵字:ai-tool-review, aitoolnotes 等
    • 回傳候選清單(名稱 + 價格)
    • 顯示在 UI 讓你勾選要買哪一個

    3. 購買網域(強制人類確認)

    • 你勾選後,才允許 Agent 呼叫 purchase_domain
    • 成功後記錄網域 ID,存入任務上下文

    4. 部署 Cloudflare Pages

    • 先由 Agent 幫你選模板+生成內容:
    • 基於 GitHub 上某個 starter template(設定在系統 prompt 裡)
    • 產生 index.html 內容(標題、關於我、最新評測文章列表 placeholder)
    • 呼叫 deploy_pages_project:
    • repo_url: 你預先準備好的 template repo
    • build_command: “npm run build” 或空字串(純靜態)
    • output_dir: dist / build

    5. 設定 DNS 與路由

    • Pages 部署完成後會有一個預設子網域
    • Agent 呼叫 update_dns_record:
    • 把剛買的網域的 @ 或 www CNAME 指到 Pages 網址

    6. 回報結果

    • Agent 最後整理:
    • 站點網址
    • 使用的網域價格
    • Pages 專案名稱與部署歷史連結
    • 你可以點進去檢查,如果沒問題,下次只要換一句需求就能複製整套流程

    想看 Cloudflare 官方更進階的案例(含 Stripe、Workers 整合),可參考:https://blog.cloudflare.com/agents-stripe-projects/


    實務風險與如何加上「人類確認」

    在 Reddit / Medium 上已經有很多討論,尤其是當 Agent 直接碰資料庫或金流時,風險會被放大。像 Vishesh Rawal 就分析了 AI Agent 連 PostgreSQL 時,因為連線被占住 6 秒而不是 5ms,讓連線池吞吐量掉了 1200 倍:https://medium.com/@visheshrawal/what-really-happens-inside-your-database-when-an-ai-agent-starts-querying-6d5254aeaa78

    💡 關鍵: AI Agent 對基礎設施與資料庫的「慢操作」,可能把吞吐量放大到原本的 1/1200,必須用節流與審批機制保護系統。

    對於 Cloudflare 這種「基礎設施類操作」,建議至少做三件事:


    1. 所有「花錢」的操作都要人工二次確認

    • 買網域、綁定正式金流、升級付費方案
    • 透過:Email、Slack bot、後台 Dashboard 的 Approve 按鈕

    2. 所有「改路由」的操作都要記錄審計

    • Log:誰下指令、Agent 呼叫了哪些工具、前後 DNS / Routing 差異
    • 發生事故時可以回溯,避免「Agent 胡亂改設定但找不到原因」

    3. 分環境:先在「沙盒帳號」驗證流程

    • 先在一個完全獨立的 Cloudflare 帳號跑完整流程
    • 確認行為符合預期後,才把相同腳本接到正式帳號,但權限再縮一級

    最低成本實驗指南:用現成工具在沙盒重現自動部署

    如果你想在一個週末內實際玩到這套「一鍵開站」流程,可以照這個極簡路線走:


    步驟 1:準備一個 Cloudflare 沙盒帳號

    1. 用新的 email 註冊一個 Cloudflare 帳號
    2. 建立一個 API Token:
    3. Template 選「Edit Cloudflare Workers」或「Edit Cloudflare Pages」
    4. Scope 只給某一兩個 zone(或一開始先不管 zone,只玩免費二級網域)

    步驟 2:選一個可以自訂 Tools 的 Agent 平台

    你可以用以下任一種方式:

    • 開源 / 自架:如基於 LangChain、LlamaIndex 或自寫 Python + OpenAI API
    • 商用平台:選一個支援「自訂工具 / Actions」的聊天式 Agent 介面

    關鍵是:你要能把「call Cloudflare API」包成一個工具,給模型呼叫。


    步驟 3:先做「最小可用流程」

    在沙盒帳號裡,先只讓 Agent 做兩件事:

    1. 建立一個 Cloudflare Pages 專案(用你現成的 GitHub 靜態站 repo)
    2. 回報部署網址給你

    這代表你只需要實作一個工具:deploy_pages_project,以及一個很簡單的 system prompt:

    你是一個幫助使用者在 Cloudflare Pages 部署靜態網站的助理。
    使用者只會提供 GitHub repo 連結與專案說明。
    你應該:
    1. 確認使用者需求
    2. 呼叫 deploy_pages_project 工具
    3. 回報部署後的網址與任何錯誤訊息。
    不要購買網域,只使用預設的 Cloudflare Pages 網址。
    

    等這條 pipeline 穩定後,再逐步加入:搜尋網域 → DNS 設定 → Workers 反向代理 → 網域購買(最後才加)。


    快速整理:這套做法的價值

    • 把「開新站」變成一條指令:從建帳號、買網域到部署,都由 Agent 操作 Cloudflare 完成
    • 可複製的腳本化流程:不同產品/客戶只改描述與 repo,其餘通用
    • 安全可控:透過細分工具、Scoped Token、人工審批,把風險鎖在沙盒與少數關鍵節點

    💡 關鍵: 先用 Pages 自動部署當起點,再逐步接入網域、Workers 與金流,是導入 Cloudflare Agent 化的漸進路線。

    如果你手上已經有穩定的 Git 部署流程,下一步就可以試著讓 Agent 幫你「接手 Cloudflare 那一段」,從最簡單的 Pages 自動部署開始,慢慢走向真正的一鍵開站。

    🚀 你現在可以做的事

    • 在 Cloudflare 開一個沙盒帳號並建立專用 Scoped API Token
    • 準備一個只含 index.html 的 GitHub 靜態站 repo,作為 Pages 測試專案
    • 在任一支援自訂 Tools 的 Agent 平台上實作 deploy_pages_project,跑通最小可用一鍵部署流程