同样是调用大模型API，为什么有的应用只能做一问一答，有的却能自动查询订单、调用插件、按步骤完成任务？差别通常不在模型本身，而在Agent配置是否真正落地。文心一言和通义千问这两家国内主流模型都已经把函数调用、工具注册、多轮状态管理做成了标准化能力，但很多工程细节仍然藏在平台控制台与SDK参数里，稍不注意就会配置成看似可用、实际无法触发工具的对话模型。下面围绕文心一言和通义千问的Agent配置，从应用创建到代码调用逐步展开。
一、先理清Agent和普通大模型对话的边界
普通大模型对话在工程上表现为无状态或简单多轮的文本生成：输入消息，模型返回文本，流程结束。Agent则是一个持续的循环体，模型根据用户输入判断是否需要调用外部工具，业务代码执行工具并把结果回填给模型，模型再基于结果继续推理，直到生成最终答复。这个循环里最关键的配置不是提示词有多长，而是工具声明是否准确、参数是否必填、上下文是否完整。
国内大模型在函数调用上形成了两套API设计。文心一言通过functions参数接收工具声明，返回结果中包含function_call字段；通义千问采用更接近国际主流接口的tools参数，返回tool_calls列表。两者都要求先在控制台创建应用或开通模型服务，因为Agent能力依赖平台侧的函数调用通道，不是任意API Key都能直接使用。如果只传入普通messages，模型永远不会主动触发工具。
配置一个可用的Agent至少包含三件事：平台开通与密钥准备、工具函数注册、多轮上下文维护。这三步任何一环缺失，都会导致工具调用失败或结果不可信。下面先看文心一言的具体配置。
二、文心一言智能体配置与调用
登录百度智能云千帆控制台，创建应用并获取API Key和Secret Key。安装qianfan SDK后，可以直接通过qianfan.ChatCompletion发起带函数声明的对话。工具列表中的description至关重要，模型是否触发函数，九成取决于描述是否说清楚了用途和适用条件。模糊的描述会直接导致模型忽略工具，转而去编造答案。
以下示例注册一个订单查询工具，并完成首轮调用：
import qianfan
def get_order_status(order_id):
# 这里对接企业内部订单系统
return {"order_id": order_id, "status": "已发货"}
functions = [
{
"name": "get_order_status",
"description": "根据订单号查询订单状态",
"parameters": {
"type": "object",
"properties": {
"order_id": {"type": "string", "description": "订单编号"}
},
"required": ["order_id"]
}
}
]
chat_comp = qianfan.ChatCompletion()
messages = [{"role": "user", "content": "帮我查一下订单A12345的状态"}]
resp = chat_comp.do(
model="ERNIE-4.0-8K",
messages=messages,
functions=functions,
temperature=0.2
)
print(resp)
首轮返回中如果包含function_call，业务代码需要执行对应的get_order_status函数，再把函数结果回填到messages。回填时通常要追加一条role为assistant的消息，其中包含原始的function_call，再追加一条role为function的消息，携带函数返回结果。这样第二轮调用时模型才能知道工具已经执行完毕，并基于真实数据生成自然语言答复。
这个步骤很容易遗漏。如果下一轮只发送用户问题而不携带之前的函数结果，模型会重复发起调用，或者直接忽略已有信息编造一个看似合理的状态。开发时建议把temperature控制在0.1到0.3之间，避免工具参数出现幻觉；同时functions列表不要一次注册太多，否则模型容易在多个工具之间选错。参数schema中的required字段必须与函数定义一致，漏掉必填项会降低调用准确率。
三、通义千问智能体配置与调用
通义千问的Agent能力集成在阿里云百炼平台，需要开通DashScope并创建API Key。安装dashscope后，使用Generation.call并传入tools参数。通义的tools结构包含type和function两层，参数声明使用JSON Schema，与文心一言的写法略有不同，但核心思路一致。
下面注册一个天气查询工具，并完成首轮调用：
import dashscope
from dashscope import Generation
from http import HTTPStatus
def get_weather(city):
return {"city": city, "temperature": "26℃", "condition": "晴"}
tools = [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "查询指定城市的实时天气",
"parameters": {
"type": "object",
"properties": {
"city": {"type": "string", "description": "城市名称"}
},
"required": ["city"]
}
}
}
]
messages = [{"role": "user", "content": "杭州今天天气怎么样"}]
response = Generation.call(
model="qwen-plus",
messages=messages,
tools=tools,
result_format="message"
)
if response.status_code == HTTPStatus.OK:
message = response.output.choices[0].message
print(message.content)
print(message.tool_calls)
else:
print(response.code, response.message)
首轮返回中如果存在tool_calls，需要把模型消息原样放入messages，再添加一个role为tool的结果消息，并携带对应的tool_call_id。只有这一步做完整，第二轮才会输出基于真实数据的自然语言。缺失tool_call_id或者结果不是字符串形式，都可能导致接口报错或模型无法关联调用。
通义千问还支持百炼平台的托管智能体，可以在控制台直接配置知识库和插件，适合不想自己写循环的团队。但托管方案灵活度较低，处理复杂业务流程时建议使用API方式。价格方面，qwen-plus等模型的工具调用与普通文本生成共用计费，开发阶段通常具备一定免费额度，足够验证配置是否正确。
四、两套方案对比与配置调优建议
从实际开发角度看，文心一言与通义千问的Agent能力差异主要体现在参数结构和平台绑定程度上。下面用表格做一次横向对比：
| 对比项 | 文心一言 | 通义千问 |
|---|---|---|
| 平台入口 | 百度智能云千帆 | 阿里云百炼/DashScope |
| 工具参数 | functions | tools |
| 返回字段 | function_call | tool_calls |
| 自托管难度 | 中等，需处理function角色 | 中等，需处理tool角色与tool_call_id |
| 托管智能体 | 支持，可在千帆控制台配置 | 支持，可在百炼控制台配置 |
无论选择哪一家，调优思路都比较接近。优先让模型返回JSON或结构化内容，方便业务侧校验；工具执行必须设置超时，避免外部接口卡死拖垮整个Agent循环；工具描述尽量与业务代码注释保持一致，减少模型理解偏差；对于涉及资金、权限等高风险操作，增加人工确认环节，比单纯调低温度更可靠。模型版本也需要定期检查，旧版本可能已经停止维护，继续使用会遇到工具调用率突然下降的问题。
如果业务需要私有化部署，两家都有企业版方案，但部署成本和运维复杂度远高于API接入。如果只是快速验证Agent流程，直接使用API方式配合几行Python代码，通常可以在半天内跑通完整循环。文心一言在中文企业文档场景下表现稳定，通义千问则对通用工具调用和结构化输出更友好，选择时建议以实际任务的工具触发准确率为准，而不是只看对话效果。
总体而言，国内大模型的Agent能力已经足够支撑订单查询、天气获取、知识库检索、工单流转等常见业务场景。关键不在于模型参数调得多复杂，而在于工具声明写得是否清楚、上下文是否完整回填、错误分支是否有兜底。把这些基础细节做扎实，Agent才能从演示状态进入生产可用状态。
AI智能体文心一言Agent配置通义千问智能体修改时间：2026-10-01 10:02:16