我发现我在反向设计我的AI工具。 这里有一个例子。这是我的新闻通讯处理链：阅读电子邮件，调用新闻通讯处理器，提取公司，然后将它们添加到CRM。这涉及四个不同的步骤，每处理一千份新闻通讯的成本为3.69美元。 之前：新闻通讯处理链（第一张图片） 然后我创建了一个统一的新闻通讯工具，它结合了所有内容，使用Google代理开发工具包，这是Google用于构建生产级AI代理工具的框架：（第二张图片） 为什么统一的新闻通讯工具更复杂？ 它在一个界面中包含多个操作（处理、搜索、提取、验证），实现了状态管理，跟踪使用模式并缓存结果，内置速率限制，并生成带有元数据的结构化JSON输出，而不是纯文本。 但这里有一个反直觉的部分：尽管内部更复杂，统一工具对LLM来说更简单，因为它提供了一致的、结构化的输出，更容易解析，尽管这些输出更长。 为了理解影响，我们对每个测试场景进行了30次迭代的测试。结果显示了新架构的影响：（第三张图片） 我们能够将令牌减少41%（p=0.01，统计显著），这线性转化为成本节省。成功率提高了8%（p=0.03），我们能够在30%的时间内命中缓存，这也是另一种成本节省。 虽然单个工具产生了更短、更“干净”的响应，但它们迫使LLM在解析不一致格式时更加努力。来自统一工具的结构化、全面的输出使得LLM处理更高效，尽管更长。 我的工作流程依赖于数十个专门的Ruby工具，用于电子邮件、研究和任务管理。每个工具都有自己的界面、错误处理和输出格式。通过将它们整合成元工具，最终性能更好，并且节省了大量成本。您可以在GitHub上找到完整的架构。