Agent API 各努力程度全面改进

Perplexity Agent API 中的努力程度让开发者可以为每项任务选择成本、速度和研究深度之间的平衡。如今，每个努力程度的单次查询成本都已降低，研究质量则有所提升或保持不变。全新的 ultra 级别现已推出，适用于覆盖面最广、最全面的研究。任何按名称选择级别的请求（例如 effort="fast", ）都会自动获得更新后的配置。

构建研究智能体意味着要为每项任务在成本、速度和深度之间找到合适的平衡。Agent API 中的努力程度可以替用户做出这一决定。每个级别都是一套打包配置，为特定任务类型定义了模型、步数预算、搜索设置和工具。Perplexity 会持续评估并更新每个级别，以在不超过当前成本的前提下提供最佳研究效果。

这些提升来自两类变化。预算、上下文处理和提取降低了每次运行的成本，而技能、模型选择和并行智能体则提升或保持了答案的质量。

medium 在 BrowseComp 和 DSQA 上的表现从 55% 提升至 77%，同时成本降低了近 90%。BrowseComp 和 DSQA 是公开的研究基准测试；WANDR 是 Perplexity 针对长篇、多实体研究任务的基准测试。xhigh 可执行智能体式工作，例如在沙盒中执行代码、维持较长的工具调用循环，以及同时处理大量来源。xhigh 的 WANDR 得分保持在 76.5%，而运行成本仅约为 2026 年 8 月配置的 25%。

一次深度研究请求在给出答案之前，可能会运行数十次搜索、阅读数百个页面并核查证据。其中每一个操作都会增加上下文中的 token 和账单上的费用。如果没有限制，智能体会不断采取行动，推高成本、挤占上下文，却无法改进答案。以下五个因素决定了大部分成本：

预算分配。设定了预算的智能体可能会耗尽步数，在完成任务之前提前结束运行。反之，没有固定预算的智能体可能会持续运行，产生成本却无法改进最终答案。
上下文开销。搜索结果和获取的页面承载着证据，但如果不加控制，上下文窗口很快就会被无关信息填满。上下文窗口的成本会逐步累积，而负担过重的窗口可能会降低智能体的表现。
工作流选择。不同的任务需要不同的方法。单一事实查询、多跳问题和广泛的来源调研，各自需要不同的工作流。如果任由模型自行选择，它往往会选出低效的工作流。在智能体的提示词中详细列出所有可用策略也无法解决这个问题。这些额外指令会在每一步中以 token 的形式被携带，而且随着时间推移，模型对每条指令的遵循也会越来越不可靠。
模型选择。换用更大的模型未必能带来与额外成本相称的性能提升。新模型发布时往往伴随着头条新闻和公布的基准测试得分。然而，基准测试上的提升可能受到数据污染，或反映出模型过拟合。如果不在真实任务上进行评估，更换模型可能会推高成本，却无法提升质量。
多智能体扩展。单个智能体在每次运行中能搜索、阅读和推理的来源数量有限。并行运行多个智能体可以提升最高难度任务的质量，但也会增加成本，而且如果处理不当，还会带来复杂性。

解决上述每一项挑战，都在不降低性能的情况下降低了各个努力程度的成本。

每个努力程度都有固定的研究预算，由三部分组成：

步数限制：智能体可执行的轮次数
工具调用：单个请求中工具调用总次数的上限。单个步骤可以同时跨多个工具发起多次调用，因此仅靠步数限制无法控制一个步骤内发生多少操作。
预算提醒：定期告知剩余步数，使智能体能够合理安排优先级，并为撰写答案留出余地，而不是在任务中途耗尽预算。

预算是核心权衡：步数越多，答案越好，但每一步都会产生成本。使用 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 更多，因为能力更强的模型往往会在单个步骤中发起多次调用。努力程度会同时限制工具调用次数和步数。对于这些模型，工具调用上限与步数限制同样重要。

每个努力程度都会调整这些限制，但智能体还必须知道自己还剩多少步数和操作可用于完成请求。如果缺少这一信息，它可能会耗尽步数或操作次数，被迫在研究完成之前作答。预算会在运行开始时说明，并在智能体接近限制时发出提醒，从而留出空间来核实并交付结果。对于 high，提醒同时涵盖步数预算和工具调用预算。

