Agent API 每個強度等級全面改進

Perplexity Agent API 中的強度等級，讓開發人員能為每項任務選擇成本、速度與研究深度之間的平衡。如今，每個強度等級的每次查詢成本都更低，研究品質則更高或維持不變。全新的 ultra 等級現已推出，適用於範圍最廣、最全面的研究。任何以名稱選擇等級的請求，例如 effort="fast", 都會自動取得更新後的設定。

建立研究型 AI 代理程式，意味著要為每項任務在成本、速度和深度之間取得適當的平衡。Agent API 中的強度等級會替使用者做出這項決定。每個等級都是一套組合設定，針對特定任務類型定義模型、步驟預算、搜尋設定和工具。Perplexity 會持續評估並更新每個等級，以等於或低於目前的成本提供最佳的研究成果。

這些成效來自兩類變更。預算、上下文處理和擷取功能降低了每次執行的成本，而技能、模型選擇和平行 AI 代理程式則提升或維持了答案的品質。

medium 在 BrowseComp 和 DSQA 上的表現從 55% 提升至 77%，成本則降低近 90%。BrowseComp 和 DSQA 是公開的研究基準測試；WANDR 則是 Perplexity 針對長時間、多實體研究任務所建立的基準測試。xhigh 可執行代理式工作，例如在沙箱中執行程式碼、維持長時間的工具使用迴圈，以及同時處理大量來源。xhigh 的 WANDR 分數維持在 76.5%，執行成本僅約為 2026 年 8 月設定的 25%。

一個深入研究請求在作答之前，可能會執行數十次搜尋、閱讀數百個頁面並查核證據。每一個動作都會在上下文中增加 token，也會讓帳單金額增加。若沒有限制，AI 代理程式會持續採取各種動作，不斷推高成本並塞滿上下文，卻無法改善答案。大部分成本主要來自五個因素：

預算分配。設有預算的 AI 代理程式可能會用完步驟，在完成任務前就提早結束執行。相反地，沒有固定預算的代理程式可能會持續執行，不斷產生成本，卻無法改善最終答案。
上下文負擔。搜尋結果和抓取的頁面承載著證據，但若不加以控管，上下文視窗很快就會被無關資訊填滿。上下文視窗會在步驟之間不斷累積成本，而負擔過重的視窗也可能降低 AI 代理程式的表現。
工作流程選擇。不同的任務需要不同的方法。單一事實查詢、多跳問題，以及廣泛的來源調查，各自需要不同的工作流程。若讓模型自行選擇，它往往會挑中效率不佳的工作流程。在 AI 代理程式的提示詞中詳述每一種可用策略，也無法解決這個問題。這些額外的指示會在每個步驟中以 token 的形式持續帶入，而且隨著時間推移，模型遵循每條指示的可靠度也會下降。
模型選擇。改用更大的模型，未必能帶來與額外成本相稱的效能提升。新模型推出時，往往伴隨著頭條新聞與公布的基準測試分數。然而，基準測試的提升可能受到資料汙染，或反映出模型過度擬合。若未在真實任務上進行評估，更換模型可能會提高成本，卻無法提升品質。
多 AI 代理程式擴展。單一代理程式每次執行時能搜尋、閱讀和推理的來源數量有限。平行執行多個代理程式能提升最高難度任務的品質，但也會增加成本，若處理不當還會帶來額外的複雜性。

逐一解決這些挑戰後，每個強度等級都在不降低效能的情況下減少了成本。

每個強度等級都有固定的研究預算，包含三個部分：

步驟限制：AI 代理程式可執行的回合數
工具呼叫：單一請求中工具呼叫總數的上限。單一步驟可同時跨多個工具發出多次呼叫，因此僅靠步驟限制，無法控制單一步驟內會發生多少動作。
預算提醒：定期通知剩餘的步驟數，讓 AI 代理程式能安排優先順序，並保留撰寫答案的空間，而不會在任務進行到一半時用盡預算。

