为什么 Agent 的 Function Call 一直不稳

为什么 Agent 的 Function Call 一直不稳

P1 · agent_architecture

🏷 标签：function_calling, stability, error_handling, tool_schema

1️⃣ 考察意图

面试官想考察你对 Agent 系统稳定性的系统性诊断能力，而非背诵概念。刁钻点在于：Function Call 不稳是表象，根源可能是 Schema 设计缺陷、模型规划能力不足、或错误恢复机制缺失。答好了能展示你从“现象”到“根因”的工程思维，以及实际落地中处理边界情况（如参数冲突、工具过载）的硬实力。这是 P1 级面试中区分“会用”和“能修”的关键题。

2️⃣ 标准答

Function Call 不稳的根因通常不在模型本身，而在系统设计。我从三个层面拆解：Schema 定义、规划策略、错误恢复。

1. Schema 定义不清晰

• 问题：参数约束模糊或语义边界重叠。例如，一个工具 search_weather 的参数 location 未指定格式（如“北京”vs“Beijing”），模型可能输出非法值，导致调用失败。
• 解法：使用 JSON Schema 严格定义参数类型、枚举值、正则约束。例如，location 加 pattern: "^[\\u4e00-\\u9fa5]+$" 限制中文。同时，为每个工具写清晰描述（description），避免歧义，如“仅支持中国城市，用中文名称”。
• 工程取舍：Schema 越严格，模型越难生成合法调用，但稳定性提升。实践中，对高频工具（如搜索）放宽约束，对关键工具（如支付）收紧。

2. 模型缺乏规划能力

• 问题：复杂任务需多步调用，但模型可能跳步或选错工具。例如，用户问“订机票并查天气”，模型可能先调用 book_flight 再 get_weather，但 book_flight 需要日期参数，而模型未从上下文提取。
• 解法：引入规划框架，如 ReAct（Reasoning + Acting）或 Plan-and-Solve。让模型先输出推理步骤，再执行调用。例如，用 thought 字段记录“用户需要先获取日期，再调用 book_flight”。
• 实际落地的坑：ReAct 会增加 token 消耗和延迟。优化策略：对简单任务（单步调用）跳过规划，直接执行；对复杂任务（>3 步）强制规划。使用 HNSW 索引缓存历史规划结果，避免重复推理。

3. 错误恢复机制缺失

• 问题：调用失败后，模型直接放弃或重复错误。例如，API 超时返回 500，模型可能重试相同参数，导致死循环。
• 解法：设计分层重试策略：第一层：自动重试（最多 3 次，指数退避，初始间隔 1 秒）。
• 第二层：参数修正。若失败因参数非法，让模型基于错误信息（如“location 格式错误”）重新生成调用。使用 LLM 的 few-shot 示例引导修正。
• 第三层：回退到用户。若重试 3 次仍失败，输出友好错误并询问用户输入。 工程取舍：重试次数过多会放大延迟和成本。实践中，对非关键工具（如天气查询）重试 1 次，对关键工具（如支付）重试 3 次并记录日志。

4. 工具数量过多导致选择困难

• 问题：工具超过 10 个时，模型选择准确率下降。例如，有 search_weather 和 search_flight，模型可能混淆。
• 解法：使用工具分组（Tool Grouping）。将相似工具归为一类（如“信息查询类”），模型先选组，再选具体工具。或使用 BM25 预检索，基于用户 query 召回 Top-3 工具，减少候选集。
• 实际落地的坑：分组可能引入额外延迟。优化：对高频工具（如搜索）不分组，直接暴露；对低频工具（如数据分析）分组。

5. 缺乏记忆导致上下文丢失