在一项 BrowseComp 任务中测试了两个智能体：一个带有预算提醒，另一个没有。该任务要求根据三份演员简介找出一部 20 世纪 90 年代的电视剧。带有提醒的智能体使用了 40 步预算中的 13 步，找到了正确答案。没有预算提醒的智能体用完了全部 40 步，仍未找到正确答案。该智能体的循环意外终止，而模型并不知道还剩多少研究预算。提醒能让智能体保持专注，并帮助它们有效地为剩余资源安排优先级。

长时间运行的研究任务会让模型的上下文窗口被搜索结果、获取的页面和中间笔记填满。一旦填满，智能体就必须停止工作。

压缩可让长时间运行的任务持续进行，而不会填满上下文窗口。当上下文超过阈值时，智能体会将迄今为止的工作替换为一份更简短的摘要，概述已发现的内容和尚待完成的工作，然后继续执行。

压缩始终会在上下文中保留三项内容：系统提示词、原始请求，以及智能体已加载的所有技能。每次压缩后，智能体会收到两条简短的指令。第一条指令是“继续工作，直到任务完成。”这可以防止智能体将摘要视为终点。第二条指令告知智能体已进行了多少次压缩，以便其规划剩余的研究任务。长时间运行的任务能够始终着眼于原始目标和计划，长循环的成本也随之降低，且质量不受影响。

智能体读取的每个页面都会增加其上下文，并且在之后的每一步中都要携带这些内容。网页中包含与问题无关的信息，例如导航、样板文字和其他内容。

fetch_url 不会将整个页面直接交给智能体，而是先执行一轮提取。页面文本会连同智能体当前的任务一起发送给一个较小的模型。该模型只返回相关段落，并逐字保留原文，以便智能体引用。在一次评估中，一个 5,561 token 的页面被精简至 293 个 token，从而为更多相关上下文腾出了空间。

使用 fetch_url 并开启提取，在 high 努力程度下，每次查询的输入 token 减少了约 50%。提取还提升了基准测试表现：启用提取时得分为 88.0%，每次查询成本为 $0.073；不使用提取时得分为 83.5%，成本为 $0.094。

网页搜索是每个智能体研究请求的核心。对智能体的搜索方式做出了三项改进：

每次搜索提供更多上下文：现在每次搜索最多返回 4K 个 token 的结果，而不再是 2K。智能体能更快找到所需内容，从而减少搜索次数并降低成本。

全新的摘要片段引擎：搜索结果会获得与查询更匹配的摘要片段，因此智能体不会被无关文本所累。
快速搜索：Fast Search 每 1K 次请求仅需 $1.00，可同时降低每次搜索调用的成本和延迟。

Perplexity Search 团队持续提升各类任务的检索质量。近期的更新在代码、开发者文档、参考页面、法律和监管内容方面均带来了提升。

有些任务需要并行运行大量搜索；另一些任务则需要仔细阅读少量长文档。

然而，将每个工作流都加载到智能体的系统提示词中会增加上下文开销，并可能导致模型在简单任务上表现不佳。因此，技能被组织成一棵采用渐进式披露的树。模型在工作过程中加载相关的技能和指令，将无关信息排除在上下文之外。在模型判定某项技能适合当前任务并加载它之前，每项技能只占用其名称和描述的开销；加载之后，完整指令才会被添加到上下文中，模型随即遵循既定的工作流。

为衡量各项技能的贡献，每次移除一项技能，在基线智能体曾加载该技能的任务上比较质量和成本。这些消融实验揭示了哪些工作流对智能体有帮助，以及它们如何影响研究效率。

以下 WANDR 基准测试运行展示了智能体为特定任务选择合适的工作流。每项任务都加载了广泛搜索和扇出指导，以满足调查多个实体的需求。人员搜索仅在 6% 的任务中被加载，且仅在问题涉及人员时才会加载。

在测试另一项 WANDR 任务时，智能体加载了采用扇出模式的人员搜索技能，以查找伦敦的推理工程师。它将 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,
            }

