Cloudflare 推出智慧體開發生命週期

在過去幾十年來，工程經理們一直在設法讓眾多程式設計師能夠在共用程式碼庫上協作。這項工作可追溯至「系統開發生命週期」（RAND，1975 年）——現今常被稱為「軟體開發生命週期」(SDLC)，其定義了以下階段：

• 規劃
• 設計
• 實作
• 測試
• 部署
• 維護
• 淘汰

AI 讓過去最慢、最昂貴的步驟——實作——變得最快且最便宜。而這反過來對下游產生了影響：讓負責 SDLC 中所有其他步驟的人員不堪重負。從被海量 Pull 請求和 Issue 淹沒的開源專案維護者，到在軟體交付速度呈數量級增長時竭力維持生產環境穩定的運維工程師，無一不深受其擾。

我們都在努力拯救我們的系統、客戶以及我們自己，以免被低品質的混亂產出 (slop) 所吞沒。

雖然聽起來有點矛盾，但解決方案恰恰在於賦予智慧體更多能力。這才是公平的！您絕不只會讓團隊中的工程師負責寫程式碼，卻指望其他人來完成驗證、合併、部署、值班處理生產環境問題，以及分類新產生的錯誤。然而，這正是大多數公司目前對待智慧體的方式。儘管模型效能已顯著提升，智慧體也能在更長的時間跨度內執行並承擔更艱鉅的任務，但它們在 SDLC 各個階段的應用卻極不均衡。

Cloudflare 將智慧體視為我們的客戶。它們可以購買網域、建立臨時帳戶並使用 Cloudflare 的全套 API。我們深知，智慧體若要代表客戶管理整個 SDLC（而不僅僅是起步階段），就必須擁有對應的 API 和工具支援。

因此，今天我們推出了一套全新工具，讓智慧體不僅能產生程式碼，還能承擔更多 SDLC 的工作。我們將分享我們為解決自身問題所建構及學到的經驗：

• @cloudflare/ci：一種在數百萬個儲存庫中執行 CI/CD 的新方式，具備自我修復能力，並能產生智慧體來執行更複雜的任務，建構於 Cloudflare Workflows 之上。
• 本地開發環境中的 OpenTelemetry 追蹤：讓智慧體在本地開發時也能獲得與生產環境相同的可觀測性，該功能已整合到 Wrangler 和 Cloudflare Vite 外掛程式中。
• 全新推出 Cloudflare Agents 與 Agent Traces：一個以智慧體產生的 OpenTelemetry 追蹤資料為核心，用來觀測、維護與最佳化智慧體的全新平台。
• Cloudflare 如何運用 AI 強制執行工程標準：我們自己在所有產品、系統的儲存庫和規格中落實最佳做法的經驗。
• 我們如何打造軟體工廠，將 Astro 的 GitHub 議題數量歸零：我們自己為一個龐大且快速成長的開源專案，建立系統來自動分類、重現、驗證及修復議題的經驗。

然而，這背後有著更深遠的意義。檢視現有的 SDLC，即便擁有最先進的自動化技術，其既有假設也已無法適應智慧體所能產生的程式碼規模，以及軟體工程團隊為保持競爭力而必須具備的敏捷節奏。我們認為，是時候用 ADLC（智慧體開發生命週期）來取代 SDLC 了。

SDLC 是為軟體團隊而生，ADLC 則是為軟體工廠而設。

如今，人們都在談論建構「軟體工廠」——也就是由智慧體驅動的系統，它們能夠接收輸入，並自主完成軟體的建置、改進、部署和管理。無論是生產環境中的錯誤、客戶提交的錯誤報告，還是關於新功能的構想，一旦輸入這些資訊，整個處理過程便完全交由智慧體負責。

即便有了智慧體，大多數軟體專案依然卡在「人類介入」的流程上：人類對智慧體下提示、告訴它們繼續進行、指示智慧體採用程式碼審查的回饋、不斷地監督許多智慧體並給予指令。在大多數軟體團隊中，人類仍然管理著 SDLC 模型中的每一步驟——唯一的改變是他們將每個步驟中的任務委派給智慧體。

因此，軟體工廠背後的夢想是：如果您重新構想這一模式，並為整個軟體建構流程打造一座工廠，會怎麼樣？我們該如何將更多的人類時間轉移到真正需要人類靈感、品味和判斷力的事情上？這將為我們留下更多時間來設計、與客戶交談，以及懷抱更遠大的夢想。

