为什么这很重要
当 LIA 调用一个语言模型时，她会把文字发给它：你的问题，有用的上下文，以及它可以使用的工具的描述。这些文字按数量计费，单位是令牌，文字越长，回答就来得越慢。LIA 覆盖几十个领域和大量工具。每次请求都把它们全部描述一遍会很贵，而且一个被选项淹没的规划器会选得更差。
反方向的过度也是一个陷阱：拿走模型需要的信息，就是逼它去猜。
我想要什么
我希望每个模型都收到它需要的东西，不少，也不多太多。并且，一条简单规则就能做到的事，不去调用模型。三个服务在 Pipeline 模式（也就是先规划再行动的模式）之前分担这项工作。
一开始就理解问题
第一个服务读取你的问题并提炼出要点：这是一次对话还是一个操作，涉及哪些领域，你的话指的是什么。「我哥哥那边天气怎么样？」涉及天气，也涉及你的联系人，因为需要你哥哥的地址。「我妻子」会变成你的记忆中知道的那个名字。「第一个」指的是 LIA 刚刚给你看的列表中的第一项。后续的所有处理都从这次分析出发，不会重新分析一遍。
只展示合适的工具
第二个服务准备规划器看到的目录：只包含所识别领域和所请求操作类型的工具，并以紧凑的方式描述。两道安全网防止这种筛选去掉关键的东西。首先，如果一个被保留的工具需要某个只有另一个工具才能产生的数据，就把那个工具也加进来：没有它，任何计划都不可能成立。其次，如果规划器仍然找不到可执行的计划，LIA 会用一个扩大的目录再试一次，仅此一次。这一切都发生在任何执行之前。
跳过已经知道的部分
第三个服务负责写计划，有时它可以不用模型。「给我看第一个的详情」：这一项已经确定，计划可以直接写出来。「找找这次会面所在的那家餐厅」：事件的地点会原样交给地点搜索。
它还依靠一些已经验证过的工具序列，比如「查找一个联系人，然后发送一封邮件」。一个经常被验证通过的序列会被推荐给规划器。当置信度非常高时，计划甚至可以免去模型的一次额外核查。这份记录由整个安装共享，只记录工具序列，不记录你写的任何内容。运营者可以载入一些参考序列，并且如果他决定的话，允许 LIA 记录那些通过核查的序列。默认情况下，这种记录是关闭的：LIA 使用已有的序列，但不学习新的。
局限
这种筛选有它的盲区。如果分析漏掉了一个领域，规划器就看不到它的工具，而扩大的目录只用一次。捷径只覆盖简单的情况。序列记录记住的是对所有人都有效的做法，而不是你个人的偏好。而且这些服务是为 Pipeline 模式准备的：在 ReAct 模式下，LIA 用另一种方式选择工具，要么根据针对你的问题计算出的相关性排序，要么让你所有的工具都随时可用，取决于你选择的交流节奏。