检查点是另一种能在长时间运行的任务中帮助智能体的工作流。检查点模式源自批处理编程。当脚本处理一份很长的列表时，它会在得到每个结果后立即将其写入磁盘，而不是将所有内容保存在内存中直到结束。如果脚本在中途崩溃或遇到错误，也不会丢失任何内容：下一次运行会读取已保存的内容，从中断处继续，并且只重试失败的项目。

在另一项 WANDR 任务中，智能体需要筛选 188 位工程师的个人资料。它加载了检查点模式，以便在工作时记录每个结果。第一轮提取了 160 份个人资料，但有 28 份失败。当智能体再次运行脚本时，它跳过了已记录的个人资料，只重试了剩余的 28 份。如果没有检查点，只要有一条记录出错，就意味着要重新获取全部 188 份资料。改编自 Python 代码摘录；省略了输入页面、筛选指令、schema 和导入语句；辅助函数名称仅作示意。

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}],
        )

检查点会记录成功的结果，但不会发起重试。将指令和 schema 纳入键中，可确保筛选条件发生变化时触发重新处理。

并非每项测试都带来了质量和效率上的提升。我们评估了在智能体开始任务之前预先加载所有技能的做法。在 BrowseComp 和 DSQA 上，预加载使成本增加了 13%。在 WANDR 上，由于更长的研究轨迹使检索内容在输入 token 中所占比例更大，预加载还会降低得分。这些结果支持继续采用渐进式披露。

随着模型能力不断进步，每个努力程度对应的最佳模型也在变化。Perplexity 采用自动化研究循环来监测新模型的发布和可用情况。一旦某个模型可供使用，便会立即触发评估。

新模型发布后，自动化智能体会让它通过评估 harness 进行测试。它会遍历不同的推理努力程度、步数和工具调用预算以及工具配置，并对照当前的各个努力程度，从质量和成本两方面为每次运行打分。如果某次运行出现退步，智能体会研究原因、调整设置，然后重新运行评估。只有当候选模型在成本相同或更低的情况下质量更优时，才会取代当前模型。

公开基准测试很有用，但其得分并不总能转化为实际任务中的表现。例如，下图显示，某个候选模型在 BrowseComp 上的得分比基线高出 13.3 分，但在内部企业、法律和金融研究任务上却远低于相应基线。

单个智能体在一个循环中能覆盖的来源有限。对于复杂任务，多个智能体会并行工作，各自协调处理问题的不同部分。

主智能体是编排器。它调用 spawn_agent 创建子智能体，并为每个子智能体分配一项具体且聚焦的任务。每个子智能体都在独立的上下文中运行自己的研究循环，使用各自的模型、工具和步数预算。子智能体将结果汇报给父智能体，父智能体可以向子智能体发送后续任务，或查看其进度。编排器与其子智能体之间通过交换消息来共享证据、标记阻碍因素并调整后续步骤。随着新信息的到来，编排器会不断细化任务分配，并在工作完成后将结果整合为一个答案。

Agent API 支持预定义的智能体角色，编排器还可以使用自定义指令创建子智能体。

ultra 努力程度会针对一项任务并行运行三个智能体。每个智能体都独立研究整个任务，从而获得不同的证据。第四个智能体会合并它们的发现、去除重复内容，并撰写最终答案。

在 WANDR 上，ultra 的得分为 85.9%，每项任务成本为 $21.71，是所有受测配置中得分最高的。

各个努力程度会持续接受评估和改进。用户选择的级别决定了一项任务获得多少研究投入，以及将花费多少成本。步数预算和工具调用预算，加上预算即将耗尽时的提醒，可将请求控制在预算范围内。压缩、提取和更好的摘要片段让上下文始终聚焦于证据。技能使工作流与任务相匹配，并行智能体则扩展了单个循环所能覆盖的范围。自动化评估循环只有在新模型以相同成本提升研究质量时才会采纳它。

随着新模型和新配置在评估中证明自身价值，每个努力程度都将持续演进。按名称调用某个级别会自动获得这些改进；固定版本则会保持配置不变。

试用 Agent API，并在您自己的工作负载上比较各个努力程度。如需了解努力程度的详细信息，请参阅我们的 Agent API 努力程度文档。

研究的成本

控制研究预算

管理上下文

压缩

只获取重要内容

聚焦式网页搜索

选择合适的工作流

模型选择

多智能体扩展

后续计划