设计AI代理工具的首选方法

AI回答与人类回答之间的差距往往不在于智能水平，而在于细节的准确性。基于真实数据的清晰、具体回答远优于流畅的猜测。更智能的模型固然有帮助，但精心设计的工具才能真正弥合这一差距。

本文概述了一种在代理工具设计中被证明有效的方法。它并非唯一途径，但已在多种代理中验证有效，因此成为笔者的首选。

工具为何至关重要

代理并非直接处理原始数据，而是通过你提供的数据接口来工作。工具名称、描述和参数每次都会影响模型的决策。以下是一些常见的失败模式：

• 模糊的工具导致决策不明确：如果两个工具能回答同一问题，代理必须猜测，而猜错的概率相当高。
• 描述不佳导致工具从未被使用：描述是代理决定何时调用工具的唯一指南。
• 粒度是一个权衡：接受原始SQL的工具将精确性负担转嫁给模型，并可能引发糟糕的查询。按对象类型设计一个工具虽好，但若超过50种类型，代理每次需在非常相似的选项中抉择。没有通用的粒度，它取决于你的具体领域。

例如，考虑get_opportunity和get_opportunity_health两个工具。对于理解数据模型的人类来说，区别可能清晰，但对于试图决定使用哪个工具的模型，它们似乎相同。这可能导致不可预测的调用，有时会遗漏用户要求的健康更新。通常的解决方法是合并这两个工具或重命名以增加清晰度。

更多工具不代表更好结果

当代理忽略某些事项时，本能反应是添加另一个工具。然而，这种本能有其局限。Anthropic的工具使用文档显示，Claude在工具数量超过30到50个时，选择准确率下降。超过这一阈值，每个新工具会与邻近工具竞争代理的注意力，而非扩展其能力。目标应是拥有能有效解决实际问题的最小工具集。

工具设计是代理大部分真实智能的所在，无论设计者是否有意为之。

从系统提示词开始

没有强大的系统提示词，就无法创建有效的工具。提示词定义了代理的身份、操作领域以及预期被问及的问题。工具服务于这一目的，而非反之。

如果跳过此步骤，会导致臃肿。模糊的提示词如“帮助用户处理他们的Salesforce数据”会使模式中的所有内容都显得相关。具体的提示词，例如“帮助收入团队识别有风险的管道并解释账户变化”，能迅速明确哪些重要——风险信号和变更历史，而非通用CRUD操作。精心定义的提示词几乎毫不费力地设定清晰的工具边界，但前提是它必须足够具体以确立这些边界。

如何判断工具是否应该存在

抛开技术细节——目标很直接：给定用户的问题，代理应该确切知道使用哪个工具。

一个有用的测试是：你能确定这个工具回答的问题没有其他工具能同样好地回答吗？如果不能，暂时不要添加——等待真实问题显示需求。“它在模式中”或“端点存在”这样的理由并不充分。出于这些原因添加的工具往往最终未被使用，或稍后与其他工具冲突。

利用代理设计工具

我们过程中一个令人惊讶的点是，我们使用代理来构建代理的工具。

一旦你有了扎实的系统提示词和一组好的示例问题，将两者连同你的数据结构（如JSON模式、数据库模式或API规范）提供给LLM，并要求它建议能够回答这些问题的工具。

这之所以有效，是因为进行设计的模型思考方式类似于最终将使用这些工具的代理。它模拟了决策过程，因此能更好地识别人类仅从模式设计时可能忽视的歧义或空白。

一个快速示例。

对于处理Salesforce的RevOps代理，其提示词关于管道健康和账户风险，问题如“本季度哪些交易有风险”、“Acme Corp最近有什么变化”以及“为什么这个机会的阶段发生了变更”，一个合理的初稿包括：

• get_pipeline_risk_signals(owner, quarter)——通过停滞时间、阶段回归或缺失下一步标记的交易
• get_account_activity(account_id, since_date)——字段变更、电子邮件和会议的时间线
• get_field_change_history(object_id, field_name)——特定字段的原始审计跟踪

值得注意的是，第三个问题凸显了字段级别历史的需求，这与账户级别活动不同。如果仅从模式设计，你可能错误假设get_account_activity也能处理这种情况——直到测试揭示它不能。

实施，然后真实测试

使用两种类型的问题：工具设计用于的问题（应立即可用）和代理未曾遇到的新问题（这是真正的测试，揭示工具是否能泛化，还是你只是构建了一个查找表）。

关注代理如何得出答案，而不仅仅是是否正确。存在三种潜在错误：使用了错误的工具；使用了正确的工具但参数错误；将多个工具链式组合，而一个精心设计的工具本应足够。每种错误指向不同的修复——描述、参数或粒度——因此避免将所有错误归为“代理搞错了”。

出错时，询问代理原因

不要仅仅修复工具就继续——询问代理什么能帮助它正确回答。它通常能准确指出问题所在：邻接工具的描述不清晰、参数需要示例、或两个工具应合并。代理对于其决策过程有直接洞察，而你在稍后阅读转录时无法获得。

持续迭代直至性能稳定

重复循环——实施，测试已知和新问题，借助代理诊断，优化——直到达到真实标准，而非仅仅是感觉。每轮跟踪一组新问题的“正确工具、正确参数、正确答案”率。当该比率保持稳定时，你就完成了——不是因为代理完美，而是因为你不再遇到工具设计问题，而是面对孤立的边缘情况，这是更小的问题。

这个过程不是一次性的设计。它更像产品迭代而非编写API规范：发布，观察实际行为，优化。关键区别在于，该过程中最有价值的设计伙伴是代理本身。