阿里云百炼联合Qwen3.7实战：手把手构建一个支持工具调用的AI Agent

前言

最近在做一个内部运维助手项目，需要 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：

1. 登录阿里云百炼控制台
2. 在「模型广场」选择 qwen-max（即 Qwen3.7-Max）
3. 进入「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("查一下北京今天的天气，然后把摘要发到 [email protected]")

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 的核心流程并不复杂，关键点在于：

1. 工具描述要精准，是影响 Agent 稳定性的核心变量
2. 合理利用并行工具调用，减少多轮交互的延迟
3. 做好工具路由的错误处理，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/

---