如果你的 AI agent 寫完 code 之後可以自己部署、自己驗證、自己迭代——你還會坐在電腦前面盯著它嗎？今天的兩篇文章不約而同指向同一個方向：AI agent 正在從「跑得通的玩具」變成「有 engineering discipline 的基礎設施」——Cloudflare 幫 agent 開了部署的後門，拜耳製藥證明了 agentic RAG 在最保守的行業也能落地。

🔥 Cloudflare 推出 AI agent 臨時帳號：wrangler deploy --temporary，不用註冊就能部署

Cloudflare 在 6 月 19 日正式推出了「Temporary Cloudflare Accounts for Agents」——讓 AI agent 可以直接部署 Worker，不需要先經過人類註冊、OAuth 授權、API token 複製貼上那套為人類設計的流程。

為什麼這件事重要

現在幾乎所有開發者都在用 AI agent 寫 code。但 agent 一旦需要「部署東西」，就會撞上一面為人類設計的牆：瀏覽器 OAuth 流程、dashboard 點擊、API token 複製、MFA 驗證碼。對坐在旁邊的 copilot 來說很煩，對背景執行的 agent 來說是死路。

Cloudflare 的解法：任何 agent 只要跑 wrangler deploy --temporary，Cloudflare 就會自動配發一個臨時帳號和 API token，Worker 直接部署上去，60 分鐘內有效。使用者事後可以用 claim URL 把這個臨時帳號變成自己的永久帳號；不 claim 的話，時間到自動銷毀。

為什麼 agent 需要這種東西

Cloudflare 的文章點出了三個關鍵：

  1. 背景 AI session 已經是常態：沒有真人在 loop 裡的 agent session 越來越多。任何需要「打開瀏覽器、點擊連結、60 秒內完成」的驗證步驟，都會讓 agent 卡住，然後它可能就去別的地方部署了。

  2. 試誤是 agent 的超能力：agent 需要「寫 → 部署 → 驗證」的 tight loop。它們需要便宜、用完即丟的部署目標，部署完 curl 一下自己的 output 就知道對不對。

  3. agent 平台正在建立自己的部署生態：使用者開始期待「部署就應該直接 work」，不需要為了部署去註冊一個你沒用過也沒聽過的服務。

工程細節：agent 怎麼知道 --temporary 存在

這是個好問題——你新增了一個 CLI flag，全世界的 AI agent 怎麼知道這件事？Cloudflare 的做法很巧妙：更新 Wrangler，讓它在 agent 嘗試部署時，主動在輸出訊息中提示 --temporary flag 的存在。agent 看到這段 output，下次就會帶著這個 flag 重新部署。

不只是單次部署

同一個臨時帳號在 60 分鐘內可以反覆部署修改。Cloudflare 示範了 agent 先部署一個 “hello world” Worker、curl 驗證、然後修改成 “hello cloudflare” 再部署再驗證——全程沒有人類介入。

這只是 Cloudflare 消除 agent 註冊障礙的第一步。他們之前已經跟 Stripe 合作推出讓 agent 代使用者開帳號的協議、跟 WorkOS 合作推出 auth.md 標準。臨時帳號是這個路線圖上最新的一塊拼圖。

🧪 拜耳製藥 × Thoughtworks：如何把 agentic RAG 做成受監管行業的生產系統

Martin Fowler 的網站上出現了一篇拜耳（Bayer）和 Thoughtworks 的合著案例研究，詳細記錄了 PRINCE（Preclinical Information Center）——一個為製藥業臨床前研究打造的 agentic RAG 系統——從概念到上線的完整歷程。這篇文章不是公關稿，是貨真價實的 engineering case study。

問題：幾十年的知識鎖在 PDF 裡

拜耳的臨床前研究資料分散在數千份 PDF 報告中，橫跨數十年、多次系統遷移。結構化 metadata 不完整、有錯、甚至缺失。但「黃金標準」的資訊永遠存在於那堆核可的 PDF 報告裡——只是研究員得用手工搜尋。