• 问题：多轮对话中，模型忘记之前调用的结果。例如，第一轮调用 get_user_info 返回“用户 ID=123”，第二轮调用 book_ticket 需要该 ID，但模型未传递。
• 解法：引入短期记忆（Short-term Memory），将每次调用的输入/输出存入上下文窗口。使用滑动窗口（如保留最近 5 轮）或摘要压缩（用 LLM 总结历史）。
• 工程取舍：记忆越多，上下文越长，模型注意力衰减。实践中，对关键信息（如用户 ID）强制保留，对非关键信息（如天气结果）压缩。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从 Schema 设计、规划策略、错误恢复三个层面回答。Schema 层面，用 JSON Schema 严格约束参数并写清晰描述，避免歧义；规划层面，引入 ReAct 框架让模型先推理再执行，对简单任务跳过规划；错误恢复层面，设计分层重试机制，包括自动重试、参数修正和用户回退。总结一句：Function Call 不稳的根因是系统设计缺陷，而非模型能力不足，通过结构化 Schema、规划框架和容错机制可明显提升稳定性。”

4️⃣ 高频追问 & 应对

追问 1：如果工具数量超过 50 个，你怎么优化选择？

使用两阶段检索：第一阶段用 BM25 或 DPR 基于用户 query 召回 Top-10 工具；第二阶段让模型从这 10 个中选。BM25 的 k1 和 b 参数需调优（默认 k1=1.5, b=0.75），对短 query 效果较好。若工具描述长，可用 ColBERT 的后期交互（late interaction）提升召回精度。取舍点：检索阶段增加延迟（约 50ms），但模型选择准确率从 60% 提升到 85% 以上。

追问 2：模型总是生成非法参数，比如日期格式不对，怎么解决？

在 Schema 中加 format: "date" 约束，并用 few-shot 示例引导。例如，在 system prompt 中加“日期格式必须为 YYYY-MM-DD”。若仍失败，用后处理（post-processing）修正：写一个正则解析器，将模型输出的“明天”或“2024/1/1”转为标准格式。工程取舍：后处理增加复杂度，但避免模型重试。实践中，对日期、数字等常见类型做后处理，对复杂参数（如 JSON 嵌套）让模型重试。

追问 3：你怎么测试 Function Call 的稳定性？

构建一个模拟测试框架：用 mock API 模拟不同错误场景（参数缺失、超时、500 错误、工具误选）。定义稳定性指标：调用成功率（>95%）、平均重试次数（<2）、端到端延迟（<3 秒）。用自动化脚本跑 1000 个测试用例，覆盖正常、边界和异常场景。例如，对“参数缺失”场景，测试模型是否自动补全或询问用户。框架可用 pytest + unittest.mock 实现。

5️⃣ 避坑 · 常见错误答法

• ❌ 说“Function Call 不稳是因为模型能力差，换 GPT-4 就好了” → ✅ 正确切入：模型能力是因素之一，但根因多在系统设计（Schema 模糊、无重试机制）。换模型只能缓解，不能根治，且成本高。
• ❌ 说“加一个 try-catch 就能解决” → ✅ 正确切入：try-catch 只能捕获异常，但无法处理参数非法或工具误选。需要分层重试策略，包括参数修正和用户回退。
• ❌ 说“工具数量多就减少工具” → ✅ 正确切入：减少工具会牺牲功能。正确做法是用工具分组或预检索优化选择，而非简单删除。

6️⃣ 简历呼应

• 如果你有 RAG 项目：从“检索与调用类似”切入，强调 Schema 设计类比于文档索引，错误恢复类比于检索失败时的 fallback 策略。展示你如何用 BM25 预检索优化工具选择。
• 如果你只做过传统 NLP：用“规则与模型结合”类比，强调 Schema 约束类似于正则表达式，规划框架类似于流水线（pipeline）。展示你如何用 JSON Schema 和 ReAct 提升稳定性。
• 如果你是校招无项目：聚焦论文复现，如 ReAct（arXiv:2210.03629）或 Toolformer（arXiv:2302.04761）。展示你理解规划框架和记忆机制的原理，并能在 demo 中实现简单版本。

7️⃣ 延伸阅读

• ReAct: Synergizing Reasoning and Acting in Language Models (arXiv:2210.03629)
• Toolformer: Language Models Can Teach Themselves to Use Tools (arXiv:2302.04761)
• JSON Schema 官方规范 (json-schema.org)
• BM25 算法详解及其在工具检索中的应用 (博客：Elasticsearch BM25 调优)
• HNSW 索引在缓存规划结果中的实践 (论文：Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs)