MCP服务商不需要50个工具：在耗尽上下文前设计工具预算

在智能体配置中添加另一个模型上下文协议（MCP）工具感觉起来似乎完全没有成本。事实并非如此。每个工具都自带名称、描述、输入架构、执行示例以及一个隐含的决策：智能体何时应该使用这个特定工具而不是其他所有可用选项？

这些材料不断地与当前任务、代码库存储库、用户的直接请求以及智能体自身的规划逻辑争夺上下文中有限的空间。当开发人员公开整个工具目录并希望模型自行解决时，可预测的结果往往令人熟悉：

• 读取任务错误地调用了破坏性的写入工具。
• 智能体在开始实际工作之前，连续调用了三个近乎重复的工具。
• 在可以使用廉价查找的地方，却触发了昂贵的搜索工具。
• 在人类审阅者看到执行计划之前，高风险工具就已经可用。
• 工具列表发生了变化，但依赖它的底层工作流却从未被重新测试。

正确的解决方法绝不是一个庞大的全能工具。这种做法只会将模糊性从工具列表中转移到更大、更不易检查的参数架构中。在**n1n.ai**，我们处理着海量的企业级大模型流量，我们发现随着上下文污染的加剧，性能和可靠性会急剧下降。核心目标必须是：赋予智能体足够的完成下一步决策的能力，而不是它可能需要的每一种能力。

理解MCP工具环境

MCP工具不仅仅是运行在服务器上的孤立函数。它们的定义构成了智能体工作环境的活跃部分。更多的工具意味着更多的文本标记、更多的重叠动词以及显著更多的可能行动路径。

这并不意味着存在一个通用的安全工具数量。配置不当的两工具服务器仍然可能是危险的，而分隔良好的二十工具服务器则完全可以正常使用。工具预算的概念本质上是为了减少特定任务模式下不必要的选择。在使用通过诸如**n1n.ai**之类的高性能聚合器访问的可靠模型构建强大的智能体管道时，管理这个表面积至关重要。

对于考虑公开的每个工具，始终要提出两个基本问题：

1. 没有这个工具，哪种具体的决策会变得不可能？
2. 智能体能否安全地将此功能推迟到稍后的阶段？

如果对第一个问题的回答很模糊而对第二个问题的回答是肯定的，则不要在初始阶段加载该工具。

建立分阶段的工具预算

有用的分析单位不是你的MCP服务器总共公开了多少工具，而是智能体现在能看到哪些工具。考虑以下针对调查、提议然后更改部署配置的工作流的保守预算：

这是一个严格的预算，而不是刚性的协议要求。至关重要的部分是结构方向：写入操作来得晚、范围狭窄，并且带有清晰的验证路径。

与其给智能体一个可以进行任何操作的通用云账户，不如定义一个特定阶段的表面：

# 分阶段工具暴露配置示例
OBSERVE_TOOLS = [
    "get_service_status",
    "get_recent_deploys",
    "read_deploy_config",
    "search_runbook"
]

PREPARE_TOOLS = [
    "validate_deploy_plan",
    "preview_config_diff"
]

EXECUTE_TOOLS = [
    "apply_approved_deploy",
    "get_service_status"
]

注意这些列表中刻意缺少了什么：delete_service、任意shell执行、全账户秘密枚举以及五个略有不同的部署操作。这些功能可能属于一个独立的、明确的管理工作流，但它们无助于智能体回答眼前的那个问题：“这个部署有什么毛病？”

编写严格的工具契约

当名称重叠时，工具列表会变得不可靠。诸如search、find、query、lookup、get和fetch之类的术语对语言模型来说可能意味着几乎完全相同的事情。模型绝不应该从营销风格的描述中推断操作策略。

为每个可见的工具编写一个严格的一行契约：

• tool: find_failed_deployments
• use_when: "当您需要一个具名服务和时间范围内的失败部署时。"
• do_not_use_when: "当您需要日志、配置差异或部署动作时。"
• returns: "部署ID、时间戳、状态和失败摘要。"
• side_effects: 无

然后，测试对比。给智能体四个小提示：一个应该调用此工具的请求、一个应该调用不同工具的近距离失误请求、一个必须因缺少输入而停止的请求，以及一个必须请求批准而不是直接行动的请求。如果两个工具对于同一个提示都是合理的，请删除、重命名或路由其中一个。

在扩展基础设施并通过**n1n.ai**连接多个模型时，保持工具契约的清晰无歧义，可以确保即使是更小、更快的模型也能在没有困惑的情况下执行复杂的工作流。

工具记分卡

在将新工具添加到技能或智能体工作流之前，请填写此操作记分卡：

TOOL: __________________________
STAGE: observe / prepare / execute / verify

[ ] 它在此阶段解锁了一个具名决策。
[ ] 其名称和描述与所有可见的替代方案明显不同。
[ ] 其输入架构拒绝了缺失或危险的模糊性。
[ ] 其输出具有小型且有文档记录的形状。
[ ] 我们知道它是读取、写入、安全重试还是触及外部系统。
[ ] 存在一个否定测试，显示智能体绝不能调用它的时机。
[ ] 如果它执行写入，则确切的效果需要批准并具有回读检查。

工具预算自然会随着时间的推移而衰减。新的集成被添加、描述改变，或者旧的兼容性别名保留了下来。为了防止智能体工作流发生漂移，请在代码库旁维护一个小型的测试夹具套件，以在每个执行步骤验证预期和禁用的工具。

智能体之所以变得强大，绝不是因为它能看到系统公开的每一个动作。只有当每个步骤都有受约束的目的、清晰的边界以及无可否认的完成证明时，它才会变得真正可靠。在n1n.ai获取免费API密钥。