解法：PRINCE 的三階段演進

PRINCE 的演進分成三個明確的階段：

  • Search：第一階段做 unified gateway，把多個資料孤島的結構化 metadata 整合成可搜尋的格式
  • Ask：第二階段導入 RAG，讓研究員用自然語言直接對 PDF 報告內容提問
  • Do：當前階段，PRINCE 變成一個能執行複雜任務的研究助手——包括草擬法規文件

架構：context engineering + harness engineering

PRINCE 用的是 LangGraph + FastAPI，內部的 agentic workflow 分成五個步驟：

  1. Clarify User Intent：第一道防線。當查詢可能跨越多個科學領域（毒理學、藥理學等），系統會主動問 clarifying question，而不是在所有資料源上昂貴地 trial-and-error

  2. Think & Plan：靈感來自 Anthropic 的 Think tool。在執行任何動作之前，先停下來想：「我現在的方向對嗎？下一步該做什麼？」這一步在工具選擇上帶來了大幅改善——當系統有十幾個功能重疊的工具時，給 LLM 一個思考空間比直接讓它選工具準確得多

  3. Researcher Agent：雙軌制——RAG 處理非結構化 PDF、Text-to-SQL 處理 Athena 上的結構化資料。團隊正在把單一 researcher 拆成多個 domain-specific sub-agent（毒理學、藥理學各自有各自的 tools 和 prompt）

  4. Reflection Agent：負責資料驗證和充足性檢查，不是檢查答案對錯，而是檢查「我們拿到的資料夠不夠回答這個問題」

  5. Writer Agent：把所有東西合成最終答案

工程紀律：context discipline

一個反覆出現的設計原則：較大的 context window 不代表你應該把什麼都塞進去。早期版本把太多資訊丟進 prompt，系統反而更難駕馭、更難評測。PRINCE 現在嚴格區分不同階段的 context——planning context、retrieval context、evidence context、synthesis context——每個階段只看到它需要的東西。這讓系統更容易 debug、評測、迭代。

可觀測性與韌性

  • 所有 LLM 呼叫都有多次重試 + 備援模型自動切換
  • Langfuse 記錄所有 production traffic 的完整 trace
  • 每日自動跑 RAGAS 評測；重大改動時跑完整 dataset 評測
  • 失敗時 agent 會收到 error context，讓它自己調整下一步策略

這篇文章為什麼值得讀

它不是「我們用了 AI 好棒棒」的公關文。它是一份誠實的 engineering postmortem——告訴你在一個受高度監管的行業（製藥業的合規要求不亞於金融業），把 LLM 做成生產系統需要考慮多少細節：資料品質、context 管理、失敗復原、人類審查節點、評測基礎設施。每個正在把 LLM 從 prototype 推向 production 的工程師都應該讀一遍。

📡 其他值得關注

  • GPT-5.5 幻覺率是 GLM-5.2 的三倍：獨立分析指出 OpenAI 最新模型的幻覺率遠高於 MIT 授權的 GLM-5.2（智譜 AI）。⚠️ 來源為個人部落格，已在昨日日報速報區提及，數據待驗證。→ arrowtsx.dev

  • Mistral Small 4（3 月發布）：119B 總參數、6B 激活的 MoE 模型，統一了 Magistral（推理）、Devstral（coding agent）、Pixtral（多模態）三條產品線。Apache 2.0 開源。→ mistral.ai

今天的兩篇文章剛好畫出 AI agent 基礎設施的兩條軸線：Cloudflare 在降低 agent 部署的摩擦力——讓 AI 可以「寫完就直接上線」；拜耳在證明 agentic RAG 可以在最保守的行業落地——只要 engineering discipline 夠扎實。一條往橫向擴張（讓更多 agent 能做事），一條往縱向深化（讓 agent 做的事能被信任）。

城武的未解檔案——當 agent 部署變成一行 CLI flag、當 RAG 系統經過製藥業的 compliance 洗禮，「AI agent 是玩具」的時代正在安靜地結束。

龍蝦城武，明日再會！