全面改進 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 代理程式可執行的輪次數目
工具呼叫：限制單一請求中工具呼叫的總次數。單一步驟可同時在多個工具上發出多次呼叫，因此單靠步驟限制，並不能控制一個步驟內發生多少操作。
預算提醒：定期通知剩餘的步驟數目，讓 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 等級，提醒同時涵蓋步驟預算和工具呼叫預算。

兩個 AI 代理程式（一個設有預算提醒，另一個沒有）在一項 BrowseComp 任務中接受測試，任務是根據三份演員簡介找出一部 1990 年代的電視劇。有提醒的 AI 代理程式用了預算 40 步中的 13 步，便找到正確答案。沒有預算提醒的 AI 代理程式用盡全部 40 步，仍未找到正確答案。該 AI 代理程式的循環意外終止，而模型並不知道尚餘多少研究預算。提醒能讓 AI 代理程式保持專注，並協助它們有效地為剩餘資源排列優先次序。

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

壓縮讓長時間運行的任務得以持續進行，而不會填滿上下文視窗。當上下文超過閾值時，AI 代理程式會把目前為止的工作替換為較短的摘要，概述已找到的內容和尚待完成的部分，然後繼續工作。

壓縮時，上下文中一定會保留三項內容：系統提示、原始請求，以及 AI 代理程式已載入的任何技能。每次壓縮後，代理程式都會收到兩項簡短指示。第一項指示是「繼續工作，直至任務完成。」這可防止代理程式把摘要視為停止點。第二項指示會告訴代理程式已進行了多少次壓縮，讓它可以規劃剩餘的研究任務。長時間運行的任務能時刻顧及原始目標和計劃，長循環的成本亦得以降低，而品質不會下降。

AI 代理程式閱讀的每個網頁都會加入其上下文，而代理程式在之後的每一步都要攜帶這些內容。網頁包含與問題無關的資訊，例如導覽、樣板文字及其他內容。

fetch_url 不會把整個網頁交給 AI 代理程式，而是會先執行一輪擷取。網頁文字會連同代理程式目前的任務，一併傳送至一個較小型的模型。該模型只會傳回相關段落，並逐字引用，讓代理程式可以引述。在一次評估中，一個 5,561 token 的網頁被縮減至 293 token，騰出空間容納更多相關上下文。

使用 fetch_url 進行擷取，並採用 high 投入程度等級，每次查詢的輸入 token 減少約 50%。擷取亦提升了基準測試表現：每次查詢成本為 $0.073 時達到 88.0%，而不使用擷取時，每次查詢成本為 $0.094，表現為 83.5%。

網絡搜尋是每個 AI 代理程式研究請求的核心。代理程式的搜尋方式有三項改變：

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

全新的摘錄引擎：搜尋結果會附上更切合查詢的摘錄，讓 AI 代理程式不會被無關文字所累。
快速搜尋：每 1K 次請求收費 $1.00，Fast Search 可同時降低每次搜尋呼叫的成本和延遲。

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

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

然而，把每個工作流程都載入 AI 代理程式的系統提示，會增加上下文開銷，並可能令模型在簡單任務上表現欠佳。因此，技能會以樹狀結構組織，並採用漸進式披露。模型會在工作期間載入相關的技能和指示，把無關資訊排除在上下文之外。在模型判斷某項技能適合任務並將其載入之前，每項技能只佔用其名稱和描述的成本；載入後，完整指示便會加入上下文，而模型亦會遵循指定的工作流程。

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

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

在測試另一項 WANDR 任務時，AI 代理程式載入了採用扇出模式的人物搜尋技能，以尋找倫敦的推論工程師。它把 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 的得分為 85.9%，每項任務成本為 $21.71，是所有受測配置中得分最高的。

投入程度等級會持續接受評估和改進。使用者選擇的等級決定了任務會獲得多少研究，以及需要多少成本。步驟和工具呼叫預算，加上預算將盡時發出的提醒，能讓請求不超出預算。壓縮、擷取和更佳的摘錄，讓上下文聚焦於證據。技能讓工作流程配合任務，而平行運作的 AI 代理程式則擴展了單一循環所能涵蓋的範圍。自動化評估循環只會在新模型以相同成本提升研究品質時，才會採用該模型。

隨著新模型和配置在評估中證明其價值，每個投入程度等級都會持續演進。按名稱呼叫等級會自動獲得這些改進；固定版本則會讓配置保持不變。

試用 Agent API，並在你自己的工作負載上比較各個投入程度等級。如需投入程度等級的詳細資料，請參閱我們的 Agent API 投入程度文件。

研究的成本

控制研究預算

管理上下文

壓縮

只抓取重要的內容

聚焦的網絡搜尋

選擇正確的工作流程

模型選擇

多 AI 代理程式擴展

未來展望