共计 1314 个字符，预计需要花费 4 分钟才能阅读完成。
背景痛点
在构建对话助手时，开发者常遇到两个核心问题：一是如何准确配置助手的行为模式，二是如何实现自然语言到结构化工具调用的转换。特别是在天气查询这类场景中，用户输入可能千变万化（如“成都天气如何”“今天北京会下雨吗”），但后端接口通常需要严格的结构化参数（如 {"city":"成都"}）。传统方案需要编写大量正则表达式或 NLP 模型，既增加复杂度又难以维护。
技术选型
对比主流对话框架：
- Rasa：灵活性高但配置复杂，需要单独训练意图识别和实体抽取模型
- Dialogflow：云服务依赖强，自定义工具调用流程受限
- chatclient.builder 优势：
- 声明式 API 直接嵌入行为规则
- 内置语义解析能力减少样板代码
- 纯代码配置便于版本管理
核心实现
1. 行为配置
defaultsystem 方法定义助手的元指令：
.defaultsystem("""
你是一个天气查询助手。当用户询问天气时：1. 从用户输入中提取城市名（如“今天成都天气”中的“成都”）2. 严格按以下格式调用工具："city": "提取的城市名"
""")2. 工具调用处理
系统会自动完成：
– 城市名实体识别（支持别名如“魔都→上海”）
– 参数格式验证
– 错误回退处理
完整代码示例
from chatclient import builder
weather_assistant = builder(model="gpt-3.5-turbo")
.defaultsystem("""
你是一个天气查询助手。当用户询问天气时：1. 从用户输入中提取城市名
2. 调用格式：{"city": "城市名"}
""")
.register_tool(
name="get_weather",
description="查询指定城市天气",
parameters={
"type": "object",
"properties": {"city": {"type": "string", "description": "城市名称"}
},
"required": ["city"]
}
)
.build()
# 使用示例
response = weather_assistant.chat("上海明天会下雨吗？")
print(response.tool_calls) # 输出：{'get_weather': {'city': '上海'}}性能与安全
性能优化
- 缓存机制 ：对相同城市请求缓存天气数据（注意设置合理 TTL）
- 批量处理 ：支持多城市查询（如“北京和上海天气”）
- 异步调用 ：耗时操作使用 async/await
安全防护
- 输入过滤 ：防止注入攻击（如
city: "';DROP TABLE"） - 频率限制 ：防止 API 滥用
- 敏感词检测 ：过滤政治相关词汇
避坑指南
-
问题 ：用户输入“帮我看看天气”未触发工具调用
解决 ：在 defaultsystem 中补充无城市名的引导话术 -
问题 ：工具返回“城市不存在”
解决 ： - 建立城市别名库（如“帝都→北京”）
-
添加模糊匹配逻辑
-
问题 ：高并发时响应慢
解决 ： - 实现请求队列
- 使用更轻量级的本地模型（如 TinyLlama）
思考与实践
- 如何扩展支持“未来三天”这类时间范围查询？
- 当用户输入“我家附近天气”时，怎样结合 GPS 数据实现定位？
- 请尝试增加空气质量指数（AQI）查询功能
欢迎在评论区分享你的实现方案！
正文完
