无需路由失败的工具扩展方案：创建Playbooks

我花了两年时间为代理机构和品牌构建一个创意操作系统。现在它已拥有超过200个工具，并且每天为付费用户运行生产工作，跨越500多个API。使其可靠的不是路由器模型、更好的系统提示或减少工具数量。而是接受模型根本不应该自己组合通过工具的路线。观察一个智能体在规模化时失败，几乎从不是一个工具调用出错。而是顺序问题。模型选择一个看似合理的工具，得到看似合理的结果，选择下一个看似合理的工具，四步看似合理的步骤后，它自信地错了。选择的不确定性不断累积。工具本身没问题。路线是即兴的。所以我们停止要求路线，开始要求结果。每个可重复的任务都变成了一个书面Playbook：步骤、顺序、每一步使用的工具、完成的样子。现在大约有150个，每个都在相同的单行合同下运行：按照用户指令忠实有序地执行主体。Playbooks存放在一个库中，其组织方式是按照工作方式，而不是工具方式。三个顶级泳道：创意工作、情报工作、客户工作。所以智能体的第一个决策不是从200个工具中选择哪个，而是这个工作属于哪个泳道。然后选择该泳道中的Playbook。然后是参数。每个决策都很小，漏斗随着进程收窄。一旦Playbook开始运行，每一步都指定了工具，所以没有东西可以即兴发挥。泳道还做另一件事，它集中了上下文。此时智能体面前的一切都是关于产生一类结果，而不是整个平台。想想快餐菜单。没人点原料，你点套餐，厨房问你要什么饮料。两个诚实的限制。Playbook无法修复一个在静默无操作时却报告成功的工具，这类错误对我们来说变得更糟，而不是更好，因为路线总是看起来像是成功了。而发现是一个真正的第二份工作。模型可能查阅的书面索引被跳过了。索引必须在路径中，而不是旁边。我们设置系统，使智能体和我们的客户都可以驱动Playbooks。客户只需说出他们想要的（例如，运行Playbook 12，或运行Playbook：创建一个新的品牌套件）。在有人说只使用更少工具之前：更少工具意味着每一步更少的即兴发挥和更低的精确度。那是病根，而不是解药。工具数量从来不是问题。即兴发挥才是。作为背景，我在广告创意领域工作了40年，最近两年构建了这个运行的平台，所以请相应看待我的偏见。对于其他可能在多步工具调用中遇到路由或上下文失败的人的问题：你们使用了什么类型的解决方案来解决更大的MCP工具集和平台上的多步执行？