預算是核心的取捨：步驟越多，答案越好，但每個步驟都會產生成本。使用 openai/gpt-6-luna 時，將步驟限制從 1 提高到 15，可讓 BrowseComp + DSQA 的準確率從 41% 提升至 80%，而每次查詢的成本則從 0.0017 美元增加到 0.0152 美元，相當於以約 9 倍的成本換取約 2 倍的分數。

僅靠步驟限制無法控制研究成本。在相同的五步驟預算下，openai/gpt-6.1-terra 發出的工具呼叫比 openai/gpt-6-luna 更多，因為能力更強的模型往往會在單一步驟中發出多次呼叫。強度等級會同時限制工具呼叫和步驟數。對這些模型而言，工具呼叫上限與步驟限制同樣重要。

每個強度等級都會調整這些限制，但 AI 代理程式也必須知道自己還剩多少步驟和動作可用來完成請求。缺少這項資訊，它可能會用完步驟或動作，被迫在研究完成前就作答。預算會在執行開始時說明，並在代理程式接近上限時發出提醒，讓它保留空間來驗證並交付結果。在 high 等級中，提醒會同時涵蓋步驟預算和工具呼叫預算。

在一項 BrowseComp 任務中，我們測試了兩個 AI 代理程式，一個有預算提醒，另一個沒有；任務是根據三份演員簡介找出一部 1990 年代的電視影集。有提醒的代理程式只用了預算中 40 個步驟裡的 13 個，就找到正確答案。沒有預算提醒的代理程式用完了全部 40 個步驟，仍未找到正確答案。該代理程式的迴圈意外結束，模型也不知道還剩多少研究預算。提醒能讓代理程式保持專注，並有效安排剩餘資源的優先順序。

長時間執行的研究任務會讓模型的上下文視窗塞滿搜尋結果、抓取的頁面和中間筆記。一旦填滿，AI 代理程式就必須停止工作。

壓縮功能讓長時間執行的任務持續運作，而不會塞滿上下文視窗。當上下文超過閾值時，AI 代理程式會將目前為止的工作替換為較短的摘要，說明已找到的內容與尚待完成的部分，然後繼續執行。

壓縮時，上下文中一律會保留三項內容：系統提示詞、原始請求，以及 AI 代理程式已載入的所有技能。每次壓縮後，代理程式會收到兩則簡短指示。第一則指示是「持續工作，直到任務完成。」這能避免代理程式將摘要視為停止點。第二則指示會告知代理程式已進行過幾次壓縮，讓它能規劃剩餘的研究任務。長時間執行的任務能持續掌握原始目標與計畫，長迴圈的成本也會降低，且品質不受影響。

AI 代理程式閱讀的每個頁面都會增加其上下文，而代理程式在之後的每個步驟中都會持續帶著這些內容。網頁中包含與問題無關的資訊，例如導覽列、制式內容和其他內容。

fetch_url 不會將整個頁面直接交給 AI 代理程式，而是先執行一次擷取。頁面文字會連同代理程式目前的任務，一起傳送給較小的模型。該模型只會傳回相關段落，並保留原文，讓代理程式能加以引用。在一次評估中，一個 5,561 個 token 的頁面被縮減為 293 個 token，騰出空間容納更多相關上下文。

使用 fetch_url 搭配擷取功能並採用 high 強度等級，讓每次查詢的輸入 token 減少約 50%。擷取功能也提升了基準測試表現，以每次查詢 0.073 美元的成本達到 88.0%；相較之下，未使用擷取功能時為 83.5%，成本為每次查詢 0.094 美元。

網路搜尋是每個 AI 代理程式研究請求的核心。我們對代理程式的搜尋方式做了三項改變：

每次搜尋提供更多上下文：現在每次搜尋最多可傳回 4K token 的結果，而非 2K。AI 代理程式能更快找到所需內容，因此搜尋次數更少、成本也更低。

全新的摘錄片段引擎：搜尋結果會取得與查詢更相符的摘錄片段，讓 AI 代理程式不會被無關的文字淹沒。
Fast Search：Fast Search 每 1,000 次請求只需 1.00 美元，可降低每次搜尋呼叫的成本與延遲。

Perplexity Search 團隊持續在各式各樣的任務中改善檢索品質。近期的更新在程式碼、開發人員文件、參考頁面、法律及法規內容方面都帶來了提升。

