2026 年 8 月 2 日，Cloudflare 用一篇三分鐘就能讀完的開幕文，正式拉開 Agents Week 的序幕。表面上是連續五天的 agent 主題發表，但這篇開幕文真正留下的不是產品，而是一個被倒過來問的問題：與其由人類定義「什麼是 Agent Cloud」，不如先承認這個問題從一開始就問錯了對象。
Cloudflare 團隊在規劃時，原本設定的題目正是「什麼是 Agent Cloud」。 但他們很快發現這個框架有個更根本的錯：只要從「我們認為 agent 需要什麼」出發，答案就永遠是人類的投射。該做的是把定義權交出去，去問 agent 本身需要什麼樣 purpose-built 的 foundation。這個轉向看起來只是修辭，實際移動的是產品設計的起點：需求從人類的想像，換成 agent 的實際行為。
為什麼要把問題反過來問
理由寫在現狀裡。今天的 cloud 與其下的 web，每一層都是為人類打造的：頁面為抓住注意力而設計，dashboard 為點擊而存在，interface 依照人類的閱讀節奏與決策習慣調校——每一層都預設「有一個人在看」。這不是哪一家的設計失誤，而是整個技術棧的預設值。
Agent 打破的正是這組預設。它們不分心、不疲倦、不會因為連續工作而失準，在乎的變數也不同：speed、structure、access。把這三個詞對照人機差異，落差就會浮出來——人類需要被吸引與被說服，agent 需要的是可預測的回應速度、可解析的結構化輸出、可程式化的存取路徑。所以「在既有工具上補一組 API」不等於 agent-ready：當預設互動對象仍然是人，agent 只能在人類流程的縫隙裡勉強運作。
Agent Cloud 的雙重任務
沿著這個轉向，Cloudflare 給 Agent Cloud 的定義是雙軌並行。 第一軌面向 agent-native 的未來：primitives 從零為 agent 打造，而不是把人類工具 retrofit 成 agent 勉強能用的樣子。第二軌面對過渡期的現實：在 human-shaped web 與 agent-shaped web 之間充當 translation layer，讓還沒改版的舊世界與正在成形的新世界互通。
值得把這當工程問題而非口號來讀（此段為我的詮釋）：只做第一軌，設計會漂亮但難以落地，因為大多數資料與系統仍活在人類形狀的網路裡；只做第二軌，則會永久背著相容包袱，agent-native primitives 永遠等不到出場。雙軌之間的張力，就是這個品類本身的難度。
五天議程：從 primitives 到 agentic web
接下來五天的主軸，官方明寫是「為 agents 與 humans 共同打造的 cloud 長什麼樣、彼此如何互動」。攤開議程可以對應到四個層次：agent 需要的 primitives 與 execution layer；更新的 agentic 軟體開發生命週期——縮寫 ADLC，官方定義很直白：像 SDLC，但把 humans 移出 loop；組織如何用安全 controls 讓 employees 與 agents 互動；以及 agentic web 的形狀，涵蓋 discovery、access 與 payments。
對 builder 來說，這份議程可以直接當檢查清單用：你的產品落在哪一層？該層的現有設計，預設使用者是人還是 agent？在產品落地前先回答這兩題，比之後再反應便宜得多。
問你自己的 agent：一個可以馬上做的實驗
開幕文最具體的號召是 ask-your-agent：不要只讀文章，直接問你自己的 agent「你需要什麼樣的 Agent Cloud」，並把回答分享出來——Cloudflare 想看的是各家 agent 的第一手回覆，不是自家 agent 的標準答案。官方給的 prompt 框架涵蓋五個面向：
| 面向 | 底層問題 |
|---|---|
| Storage 與 compute cloud | 運算與儲存以什麼形態供給 |
| Primitives（execution、storage） | agent 需要哪些原生積木 |
| ADLC | 人類移出 loop 之後，開發流程怎麼運轉 |
| Systems of record | deep work 需要哪些安全存取 |
| Web（discovery、access、payments） | agent 形狀的網路還缺什麼 |
就算你的 agent 還在 prototype 階段，這個實驗也值得跑。它逼你逐一檢查產品的預設假設：interface 是為誰的最佳體驗？資料結構是為誰的讀取效率？權限模型是為誰的工作流程？三個答案如果都是「人類」，你的 agent 整合就還停留在翻譯層。
願景文的讀法與限制
最後要誠實標定這篇開幕文的性質：它是願景文，不是產品公告。沒有 GA 時程、沒有量化數據，Agent Cloud 的邊界也還在「用問題定義」的階段。 ask-your-agent 同樣有方法學限制——agent 的回答終究是模型輸出，反映訓練分佈與 prompt 引導，未必等於基礎設施的真實需求；當探索工具很好，當需求聖經就危險了。
合理的期待是把這一週當成一場大規模的需求側公開實驗：看各家 agent 對同一份框架給出多分歧的回答，再看 Cloudflare 如何把這些回答收斂成 primitives。對 builder 而言，這比任何路線圖都直接——因為它展示的是需求方自己描述的需求，而不是廠商替它想像出來的。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。