前言
最近在做一个内部运维助手项目，需要 AI 不只是「聊天」，而是真正能调用外部工具、查询数据库、触发工作流——也就是现在大家说的 Agent 模式。
调研了几个平台后，最终选定了阿里云百炼（AI 创新入口）作为底座，搭配最新的 Qwen3.7-Max 模型。选它的主要原因有两点：一是百炼提供了完整的 Function Calling 支持，二是 Qwen3.7 在工具调用的指令遵循能力上比上一代有明显提升。
这篇文章记录整个搭建过程，包括踩坑经历，供有同样需求的同学参考。
一、为什么选择 Qwen3.7 + 百炼？
在动手之前，先简单说一下模型选型的考量。
目前构建 Agent 的常见选择有三类：
| 方案 | 优点 | 局限 |
|---|---|---|
| OpenAI GPT-4o | Function Calling 成熟，生态完善 | 国内访问不稳定，成本高，数据出境合规风险 |
| 本地部署开源模型 | 数据完全自主，零 API 费用 | 需要 GPU 资源，7B 以下模型工具调用不稳定 |
| 阿里云百炼 + Qwen3.7 | 国内网络稳定，数据不出境，工具调用能力强 | 生态相比 OpenAI 稍小，部分小众工具链需适配 |
对于企业内部应用，数据合规是硬需求，所以百炼成了首选。
Qwen3.7 相比前代的核心改进在于：
- 长上下文窗口扩展到 128K，适合处理长对话和复杂上下文
- 多工具并行调用，一次请求可同时触发多个函数
- 指令遵循稳定性提升，减少 JSON 格式错误的概率
二、环境准备
开通阿里云百炼服务后，先拿到 API Key：
- 登录阿里云百炼控制台
- 在「模型广场」选择
qwen-max（即 Qwen3.7-Max） - 进入「API-KEY 管理」创建新的 Key
Python 环境安装依赖：
pip install openai httpx
# 百炼兼容 OpenAI SDK，无需额外安装
百炼的 API 端点与 OpenAI 格式完全兼容，只需修改 base_url：
from openai import OpenAI
client = OpenAI(
api_key="YOUR_DASHSCOPE_API_KEY",
base_url="https://dashscope.aliyuncs.com/compatible-mode/v1"
)
三、核心实操：构建一个带工具调用的 Agent
Step 1：定义工具（Functions）
工具调用的核心是告诉模型「你有哪些能力」。以一个查询天气+发送报告的 Agent 为例：
tools = [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定城市的实时天气信息",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "城市名称，如「北京」「上海」"
},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit"],
"description": "温度单位"
}
},
"required": ["city"]
}
}
},
{
"type": "function",
"function": {
"name": "send_report",
"description": "将生成的报告发送到指定邮箱",
"parameters": {
"type": "object",
"properties": {
"email": {
"type": "string", "description": "收件人邮箱"},
"content": {
"type": "string", "description": "报告正文"}
},
"required": ["email", "content"]
}
}
}
]
Step 2：实现 Agent 循环
Agent 的核心是一个「思考-行动-观察」的循环（ReAct 模式）：
import json
def run_agent(user_message: str):
messages = [{
"role": "user", "content": user_message}]
while True:
# 调用模型
response = client.chat.completions.create(
model="qwen-max",
messages=messages,
tools=tools,
tool_choice="auto"
)
msg = response.choices[0].message
# 如果模型决定调用工具
if msg.tool_calls:
messages.append(msg) # 把模型的决策加入历史
# 执行每个工具调用
for tool_call in msg.tool_calls:
function_name = tool_call.function.name
function_args = json.loads(tool_call.function.arguments)
# 路由到实际函数
result = dispatch_tool(function_name, function_args)
# 把工具返回结果加入对话
messages.append({
"role": "tool",
"tool_call_id": tool_call.id,
"content": json.dumps(result, ensure_ascii=False)
})
else:
# 模型给出最终回复
print(f"Agent 回复：{msg.content}")
break
def dispatch_tool(name: str, args: dict) -> dict:
"""工具路由，实际项目中替换为真实的 API 调用"""
if name == "get_weather":
# 替换为实际天气 API
return {
"city": args["city"], "temp": "25°C", "condition": "晴"}
elif name == "send_report":
# 替换为实际邮件发送逻辑
return {
"status": "success", "message": f"报告已发送至 {args['email']}"}
# 运行
run_agent("查一下北京今天的天气，然后把摘要发到 test@example.com")
Step 3：处理多轮工具调用
Qwen3.7 支持在一次推理中并行调用多个工具，上面的代码已经通过 for tool_call in msg.tool_calls 处理了这个情况。
实际测试中，当我发出「查北京和上海的天气，对比后生成报告发给我」这类请求时，模型会一次性触发两个 get_weather 调用，而非串行执行，效率有明显提升。
四、踩坑记录
坑 1：工具描述要足够精确
刚开始写工具描述时用的是「获取天气」，结果模型有时会在本可以一步完成的情况下多做推断。后来改成了更具体的描述（「获取指定城市的实时天气信息，返回温度、天气状况、湿度」），稳定性明显提升。
坑 2：tool_call_id 必须准确匹配
把工具结果加入消息时，tool_call_id 必须和模型返回的 tool_call.id 完全一致，否则 API 会报错。这个细节在官方文档里有说但容易忽略。
坑 3：大量工具时的性能问题
当工具数量超过 20 个时，模型的选择准确率会下降。建议按场景对工具分组，每次只注入当前场景需要的工具子集。
五、成本参考
百炼的计费是按 Token 算的，Qwen3.7-Max 目前有限时折扣。以我们实际项目测算：
- 单次对话含工具调用，平均消耗约 2,000-5,000 Tokens
- 日均 1,000 次调用，月成本在百元级别，比同等 GPT-4o 调用便宜约 60-70%
另外百炼现在对新用户有免费 Token 额度，用于前期开发测试完全够用。
总结
用阿里云百炼 + Qwen3.7 搭建 Agent 的核心流程并不复杂，关键点在于：
- 工具描述要精准，是影响 Agent 稳定性的核心变量
- 合理利用并行工具调用，减少多轮交互的延迟
- 做好工具路由的错误处理，Agent 在生产环境中必须有降级机制
如果你也在做类似的 AI 应用，可以去百炼的活动页面看看——新用户有超过 1 亿 Tokens 的免费额度，做 POC 验证阶段完全不用担心成本。
相关链接
- 阿里云百炼平台：https://www.aliyun.com/activity/hub/ai-innovation?userCode=aptjpq1x
- 百炼控制台：https://bailian.console.aliyun.com
- DashScope API 文档：https://help.aliyun.com/zh/dashscope/
