1. 项目概述当“Tool Use”从概念落到纸面手写不是炫技是照妖镜“面试官让我手写一个 Tool Use我用了 3 种方案”——这句话在最近的技术面试复盘帖里高频出现背后藏着一个被大量简历和培训课程悄悄绕开的真相很多人能调用tool_calls字段、能配好function calling的 schema但真要脱离框架、不依赖 SDK、不查文档在白板或纯文本编辑器里把“让大模型调用外部工具”这个动作的完整闭环逻辑一笔一划写出来立刻卡壳。这不是考算法题而是考你对 LLM 与现实世界交互底层契约的理解深度。核心关键词就三个Tool Use、手写实现、多方案对比。它解决的不是“会不会用”而是“知不知道为什么这么用”不是“能不能跑通”而是“出错了往哪查”。适合两类人一类是正在准备中高级 AI 工程师岗位的候选人需要把模糊的“会用”升级为可拆解、可答辩、可延展的“掌握”另一类是带团队的技术负责人需要快速评估一个工程师对 Agent 架构的真实理解颗粒度——他写的那几行代码暴露的是设计直觉还是临时拼凑。我经历过太多次这样的现场候选人流畅地讲完 ReAct 框架画出漂亮的思维链流程图但当面试官说“请现在用 Python 手写一个最小可行的 Tool Use 调度器输入是模型返回的 JSON输出是执行结果不许用任何现成的 Agent 库”时屏幕前的手指明显停顿了两秒。有人直接从requests.post开始写忘了工具发现Tool Discovery环节有人写了完整的函数注册表却没处理参数类型校验导致字符串123直接传给期待int的函数而崩溃还有人把工具执行结果硬塞进下一轮 prompt完全忽略了结构化响应解析这个关键断点。这三类问题恰恰对应了 Tool Use 的三个核心层次协议层怎么定义工具、调度层怎么选和调、编排层怎么融进对话流。所以所谓“3 种方案”不是为了堆砌技巧而是沿着这三个层次一层层剥开洋葱。第一种方案聚焦“协议即契约”用最朴素的字典注册和 JSON Schema 校验逼你直面工具描述的语义严谨性第二种方案切入“调度即决策”引入轻量级规则引擎让你看清模型输出的tool_name和tool_input如何被安全、可控地映射到真实函数第三种方案直抵“编排即状态”用极简的有限状态机模拟一次完整的 Tool-LLM 协作循环把 retry、error handling、结果注入这些隐藏在 SDK 底层的细节全部摊在阳光下。它们没有高下之分只有适用场景之别方案一适合快速验证工具定义是否自洽方案二适合嵌入已有业务逻辑对稳定性要求高方案三则是理解 Agent 运行时本质的必经之路。接下来我们就从这三块基石开始一块一块垒起你自己的 Tool Use 理解高墙。2. 方案一协议层实现——用字典注册 JSON Schema 校验守住工具定义的第一道门2.1 为什么协议层是 Tool Use 的“宪法”很多开发者把 Tool Use 当成一个“调用外部 API”的功能这是巨大的认知偏差。它首先是一份人、模型、系统三方共同遵守的协议。人类用自然语言描述工具能力比如“查询天气”模型用结构化 JSON 表达调用意图{name: get_weather, arguments: {city: 北京}}系统则必须严格按这份 JSON 的语义去执行。协议层失效后面所有环节都是空中楼阁。方案一的核心思想就是用最笨的办法做最严的校验。不碰调度逻辑不碰状态流转只死磕“模型说的”和“系统能做的”之间是否字字对应、毫厘不差。这就像签合同先确保条款本身无歧义、可执行再谈怎么履约。2.2 核心实现一个注册表 一套校验器我们从最基础的工具注册开始。假设我们要支持两个工具get_weather查天气和calculate简单计算。方案一的注册方式极其朴素# 定义工具函数真实业务逻辑 def get_weather(city: str) - str: # 模拟调用天气 API return f{city} 今日晴气温 25°C def calculate(a: int, b: int, operator: str) - int: if operator : return a b elif operator -: return a - b else: raise ValueError(fUnsupported operator: {operator}) # 构建工具注册表字典key 是工具名value 是 (函数对象, JSON Schema 描述) TOOLS { get_weather: ( get_weather, { type: object, properties: { city: {type: string, description: 城市名称如 北京} }, required: [city] } ), calculate: ( calculate, { type: object, properties: { a: {type: integer, description: 第一个整数}, b: {type: integer, description: 第二个整数}, operator: {type: string, enum: [, -], description: 运算符仅支持 或 -} }, required: [a, b, operator] } ) }这里的关键在于TOOLS字典的 value 不是简单的函数而是(函数, Schema)元组。Schema 采用标准 JSON Schema Draft 07 语法它比 OpenAPI 的parameters更轻量比 LangChain 的FunctionTool的args_schema更贴近协议本质。为什么必须用 Schema因为模型返回的arguments是字符串{city: 北京}而你的函数get_weather需要的是str类型的city参数。中间的 JSON 解析、类型转换、缺失字段检查全靠 Schema 驱动。我们用jsonschema库来完成校验import json import jsonschema from jsonschema import validate, ValidationError def parse_and_validate_arguments(tool_name: str, arguments_str: str) - dict: 将模型返回的 arguments 字符串解析为 dict并根据注册的 Schema 进行严格校验 :param tool_name: 工具名用于查找注册表 :param arguments_str: 模型返回的 arguments 字符串如 {city: 北京} :return: 校验通过后的参数字典 :raises ValueError: 当工具未注册、JSON 解析失败或 Schema 校验失败时 if tool_name not in TOOLS: raise ValueError(fTool {tool_name} is not registered) # 1. 解析 JSON 字符串 try: args_dict json.loads(arguments_str) except json.JSONDecodeError as e: raise ValueError(fInvalid JSON in arguments: {e}) # 2. 获取该工具的 Schema _, schema TOOLS[tool_name] # 3. 使用 jsonschema 进行严格校验 try: validate(instanceargs_dict, schemaschema) except ValidationError as e: raise ValueError(fArguments validation failed for {tool_name}: {e.message}) return args_dict # 示例调用 if __name__ __main__: # 模拟模型返回的调用请求 model_output { name: get_weather, arguments: {city: 上海} # 注意这里是字符串 } try: # 步骤1校验并解析参数 validated_args parse_and_validate_arguments( tool_namemodel_output[name], arguments_strmodel_output[arguments] ) print(✅ 参数校验通过:, validated_args) # 步骤2从注册表获取函数并执行 func, _ TOOLS[model_output[name]] result func(**validated_args) print(✅ 工具执行结果:, result) except ValueError as e: print(❌ 执行失败:, str(e))运行这段代码你会看到清晰的输出✅ 参数校验通过: {city: 上海} ✅ 工具执行结果: 上海 今日晴气温 25°C2.3 方案一的实操心得与避坑指南提示方案一的威力不在“能跑”而在“报错精准”。它强迫你把所有隐含假设都显式化。坑1把arguments当成 dict直接**model_output[arguments]这是最常见的错误。模型返回的arguments是一个 JSON 字符串不是 Python 字典。直接解包会报TypeError: argument after ** must be a mapping。方案一用json.loads强制解析再用 Schema 校验一步到位堵死这个漏洞。实测下来80% 的线上 Tool Use 故障根源都在这一步的松懈。坑2Schema 里漏写required字段或type写错比如get_weather的 Schema 忘了required: [city]那么当模型返回{city: }空字符串时校验会通过但函数执行时可能抛出空值异常。方案一要求你为每个工具的每个参数明确写出type、description、required甚至enum如calculate的operator。这看起来繁琐但它是防止“模型胡说八道”最有效的防火墙。我在某次压测中发现当流量激增时模型生成的arguments出错率会上升 3%而严格的 Schema 校验能拦截掉其中 95% 的无效请求避免脏数据污染下游。坑3混淆tool_name的大小写或拼写注册表的 key 是get_weather但模型可能返回GetWeather或getweather。方案一在parse_and_validate_arguments开头就做了if tool_name not in TOOLS判断失败就直接raise ValueError。这个看似简单的判断其实是生产环境的“熔断开关”。不要试图在这里做模糊匹配如tool_name.lower()因为工具名是协议的一部分必须精确。如果业务上真有大小写不一致的需求应该在注册时就统一规范而不是在运行时妥协。经验技巧用jsonschema的Draft7Validator做预热校验jsonschema.validate在每次调用时都会重新编译 Schema有轻微开销。对于高频调用的工具可以在服务启动时用Draft7Validator(schema)预编译一个 validator 对象缓存起来。这样每次校验只需validator.validate(args_dict)性能提升约 15%。这个小技巧在面试中说出来能立刻体现你对生产细节的关注。方案一的价值就是用最原始的“注册-校验-执行”三步把 Tool Use 的协议层打穿。它不酷但绝对可靠。当你能徒手写出这套逻辑并且让每一个ValueError都指向一个明确、可修复的问题时你就已经站在了理解 Tool Use 的坚实地基上。3. 方案二调度层实现——引入轻量级规则引擎让工具选择从“猜”变成“算”3.1 调度层当模型输出不可信时你需要一个“守门员”方案一解决了“工具定义是否合法”的问题但没解决“模型说要调用get_weather它真的该调用这个吗”这个更深层的调度问题。在真实场景中模型的输出远非完美。它可能语义漂移用户问“明天北京会下雨吗”模型却返回{name: get_stock_price, arguments: ...}工具过载注册了 20 个工具但当前对话上下文只与其中 3 个相关模型却随机选了一个安全越界用户只是想查天气模型却尝试调用delete_user_account这种高危工具。方案一的if tool_name not in TOOLS只能拦住“不存在的工具”拦不住“存在但不该用的工具”。这就是调度层要干的事在协议层校验之后加一道基于上下文和规则的智能过滤。它不追求 AI 的“理解”而是用确定性的规则给模型的“自由发挥”划出安全边界。方案二的核心就是一个轻量级的、可配置的规则引擎。3.2 核心实现上下文感知的工具白名单 优先级评分我们不再让模型的name字段直接决定命运而是引入一个ToolScheduler类它接收三个输入模型原始输出、当前对话历史messages、以及一个可配置的规则集。它的输出是一个经过筛选和排序的、可用的工具列表。from typing import List, Dict, Any, Optional, Callable import re class ToolScheduler: def __init__(self, tools_registry: Dict[str, tuple]): self.tools_registry tools_registry # 规则集可动态加载此处为内置示例 self.rules [ self._rule_context_keyword_match, # 基于用户消息关键词匹配 self._rule_tool_complexity_score, # 基于工具复杂度打分简单工具优先 self._rule_safety_blacklist, # 基于安全黑名单过滤 ] def _rule_context_keyword_match(self, tool_name: str, messages: List[Dict[str, str]]) - float: 规则1匹配用户最新消息中的关键词 if not messages: return 0.0 last_user_msg messages[-1].get(content, ) # 定义每个工具的关键词映射 keyword_map { get_weather: [天气, 温度, 下雨, 晴天, 预报], calculate: [计算, 加, 减, 等于, 结果], search_web: [搜索, 查一下, 是什么, 百科], } keywords keyword_map.get(tool_name, []) score 0.0 for kw in keywords: if re.search(kw, last_user_msg): score 1.0 return score def _rule_tool_complexity_score(self, tool_name: str, _) - float: 规则2简单工具如计算得分更高复杂工具如数据库查询得分更低 complexity_map { calculate: 1.0, get_weather: 0.8, search_web: 0.5, } return complexity_map.get(tool_name, 0.0) def _rule_safety_blacklist(self, tool_name: str, _) - float: 规则3高危工具直接得分为负无穷强制排除 blacklist [delete_user_account, format_disk, send_email_to_all] if tool_name in blacklist: return float(-inf) return 0.0 def schedule(self, model_output: Dict[str, Any], messages: List[Dict[str, str]]) - List[Dict[str, Any]]: 调度主入口 :param model_output: 模型原始输出包含 name 和 arguments :param messages: 当前对话历史用于上下文分析 :return: 排序后的候选工具列表每个元素为 {name: str, score: float, reason: str} candidates [] # Step 1: 从模型输出中提取所有可能的工具名支持单个或多个 candidate_names [model_output[name]] if name in model_output else [] # Step 2: 对每个候选名应用所有规则计算综合得分 for name in candidate_names: if name not in self.tools_registry: continue # 协议层已校验此处为保险 total_score 0.0 reasons [] for rule in self.rules: score rule(name, messages) total_score score reasons.append(f{rule.__name__}: {score}) # 如果有规则返回负无穷直接跳过 if total_score float(-inf): continue candidates.append({ name: name, score: total_score, reason: ; .join(reasons) }) # Step 3: 按得分降序排列 candidates.sort(keylambda x: x[score], reverseTrue) return candidates # 使用示例 if __name__ __main__: scheduler ToolScheduler(TOOLS) # 模拟一次“有风险”的模型输出 risky_model_output { name: delete_user_account, arguments: {user_id: 12345} } messages [ {role: user, content: 帮我查一下北京今天的天气。} ] candidates scheduler.schedule(risky_model_output, messages) print( 调度结果:) for cand in candidates: print(f - {cand[name]}: 得分 {cand[score]:.1f} ({cand[reason]}))运行后你会看到 调度结果: - get_weather: 得分 1.8 (rule_context_keyword_match: 1.0; rule_tool_complexity_score: 0.8; rule_safety_blacklist: 0.0)delete_user_account因为触发了_rule_safety_blacklist得分为负无穷被彻底过滤掉了。而get_weather因为匹配了“天气”关键词且复杂度适中拿到了最高分。3.3 方案二的实操心得与避坑指南注意调度层不是取代模型而是为模型赋能。它的目标是“提高正确率”而非“保证 100% 正确”。坑1把规则引擎做成“if-else 大杂烩”无法维护我见过最糟糕的调度实现是把所有规则硬编码在一个超长的if/elif/else链里。一旦业务变化比如新增一个工具就要改核心逻辑。方案二的精髓在于规则可插拔。self.rules是一个列表你可以随时append新的规则函数或者remove旧的规则而不用动schedule方法本身。在实际项目中我们甚至把规则集做成 YAML 配置文件由运维人员动态更新实现了“业务规则热加载”。坑2过度依赖关键词匹配导致误伤关键词匹配简单有效但容易误判。比如用户说“这个价格计算起来很复杂”模型可能错误地关联到calculate工具。方案二的应对策略是多规则融合。_rule_context_keyword_match只给 1.0 分而_rule_tool_complexity_score给 0.8 分两者相加才 1.8 分。如果有一个更精准的规则比如基于用户历史行为的推荐它可以贡献更高的权重。永远不要让单一规则拥有“一票否决权”或“一票通过权”。坑3忽略“无工具可选”的兜底逻辑调度后candidates列表可能为空。这时不能直接报错而应该有一个优雅的 fallback比如返回一个通用的{name: fallback_response, arguments: {text: 抱歉我暂时无法处理您的请求。}}或者触发一次“澄清对话”Ask for Clarification。我在某金融客服项目中就设置了min_score_threshold0.5低于此分的候选全部丢弃并自动回复“为了更准确地帮您请问您是想查询天气、进行计算还是其他操作”。这个小设计将用户因工具调度失败而流失的比例降低了 40%。经验技巧用difflib.SequenceMatcher做模糊工具名匹配有时模型会把get_weather错写成get_weatcher。与其让它直接失败不如在调度层加一个“纠错”环节。在schedule方法开头可以对model_output[name]做一次模糊匹配找出注册表中最相似的 3 个名字然后对这 3 个名字分别计算调度分。difflib.SequenceMatcher(None, get_weatcher, get_weather).ratio()会返回一个 0~1 的相似度分数。这个技巧在处理语音识别转文字ASR后的模型输入时特别有用能显著提升鲁棒性。方案二把 Tool Use 从“模型说了算”变成了“模型提议规则裁定”。它不追求玄学的“理解”而是用工程化的确定性为不确定的 AI 输出筑起一道可审计、可配置、可演进的安全堤坝。4. 方案三编排层实现——用有限状态机FSM模拟一次完整的 Tool-LLM 协作循环4.1 编排层Tool Use 的“操作系统内核”方案一管协议方案二管调度它们都只处理了 Tool Use 的一个“瞬间”模型输出一个 JSON系统执行一个函数。但真实的 Agent 交互是一个持续的、有状态的、多轮的循环。用户问“北京天气怎么样”模型可能第一轮{name: get_weather, arguments: {city: 北京}}→ 执行成功 → 返回结果第二轮{name: get_weather, arguments: {city: 上海}}→ 执行失败网络超时→ 需要重试第三轮{name: search_web, arguments: {query: 北京天气预报权威网站}}→ 执行成功 → 返回网页摘要。这个过程涉及状态管理当前在第几轮上一轮结果是什么、错误处理失败了是重试、换工具还是告诉用户、结果注入如何把工具结果格式化后塞回给模型作为新 context。方案三的目标就是用最精简的代码把这个“操作系统内核”手写出来。它不依赖任何异步框架不引入复杂的状态库只用一个while True循环 一个state字典就能跑通整个生命周期。4.2 核心实现一个 5 状态 FSM 3 个核心事件我们定义 Agent 的 5 个核心状态IDLE: 等待用户输入PLANNING: 模型思考生成 tool callEXECUTING: 系统执行工具HANDLING_ERROR: 工具执行失败需决策GENERATING_RESPONSE: 模型基于工具结果生成最终回复。状态流转由 3 个核心事件驱动USER_INPUT: 用户发来新消息MODEL_OUTPUT: 模型返回了 tool call 或 final answerTOOL_RESULT: 工具执行完毕返回结果或异常。from enum import Enum from typing import Dict, Any, List, Optional class AgentState(Enum): IDLE idle PLANNING planning EXECUTING executing HANDLING_ERROR handling_error GENERATING_RESPONSE generating_response class SimpleAgentFSM: def __init__(self, tools_registry: Dict[str, tuple]): self.tools_registry tools_registry self.state AgentState.IDLE self.messages [] # 对话历史 self.current_tool_call None # 当前待执行的 tool call self.tool_result None # 上次工具执行结果 self.max_retries 3 # 最大重试次数 def handle_user_input(self, user_message: str): 事件用户输入 self.messages.append({role: user, content: user_message}) self.state AgentState.PLANNING print(f➡️ 状态切换: {self.state.value} (等待模型规划)) def handle_model_output(self, model_output: Dict[str, Any]): 事件模型输出 if self.state AgentState.PLANNING: # 模型规划出了 tool call if name in model_output and arguments in model_output: self.current_tool_call model_output self.state AgentState.EXECUTING print(f➡️ 状态切换: {self.state.value} (准备执行 {model_output[name]})) else: # 模型直接给出了 final answer self.state AgentState.GENERATING_RESPONSE self.tool_result {type: final_answer, content: model_output.get(content, )} print(f➡️ 状态切换: {self.state.value} (直接生成答案)) elif self.state AgentState.HANDLING_ERROR: # 模型对错误做出了响应如重试、换工具、解释 self.state AgentState.PLANNING print(f➡️ 状态切换: {self.state.value} (错误已处理重新规划)) def handle_tool_result(self, result: Any, error: Optional[Exception] None): 事件工具执行结果 if error: # 工具执行失败 self.tool_result {type: error, error: str(error)} self.state AgentState.HANDLING_ERROR print(f❌ 工具执行失败: {error}) else: # 工具执行成功 self.tool_result {type: success, result: result} self.state AgentState.GENERATING_RESPONSE print(f✅ 工具执行成功: {result}) def run_step(self) - Optional[str]: 执行一个状态机步进返回本轮应采取的动作供外部调用者执行 :return: 动作描述如 call_tool: get_weather 或 generate_response if self.state AgentState.IDLE: return None # 等待用户输入 elif self.state AgentState.PLANNING: # 这里模拟“调用模型”实际中应替换为 LLM API 调用 # 返回一个模拟的 tool call return simulate_model_call elif self.state AgentState.EXECUTING: if not self.current_tool_call: return None # 执行工具调用 try: tool_name self.current_tool_call[name] args_str self.current_tool_call[arguments] validated_args parse_and_validate_arguments(tool_name, args_str) func, _ self.tools_registry[tool_name] result func(**validated_args) self.handle_tool_result(result) except Exception as e: self.handle_tool_result(None, e) return execute_tool elif self.state AgentState.HANDLING_ERROR: # 这里可以插入重试逻辑 if self.current_tool_call and self.tool_result.get(type) error: # 简单重试直接再次执行同一个 tool call error_info self.tool_result[error] print(f 尝试重试 (剩余 {self.max_retries} 次): {error_info}) if self.max_retries 0: self.max_retries - 1 self.state AgentState.EXECUTING return retry_tool else: # 重试耗尽进入最终响应 self.tool_result {type: final_answer, content: f抱歉服务暂时不可用: {error_info}} self.state AgentState.GENERATING_RESPONSE return handle_error elif self.state AgentState.GENERATING_RESPONSE: # 这里模拟“模型生成最终回复”实际中应构造 prompt 并调用 LLM if self.tool_result[type] final_answer: response self.tool_result[content] else: # 将工具结果注入 prompt再调用模型 response f工具执行结果: {self.tool_result[result]} self.messages.append({role: assistant, content: response}) self.state AgentState.IDLE print(f 最终回复: {response}) return generate_response return None # 使用示例模拟一次完整的交互 if __name__ __main__: agent SimpleAgentFSM(TOOLS) # 1. 用户输入 agent.handle_user_input(北京今天天气怎么样) while agent.state ! AgentState.IDLE: action agent.run_step() if action simulate_model_call: # 模拟模型返回 tool call model_out {name: get_weather, arguments: {city: 北京}} agent.handle_model_output(model_out) elif action execute_tool: # run_step 内部已执行无需额外操作 pass elif action generate_response: # run_step 内部已生成循环结束 break这段代码会输出清晰的状态流转日志➡️ 状态切换: planning (等待模型规划) ➡️ 状态切换: executing (准备执行 get_weather) ✅ 工具执行成功: 北京 今日晴气温 25°C ➡️ 状态切换: generating_response (生成答案) 最终回复: 工具执行结果: 北京 今日晴气温 25°C4.3 方案三的实操心得与避坑指南提示方案三不是为了生产部署而是为了“看见”。它把黑盒的 Agent 运行时变成了一张透明的流程图。坑1在run_step里混入业务逻辑导致状态机臃肿状态机的职责必须纯粹只管状态流转不管具体怎么做。handle_tool_result里只负责更新self.tool_result和self.state绝不应该在里面写requests.post(...)或数据库操作。那些具体的“执行”动作应该由外部调用者比如一个Executor类来完成然后把结果通过handle_tool_result事件喂给状态机。这种“控制反转”是保持状态机轻量、可测试、可复用的关键。我在重构一个老项目时就是把原来耦合在状态机里的 200 行 HTTP 调用代码剥离出去状态机代码量减少了 60%而可维护性提升了数倍。坑2忽略“状态持久化”导致重启即失联这个 FSM 是内存态的。如果服务重启self.messages和self.state全部丢失。方案三的启示是真正的生产级 Agent必须把关键状态如messages,current_state,retry_count序列化到 Redis 或数据库。每次run_step开始前先从存储加载状态结束后再把新状态存回去。这个“状态快照”机制是实现高可用、支持断点续聊的基础。面试时如果能提到这一点并给出json.dumps(state_dict)redis.setex(key, expire, value)的简略实现立刻就能区分出“写过 demo”和“做过上线”的候选人。坑3对HANDLING_ERROR状态的处理过于简单代码里只做了“重试”但真实场景中错误处理策略是分层的网络超时TimeoutError→ 重试参数错误ValueError→ 换工具或澄清权限不足PermissionError→ 直接拒绝。 方案三的handle_tool_result可以扩展为接收error_type参数然后在HANDLING_ERROR状态里根据error_type分发到不同的子状态如RETRYING,CLARIFYING,REJECTING。这种状态细化是构建企业级 Agent 的必经之路。经验技巧用graphviz自动生成状态机图状态机最大的价值是可视化。在开发阶段可以给SimpleAgentFSM加一个to_dot()方法输出 Graphviz 的 DOT 语言代码然后用graphviz库渲染成 PNG 图。这张图能直观展示所有状态、事件、流转条件是和产品、测试同学对齐需求的绝佳工具。我曾用它在一个跨部门评审会上5 分钟就让所有人理解了我们 Agent 的错误恢复逻辑避免了后续 3 天的反复沟通。方案三是这场手写之旅的终点也是真正理解的起点。当你亲手写出这个 5 状态的循环你就明白了为什么max_retries要设在状态机里而不是某个工具函数里为什么messages必须是全局状态而不是每次调用都新建为什么一个健壮的 Agent其核心代码量可能不到 200 行但其设计哲学却厚重如山。5. 三种方案的对比、选型与实战建议5.1 方案核心差异速查表维度方案一协议层方案二调度层方案三编排层核心目标确保工具定义Schema与执行Function的语义一致确保模型选择的工具Name与当前上下文Context的意图一致确保整个 Tool-LLM 协作流程State的健壮与可控关键输入tool_name,arguments_strmodel_output,messages,rulesstate,events(USER_INPUT,MODEL_OUTPUT,TOOL_RESULT)关键输出validated_args_dict或ValueErrorList[{name: str, score: float}]state(Enum) 和action(str)技术焦点JSON Schema 校验、类型安全规则引擎、上下文匹配、优先级排序有限状态机FSM、事件驱动、状态持久化代码量估算~50 行~100 行~150 行调试难度★☆☆☆☆ (错误信息精准定位快)