工具集设计关键因素?

来源标签：字节公司标签：字节 #字节 #Agent #Agent 工具集设计 #工具调用机制 #Function Calling

完整题目

在Agent系统设计中，工具集(toolset)的设计应该考虑哪些关键因素？如何实现有效的工具调用机制？

答案要点

工具设计的原子性与组合性平衡
工具描述的清晰性与LLM可理解性
工具调用的错误处理与重试机制
工具结果与上下文的融合策略
工具权限与安全隔离

工具集设计的关键因素

1. 工具粒度设计

原子性：每个工具只做一件事，如search_web vs get_weather
可组合性：支持工具链编排，复杂任务拆解为子工具调用
避免过细/过粗：过细增加调用次数，过粗降低灵活性

2. 工具描述优化

# 关键：让LLM准确理解何时调用
{
    "name": "calculate_mortgage",
    "description": "计算房贷月供，当用户询问贷款、月供、利率相关问题时使用",
    "parameters": {
        "principal": {"type": "number", "description": "贷款本金（万元）"},
        "years": {"type": "integer", "description": "贷款年限"},
        "rate": {"type": "number", "description": "年利率，如4.2表示4.2%"}
    }
}

3. 调用机制核心设计

环节	关键策略

学习内容与项目面试，在同一条路上。

站内 RAG 在线实战

换一种问法，检查是否真正理解

场景切入

假设你在做一个智能客服Agent，用户问“帮我查一下上周的订单”，然后又问“那这个订单现在到哪了”，你手头有查订单、查物流、查用户信息这些工具，你会怎么设计这些工具？需要考虑哪些点？

层层追问

Agent要调用外部工具时，你觉得设计一个工具集要考虑什么？……那怎么保证LLM能准确选对工具？……如果工具调用失败或者返回格式不对，系统该怎么处理？

直球架构

设计一个Agent系统的工具集，关键因素有哪些？比如工具粒度、描述、错误处理这些。另外，工具调用的机制怎么实现，包括意图识别、参数填充、结果回传这些环节，说说你的思路。

练习口述回答 · 约4分钟

工具集设计本质是平衡问题
工具粒度：原子与组合的取舍
描述清晰度：让LLM准确理解
调用机制：错误处理与安全隔离
上下文管理：压缩与轨迹保留

这道题其实问的是，怎么让大模型安全、高效地调用外部能力，核心是在灵活性和可控性之间找平衡。

先说工具粒度。我做的时候会遵循一个原则：每个工具只做一件事，但这件事要做得完整。比如搜索工具，我不会拆成search_web和parse_results两个，因为模型调用两次成本高，容易出错。但也不建议写一个do_everything的大工具，那样模型很难判断什么时候该用。真正落地时，我倾向于把常用操作封装成中等粒度的工具，比如search_flights、book_flight，复杂任务再通过[[ReAct]]或[[Chain-of-Thought]]组合调用。

再一个关键是工具描述。模型能不能正确调用，百分之八十靠描述。我一般会在description里写清楚触发场景和参数含义，比如“当用户问房贷月供时调用，本金单位是万元，利率是年化百分比”。如果参数有默认值或边界，我也会写进去，比如“贷款年限不超过30年”。这样能减少模型瞎填参数的情况。

调用机制上，我会分三块。先说意图识别，我一般用[[Function Calling]]机制，模型自己选工具，但我会在system prompt里给一些few-shot例子，比如“用户说查天气，优先调用get_weather”。接着说参数校验，模型填的参数不一定是合法的，我会做一层JSON Schema校验，缺失的让模型追问用户，不合法的报错让模型重试。再补充执行安全，敏感操作比如发邮件、扣款，我会放到沙箱里执行，或者加一道人工确认。

这里有个常见的坑：工具调用失败怎么办？比如天气API超时了。我会把错误信息原样返回给模型，让它自己决定是重试、换工具还是告诉用户稍后再试。但得设个超时熔断，防止一个工具卡死整个[[Agent]]。

结果回传也要注意。工具返回的数据可能很长，比如搜索返回100条结果，直接塞回上下文会浪费token，还可能冲淡模型对用户问题的注意力。我会做摘要或只取前几条，同时保留工具调用的轨迹，也就是thought-action-observation，这样模型能回顾自己做过什么，方便多轮规划。

还有一个有意思的点，当工具数量超过几十个时，模型选工具会变得困难，这时候需要引入[[RAG]]来检索工具描述，而不是让模型从所有工具里硬选。这块其实涉及工具库的索引和检索质量，值得深入聊。

所以整体上，我会把工具集设计看成是给模型搭脚手架，既要让模型够得着，又不能让它摔下来。上线前我会特别关注错误处理的覆盖率，比如所有工具调用失败后的兜底逻辑，以及安全隔离的完善度。

意图识别	用prompt明确工具选择逻辑，或训练专用router模型
参数填充	严格JSON Schema校验，缺失参数时主动追问
执行隔离	沙箱环境运行，敏感操作需人工确认
结果回传	结构化输出，支持错误码与部分结果

完整题目

答案要点

工具集设计的关键因素

对应课程

第 1 章:为什么需要 Deep Research

第 2 章：执行框架与状态取舍——ReAct、IterResearch 等怎么选

第 3 章:工具集设计,让 Agent 真正「会用工具」

第 4 章:多轮对话与长程记忆管理