Factory 發布 Droid 1.0，以程式化工具呼叫構建企業級 Agent harness
Factory 釋出 Droid 1.0，以程式化工具呼叫構建企業級 Agent harness
- Droid 1.0 是 Factory 推出的模型無關 Agent harness，主打程式化工具呼叫（PTC）。 - 透過 JavaScript 程式在沙箱中一次執行數百個工具呼叫，降低模型請求次數，提升效率。
原文給出 Droid 1.0 的基準對比與程式化工具呼叫設計，讀者可評估此 Agent harness 的成本與效能取捨。
Factory 研究 / 產品·2026-10-29 08:00· 2 天前精選AI 評分75
Droid 1.0: Building a Frontier Harness
AI 導讀
Factory 釋出 Droid 1.0，一個模型無關的 agent harness，主打程式化工具呼叫（PTC），模型通過編寫 JavaScript 程式在沙箱中一次執行數百個工具呼叫。
推薦理由
原文給出 Droid 1.0 的基準對比資料和程式化工具呼叫設計細節，讀者可以據此評估這個 Agent harness 的成本與質量取捨。
驅動 Factory 企業級智慧體的全新引擎，專為複雜專案和日常開發打造。
2026年10月29日作者：Factory Research閱讀時長 15 分鐘
分享
過去一年，我們與全球一些最大型企業中的數十萬名開發者合作。在與這些團隊並肩工作的過程中，我們構建並不斷打磨了一套前沿的智慧體執行框架（agent harness），直接滿足企業開發的需求：在複雜任務上給出高質量結果、高效利用資源，並具備強大的安全管控。
今天，我們推出 Droid 1.0：它比以往更準確、更高效、也更快，背後是全新的設計原則和一套程式化工具呼叫引擎。
Droid 是我們的智慧體執行框架。所謂執行框架，指的是模型之外的一切：提示詞、工具、工具結果的返回方式，以及驅動這一切運轉的迴圈。如今智慧體可以連續工作數小時甚至數天、跨越數百個回合，而每個回合都要重新發送指令、工具和歷史記錄。
此次 Droid 的更新是迄今規模最大的一次。在相同任務上，Droid 的表現優於各模型自帶的原生執行框架，效率最高提升 20%。它也為未來做好了準備：當前沿模型能夠把整個工作流規劃成程式碼時，Droid 可以讓它們在單次模型請求中執行數百次工具呼叫。
Factory 在設計上不繫結任何模型。我們相信，最好的智慧體執行框架應當為每一種模型而構建，這樣使用者既能選擇市面上最強的模型，也能讓 Droid 通過我們的自動模型路由 Factory Router，挑選最高效的模型組合。
為多種模型打造執行框架，本身就會讓框架變得更好。如果只針對單一模型調優，就很難分清哪些是真正的進步，哪些只是對該模型特性的遷就。跨模型工作能確保最有力的改進具有普適性，並且在啟發它的那個模型之外依然成立。
這正是我們內部 Agent Factory 的理念。智慧體會研究基準測試中的失敗案例，以及使用者在真實會話中遇到的阻礙，提出改動方案，並在每一個受影響的模型家族上逐一測試。我們的工程師稽核證據，再決定哪些改動上線。
最終成果是市面上最高效、面向企業、併為每一種前沿模型（無論開放權重還是閉源權重）調優過的程式設計智慧體。
本文餘下部分將介紹正面對比的結果、執行框架背後的設計原則、我們如何搭建內部 Agent Factory，以及帶來最大影響的核心改動。
市面上最高效的執行框架
在相同任務、相同模型下，Droid 的得分高於我們測試過的其他所有執行框架，成本卻更低。
圖 1 Terminal-Bench 4
GPT-6.1 Sol
通過率與每個通過任務的成本對比，GPT-6.1 Sol。Droid：57.6%，$0.79；OpenCode：51.0%，$0.77；Codex：54.0%，$0.90；Devin：45.0%，$1.27。
未列出 Cursor：它無法訪問 OpenAI 模型。
Opus 5.5
通過率與每個通過任務的成本對比，Opus 5.5。Droid：65.2%，$4.73；Cursor：62.1%，$4.78；OpenCode：62.1%，$6.20；Devin：59.6%，$6.21；Claude Code：57.6%，$5.71。
Terminal-Bench 4。使用 GPT-6.1 Sol 時，Droid 比 Codex 高 3.5 分，成本低 12%；比 OpenCode 和 Devin 高 6.6 至 12.6 分。使用 Claude Opus 5.5 時，Droid 比 Cursor、OpenCode、Devin 和 Claude Code 高 3.0 至 7.6 分，成本最多低 24%。方法說明
智慧體執行時間越長，這個差距就越重要。在數百個步驟中，更強的智慧體犯的錯誤更少，後續步驟可以在此基礎上繼續推進；而成本更低的智慧體則讓你能在同樣的預算下執行更多智慧體。Droid 會針對它支援的每個模型分別調整提示詞、工具描述和工具呼叫模式，因此每個受支援的模型都能獲得這些收益，包括你自帶 API 金鑰的情況。
這些結果背後最大的變化，是讓模型可以從程式中呼叫工具。
程式化工具呼叫
在標準的智慧體迴圈中，模型直接呼叫工具，每次工具輸出都會追加到上下文中。程式化工具呼叫（PTC）則針對長週期任務採取了不同的思路：智慧體編寫一個程式來呼叫這些工具。
藉助 PTC，智慧體可以先進行推理，為工具呼叫工作流編寫程式碼，然後在一次呼叫中端到端執行整個程式。例如，它可以編寫一個工作流來讀取數百個檔案並找出其中提到某個主題的少數幾個，對數十個 Linear 工單進行分診，或者按照確定性流程分步執行一次棘手的資料庫遷移。
CodeAct（Wang 等，2024）表明，在 17 個模型上，通過程式碼執行操作優於 JSON 和文本工具呼叫。Cloudflare 和 Anthropic 在 2025 年底將這一思路投入生產，Codex 今年又將其引入編碼智慧體。
我們在 Droid 1.0 中將 PTC 設為預設，原因有三。第一，它能讓智慧體的上下文視窗保持乾淨，因為它收到的只是其程式的輸出。普通的工具輸出（原始檔案、搜尋結果、日誌）作為變數留在程式內部。第二，它減少了模型請求次數，因為一個程式可以執行多次呼叫，從而讓複雜任務更快、更便宜。第三，它讓智慧體更可靠：檢查和迴圈在程式碼中確定性地執行，消除了模型可能偷懶、儘管原本計劃過卻漏掉某個情況的可能性。
指令碼模式
Droid 將 PTC 實現為一個 Script 工具。模型編寫 JavaScript，在沙箱中執行，自身沒有檔案、網路或系統訪問許可權。
一個 Script 可以在一次模型請求中發起數百次工具呼叫，因此指令和歷史只發送一次，而不是每隔幾次呼叫就重新發送。列印輸出有大小上限，完整結果會記錄在日誌中，模型之後可以搜尋。互不依賴的呼叫會併發執行，因此一批呼叫的耗時取決於其中最慢的那次呼叫。
圖 2 程式化工具呼叫
直接工具呼叫：10 次模型呼叫和 15 次工具呼叫，耗時 56.8 秒。Script 工具：5 次模型呼叫和同樣的 15 次工具呼叫，耗時 41.6 秒，快了 15.2 秒。
直接工具呼叫，逐次如下：
- 模型呼叫 1，8.52 秒，然後 TodoWrite todos，5 毫秒；Read invoice.ts，14 毫秒。
- 模型呼叫 2，3.27 秒，然後 Read invoice.test.ts，22 毫秒。
- 模型呼叫 3，4.04 秒，然後 Execute git status，218 毫秒。
- 模型呼叫 4，3.42 秒，然後 Read tax.ts，14 毫秒。
- 模型呼叫 5，3.55 秒，然後 Read money.ts，20 毫秒。
- 模型呼叫 6，3.57 秒，然後 TodoWrite todos，5 毫秒；ApplyPatch invoice.test.ts，1.05 秒。
- 模型呼叫 7，3.42 秒，然後 TodoWrite todos，6 毫秒；Execute vitest run，3.59 秒。
- 模型呼叫 8，4.73 秒，然後 Execute eslint，7.94 秒；Execute prettier --check，432 毫秒。
- 模型呼叫 9，5.49 秒，然後 Execute git diff --check，120 毫秒；Execute git status，271 毫秒。
- 模型呼叫 10，2.33 秒，然後 TodoWrite todos，7 毫秒，並給出最終答案。
Script 工具，逐次如下：
- 第 1 次模型呼叫，8.64 秒，隨後執行一個指令碼，421 毫秒，執行 TodoWrite todos，5 毫秒；讀取 invoice.test.ts，22 毫秒；讀取 invoice.ts，14 毫秒；執行 git status，218 毫秒；讀取 tax.ts，14 毫秒；讀取 money.ts，20 毫秒。
- 第 2 次模型呼叫，5.35 秒，隨後執行一個指令碼，1.25 秒，執行 TodoWrite todos，5 毫秒；ApplyPatch invoice.test.ts，1.05 秒。
- 第 3 次模型呼叫，3.36 秒，隨後執行一個指令碼，3.78 秒，執行 TodoWrite todos，6 毫秒；執行 vitest run，3.59 秒。
- 第 4 次模型呼叫，8.42 秒，隨後執行一個指令碼，8.14 秒，執行 Execute eslint，7.94 秒；執行 prettier --check，432 毫秒；執行 git diff --check，120 毫秒；執行 git status，271 毫秒。
- 第 5 次模型呼叫，2.27 秒，隨後執行 TodoWrite todos，7 毫秒，並給出最終答案。
直接工具呼叫
模型每進行一到兩次工具呼叫後就會被再次呼叫。
模型呼叫
1
工具呼叫
0
耗時
0.0 秒
指令碼工具
每次模型呼叫都會寫一個程式，由它執行各項工具呼叫並返回一個結果。
模型呼叫
1
工具呼叫
0
耗時
0.0 秒
模型呼叫工具呼叫指令碼節省時間
下面是一個常見的會話模式：用 GPT-6.1 Sol 在高推理檔位修復一個失敗的單元測試，並在同一時間軸上分別回放兩種方式。採用
直接工具呼叫時，模型每進行一到兩次工具呼叫後就會被再次呼叫，總共
10
次。採用
指令碼工具時，每次模型呼叫都會寫一個程式，由它執行各項工具呼叫並返回一個結果，因此同樣的
15
次工具呼叫只需
5
次模型呼叫。模型呼叫耗時從
42.3 秒
降到
28.0 秒
,任務完成時間從
56.8 秒
縮短到
41.6 秒
。工具耗時均為實測值。直接呼叫方式把同樣的呼叫按每次模型呼叫一到兩次來安排，工具結果與下一次模型呼叫之間間隔
0.15
秒。每次工具呼叫各佔一行，寬度與呼叫耗時成正比。懸停或點按條形可檢視精確耗時。
由於這些呼叫本身就是程式碼，一個結果可以影響下一次呼叫。例如，一個程式可以一次完成搜尋、讀取所有匹配項並篩選結果。若用直接呼叫，每一步都要消耗一次模型請求。
與直接工具呼叫相比，在 Claude Opus 5.5 上，指令碼模式將 Droid 的成本降低了 15%。大多數指令碼都很小，每個任務的節省主要集中在其中 12.5% 會發起六次及以上工具呼叫的指令碼上。
從我們自己的會話中選取了處於這一長尾的兩個指令碼（已簡化，名稱和識別符號有改動），用以說明效果。對每個指令碼，指令碼方式和直接呼叫方式執行相同的工具呼叫，區別在於所需的模型請求次數：直接呼叫每次請求只能容納少量呼叫，且步驟之間要等待模型；而指令碼方式在一個程式中全部執行。直接呼叫的數字為估算值，假設每次請求 3 到 10 次呼叫。
Linear 清理任務在佇列之間移動了 151 個 issue 並逐一驗證，共 312 次工具呼叫。若用直接呼叫，每次請求都要重新發送指令和不斷增長的歷史記錄，因此即便按每次請求 10 次呼叫計算，該任務也需要 36 次請求，讀取約 310 萬輸入 token。而指令碼方式只用了 2 次請求、約 61,000 token：一次請求用於編寫程式，一次用於讀取程式列印的結果。
CI 掃描則體現了節省的另一半：模型讀取的內容。指令碼檢查了 547 次執行中的 5,384 個桌面任務，共 550 次工具呼叫，每次併發 60 個，只用了 2 次請求，而估算需要 59 到 187 次。模型只看到一份包含五個數字的摘要，其中包括 41 個失敗任務。進入其上下文的工具結果不到 0.1%。該掃描在後臺運行了約 8 分鐘，期間模型繼續處理另一項任務。
圖 3 指令碼方式與直接呼叫對比
同樣是 312 次工具呼叫，兩種做法。直接呼叫按每次請求 10 次呼叫估算：需要 36 次模型請求，而且每個原始結果都會進入模型的上下文。而用一段 Script：只需 2 次模型請求，一次用來寫程式，一次用來讀取它打印出的 6 行內容；原始結果都留在程式裡。
第 1 次請求中寫出的 Scripttext() 會把內容列印給模型
1const remaining = new Set(readReport('<report>').notAttempted) // 151 個問題
2
3// 兩個佇列並行讀取
4const queues = await Promise.all([listAll('Triage'), listAll('<queue 2>')])
5const targets = queues.flat().filter((i) => remaining.has(i.id))
6
7const verified = [], failures = []
8for (const batch of chunks(targets, 3)) { // 每次處理 3 個問題
9 await Promise.allSettled(batch.map((i) => setStatus(i, 'Backlog')))
10 const after = await Promise.allSettled(batch.map((i) => getIssue(i)))
11 after.forEach((r, n) =>
12 (onlyStatusChanged(batch[n], r.value) ? verified : failures).push(batch[n].id))
13 if (failures.length) break // 遇到第一處意外變更就停止
14 if (verified.length % 30 === 0) text(`${verified.length} of 151 verified`)
15}
16
17writeResult('<result file>', { verified, failures })
18text({ verified: verified.length, failures })
這是 Factory 自己會話中一段真實的 Script，即 Linear 清理任務，經過簡化並改了名稱。兩邊都跑在同一個示意性的時鐘上。直接呼叫一側是按每次請求
10
次呼叫做的估算：每一批都要等模型讀完上一批的結果。如果按每次請求
3
次呼叫算，就需要
107
次請求。由於每次請求都要重新發送約 28,000 個 token 的指令，直接呼叫一側要讀取
約 310 萬
個輸入 token；而 Script 只讀取
61,000
. 結果大小按典型問題的規模估算。
它如何提升質量
- 更乾淨的上下文。原始檔案、搜尋結果和日誌都留在程式裡，模型推理時受到的噪聲干擾更少。
- 迴圈和工作流以確定性的方式執行。Linear 清理任務在每次寫入前後都比較 15 個欄位，保留精確計數，並且被設定為一旦某個問題出現其他任何變更就立即停止。
- 規劃在前。模型在推理過程中就把整個執行順序想清楚，它寫出的程式就是計劃。模型越強，規劃得越遠，寫出的 Script 也越複雜，單次請求能完成的事情越多。
前沿模型已經能把程式化工具呼叫發揮到極致，我們預計隨著前沿模型不斷進步，收益還會繼續擴大。
Script 模式預設對 GPT-6.1 Sol、GPT-6.1 Terra、GPT-6 Astra、GPT-6 Sol、GPT-5.6 Sol、Claude Fable 5.1、Claude Fable 5、Claude Opus 5.5、Claude Opus 5 和 Kimi K3 開啟。
設計取捨
程式化工具呼叫實現起來簡單，卻很容易做錯。以下是最關鍵的幾項取捨。
| 取捨 | 實現方式 | 為何重要 |
|---|---|---|
| 程式拿到的是真實資料 | 完整檔案，以及結構化、帶型別的搜尋結果。 | 過濾和計數都在程式碼裡完成，不消耗 token。 |
| 字面文本原樣傳遞 | 檔案內容、補丁和命令都放在原始輸入塊裡，不做跳脫字元串處理。 | token 更少，格式錯誤的呼叫也更少。 |
| 編輯結果返回簡短 | 在程式中執行編輯，返回的摘要和直接編輯一樣簡短。 | 檔案不會被重新貼上回上下文。 |
| 長任務不會卡住 | 程式最多等待 5 分鐘，然後交回目前為止的輸出。它也可以在後臺啟動並立即返回。 | 模型可以繼續工作。 |
| 無需輪詢 | 有專門的工具負責檢視、等待或停止正在執行的程式。後臺任務完成後，Droid 會喚醒模型。 | 不必再花請求去問任務是否完成。 |
智慧體工廠
指令碼模式，以及每個模型是否使用它的選擇，都出自同一個迴圈——Droid 的大多數改動正是由這個迴圈產生的。新模型和新快照每隔幾週就會出現，沒有哪個團隊能靠手工為每一個調優執行框架來跟上節奏。
圖 4 Droid 的構建方式
01
引入
新模型被加入 Droid 並接受檢查。
02
評估
每個模型都執行相同的任務。
03
讀軌跡
智慧體找出失敗執行之間的共同點。
04
提議
一份附帶明確假設的改動草案。
05
測試
在每個受影響的模型上做受控實驗。
工程師合併
每個模型執行的框架，以及執行這個迴圈的智慧體。
每個新模型都從第 1 步進入。Droid 自己執行每一步，在工程師審查併合並之前，任何改動都不會上線。改進後的 Droid 再執行下一輪迴圈。
迴圈從模型首次可用時開始，通常是一個搶先體驗的快照。一套追蹤 20 多個模型的自動化流程會把它加入 Droid，並用我們的行為斷言來檢查它。通過斷言只是最低要求，並不是釋出門檻。此後，每個可用模型都通過產品本身來評估：在真實環境中、通過 QA，以及每日基準測試。線上錯誤日誌和使用者遇到的摩擦會被補充到每個模型的結果中，這樣負責審查的智慧體就能同時看到基準測試失敗和真實會話。
單次失敗說明不了什麼，所以智慧體會尋找在不同任務和模型之間重複出現的原因。它把每個發現轉化為一份提議改動，寫明假設，再用受控實驗在每一個受影響的模型上衡量改動效果。
由於這些改動大多由智慧體編寫，提出改動的智慧體和審查它的工程師必須對“什麼是好的改動”有相同的理解。每一輪都會重新發送整個請求，所以一條位置不當的指令或一份過時的工具輸出不會只造成一次傷害，它會在之後的每一輪裡分散模型的注意力，損失質量、token 和時間。每份提議都必須遵循同樣的原則：
- 精打細算每一個 token，把大型工具結果儲存在檔案裡。
- 始終維護提示詞快取，讓請求逐步增長。
- 剖析通往推理的熱路徑，能快取的一律快取。
- 跟蹤後臺工作，比如長命令和子智慧體，並在完成時喚醒模型。
- 智慧體卡住時，總要準備好下一步：輕推、重試、總結或停止。
Droid 提出的改動取決於它要達成的目標。此外還有一項要求：每個目標都必須在所有模型家族上成立。我們在 GPT-6.1 Sol、Claude Opus 5.5、GLM 5.3 和 Kimi K3 上調整 Script 模式時，目標之一是：同時提供 Script 和直接工具時，模型應當選擇 Script。這個迴圈產出的改動涉及提示詞、Script 內部所呼叫工具的描述，以及 Script 結果的結構。沒有任何一項單獨改動能推動所有模型，但三項合在一起，在所有模型上都達成了目標。
另一個目標是讓 Script 模式的成本在每個模型家族上都低於直接呼叫。給每個讀取檔案的每一行編號，讓 Sol 不再通過 shell 重讀檔案來獲取行號，並在某個任務上把 Opus 的成本降低了 22%。但這也讓每次讀取每行多出約兩個 token，使 GLM 的成本上升 8%、Kimi 上升 32%——這兩個模型本來就沒有可節省的空間。最終這項功能作為可選項釋出，由模型在需要行號時主動請求。
工程師處在迴圈的末端。他們會結合證據閱讀每一份提案，對照這些原則進行核查，再決定哪些改動上線。最終得到的是一套能與模型提供方保持同步的 harness。
超越程式化工具呼叫
程式化工具呼叫是這個迴圈產出的最大改動，但並非唯一改動。其餘改動較小，分散在 harness 各處：每次請求中提供方可複用的部分有多少、每次請求包含什麼內容、一輪出錯後迴圈如何恢復，以及每次請求發出的速度。
保持提示詞快取有效
提供方按字首快取請求，因此任何改動都會使其後的內容全部失效。Droid 的請求原本就是隻追加的，只有一個例外：工具發現。工具定義位於請求靠前的位置，因此在會話中途載入 MCP 或聯結器工具，意味著要重新處理整段對話。現在 Droid 會把新發現的工具追加到請求末尾，保持已快取的字首不受影響。
圖 5 載入工具
同一請求的兩種方式示意
改動前 · 新工具插入工具列表
73,500 個 token 重新處理
28,000 個 token 從快取複用
改動前：28,000 個 token 從快取複用，73,500 個 token 重新處理。
Droid 1.0 · 新工具追加到末尾
1,500 個 token 重新處理
100,000 個 token 從快取複用
Droid 1.0：100,000 個 token 從快取複用，1,500 個 token 重新處理。
| 會話中的改動 | 下一次請求從快取讀取的情況 |
|---|---|
Git 狀態變化 測試中 · 19,976 個 token 複用，176 個新增 | 99.1% |
會話回滾 測試中 | 99.8% |
第二個同類型子智慧體 測試中 | 96.5% |
載入新工具 Azure 上的前後對比測試 · 全部 26,400 個 token 複用 | 100% |
從快取讀取重新處理新增 token
上圖：一個約
100,000
個 token 的請求示意，其中約
28,000
個 token 的指令和工具位於對話之前。提供方只會複用請求開頭直到第一個改動處為止的部分。把工具插入工具列表會改動請求靠前的位置，因此其後的整段對話都要重新處理。追加到末尾時，該工具就是唯一新增的部分。下圖：會話中的其他改動，以及下一次請求從快取讀取的比例，均為測試實測；工具載入是在 Azure 上進行的前後對比測試。
在生產環境中，典型請求有 98% 的輸入來自快取，98.6% 的請求嚴格只做追加。監控程式會拿每個請求與前一個請求比對，指出任何破壞快取的部分，從而維持這一狀態。這類破壞代價高昂：請求開頭只要有一個 token 發生變化，就得整體重新處理。這也正是 Agent Factory 最擅長的工作，它已經交付了多項提示詞快取修復。現在，git 狀態變化後，下一個請求只新增 176 個 token。回滾能複用 99.8% 的快取，同類型的第二個子智慧體複用 96.5%。出錯也不會重置快取，因為 Droid 會在已經持有該請求的提供商那裡重試失敗的請求。
基礎提示詞縮減 37%
首個請求攜帶指令、工具定義和啟動上下文，這些內容會隨之後每一輪一起傳送，因此是我們削減力度最大的部分。從 Droid 0.170.0 到 0.250.0，它從 20,887 個輸入 token 降到 13,055 個（減少 37%）。
節省主要來自工具。Droid 過去會預先發送 11 個工具定義，現在只發 2 個，不常用的工具在模型需要時按需載入。工具定義減少了 45%，Droid 在啟動時新增的提醒減少了三分之一。系統提示詞則相反，增長了 31%，儘管舊提示詞中的大部分規則都被縮短了。增長來自兩個領域的新指引：智慧體如何與使用者交流，以及如何處理影像、已連線應用和個人資料等環境細節。
圖 6 提示詞預算
實測
工具定義
15,798 → 8,528−46%
啟動提醒
3,463 → 2,362−32%
系統提示詞
1,618 → 2,155+33%
訊息“hi”
8 → 10+2
總計
20,887 → 13,055−37%
Opus 4.8 上的 0.170.0Opus 5.5 上的 0.250.0
會話首個請求（使用者輸入“hi”）的輸入 token 數：Droid
0.170.0
在
Claude Opus 4.8
上對比
0.250.0
在
Claude Opus 5.5
。這些部分在之後的每一輪對話中都會一併傳送。Droid 過去會預先發送 11 個工具定義，現在只發送 2 個；不常用的工具會在模型需要時再載入。這兩個版本執行在不同的模型上，因此分詞器不同；若按字元數計算（字元數不依賴分詞器），請求量從
57,035
降至
36,802
(
−35%
).
大量改寫工作由模型自己完成。有一套自動化流程會定期把 Droid 的指令交給模型，讓它找出其中重複、矛盾或表述不清的指導內容。每條發現都會變成一項修改建議，並像其他任何改動一樣接受測試。
有邊界的自主性
智慧體自主執行的時間越長，就越容易卡住、重複勞動，或者乾脆把任務丟掉。Droid 能檢測出這幾種情況，並且每種情況都有明確的下一步：輕推一下、重試，或者停止。這些規則寫在迴圈裡，而不是模型裡，因此對 Droid 支援的每一家提供商都成立，新模型從第 0 天起就能用上。
卡住通常會在流裡表現出來。在 Factory 託管的 Anthropic 流上，靜默 4 分鐘即視為流中斷，會進行重試。觸及硬性時間上限的響應最多嘗試兩次；中途中斷的響應會在重試前被移除，這樣模型只會在完整答案的基礎上繼續構建。
重複勞動靠計數來發現。連續三輪沒有可見輸出，Droid 就會停止。三次完全相同的工具呼叫會觸發一次輕推，六次則終止迴圈。如果重複呼叫返回了新結果，比如輪詢構建狀態，則可以繼續。
任務丟失最常發生在長對話被壓縮總結的時候。現在這些壓縮摘要的容量從 8,000 個 token 提升到了 16,000 個，因為我們估計有三分之一甚至更多的摘要都頂到了舊上限。
不過，並非所有漫長的等待都是故障。當模型開始一項耗時的工作，比如啟動子智慧體或執行長時間執行的命令時，它可以把這項工作移到後臺並進入休眠。工作完成後，Droid 會用提醒把它喚醒。
剖析熱路徑
請求已經做了快取和精簡，模型的響應時間基本不在我們掌控之中。但請求送達模型的速度，我們還能管。Droid 過去每一輪都會重建已連線應用的列表，而且隨著會話歷史變長，預檢工具查詢也越來越慢。
第一輪的開銷最大。登入檢查重複做同樣的工作，而且還是一個接一個地跑。啟動請求要等 Droid 的全部程式碼載入完，第一次模型請求則要等所有 MCP 伺服器就緒。自帶 Amazon Bedrock 憑據的使用者還要額外等待這些憑據載入。
在最新版本中，這些等待要麼消失了，要麼被挪出了關鍵路徑。Droid 會複用已連線應用的列表，直到連線發生變化才重建，把每輪準備時間縮短到 24 毫秒。在一項對照測試中，僅這一項改動就讓響應完成時間的中位數提前了 13%。Droid 現在只讀取會話歷史的最新部分，因此預檢工具查詢只需約 1 毫秒。登入檢查並行執行且不再重複，中位數從 101 毫秒降到 59 毫秒。droid exec 在程式碼仍在載入時就同時發出身份、功能開關、組織策略和聯結器請求，把首次模型請求的中位時間從 1,741 毫秒縮短到 646 毫秒。MCP 伺服器與第一輪同時啟動，因此一個需要 3 秒初始化的伺服器不再拖住第一輪，Bedrock 憑據也會在首次請求之前就緒。在使用者機器之外，我們在推理代理中修復了路由問題，讓每次模型呼叫都省下 150 毫秒。
這些改進在真實的生產智慧體輪次中一目瞭然。從按下 Enter 到發出請求，Droid 只用了 124 毫秒：97 毫秒用於收集上下文，27 毫秒用於構建請求。這意味著使用者等待首個 token 的時間裡，有 97% 花在模型請求本身。
從啟動就快
除了智慧體迴圈，Droid 1.0 還削減了使用者在應用本身遇到的延遲：開啟應用、啟動會話、同時執行多個會話以及退出。
3.8×
首次繪製更快 · 1,839 → 488 毫秒
3.0×
到首個提示詞更快 · 1,876 → 618 毫秒
30 毫秒
退出，生產環境中位數 · 原為 648 毫秒
開啟應用是每個會話的第一次等待。在 8 月 25 日到 10 月 20 日的版本之間，首次繪製的中位時間從 1,839 毫秒降到 488 毫秒，Droid 接受提示詞的時間從 1,876 毫秒降到 618 毫秒，各自縮短了約 70%。這主要來自在第一幀之前少做事情。Droid 現在釋出預編譯程式碼，因此啟動時不再解析約 6,000 個模組。啟動完成前按鍵就能被記錄，而且任何讓首次按鍵 p95 超過 250 毫秒的改動都會導致 CI 失敗。升級到 Bun 1.4.2 後，Linux、macOS 和 Windows 上的啟動時間 p95 降低了 13–22%；在 Windows 上，Droid 現在還跳過了控制台初始化，並快取了系統證書列表。
遠端計算機上的會話執行在守護程序裡，所以守護程序就緒之前會話無法啟動。過去，守護程序要先等登入 shell、證書、locale 和技能載入完。現在這些內容都改為按需即時載入。在一位開發者的 Mac 上，從啟動到就緒的中位時間從 1,956 毫秒降到 392 毫秒；使用空 shell 配置時則從 887 毫秒降到 376 毫秒。
最深層的變化在架構上。過去同時執行多個會話意味著要跑多個程序，每個程序約佔 350 MB 記憶體，因此五個並行子智慧體加上主會話要佔用 2 GB 以上。現在它們共享守護程序的程序，每個會話只增加約 20 MB，/new 也是瞬間完成。
退出是最後一項等待，過去它依賴網路。現在 Droid 把尚未完成的遙測和會話同步交給一個分離程序處理，然後立即退出。生產環境中的退出中位時間從 648 毫秒降到 30 毫秒。
比以往更快
省 token 的改動也能省時間：指令碼模式發出的請求更少，剩下的每個請求也更小，且大部分命中快取。在 Claude Opus 5.5 上，Droid 每完成一個通過任務所需的時間比 Claude Code 少 26%，token 用量少 17%。在 GPT-6.1 Sol 上，它的 token 用量比 Codex 少 12%，但耗時多 10%。
圖 7 Terminal-Bench 4
GPT-6.1 Sol
每任務分鐘數對比每通過任務成本，GPT-6.1 Sol。Droid：25.8 分鐘，$0.79；OpenCode：26.89 分鐘，$0.77；Codex：23.52 分鐘，$0.90；Devin：29.09 分鐘，$1.27。
未列出 Cursor：它無法訪問 OpenAI 模型。
Opus 5.5
每任務分鐘數對比每通過任務成本，Opus 5.5。Droid：42.6 分鐘，$4.73；Cursor：57.74 分鐘，$4.78；OpenCode：56.25 分鐘，$6.20；Devin：50.71 分鐘，$6.21；Claude Code：57.37 分鐘，$5.71。
Terminal-Bench 4。在 Opus 5.5 上，Droid 每完成一個通過任務所需的時間比其他所有 harness 少 16% 到 26%。在 GPT-6.1 Sol 上，它比 Codex 多花 10% 的時間，但成本低 12%，比 OpenCode 和 Devin 少花 4% 到 11% 的時間。方法說明
這些時間只涵蓋任務本身。在任務之外，Droid 開啟、啟動會話和退出的耗時都只有八月份的一小部分，因此新建會話或在多個會話間切換幾乎不花時間。
試用 Droid 1.0
Droid 1.0 今日釋出。可下載 macOS 和 Windows 桌面應用，或安裝終端 UI。
如果想在同一個 harness 之上構建，可以使用 Droid SDK（@factory/droid-sdk）。它執行的是與 CLI 相同的 Droid，因此本文中的每一項改動都隨它一同釋出。在 Node 中，應用可以啟動 Droid、維持多輪會話、流式獲取其工作過程，並通過 MCP 為它提供自定義工具。從另一個程序或本地瀏覽器工具中，應用可以連線到正在執行的 Droid 守護程序並在那裡管理會話。
方法說明
- Head-to-head.
- 使用的版本：
codex@0.163.0、claude-code@2.1.306、cursor-cli@2026.10.19-6bbf2c4、devin@3000.11.92、opencode@2.1.2。 - 使用的模型：Claude Opus 5.5（高推理）和 GPT-6.1 Sol（高推理）。
- 選擇高推理是因為它是我們平臺上最受歡迎的推理選項，最能代表委託給 Droid 的工作負載。
- 基準測試：Terminal-Bench 4，全部任務，預設時間限制，運行於 2026 年 10 月 23 日至 28 日。
- 每個 harness 對每個任務執行三次試驗。
- 因 harness 之外的原因失敗的試驗會重跑：評測未能啟動、模型請求超時，或提供商容量不足。
- Anthropic 的內容稽核在 Claude Opus 5.5 上攔截了部分任務。對每個遇到此情況的 harness，這些試驗都在 Claude Opus 5 上重跑，直到不再出現內容稽核錯誤。GPT 模型沒有此類攔截。
- Devin 無法關閉向用戶提問的工具，因此在某些任務上使用 GPT-6.1 Sol 時，它會停下來提問而不是完成任務。為保證對比公平，如果 Devin 停下來提問的任務在 Codex 上通過了，就計為通過（每次試驗平均 4.7 個任務）。這隻影響準確率，不影響成本或時間。
- Cursor 在任務中途重連時會少算 token，因此出現這種情況的兩次試驗中，我們根據對話記錄估算了缺失的用量。
- 成本和時間按每個通過的任務計算，採用各供應商的標價。圖表中成本從左到右由高到低排列。
- Droid 每次只與一個 harness 在同一模型上對比。
- 我們只統計兩個 harness 在三次試驗中全部通過的任務，確保兩者衡量的是同樣的工作。
- 成本按所用 token 以標價計算。
- 時間指智慧體實際工作的時間，不含環境搭建和評分。
- 使用的版本：
- Everything else.
- 這裡描述的每一項改動都已在生產版 Droid 中執行。
- 生產資料來自 Droid 自身的遙測，已排除 CI：提示詞複用、每週最新版本的啟動中位數、退出時間，以及首輪追蹤。
- 提示詞複用按請求統計：截至 10 月 22 日的 7 天內，生產環境 Droid CLI 的 2040 萬次請求中，從供應商快取讀取的輸入 token 佔比，已排除 CI 和評測。若按 token 而非按請求加權，該佔比為 91.5%。僅追加指提示詞快取監控未標記的請求佔比。
- 部分與啟動時間相關的指標來自受控測試，在同一批任務和同一臺機器上對比改動前後的構建。
- 建模數字對應 Script 示例中的直接呼叫一側：每次請求低端 10 次呼叫、高階 3 次呼叫，每次請求約有 28,000 個 token 的固定指令。
引用格式
Factory Research. "Droid 1.0: Building a Frontier Harness." Factory, October 2026. factory.ai/news/frontier-harness
來源：Factory 研究 / 產品 · factory.com