有些任務需要平行執行大量搜尋；有些則需要仔細閱讀少數幾份長篇文件。

然而，將所有工作流程都載入 AI 代理程式的系統提示詞中，會增加上下文負擔，並可能使模型在簡單任務上表現不佳。因此，技能會以樹狀結構組織，並採用漸進式揭露。模型會在工作過程中載入相關的技能與指示，將無關資訊排除在上下文之外。在模型判斷某項技能符合任務並將其載入之前，每項技能只會占用其名稱和描述；載入後，完整指示才會加入上下文，模型也會依照規定的工作流程執行。

為了衡量個別技能的貢獻，我們會一次移除一項技能，並在基線 AI 代理程式曾載入該技能的任務上比較品質與成本。這些消融實驗顯示哪些工作流程對代理程式有幫助，以及它們如何影響研究效率。

以下的 WANDR 基準測試執行結果，展示了 AI 代理程式如何為特定任務選擇正確的工作流程。由於需要調查多個實體，每項任務都載入了廣泛搜尋與扇出指引。人物搜尋僅在 6% 的任務中載入，而且只在問題涉及人物時才會載入。

在測試另一項 WANDR 任務時，AI 代理程式載入了採用扇出（fanout）模式的人物搜尋技能，以找出位於倫敦的推論工程師。它將 39 個職務名稱擴展成 117 個查詢，然後將第一輪結果合併為 43 份不重複的個人檔案，以便進一步篩選。人物搜尋技能引導代理程式完成這項擴展，而不會加入無關的上下文。以下摘錄改編自代理程式的指令碼；輔助函式名稱僅供說明。

code1

text

Python

# roles contains the 39 role variants selected by the agent.
queries = []
for role in roles:
    queries.extend([
        {"query": f"Google DeepMind {role} London"},
        {"query": f"Google {role} London"},
        {"query": role, "company": "Google", "location": "London"},
    ])

results = pplx_sdk.search.people_many(
    queries, limit_per_query=50, concurrency=8
)

profiles = {}
for result in results:
    if not result.ok:
        continue
    for profile in result.result:
        if "linkedin.com/in/" not in profile.url:
            continue
        url = profile.url.split("?")[0].rstrip("/")
        previous = profiles.get(url, {})
        if url not in profiles or len(profile.summary or "") > len(
            previous.get("summary") or ""
        ):
            profiles[url] = {
                "url": url,
                "title": profile.title,
                "summary": profile.summary,
            }

檢查點是另一種能協助 AI 代理程式處理長時間任務的工作流程。檢查點模式源自批次程式設計。當指令碼處理一份很長的清單時，會在取得每個結果後立即將其寫入磁碟，而不是將所有內容保留在記憶體中直到最後。如果指令碼在中途當機或發生錯誤，也不會遺失任何資料：下一次執行時會讀取已儲存的內容，從中斷處繼續，並只重試失敗的項目。

在另一項 WANDR 任務中，AI 代理程式必須篩選 188 位工程師的個人檔案。它載入了檢查點模式，在工作過程中記錄每個結果。第一輪擷取了 160 份個人檔案，但有 28 份失敗。當代理程式再次執行指令碼時，它會略過已記錄的個人檔案，只重試剩下的 28 份。若沒有檢查點，只要一筆紀錄出錯，就得重新抓取全部 188 份。改編自 Python 摘錄；已省略輸入頁面、篩選指示、結構描述和匯入項目；輔助函式名稱僅供說明。

code 2

text

Python

checkpoint = Checkpoint("research/profile-screening")
config = instruction + json.dumps(schema)
config_id = hashlib.md5(config.encode()).hexdigest()[:6]

def checkpoint_key(page):
    url_id = hashlib.md5(page["url_in"].encode()).hexdigest()[:10]
    return config_id + url_id