軟體工廠必須涵蓋 SDLC 的所有步驟，但它對底層平台的要求更高。因為當您把鑰匙交出、讓智慧體掌舵時，原本仰賴人類的每一個手動步驟，都必須調整成具備以下特性：

• 可程式化 (Programmatic)：「點擊操作 (ClickOps)」對人類而言本來就是一種糟糕的做法，對智慧體更是完全不可行。每一項操作都必須有 API，讓智慧體能呼叫、除錯並穩定依賴。
• 水平可擴展 (Horizontally scalable)：當人類在建置過程中盯著螢幕，或手動接管預發布 (staging) 伺服器以在上線前排查問題時，預覽部署往往只是錦上添花的功能；但若要由智慧體主導，每個智慧體都必須擁有與生產環境一致的獨立預覽環境。
• 可重現 (Reproducible)：如果有一個錯誤只能在 iPhone 15 上模擬 4G 時重現，該怎麼辦？或者只能從某個國家/地區的 IP 重現？傳統的單元測試和整合測試工具在這裡幫不上忙。
• 即時、基於推送 (Real-time, push based)：靠人類盯著正確的儀表板來判斷系統是否正常，本來就不是好方法，放到智慧體身上更是徹底失效。您需要一個事件來觸發智慧體執行工作。
• 原子化 (Atomic)：每一次變更都必須能獨立測試、獨立發布、獨立觀測，且在必要時可回滾，且不影響其他不相關的功能。
• 權限控管 (Permissioned)：雖然明知不妥，但為了應對突發嚴重故障，您有時還是會把生產環境的 SSH 存取權交給幾位值得信賴的工程師。您絕不能讓智慧體擁有這種權限──但如果無法在必要時提升權限，智慧體又該如何完成工作呢？
• 自我改進 (Self-improving)：人們從經驗中學習。第一週上線或第一次值班輪調時，人類動作很慢，需要跟著別人學習，但之後會變得更好、更快。智慧體也需要有從經驗中學習的方式。

如果我們要讓軟體工廠能安全地用於真正的生產軟體，我們需要一些新東西。軟體工廠面臨著與其他自發系統（如自駕車）相同的挑戰——從 80% 的時間成功運作，推進到 99% 以上的高可用性。

要給智慧體掌管 SDLC 的鑰匙，您不能給它們一輛為人類設計的車

自動駕駛車輛搭載了一般汽車所沒有的感測器和技術。光達感測器、攝影機、用於執行推論的強大運算能力，以及連接到中央指揮系統（必要時可遠端接管）的通訊能力。

要讓自動駕駛車輛達到人類駕駛能力的 80%，我們或許並不需要所有這些配置。自駕技術在十年前就已經達到約莫人類駕駛能力的 80%。但這不是我們要跨越的門檻——門檻是要比人類駕駛好得多、安全得多。當我們把鑰匙交給機器時，這就是我們的期望，這樣我們才能在 101 號公路上以時速 60 英里行駛時安心地打個盹。正因如此，自動駕駛汽車才配備了專為自動駕駛打造的技術——這不僅是建立信任的關鍵，也是應對那些無法預先設計的「邊緣情況」的必要手段。

自動駕駛軟體也是同樣的道理。試問一下：為什麼您至今仍未允許您的智慧體自動核准並合併其針對生產環境服務的 PR（拉取請求）？您所建構系統的利害關係越重大，您列出的理由往往就越多。

當您深入剖析這個過程時，會發現它極為複雜：既要考慮可能引發災難性後果的各種風險，又要兼顧為客戶打造正確產品所需的各項要素。這絕非 GitHub Actions YAML 檔案中簡單的線性步驟所能涵蓋，也遠遠超越傳統自動化測試的範疇。即便是儀表板上的微小改動，也可能涉及不同的角色、專業領域和組織架構；而那些基於主觀判斷的變更，往往最難進行測試或授權。目前，這些環節大多並未納入您的 CI/CD 管線。然而，若想在賦予智慧體「軟體工廠」全面控制權的同時，確保這些必要環節得以落實，就必須將它們整合進來。

