摘要： Parallel 在 4 月發布的 Task API 作法，是讓模型在隔離環境中寫 Python，把中間資料留行程式變數，據此宣稱 Ultra 8x 在 DeepSearchQA 拿到 82% 準確率。這項結果凸顯上下文與資料流程設計對研究型 Agent 的影響，但成績出自 Parallel 自身公布，也不應直接推廣到所有工作負載。
症結未必是模型本身，而是上下文早被塞爆
研究型 Agent 常碰上這種狀況：每搜尋一次、抓取一個頁面，原始內容就原封不動地進了對話歷史。任務愈往後跑，模型除了要回答問題，還得不停回頭消化先前累積的成堆資料。
Parallel 在 4 月發布的 DeepSearchQA 測試結果 裡，替這個難題換了個思路：不再讓模型單靠一輪又一輪的 tool calling 往前走，而是讓它動手寫 Python，在隔離環境中呼叫搜尋與擷取工具。中間產出的資料存放在程式變數裡，每次執行只有結果會送回模型的上下文。
差別看似細微，卻決定了 Agent 能應付的研究有多長、多複雜。
成績先看，但排行榜不是全部
按照 Parallel 的說法，Ultra 8x 在 Google 的 DeepSearchQA 評測拿到 82% 準確率，每千次請求成本為 2,400 美元。Ultra 基本版是 70%、每千次 300 美元；同一張表中的 GPT-5.4 加上 code execution 則落在 63%、每千次 701 美元。完整對照如下：
| 供應商 | 模型 | 成本（每千次請求） | 準確率 |
|---|---|---|---|
| Parallel | Ultra 8x | $2,400 | 82% |
| Parallel | Ultra 4x | $1,200 | 81% |
| Parallel | Ultra 2x | $600 | 77% |
| Parallel | Ultra | $300 | 70% |
| OpenAI | GPT-5.4 with code execution | $701 | 63% |
| Gemini 3.1 Pro with code execution | $707 | 62% |
這些成績出自 Parallel 自己的公布，用來掌握它的產品定位很合適，卻不宜直接當成對所有真實工作負載的承諾。各種任務的來源品質、答案格式與延遲條件，都可能讓結果走樣。話雖如此，這份測試仍點出一件事：想把研究品質拉高，未必只能換更大的模型，Agent 怎麼存放與處理中間資料同樣是關鍵。表格上還有一條耐人尋味的註記：Opus 4-6 搭配 PTC 的每千次成本飆到 36,231 美元，官方解釋是 Anthropic 的 prompt caching 節省沒有回饋到帳單的計費問題——比較表有時暴露的正是計費結構的落差。至於為什麼挑 DeepSearchQA 而不選 BrowseComp，Parallel 也寫明原因：若干模型已把 BrowseComp 資料集背熟，表面的成績可能因此灌水。
DeepSearchQA 收錄 900 道題，橫跨 17 個領域。這些題目不是查到一個網頁就能交卷，得先破譯第一段線索，再決定接著搜尋什麼，最後把完整答案交叉驗證。上下文管理最容易失守的，恰恰就是這類場景。
讓原始資料待在程式裡就好
常見的 Agent loop 這樣運轉：「模型挑選工具、工具吐回內容、模型再決定下一步」。搜尋結果與網頁全文每輪都把上下文撐得更大。任務拖得愈久，模型耗在整理舊內容上的空間與開銷就愈可觀。假設要查某家公司 2020 到 2024 年的營收變化，標準 agent loop 的上下文會像這樣一路漲大：
Step 1: search("company X revenue 2024") → [5 results in context]
Step 2: extract(url_1) → [full page content in context]
Step 3: extract(url_2) → [full page content in context]
Step 4: search("company X revenue 2023") → [5 more results in context]
...context grows with every stepParallel 的路數是讓模型產出程式碼，交由沙盒執行搜尋、擷取、篩選與彙整。以跨年度營收比較來說，程式可以先從報告網址歸納出固定格式，再用迴圈逐年抓出目標欄位。同一件事改寫成 Parallel 的風格會長這樣：
# First, use one search step to discover the URL pattern.
results_2024 = search("Company X 2024 annual report")
report_2024 = results_2024[0].url
# e.g. https://investors.companyx.com/financials/annual-reports/2024-annual-report.pdf
# Infer a reusable template from the 2024 URL and a parse function parse_fn.
url_template = "https://investors.companyx.com/financials/annual-reports/{year}-annual-report.pdf"
years = [2022, 2023, 2024]
reports = {}
for year in years:
url = url_template.format(year=year)
reports[year] = parse_fn(extract(
question=f"What was Company X's reported revenue in {year}? Return the value and supporting quote.",
urls=[url],
))
return reports搜尋、擷取與分析在同一個執行步驟內一氣呵成，整份報告不必塞回對話，模型拿到的只有整理過的數字與佐證。
官方把成效歸納為五項技術的疊加：程式化工具使用、積極的 prompt caching、預算感知執行、上下文壓縮，以及專為 agentic 工作負載打造的自家 Search 與 Extract API。架構上則拿四種常見路線來對照：純 agent loop 的上下文逐步膨脹；補上壓縮會犧牲關鍵細節；靜態計畫＋子代理難以中途調整；動態子代理則苦於跨代理的記憶碎片問題。Task API 的賣點，是在成本效率、細粒度控制與適應性三條軸線上同時過關。
Parallel 指出，一個原本會撐爆 128K context window 的 20 步研究任務，換用這套做法後能壓在 30K token 以內。更要緊的是程式變數可以跨步驟留存；就算對話歷史事後被壓縮，已經蒐集到的細節仍然停在直譯器的狀態裡。
Task API 已經有 Opendoor、Attio、Modal 等團隊用在 production 環境，一句簡單的 API 呼叫即可啟動深度研究：
import parallel
client = parallel.Client(api_key="your-api-key")
task = client.task_runs.create(
objective="Identify every researcher who co-authored papers "
"with Dr. Maria Chen at Stanford, MIT, and Caltech "
"between 2010 and 2020, then determine which of those "
"co-authors later joined the NIH Advisory Committee "
"to the Director.",
processor="ultra8x",
)
print(task.output)Processor 等級涵蓋 Lite（基本查詢，$5/1K）到 Ultra8x（最困難的深度研究，$2,400/1K），可按照任務難易與預算挑選。
沙盒是先決條件，不是加值選配
開放模型執行程式，風險也跟著來。Parallel 的解法是一座以 Rust 打造的 Python 沙盒，網路、檔案系統與作業系統一律不准直接碰觸。程式要接觸外部資料，只能透過平台注入的 search、extract 和少數狀態管理函式。
這道界線意義重大。模型照樣能寫篩選、聚合與條件判斷，副作用卻被關在平台明確開放的工具範圍內。把任意程式執行直接接上正式環境，換來的不見得是更能幹的 Agent，反而可能是更寬的安全破口。
預算同樣該是 Agent 的輸入
Parallel 更進一步把預算納進執行流程。系統記錄每輪模型與子模型的累積花費，逼近上限時提醒 Agent 收斂搜尋、把答案整理出來。簡單的問題也許兩輪就收工，複雜的問題則可以拿到較高的運算預算繼續深挖。
這比硬性規定「最多執行十步」更貼近研究本來的樣貌。固定步數既讓簡單問題白燒資源，也可能迫使真正棘手的問題提前喊停；改用成本畫線，品質、延遲與費用之間的取捨至少攤在明面上。
做 Agent 產品的人，該帶走的是什麼
這篇文章最值得借鏡之處不在 82% 這個成績，而是它把 Agent 的記憶切成兩層：對話留下高階推理軌跡，程式狀態收納原始資料。一旦分開，對話可以放心壓縮，細節也不會跟著被丟掉。
如果你的 Agent 已經在處理十幾步的搜尋、文件比對或資料整理，先別急著換模型。有三件事值得先查：原始工具輸出是不是全數灌進上下文、中間結果能否存成結構化狀態，以及執行環境有沒有清楚的權限界線。不少時候，真正壓住研究品質的，正是這三個工程問題。