OpenClaw的爆火，让众多AI应用开发者第一次直面了高昂的Token账单——一个用户请求可能触发多轮工具调用，每次调用都携带超长上下文，实际的API成本远超预期，甚至可能达到订阅费用的数十倍。如何有效控制Token成本，正成为AI Agent开发者面临的核心挑战与增长瓶颈。

这显然不是可持续的商业模式。一个成熟的AI应用，如果连自身的Token成本结构都无法清晰掌控，就难以实现商业化成功。问题的关键或许不全在于Token定价本身，而在于大量Token被消耗在了低效环节：重复的搜索请求、冗余的上下文信息、错误粒度的数据提取，以及不匹配的模型选择策略。

小米MiMo大模型负责人罗福莉此前也曾指出：Agent时代不属于盲目消耗算力者，而属于精于优化算力者。每一位AI从业者，都应建立自己的“Token经济学”思维。

带着对AI Agent成本优化的深度思考，我们专访了杜知恒：小宿科技的CEO兼联合创始人，一位亲历了搜索引擎从PC到移动互联网完整变迁的行业老兵。小宿科技的核心业务是智能搜索，专注于为AI Agent提供高效、精准的搜索引擎服务。这并非面向普通用户的搜索，而是专为Kimi、DeepSeek、Manus等AI Agent产品调用的底层搜索基础设施。目前，国内超过半数的头部Agent企业都在使用其搜索API，月调用量已达数亿级别。

在智能搜索领域深耕多年，杜知恒对于“如何高效使用Token”、“如何优化搜索与推理的协同”积累了丰富的实战洞察。我们与他深入探讨了以下关键议题：如何通过智能搜索从源头节省Token？搜索与模型推理应如何高效配合？面对众多模型，开发者应如何制定最具性价比的选择策略？

一、智能搜索：从信息源头实现精准投喂

问：我们常提AI“联网搜索”，但AI Agent调用搜索引擎，与人类使用浏览器搜索，在本质上有何不同？

杜知恒：两者存在根本性差异。人类使用搜索引擎的本质是“信息浏览”——会被标题吸引，通过摘要判断是否点击，并逐条阅读。因此，传统搜索引擎长期优化的核心目标是提升相关性与点击效率，关键指标是CTR（点击率）。

然而，AI Agent调用搜索的根本目的并非浏览，而是获取执行特定任务所必需的“结构化原材料”。Agent可能基于搜索结果进行研究分析、撰写报告、制定计划，或将结果传递给下游工具进行进一步处理。在Agent的任务链路中，搜索结果不是一个供选择的“入口”，而是任务执行的“基础物料”。

这一本质区别导致了优化目标的彻底转变。你不再需要将最易点击的链接置顶，而是需要交付一组具备完整性、高可信度、可追溯、且易于模型高效解析的内容。举例来说：若让Agent规划一次新加坡亲子游，它不会像人类一样逐条点击比较，而是需要快速抓取签证政策、航班信息、酒店价格、儿童设施、天气状况、安全须知等全方位信息，并将其整合为可执行的行程方案。此时，搜索的作用是批量、快速、精准地提供任务执行所需的所有原材料。

问：当前AI生成内容泛滥，部分内容甚至存在“一本正经的胡说八道”，搜索引擎能否有效识别这类信息？

杜知恒：我们构建了多层次的质量控制体系。

第一层是基础的信源与内容质量筛选。这包括分析网页间的引用关系、判断是否来自权威媒体或官方机构、评估语言表达的逻辑性与结构性等，模型会对此进行综合评估。

第二层是信息密度与原创性判断。评估内容是否提供了真实的信息增量？是否有原始出处？还是仅仅是对已有内容的简单复述或聚合？时间戳在此至关重要——若一条内容的发布时间晚于其原始信源，则很可能仅为转述。

第三层是交叉验证。我们将待判断的内容与原始发布源——如最新官方文件、学术论文、权威数据库、可信媒体——进行比对。若一条信息链条完全由转述构成，其可信度将大打折扣。

此外，我们还会严格控制搜索结果间的互补性。对人类用户而言，10条结果中有7条内容重复尚可接受，点击一条即可。但对Agent而言，重复即意味着资源浪费。它需要的是不同视角、不同信源的信息覆盖，确保每条结果都能提供增量价值。

问：这里存在一个关键问题：传统搜索引擎依赖点击率进行迭代优化，但Agent并不点击，你们如何评估搜索结果的质量？

杜知恒：这正是Agent时代构建搜索系统面临的核心挑战之一。人类搜索行为会产生清晰的点击信号，CTR高低直接反映结果优劣，A/B测试直观有效。但对于Agent，无论搜索结果质量如何，客户通常都是直接获取10条或20条完整内容，我们无法获得任何点击行为数据。

