最近在 FastGPT 里做了一个类似 grill-me 的购物决策应用，起因很普通：我买东西比较容易纠结。

买一个鼠标、显示器或者电脑配件，往往要在几个型号之间反复比较。参数看了很多，最后反而不知道多花的钱到底值不值。

所以我希望做一个购物决策 Agent。它不需要替我做出100分的选择，只要能帮我把需求想清楚，减少明显遗漏，让购买决策稳定达到60分以上，就已经有用。

原来的应用已经能做一部分工作：追问预算、用途和真正看重的功能；我把几个候选商品的参数和价格贴进去后，它也能继续分析差异和性价比。

但到了真正准备下单的时候，它缺了一块很关键的能力：实时商品信息。

它会分析需求，但不知道市场上现在有什么

购物决策大致包含两类问题。

一类是“我到底需要什么”。

例如预算是多少，主要用来做什么，性能是不是过剩，哪些参数会真正影响体验。这些问题不依赖最新数据，适合让大模型不断追问和梳理。

另一类是“市场上现在有什么”。

新型号有没有发布，某个配置现在多少钱，不同渠道的价格是不是同一个口径，这些就不能只靠模型已有知识。

商品信息变化很快。价格、促销和售后政策会变，相近型号也容易被混在一起。模型可以帮助理解一类商品，但不适合作为实时商品数据库。

所以这次要解决的问题很具体：

不大改原来的 FastGPT 工作流，只给现有的购物决策应用补上一层联网搜索。

用 MIMO 搜索做最小改动

最后选的是小米 MIMO 模型提供的网页搜索能力。

也考虑过 Tavily 这类独立搜索服务。它的搜索过程可能更容易单独控制，但通常还要增加搜索请求、结果处理和模型总结等编排。

这和我当前“少改一点，先能用”的目标不太一致，所以暂时没有走这条路。

我的做法是在 FastGPT 的模型配置 Body 中加入下面的参数：

{
  "tools": [
    {
      "type": "web_search",
      "max_keyword": 3,
      "force_search": true,
      "limit": 3
    }
  ],
  "tool_choice": "auto"
}

按照目前的理解：

• type: web_search：启用网页搜索工具；
• max_keyword: 3：最多使用三个搜索关键词；
• limit: 3：限制返回的搜索结果数量；
• tool_choice: auto：由模型处理工具调用；
• force_search: true：强制执行搜索。

这里有一个容易混淆的地方。

不是 FastGPT 自己去搜索网页，而是 FastGPT 把这些参数传给 MIMO 接口，再由 MIMO 模型服务完成搜索。

所以更准确地说，这不是让 FastGPT 本身获得原生联网能力，而是在 FastGPT 中调用支持网页搜索的 MIMO 模型。

怎么确认配置已经生效

测试时，我问的是 Mac mini M4 24GB 内存、512GB 存储版本的价格。

这次没有专门做联网版和非联网版的完整对照，只验证配置有没有真正触发搜索。

实际看到的结果包括：

• 应用能够围绕这个具体配置查询价格信息；
• MIMO 后台出现了联网搜索调用次数；
• 账户发生了对应的联网调用扣费。

对我来说，这已经足够证明参数生效。

没有必要再用两份长回答去证明“联网后能获得更新的信息”。这本身并不是这次实践里最值得讨论的部分。

真正需要注意的是成本和搜索边界

联网搜索不是免费的。

当时后台显示的计费是1000次联网调用16元。这个价格以后可能变化，正式发布文章前仍然需要再确认一次。

对于个人低频使用，这个成本目前可以接受。一方面调用量不大，另一方面账户里还有小米提供的赠送金。

但当前配置里有一个比较明显的问题：

"force_search": true

按目前的理解，这意味着请求会强制执行搜索。

购物决策过程中，并不是每个问题都需要联网。例如预算、用途、能不能接受更重的鼠标、是否愿意为了售后多付20元，这些只是需求澄清，不需要查询实时信息。

真正需要联网的，通常是：

• 新型号和具体参数；
• 当前价格；
• 渠道和促销；
• 退换货政策；
• 近期质量问题。

如果每一轮对话都搜索，就会产生一些没有必要的调用。

后面可以尝试把 force_search 改为 false，看看模型能不能正确判断什么时候需要搜索。也可以把流程拆成两段：前面用普通模型梳理需求，到了商品核实和价格查询时，再调用联网模型。

不过这些都还没有测试，目前只能作为后续方向。

另一个边界是搜索准确性。

联网解决的是信息时效问题，不代表结果一定正确。模型仍然可能混淆相近型号，也可能把官方价格、补贴价格、第三方店铺价格和短期促销价放在一起。

因此，联网搜索更适合补充事实来源，而不是替代下单前的最后核对。

目前先这样用

目前我会继续保留这套配置。

原因很简单：个人使用频率不高，账户里又有赠送金，没有必要现在就为了节省少量搜索次数，增加新的判断节点和工作流。

原来的应用负责帮我想清楚“我需要什么”，MIMO 搜索负责补充“市场上现在有什么”。两部分合在一起，已经比单纯依赖模型记忆更接近实际购买场景。

force_search: true 和搜索准确性的问题都还在，但目前先能用，比一开始就把流程做复杂更符合这次改造的目标。