問題不一定出在模型，而是上下文被塞滿了
研究型 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 節省沒有回饋到帳單的計費問題——比較表有時也在暴露計費結構的差異。另外，Parallel 選擇 DeepSearchQA 而非 BrowseComp 的理由也載明：部分模型已開始背熱 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 已經開始處理十幾步的搜尋、文件比較或資料整理，先別急著換模型。可以先檢查三件事：原始工具輸出是否全部進了上下文、中間結果能否以結構化狀態保存，以及執行環境是否有清楚的權限邊界。很多時候，真正卡住研究品質的，是這三個工程問題。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。