1. 什么是 tool gating，以及为何值得单独讲一课到目前为止，在简化示例中我们通常这样做：为 App 描述一组工具，接上 MCP 服务器——然后这些都始终对模型可见。若目标是“5 分钟做个 demo”，这没问题；但放到真实产品里——就不太行了。Tool gating 是一种模式，其中模型可用的工具列表不是固定的，而是依赖上下文：工作流步骤、用户权限、数据状态等。最重要的是：tools 列表不是“你曾经写过的一切的大杂烩”，而是场景设计的一部分。当你设计 workflow 时，其实也在设计模型在每个阶段有权看到哪些工具。一个最简单的类比：你不会让银行实习生一上来就接触所有系统——先只能查看，再是简单操作，最后才是更严肃的权限。这里也是同样的逻辑，只不过“实习生”换成了 LLM。2. “一次性开放所有工具”的问题：上下文污染与安全性如果给模型几十个工具，它会在多个方面同时受挫：上下文过载、选择混乱以及安全问题。OpenAI/Anthropic 的研究显示，你在上下文中描述的功能越多，模型越难选中正确的那个。首先，每个工具的定义都会占用 token：名称、描述、JSON Schema。30–40 个 tools 的列表很容易吃掉上千 token。这些 token 本可以用于对话历史、用户上下文、优质回答示例；结果模型却在“读你的 API 小说”。其次，当工具相似时，模型会混淆。如果你有 search_products 和 get_product_details，它可能会直接用文本查询去调用 get_product_details，因为它觉得那个描述更匹配。还有安全问题。一个朴素但重要的原则是最小权限（least privilege）：系统应当只拥有“此时此地”真正需要的能力。如果在“认识阶段”模型就已经知道 checkout，只要有一点用户的 prompt 注入，它就可能提前尝试发起支付。Tool gating 正是最小化权限的便捷做法：每一步只开放必要的工具。最后，还有 UX。若模型突然做了用户没预期的“魔法”（例如人还在挑礼物，它就创建了订单），用户对你的 App 的信任会迅速下滑。3. 以 GiftGenius 演示 tool gating拿我们的 GiftGenius 案例，实事求是地看下步骤：访谈：了解收礼人的年龄、性别、兴趣、预算等。挑选：按目录搜索商品，给出点子。Checkout：当用户已经选定礼物，进入下单流程。如果在访谈步骤模型就已经知道 search_products、add_to_cart 和 checkout，它可能会：还没收集到足够偏好信息就开始过早地调用搜索；因为用户说了“哦，这个不错，就它吧”，而立刻尝试“下单”。正确的做法是——随着步骤推进，改变可见的 tools 列表。下面我们就分析这样的场景：访谈阶段只看得到保存偏好的工具；挑选阶段开放搜索和加购；checkout 阶段才开放 checkout。把它汇总成一个小表：Workflow 步骤步骤目标模型可用的工具此步骤模型“看不到”的内容INTERVIEW收集收礼人画像save_preference, finish_interviewsearch_products, add_to_cart, checkoutBROWSING挑选并细化点子search_products, get_product_details, add_to_cartsave_preference+checkout(如果购物车为空)CHECKOUT完成下单search_products, get_product_details, add_to_cart, checkout