要讓智慧體主導整個流程，我們需要一個更優的方式來編排這些動態的步驟序列。我們認為，Workflow 便是理想的解決方案，它具備啟動容器、智慧體及瀏覽器的能力。Workflow 能設定功能旗標並針對測試使用者啟用、調查紀錄與追蹤資料、在變更逐步推出時觀測生產指標，並執行所有確保安全上線所需的操作。

CI/CD 管線就是一個 Workflow。但 Workflow 能做到的遠不止 CI/CD 管線。

Cloudflare Workflows 讓您能串接多個步驟、自動重試失敗任務，並將狀態持久化保存數分鐘、數小時，甚至數週。它們的設計目的，是以邏輯清晰、易於理解的程式碼，來表達複雜且動態的商業流程。這篇部落格文章深入解析了為什麼 Workflows 搭配 Artifacts，能從根本上簡化 CI/CD 管線的定義與觸發方式。舉例來說：

import { CIWorkflow } from `@cloudflare/ci`

const deps: CiRunnerResult = await ci.runner({
      name: 'install',
      command: 'bun install --frozen-lockfile',
      cache: { inputs: ['package.json', 'bun.lock'] },
    });

    await Promise.all([
      deps.runner({ name: 'lint', command: 'bun run lint' }),
      deps.runner({ name: 'test', command: 'bun run test' }),
      deps.runner({ name: 'typecheck', command: 'bun run typecheck' }),
      deps.runner({ name: 'build', command: 'bun run build' }),
    ]);

    await deps.runner({
      name: 'deploy',
      command: 'bun wrangler deploy',
      cloudflareCredentials: {
        accountId: this.env.CLOUDFLARE_DEPLOY_ACCOUNT_ID,
      },
    });

不過，Workflows 的能力不僅止於一連串線性步驟。它們可以動態定義，也能衍生出其他智慧體或 Workflow。這個範例展示了一個每日檢閱新資料的 Workflow。這個 Workflow 能完全掌控何時、以何種方式提示智慧體，並在各步驟間傳遞上下文：

import { WorkflowEntrypoint, type WorkflowEvent, type WorkflowStep } from 'cloudflare:workers';
import { init } from '@flue/runtime';
import { Reviewer } from './agents/reviewer.ts';
import { collectFindings } from './shared/nightly.ts';

type Params = { date: string };

export class NightlyReview extends WorkflowEntrypoint {
  async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
    const findings = await step.do('collect findings', () => collectFindings(event.payload.date));

    const agent = init(Reviewer, { id: `nightly-${event.payload.date}` });

    const receipt = await step.do('dispatch review', () =>
      agent.dispatch(`Review these findings:\n${findings}`),
    );

    const review = await step.do('read review', async () => {
      const reply = await agent.read(receipt);
      return { text: reply.text, data: reply.data };
    });

    // ...
  }
}

一旦您看到了這種模式，並且像 Cloudflare 一樣「被 Workflow 深深說服」，您就會開始問：我還可以讓 Workflow 為我處理什麼？還有哪些受制於人為瓶頸的步驟，我可以委派給這個 Workflow + Flue 智慧體的組合？

基於 Cloudflare 技術堆疊的完整 ADLC

有了能夠編排複雜步驟的 Workflows，以及作為程式碼儲存層的 Artifacts，當您審視 SDLC 的各個階段時，智慧體要全權掌管建構、交付與維運軟體所需的一切，Cloudflare 都已經備齊：

打造您的軟體工廠的基礎元件

現在，走在最前沿的人們正在打造未來的軟體工廠。最終，軟體工廠將變得像智慧體和 AI 一樣，成為人們建構軟體的常態方式。但對大多數人和大多數組織來說，我們還沒到那一步。

我們想要改變這一點。

為此，我們問自己的問題是：我們如何才能讓事情變得簡單且易於使用，讓網際網路上的每個人都能從這樣的典範轉移中受益？哪些底層基礎元件，是我們可以開放給所有人的——無論是最小的新創團隊，還是全球最大的平台？

在這種情況下，我們認為這些基礎元件已經就緒。雖然還需要更多工作來將它們串聯起來，繼續打造我們自己的軟體工廠並從中學習，但就在今天，我們已經準備好讓您在 Cloudflare 上打造那台「打造機器的機器」。從 @cloudflare/ci 開始，建構一個智慧體，看看您能讓 SDLC 中的多少環節變得自主運作。