因此，反馈来源转变为客户自身。当客户的Agent在特定场景下表现不佳时，其自身能够感知——终端用户会追问、给出负面反馈，或Agent反复处理同一已解答的问题。这些信号虽不像点击率那样非黑即白，但均可作为强化学习用于优化排序与召回策略的有效输入。

问：这是否意味着你们必须与客户建立深度绑定关系？客户是否愿意共享优化所需的反馈数据？

杜知恒：这本质上是一个信任构建与数据合作的问题，也是该赛道的核心壁垒所在。客户若要优化其Agent质量，就需要对调用的搜索API提出更具体的要求与改进建议。然而，反馈信号是最具价值的数据资产，只有建立在足够信任的基础上，客户才愿意开展共建。

信任的前提是基础能力达标。搜索服务至少需达到主流商业引擎的水平，客户才会认真考虑合作。在此基础上，客户会告知我们在某些垂直领域的前几条结果存在何种问题，或某类查询的返回结果总是不尽人意。这更像一种长期的、基于日常交互的市场关系：双方持续协作，当客户指出“周四的鱼不够新鲜”，我们就去优化对应的“供应链”。

高质量的深度合作客户必然是有限的，我们也会审慎选择合作伙伴。接收所有信号等同于没有信号，我们需要那些需求具备普适性、反馈能真正帮助提升基础能力的客户。这种基于共同目标的互依关系，对双方而言都具有长期价值。

二、搜索与推理解耦：能查询就别计算

问：当前许多开发者直接使用模型内置的搜索能力（如GPT的联网功能）。将搜索层独立出来，有何具体优势？

杜知恒：从抽象层面看，人类解决问题无非两种路径：一是依靠脑力进行推理计算，例如解数学题；二是进行查询，借助字典、搜索引擎等工具寻找现成答案。对Agent而言，逻辑完全相同：一是利用模型进行推理，二是通过互联网搜索获取原生信息。

在绝大多数情况下，查询比推理更可靠、也更经济。推理可能产生幻觉，搜索虽不能保证100%准确，但其错误率远低于凭空推理。更重要的是，推理过程消耗的Token数量通常远超一次搜索调用。因此，对于任何存在确定答案或可查询信息的问题，优先调用搜索的性价比远高于让模型自行推理。

目前，许多Agent尚未建立“搜索优先”的思维习惯，大量本可通过简单查询解决的问题走了复杂的推理链路，导致结果既不准确，成本也不经济。

问：在具体任务执行中，搜索应被嵌入在链路的哪个环节？

杜知恒：搜索并非单点触发，而是嵌入在任务链路的中间层。仍以旅行规划为例：Agent接收到任务后，首先通过推理将任务分解为若干子问题——目的地概况、签证要求、航班选项、酒店信息、儿童设施等。随后，针对每一类子问题，调用最合适的工具：部分调用通用搜索引擎，部分直接调用携程等垂直API，部分调用天气服务。最后，再通过推理将所有结果整合为可执行的方案。

因此，一次完整任务的最优结构是：推理拆解 → 多层搜索与工具调用 → 推理整合。首段推理负责问题分解，末段推理负责结果综合，中间的执行链路则尽量交由搜索和专用工具承担。这才是性价比最高的Agent架构设计。

问：搜索结果的输出形式应如何确定？何时返回长文本，何时返回短摘要？

杜知恒：这取决于客户具体场景的优先级。有些场景追求低延迟，例如聊天机器人实时回复，用户等待容忍度低，此时应返回精炼摘要，便于Agent快速整合答案。有些场景则追求高质量，例如学术研究、生成深度报告，此时需要提取网页甚至PDF的完整内容，为Agent提供干净、完整的长文本作为工作原材料。

这并非由我们单方面决定，而是基于客户的具体业务场景进行配置。本质上，这都是实时数据的获取与交付，只是形态不同。对于客户的Agent而言，搜索结果是一种输入，不同场景对输入格式与信息密度的要求截然不同。

三、Token节省之道：关键在于策略性选择

问：模型选择日益增多，开发者应如何决策？同一产品的不同功能场景，能否使用不同的模型？

杜知恒：这是当前许多开发者面临的现实困惑。一个常见的误区是，将问题简单理解为“究竟该选择哪一个最强的模型”。

然而，真实业务并非如此运转。一个Agent要完成任务，通常同时涉及数据获取、信息处理、上下文组织、模型推理和工程编排等多个环节。

这些环节相互关联，并非彼此独立。许多表面上的模型效果问题，其根源可能是数据质量不足、上下文过长或链路设计不合理；表面上的调用成本高企，深入分析后往往发现，也并非模型本身昂贵，而是不同复杂度的任务被塞进了同一种处理流程。

从我们的视角看，开发者不仅可以在，而且应当在同一产品的不同场景中，使用不同能力层级的模型。

