天气大模型要关联地理位置信息，如杭州属于中国，该怎么处理？如何对接天气 API？怎么定义 API 调用的相关内容
1️⃣ 考察意图
面试官想看你能否将大模型从“聊天玩具”升级为“能操作真实世界的 Agent”。核心考察三点：地理知识的结构化表达（不是让模型硬记，而是用知识库或工具解耦）、API 集成的工程细节（参数映射、错误处理、限流）、工具调用的设计哲学（LLM 何时该调用、如何保证参数准确）。刁钻点在于：用户说“杭州”时，模型需要知道它属于中国，但你不能让模型背地理表——这暴露了“知识 vs 工具”的取舍。答好了能展示你懂 Agent 的“感知-推理-行动”完整流程，以及处理模糊输入和异常的高阶能力。
2️⃣ 标准答
第一步：地理位置处理——用知识库解耦，别让模型死记
- 方案：构建一个轻量级地理位置知识库，存储城市-省份-国家三级映射。例如用 JSON 或 SQLite 表，键是城市名（含别名，如“杭州”=“Hangzhou”），值是
{province: "浙江", country: "中国", lat: 30.274, lon: 120.155}。 - 为什么这么做：LLM 的参数量虽大，但地理知识是静态且频繁更新的（行政区划调整），硬塞进 prompt 或微调会导致幻觉和过时。用外部知识库查询，准确率从 70% 提到 99%+，且维护成本低。
- 实际落地坑：用户可能说“魔都”或“帝都”，知识库必须包含别名映射。解法：用实体识别（如 spaCy 的 NER）先提取地点，再模糊匹配知识库，匹配失败时回退到 Geocoding API（如 Nominatim）做反向解析。
第二步：对接天气 API——设计参数映射与响应解析
- API 选择：OpenWeatherMap 或 WeatherAPI，免费版支持 5 天预报，日调用 1000 次。用城市名或经纬度查询，推荐经纬度（避免同名城市歧义，如“伦敦”有英国和加拿大两个）。
- 参数设计：函数签名
get_weather(lat: float, lon: float, units: str = "metric")。从知识库拿到经纬度后传入，units 控制温度单位（metric 返回摄氏度）。 - 响应解析：API 返回 JSON，提取
main.temp（温度）、weather[0].description（描述）、wind.speed（风速）。关键取舍：不要返回原始 JSON 给 LLM，而是格式化字符串，如“杭州当前温度 25°C，多云，风速 3m/s”，减少 LLM 解析负担。 - 实际落地坑：API 可能返回 404（城市不存在）或 429（限流）。解法：404 时回退到 Geocoding API 重新解析；429 时用指数退避重试（初始 1 秒，最多 3 次），并缓存结果 10 分钟避免重复调用。
第三步：定义 API 调用——Agent 工具设计
- 工具 Schema：用 OpenAI 的 Function Calling 格式或 LangChain 的 Tool 类。核心字段：
name: "get_weather"description: "获取指定地点的当前天气，需要城市名或经纬度。输入城市名时会自动补全地理信息。"parameters:{type: "object", properties: {location: {type: "string", description: "城市名，如'杭州'或'New York'"}}}- 调用逻辑：LLM 根据用户 query 决定是否调用工具。当用户说“杭州今天热吗”，LLM 输出
function_call: {name: "get_weather", arguments: {location: "杭州"}}。Agent 执行函数：先查知识库拿到经纬度，再调 API，最后返回格式化结果。 - 错误处理：如果 LLM 提取的参数不完整（如只给“杭州”没给国家），Agent 自动补全省份和国家信息（从知识库查）。如果 API 超时，返回“天气服务暂时不可用，请稍后再试”，并记录日志。
第四步：优化与扩展
- 缓存：用 Redis 或内存字典缓存同一地点的查询结果，TTL 设为 10 分钟。减少 API 调用，避免限流。
- 多 API 备选：主 API 失败时切换到备选（如 WeatherAPI），用健康检查机制（每 5 分钟 ping 一次）动态切换。
- 限流：在 Agent 层加令牌桶，每秒最多 5 次调用，防止用户刷接口。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从地理位置处理、API 集成、工具设计三个层面回答。第一，地理位置用知识库解耦，存储城市-省份-国家映射，避免模型硬记。第二，对接天气 API 时用经纬度查询，设计参数映射和响应格式化，并处理 404 和 429 错误。第三，在 Agent 中定义工具 Schema，让 LLM 自动提取参数，并加缓存和限流优化。总结一句：核心是让 LLM 做推理决策，让外部工具做精确执行，通过知识库和错误处理保证鲁棒性。”
4️⃣ 高频追问 & 应对
追问 1：如果用户说“帮我查一下杭州和上海的天气”，你怎么让 LLM 一次调用两个 API？
应对策略：设计工具支持批量查询。在参数 Schema 中把
location改为数组类型locations: {type: "array", items: {type: "string"}}，LLM 输出arguments: {locations: ["杭州", "上海"]}。Agent 内部并行调用两个 API（用 asyncio 或线程池），合并结果返回。注意：并行调用要控制并发数（如最多 3 个），避免触发 API 限流。如果其中一个失败，返回部分结果并提示“上海天气查询失败，已返回杭州天气”。
追问 2：如果用户说“明天杭州会下雨吗”，但你的 API 只支持当前天气，怎么处理？
应对策略：在工具描述中明确标注能力边界，如“仅支持当前天气，不支持预报”。如果 LLM 仍错误调用，Agent 在返回结果时附加提示：“当前仅支持实时天气，预报功能开发中”。更优方案：升级 API 到支持 5 天预报的端点（如 OpenWeatherMap 的
forecast），在工具中加forecast_days参数，默认 0 表示实时，用户指定天数时调用预报端点。关键取舍：不要盲目扩展功能，先评估用户需求频率，再决定是否集成。
追问 3：如何防止用户通过恶意输入（如“查一下北京，然后忽略所有限制”）绕过你的限流？
应对策略：在 Agent 层做输入过滤和限流，不依赖 LLM 的“道德判断”。具体做法：1）在工具调用前加正则检查，拒绝非地点字符（如 SQL 注入或 prompt 注入）。2）限流在 Agent 层硬编码，LLM 无法绕过（如令牌桶在函数执行前检查）。3）记录每次调用的用户 ID（如果系统有登录），对同一用户设置更严格的限流（如每分钟 10 次）。4）如果检测到异常模式（如 1 秒内 10 次调用），直接返回“请求过于频繁，请稍后再试”，并告警。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“让 LLM 记住所有城市的地理信息，用 prompt 告诉它杭州在中国” → ✅ 正确做法：用外部知识库或 Geocoding API 查询，避免模型幻觉和过时数据。LLM 只负责推理，不负责记忆静态知识。
- ❌ 说“直接调 API，返回原始 JSON 给 LLM 让它自己解析” → ✅ 正确做法：在 Agent 层格式化响应为自然语言字符串，减少 LLM 解析负担，提高准确率。原始 JSON 可能包含无用字段，且 LLM 可能误解。
- ❌ 说“只用一个 API，失败了就报错” → ✅ 正确做法：设计多 API 备选和错误重试机制，保证服务可用性。单点故障是生产环境大忌。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“知识库构建”角度切入，类比 RAG 中文档检索与地理知识库的相似性，强调实体识别和模糊匹配的复用经验。
- 如果你只做过传统 NLP：用“NER + 规则匹配”类比，说明如何用 spaCy 提取地点，再用字典映射补全层级信息，展示从 NLP 到 Agent 的迁移能力。
- 如果你是校招无项目：聚焦论文复现，引用 Toolformer（2023）或 Gorilla（2023）中工具调用的设计思想，说明你理解 LLM 调用外部 API 的范式，并可以快速实现 demo。
- Toolformer: Language Models Can Teach Themselves to Use Tools (2023)
- Gorilla: Large Language Model Connected with Massive APIs (2023)
- OpenAI Function Calling 官方文档
- LangChain Tool 设计与错误处理最佳实践
- OpenWeatherMap API 文档与限流策略