SmartCall v1.0.5 的变化，重点不只是增加一个版本号，而是让呼叫中心里的 AI 智能体从“会对话”进一步走向“能执行任务”。项目基于 AI 大模型与 Asterisk 通信引擎，整合 AI 语音机器人、智能 IVR 流程编排、端到端双工对话、实时语音识别（ASR）、语音合成（TTS）以及大模型意图识别等能力。
本次版本摘要明确提到：智能体支持技能与工具。对于客服系统来说，这意味着智能体可以围绕业务目标组织能力，并在合适的对话节点调用外部系统，而不是只返回一段自然语言。
从“回答问题”到“完成动作”
传统语音机器人通常可以完成三件事：识别用户说了什么、判断用户意图、生成一段回复。这样的流程适合查询类问题，但在真实客服场景中，用户往往希望系统直接完成操作：查询订单、核验状态、创建工单，或者把通话转交给人工坐席。
“技能”可以理解为面向业务目标的能力集合，例如“查询订单”或“创建服务工单”；“工具”则是智能体完成这些技能时可以调用的具体接口或函数。一个技能可能由多个工具组合而成，也可能包含参数收集、权限检查、结果确认和失败兜底等步骤。
可以把一次对话抽象成下面的链路：
用户语音
-> ASR 转写
-> 意图识别
-> 智能体选择技能
-> 收集工具参数
-> 调用业务系统
-> TTS 播报结果
-> 继续对话或转人工
这条链路的价值在于，通信能力和业务执行能力被连接起来。Asterisk 负责电话接入、通话路由等通信基础设施，AI 层负责理解和决策，业务工具负责执行确定性的系统操作。
技能与工具如何划分
落地时建议把“能做什么”和“怎么做”分开定义。
技能描述用户目标，应该使用业务人员也能理解的名称，例如：
- 查询订单物流
- 修改预约时间
- 查询账户余额
- 创建售后工单
- 转接人工客服
工具描述具体的执行动作，例如调用订单服务 API、写入工单系统或触发 Asterisk 的转接流程。工具接口应尽量做到参数明确、结果结构化，并且不要让大模型直接拼接 SQL、拨号指令或内部脚本。
下面是一个可以改造成实际实现的最小 Python 示例。示例假设智能体已经完成意图识别，现在根据用户提供的订单号调用一个 HTTP 业务接口。接口地址、鉴权方式和返回字段需要替换为企业自己的服务。
from __future__ import annotations
import os
from typing import Any
import requests
ORDER_API = os.environ.get("ORDER_API", "http://127.0.0.1:8080/api/orders")
API_TOKEN = os.environ.get("ORDER_API_TOKEN", "change-me")
def query_order(order_id: str) -> dict[str, Any]:
"""A tool exposed to the agent: query one order by ID."""
if not order_id or len(order_id) > 64:
return {"ok": False, "error": "invalid_order_id"}
response = requests.get(
f"{ORDER_API}/{order_id}",
headers={"Authorization": f"Bearer {API_TOKEN}"},
timeout=5,
)
response.raise_for_status()
data = response.json()
return {
"ok": True,
"order_id": order_id,
"status": data.get("status", "unknown"),
"estimated_delivery": data.get("estimated_delivery"),
}
if __name__ == "__main__":
order_id = os.environ.get("ORDER_ID", "demo-10001")
print(query_order(order_id))
运行前安装依赖并设置参数：
python -m pip install requests
export ORDER_API="https://example.internal/api/orders"
export ORDER_API_TOKEN="replace-with-your-token"
export ORDER_ID="A10001"
python order_tool.py
这个示例只演示工具边界。生产环境还需要补充鉴权、重试策略、日志脱敏、幂等控制和业务错误映射。例如，订单不存在不应该让智能体得到一段原始 HTTP 错误，而应该返回类似 order_not_found 的稳定错误码，让智能体用自然语言向用户解释。
为语音场景设计工具调用
文本聊天中的工具调用可以等待几秒，但电话对话对延迟更敏感。一个工具设计是否适合语音客服，至少要考虑以下问题：
- 参数是否容易通过语音获得。订单号、身份证号等信息应支持逐位确认，避免 ASR 把数字识别错误。
- 是否需要二次确认。涉及退款、改约、取消服务等不可逆操作时，应在执行前明确复述关键参数。
- 失败后是否有可说出口的结果。工具返回值应能映射为简短、清晰的语音提示。
- 是否需要转人工。连续识别失败、接口超时或命中高风险意图时，应进入明确的兜底流程。
可以用一份简化的 YAML 描述技能和工具之间的关系。该配置是实践示例，具体字段需要根据 SmartCall 的实际配置格式调整：
agent:
name: order-service-agent
system_prompt: |
你是订单客服。回答前优先使用可用工具核实订单状态。
涉及取消、退款或修改信息时，必须先向用户复述并取得确认。
工具失败时不要编造结果，必要时转接人工。
skills:
- name: query_order
description: 查询订单当前状态和预计送达时间
tools:
- get_order
- name: human_handoff
description: 将当前通话转交人工坐席
tools:
- transfer_to_human
tools:
- name: get_order
type: http
method: GET
path: /api/orders/{order_id}
parameters:
order_id:
type: string
required: true
description: 用户口述的订单号
timeout_seconds: 5
- name: transfer_to_human
type: telephony
action: transfer
queue: customer-service
配置中最重要的不是字段名称，而是职责边界：模型负责选择技能和组织对话，业务服务负责校验数据并执行操作，电话引擎负责通话控制。将三者混在一个提示词或脚本里，后续很难审计和维护。
与现有呼叫中心的结合点
SmartCall 的技术组合覆盖了呼入和外呼场景，因此技能与工具可以嵌入多个节点：
- 呼入接待：识别来电目的，直接查询业务信息或创建工单。
- IVR 流程：在固定菜单和自然语言对话之间切换，减少层层按键。
- 智能外呼：在确认接通和用户意愿后调用预约、提醒等业务能力。
- 双工对话：允许用户自然打断，智能体在实时语音交互中继续完成任务。
- 人机协作：当工具调用失败或业务复杂度超过边界时，把上下文传给人工坐席。
这里需要特别注意，工具能力越强，越不能只依赖模型提示词来控制风险。企业应在工具服务端实施权限校验、参数校验、审计记录和操作幂等；提示词只能帮助智能体遵循流程，不能替代业务系统的安全边界。
上线 v1.0.5 前的检查清单
可以从一个低风险、只读的查询技能开始验证：
- 选定一个明确的业务目标，例如订单状态查询。
- 为工具定义稳定的输入参数和结构化输出。
- 为 ASR 可能产生的数字、姓名和日期错误增加确认话术。
- 覆盖接口超时、业务不存在、权限不足和重复调用等异常情况。
- 记录模型决策、工具请求、工具结果和最终话术，但对手机号、证件号等敏感字段脱敏。
- 为无法完成任务的情况设计转人工路径，并测试上下文是否完整传递。
- 通过真实录音或回放评估延迟、打断处理和语音可理解性。
SmartCall v1.0.5 的“技能与工具”支持，为 AI 呼叫中心补上了从理解到执行的关键一环。采用时不必一次开放所有业务权限，先从只读查询和可回滚操作开始，再逐步扩展到预约、工单和交易类流程，更容易控制风险，也能更清楚地衡量智能体是否真正减少了人工处理成本。