因为同一个产品内部，本就存在多种性质的任务：有些是分类、信息抽取、翻译、文本改写等相对标准化的任务；有些则是复杂理解、长链路决策、多工具协同等更依赖深度推理的任务。它们对模型能力、稳定性、延迟和成本的要求本就不同。

若所有场景都采用同一套最高配置，效果未必最优，成本通常不合理；若一味追求低价，将所有任务压给低配模型，则容易在稳定性和结果质量上出现问题。

真正的关键，并非先问“哪个模型最强”，而是先厘清任务链路，明确每个环节究竟需要何种能力、何种质量要求、何种响应速度，以及何种成本结构。

当这些问题清晰后，模型选择便会水到渠成：不是围绕模型去设计产品，而是围绕具体场景去配置最合适的能力组合。

问：您曾提及模型内置搜索的成本是独立搜索API的5到10倍。罗福莉也指出许多系统频繁压缩搜索结果导致缓存失效。这个倍数具体如何产生？开发者将搜索从模型中解耦并单独采购，实际能节省多少成本？

杜知恒：这个5到10倍的差异，是多重成本叠加的结果。

第一层，搜索结果变成了持续的上下文负担。正常情况下，一次搜索调用在返回结果后即结束。但当搜索被绑定在模型内部时，这些内容会进入长上下文，在后续每一轮推理中被反复携带——成本从“一次性查询”变成了“多轮放大”。

第二层，对搜索结果的二次处理本身也在消耗Token。许多系统会对结果进行摘要、压缩、改写后再塞回模型，本意为节省成本，但若策略不当，这一步本身就在产生额外Token消耗，同时还可能丢失关键信息，导致既未省钱，效果反而下降。

第三层，缓存命中率大幅降低。搜索结果具有高度动态性，一旦进入上下文，每次输入都在变化，几乎导致缓存复用机制失效。

第四层，将本应在模型外完成的工作全部交给了模型。网页抓取、正文提取、去重、排序、结构化等操作，在模型外部可以高效完成。若全部交由模型处理，无异于用最昂贵的系统执行性价比最低的任务。

这几层因素叠加，便产生了可观的成本倍数。

我们的解决思路是尽可能将这些处理动作前置，在信息进入模型之前就完成“形态优化”。但这存在一个现实矛盾：过度压缩会丢失细节，直接喂入全文则成本高昂。

这也是我们开发“Chunks”（智能片段提取）功能的原因——从原始内容中提取与当前问题最相关的片段并重新组织，而非整篇塞入。例如，在进行投资研究时，若Agent需要分析一家公司，直接阅读20篇全文（每篇约1000字）的总输入约2万字；通过Chunks提取关键片段重组后，输入量可降至原内容的约70%，关键细节得以保留，Token成本降低约30%，同时信息覆盖率仍能维持在95%以上。

回到您的问题，解耦具体能省多少？很难给出统一数字，不同业务链路差异很大。但如果原架构是“模型内直接接搜索 + 大量结果反复进入长上下文”的模式，在完成解耦并增加前置结构化处理后，成本、延迟、稳定性通常都会有显著改善。

真正节省的，不仅是单次调用的费用，更是整条Agent链路中大量原本不必要的Token消耗。

问：如何成为善用算力的“聪明人”？如果一个AI团队希望降低Token成本，您建议他们优先优化搜索环节，还是优先优化模型选择？哪个环节的降本空间更大？

杜知恒：如果只能给一个建议，那就是：先别急于更换模型，首先审视并优化输入信息与任务链路。

原因很直接。从我们接触的大多数团队来看，最容易被忽视、但也最容易导致成本放大的环节，往往不是模型本身，而是搜索策略与上下文组织方式。

逻辑很简单：如果搜索结果本身冗长、重复、缺乏结构，或者同一份材料在链路中被反复拼接、摘要、送入模型，那么无论后续更换何种模型，本质上都是在为无效的Token付费。

因此，优化第一刀通常应落在前端的输入治理上：搜索结果是否过长？是否存在重复内容？是否将网页正文、摘要、历史上下文不加区分地一并塞入？哪些信息根本无需进入模型？哪些内容可以复用，哪些又在每次都被重新计算？

将这些问题理顺后，模型选择优化的价值才能稳定体现。因为此时你是在一个更干净、更克制的输入基础上进行能力分配，而非在一堆已然失控的上下文上进行局部修补。在后一种状态下更换模型，大概率只是换了一种更贵或更便宜的方式继续浪费资源。

因此，如果必须排序：短期内最容易见到显著降本效果的，往往是搜索与上下文治理；中长期最稳定、最体系化的优化，则需要将前端的信息治理与后端的推理能力分配协同进行。前者解决的是“不该喂给模型的东西太多”，后者解决的是“不该使用高配模型的地方太多”。

将这两件事结合起来，才是真正意义上的Token效率优化与AI Agent成本控制。