团队用面向 AI 代理的网页搜索 API 构建什么？

这四项任务有什么共同点？

每一项都需要页面上的文字，而不只是一串链接。160 字符的摘要很少能包含模型必须引用的数字、日期或条件。所以大多数技术栈最终都会用两个服务：一个搜索 API 用来找 URL，一个阅读器用来抓取这些 URL。

LLMWebSearch 把这两步合并了。一次调用即可运行实时网页搜索，并读取它找到的前几个页面。每条结果都包含位置、标题、URL、主机名、摘要，以及在被读取时该页面的正文内容（Markdown 或纯文本），并附词数，以及在已知时的发布日期。Agent 在同一次往返中就能拿到可引用的文本，而你只需付一张账单。

另一个共同需求是控制。你决定返回多少条结果（max_results）、读取多少个页面（read）以及每个页面可以有多长（max_chars）。这三个数字同时决定了你模型侧的 token 成本和我们的积分成本。

每种用例适合哪些设置？

从默认值开始，一次只改一项。

• Agent 工具。 保留 max_results=5 和 read=3，并把页面限制在 3,000 到 5,000 字符。Agent 会频繁调用该工具，所以简短的回答能让上下文保持干净。
• 深度研究。 多次小搜索胜过一次大搜索。每个查询用 read=3，并运行更多查询。只有当一次查询必须深入覆盖一个狭窄主题时，才提高 read。
• RAG。 请求更长的页面（max_chars 约为 12,000），并自行分块。当答案必须来自已知来源时，加上 include_domains。
• 新闻监控。 设置 topic=news 和 time_range=day，然后移除已经见过的 URL。每个查询读三篇文章来总结发生了什么变化。

所有筛选条件都列在搜索参考中。

如何估算第一个 pack 的用量？

把每天的任务数乘以每个任务的搜索次数，再乘以 30。一个每天回答 100 个问题、每个问题搜索 4 次的助手，每月大约需要 12,000 次搜索。这落在 25,000 次查询 范围内，还有余量够第二个月使用。

积分不会在计费周期结束时失效。查询积分永不过期：这个月没用完的，明年还在。为原型购买的小 pack 会一直保值，直到项目成长壮大。成本指南详细分析了三个更大的案例，并将它们与其他 API 以及模型内置的搜索工具进行了比较。