pending = [
    page for page in pages if not checkpoint.has(checkpoint_key(page))
]
for offset in range(0, len(pending), 20):
    batch = pending[offset : offset + 20]
    inputs = [
        json.dumps({
            "url": page["url_in"], "content": page["content"][:30_000]
        })
        for page in batch
    ]
    results = pplx_sdk.llm.extract_many(
        inputs,
        instruction=instruction,
        output_schema=schema,
        chunk_size=5,
        concurrency=4,
    )
    for page, result in zip(batch, results):
        if not result.ok or result.result.error:
            continue
        checkpoint.record(
            checkpoint_key(page),
            [{"url": page["url_in"], **result.result.result}],
        )

檢查點會記錄成功的結果，但不會啟動重試。將指示和結構描述納入索引鍵，可確保篩選條件變更時會觸發重新處理。

並非每項測試都帶來品質與效率的提升。我們也評估了在 AI 代理程式開始任務前預先載入所有技能的做法。在 BrowseComp 和 DSQA 上，預先載入使成本增加了 13%。在 WANDR 上，由於研究軌跡較長，擷取到的內容在輸入 token 中所占比例更大，預先載入同樣會降低分數。這些結果支持繼續採用漸進式揭露。

隨著模型能力不斷進步，每個強度等級的最佳模型也會隨之改變。Perplexity 採用自動化研究迴圈，監控新模型的發布消息與可用性。只要模型一開放使用，就會立即觸發評估。

新模型發布時，自動化 AI 代理程式會將其放入評估 harness 中進行測試。它會遍歷各種推理強度、步驟與工具呼叫預算以及工具設定，並根據目前的強度等級，為每次執行的品質與成本評分。若某次執行出現退步，代理程式會研究原因、調整設定，然後重新執行評估。只有當候選模型能以相同或更低的成本在品質上勝出時，才會取代目前的模型。

公開基準測試很有用，但其分數不一定能反映真實世界任務的表現。例如，下方圖表顯示，某個候選模型在 BrowseComp 上的分數比基線高出 13.3 分，但在內部企業、法律和金融研究任務上，卻遠低於對應的基線。

單一 AI 代理程式在一個迴圈中能涵蓋的來源有限。面對複雜任務時，會由多個代理程式平行運作，各自協調處理問題的不同部分。

主要 AI 代理程式是協調者。它會呼叫 spawn_agent 建立子代理程式，並為每個子代理程式指派一項具體且聚焦的任務。每個子代理程式都會在獨立的上下文中執行自己的研究迴圈，並使用自己的模型、工具和步驟預算。子代理程式會將結果回報給父代理程式，父代理程式則可向子代理程式發送後續指派，或檢查其進度。協調者與子代理程式之間會互相傳遞訊息，以分享證據、標示阻礙並調整後續步驟。隨著新資訊陸續送達，協調者會調整指派內容，並在工作完成後將結果整合成單一答案。

Agent API 支援預先定義的 AI 代理程式角色，協調者也能使用自訂指示建立子代理程式。

ultra 強度等級會針對一項任務平行執行三個 AI 代理程式。每個代理程式都會獨立研究整個任務，因而取得不同的證據。第四個代理程式會合併它們的發現、去除重複內容，並撰寫最終答案。

在 WANDR 上，ultra 以每項任務 21.71 美元的成本取得 85.9% 的分數，是所有受測設定中的最高分。

強度等級會持續接受評估與改進。使用者選擇的等級，決定了任務能獲得多少研究量，以及需要花費多少成本。步驟與工具呼叫預算，加上預算即將用盡時的提醒，能讓請求維持在預算之內。壓縮、擷取和更好的摘錄片段，則讓上下文聚焦於證據。技能會讓工作流程與任務相符，而平行執行的 AI 代理程式則能擴展單一迴圈的涵蓋範圍。自動化評估迴圈只會在新模型能以相同成本提升研究品質時才予以採用。

隨著新模型與新設定在評估中證明其價值，每個強度等級都會持續演進。以名稱呼叫等級時，會自動套用這些改進；固定版本則會讓設定保持不變。

試用 Agent API，並在您自己的工作負載上比較各強度等級。您可以在我們的Agent API 強度等級說明文件中找到強度等級的詳細資訊。

研究的成本

控制研究預算

管理上下文

壓縮

只抓取重要的內容

精準的網路搜尋

選擇正確的工作流程

模型選擇

多 AI 代理程式擴展

未來展望