摘要： Cloudflare 以 Agents Week 開幕文翻轉提問方向，主張向 agent 詢問它們需要的 Agent Cloud 基礎，而不是只由人類想像需求。活動議程涵蓋 primitives、執行層、ADLC、安全控制，以及 agentic web 的探索、存取與付款。
2026 年 8 月 2 日，Cloudflare 發表一篇短文，為 Agents Week 正式揭幕；全文讀畢約需三分鐘。活動形式上是連續五天的 AI agents 相關發表，但開幕文傳遞的核心並非某項產品，而是一個被翻轉的提問角度——以往人類急於回答「Agent Cloud 是什麼」，如今需要先承認：這個問題問錯對象了。
籌備 Agents Week 時，Cloudflare 團隊給自己的命題就是「什麼是 Agent Cloud」。不久他們便發現，這個框架有個結構性缺陷：起點一旦定為「我們認為 agent 需要什麼」，答案注定是人的想像投射。該做的是把定義權外移——去問 agent 本身要什麼樣的 purpose-built foundation。表面上是措辭調整，實則改變了產品設計的原點：需求不再由人腦猜測，而由 agent 的實際行為決定。
提問方向為何要反轉
原因就埋在今天的基礎設施裡。現行的 cloud 與其承載的 web，每個層級都是 human-first：頁面為了抓注意力而設計，dashboard 的存在意義是被點擊，interface 則配合人類閱讀與決策節奏調校——處處預設「有人在看」。這不是單一廠商的失誤，而是整個技術棧的預設值。
Agent 之所以關鍵，正因它衝破這組預設。它們不會分心、不會疲倦，長時間工作也不會失準；在意的變數也不同：speed、structure、access。把這三個詞與人類-agent 落差對照，差異立刻可見——人類要被吸引與說服；agent 要可預期的回應速度、可解析的結構化輸出，以及可程式化的存取路徑。於是，「在既有工具上加 API」不等於 agent-ready：只要預設互動對象仍是人，agent 就只能從人類流程的縫隙鑽過。
Agent Cloud 的雙軌定位
順著這個轉向，Cloudflare 把 Agent Cloud 定義成兩條並行路線。第一軌朝 agent-native 未來：primitives 從頭為 agent 打造，而非把 human 工具 retrofit 成勉強可用。第二軌對應過渡期現實：在 human-shaped web 與 agent-shaped web 之間作 translation layer，讓未改版的舊世界與成形中的新世界互通。
值得用工程視角讀這段，而非當口號（此段為我的詮釋）：只做第一軌，設計乾淨卻難落地，因多數資料與系統仍在 human-shaped 網路；只做第二軌，相容包袱永續背負，agent-native primitives 也永遠輪不到。兩軌張力即此品類的難度所在。
五天議程：從 primitives 到 agentic web
官方寫明接下來五天主軸：「為 agents 與 humans 共同打造的 cloud 長什麼樣、如何互動」。議程可拆成四層：agent 所需 primitives 與 execution layer；更新後的 agentic 軟體開發生命週期——ADLC，官方定義直白：像 SDLC，但把 humans 移出 loop；組織如何用 security controls 讓 employees 與 agents 互動；以及 agentic web 的形狀，含 discovery、access、payments。
對 builder 而言，這份議程可直接當 checklist：產品落在哪一層？該層設計預設使用者是人還是 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 為誰最佳化？資料結構為誰的讀取效率服務？權限模型回應誰的工作流？三答案若皆「人類」，整合仍卡在 translation layer。
願景文的讀法與其邊界
最後須坦白標示：這是願景文，非產品公告。無 GA 時程、無量化數據，Agent Cloud 邊界仍停留「用問題定義」。ask-your-agent 也有方法學限制——agent 回答是模型輸出，反映訓練分佈與 prompt 引導，未必等於基礎設施真需求；作探索工具很好，作需求聖經則危險。
合理期待是把本週視為大規模需求側公開實驗：看不同 agent 對同一框架回答多分歧，再看 Cloudflare 如何收斂成 primitives。對 builder，這比路線圖更直接——呈現的是需求方親口說的需求，不是廠商代為設想。