AI Agent打电话的架构分层：从规则脚本到Function Calling的实现

1. 这篇文章真正要解决的问题把同样的任务交给不同架构的 AI Agent结果是完全不一样的。别被“智能体”这个名词骗了以为凡是能回答问题的模型都能稳定完成一个复杂的多步骤任务。拿“打电话”来举例这不是一个“张口说话”的问题而是意图识别、任务规划、工具调用、状态管理、多轮对话、异常恢复、结果校验的复合工程。一个 Agent 打电话打得好不好直接暴露的是它背后的架构深度而不是模型参数的多少。本文要讨论的正是“不同希人打电话的方式”背后体现出的技术差异。这里的“希人”在 AI 应用语境下可以理解为具备拟人化交互能力的智能体主体也就是你对接的 AI 助理、数字员工、虚拟客服、外呼机器人。它们表面上都会“打电话”但内部实现逻辑天差地别。读完这篇文章你能解决三个问题看清不同 Agent 实现打电话任务的架构分层知道它们各自能做什么、不能做什么。从零跑通一个最小可用的 Agent 打电话流程理解工具定义、上下文管理、状态机设计这几个关键环节。知道真实项目落地里决定一个电话型 Agent 成败的坑在哪不是模型会不会说话而是它对“当前会话处于什么阶段”有没有感知。2. “希人”打电话的核心概念与任务拆解先把“打电话”拆开。一个自然、完整的电话任务听起来很简单拨打号码、接通后说清楚来意、根据对方反应做出应答、最终达成一个目标。但在 Agent 眼中这至少是五个独立子任务的连续执行意图理解用户说“帮我打电话给张总问一下合同进度”Agent 要解析出动作是“打电话”、对象是“张总”、目的是“询问合同进度”。通讯录匹配把人名匹配到真实的电话号码。这里有个隐性难点同名联系人、备注昵称、公司内部短号都会让匹配出错。任务规划要根据通话目标规划开场白、核心问题、结束语并预判对方可能的回答。多轮对话执行通话是实时的Agent 必须根据对方真实回应动态调整话术而不是照着脚本念完。结果总结与后续行动挂断后要把通话内容转化为结构化记录生成待办事项比如“明天再跟进合同邮件”。如果再把“打电话”放到真实业务场景里它还会牵扯到通信能力层也就是 SIP 线路、通话状态回调、录音存储、ASR/TTS 服务。所以一个完整方案不是“模型话筒”而是“模型工具通信能力业务逻辑”的集成。这里真正容易踩坑的地方是很多人只关注模型对话能力把精力全花在提示词上结果上线后发现在真实通话里Agent 不知道该在什么时候挂断、什么时候等待、什么时候把电话转给人工。这不是模型笨而是整个系统缺少对通话状态的管理能力。从材料看不同“希人”打电话的方式差异本质上就是不同 Agent 对上述任务链的处理深度差异。3. 五种典型的“希人打电话”实现方式把市面上的实现归拢一下大致可以分成五类。3.1 规则脚本式这是最早期、也是最常见的方式。核心逻辑是“如果-那么”用按键导航或简单关键词匹配来决定下一句要说的话。典型场景是传统的 IVR 语音导航比如“查余额请按 1人工服务请按 2”。这种方式打电话最“稳”因为它根本没有自由度每一步都是预设的。但它致命的缺陷是处理不了任何偏离脚本的回复。用户只要说一句“我不太清楚我在说什么”系统可能就陷入死循环。3.2 NLU 槽位填充式在规则脚本之上加入了自然语言理解模块。系统先通过意图识别模型判断“用户想要什么”再通过槽位提取拿到关键参数。比如“我要订明天早上九点的会议电话”就会被解析成日期明天、时间9:00、事件会议电话。这种方式比纯规则灵活很多适合任务目标明确、参数固定的场景比如预约类、查询类电话。但当会话从“填槽”演变成“真实对话”时它就力不从心了。因为它本质上还是在做信息抽取并没有真正理解整段对话的语义。3.3 大模型 Function Calling 式这是当前最主流的方式。模型本身不直接执行动作而是根据用户意图生成一个结构化的函数调用请求。比如用户说“帮我给王经理打电话”模型输出{ function: make_phone_call, arguments: { contact_name: 王经理, purpose: 确认项目上线时间 } }系统收到这个结构化输出后再去查通讯录、拨号并把结果返回给模型。这样模型既能保持自然语言交互又能可靠地触发外部动作。相比 NLU 方案它的优势是模型理解能力强能处理复杂指令相比规则方案它不再需要穷举所有对话分支。3.4 带记忆与规划的 Agent 框架式它在 Function Calling 之上加了两个核心机制记忆和规划。记忆分短期和长期。短期记忆负责“当前这通电话说了什么”长期记忆负责“这个客户过去是什么情况上次沟通到哪一步”。规划机制则让 Agent 能在动作前先生成多步计划。例如打电话前它会先规划出“查询通讯录 - 拨号 - 开场白 - 询问核心问题 - 总结 - 挂断 - 写记录”这样的链路并在每步执行后根据结果修正下一步。这种方式打电话已经比较接近“人”了它有目标、有上下文、有动态调整能力。3.5 多 Agent 协作式把不同职责拆给不同 Agent 分别承担。例如一个“主控 Agent”负责人机对话一个“质检 Agent”在后台实时监听通话内容判断是否出现违规话术或用户情绪激动一个“数据 Agent”负责读写 CRM 系统。多 Agent 的核心价值是隔离复杂度但也引入了一个新问题——Agent 之间的信任和通信成本。你怎么保证质检 Agent 的判定准确主控 Agent 是否会忽略质检 Agent 的建议这些问题在工程上都比单 Agent 更棘手。实现方式灵活度上下文理解工程复杂度适用场景规则脚本极低无低按键导航、固定流程NLU 槽位填充中弱中预约、查询、信息登记Function Calling高中中单轮指令触发工具调用Agent 框架很高强较高复杂任务、多轮对话多 Agent 协作极高强高大型业务系统、实时质检4. 环境准备与前置条件下面直接进入可落地操作的部分。无论你要做哪一种 Agent 打电话方案环境准备都绕不开以下几个环节。这里我们以最通用的 Python 技术栈为例核心目标是把一套“Function Calling 模拟电话流程”跑通。4.1 基础运行环境建议使用 Python 3.10 以上版本因为新版类型标注和异步特性在开发 Agent 时更顺手。无论如何建议先创建独立的虚拟环境避免依赖冲突python -m venv agent-venv source agent-venv/bin/activate pip install --upgrade pip如果输入材料没有给出具体依赖版本这里就不做过死锁定以实际安装为准。4.2 需要安装的依赖一个最小可运行的 Agent 电话流程需要以下依赖pip install openai pip install fastapi pip install uvicorn其中openai提供对 GPT 系列模型 Function Calling 能力的调用接口。fastapi和uvicorn用于快速搭建一个模拟通信网关的 Web 服务模拟电话事件回调。如果你使用的是国内大模型服务只要它支持 OpenAI 兼容的接口格式代码结构可以基本保持不变只需要修改base_url和api_key配置。4.3 准备模型访问凭证这里不指定具体的 API Key 获取方式但你需要确认你使用的模型服务支持 Function Calling 或 Tool Calling。在代码中通过base_url指向对应的服务即可。5. 完整示例跑通一个 Agent 打电话的最小流程下面用一个最小示例演示“不同希人打电话的方式”中最有代表性的两种第一种是直接提示词对话第二种是 Function Calling 结构化调用。为了安全地演示我们不在本地真实拨号而是用模拟电话终端来验证逻辑。真实项目里只需要把模拟终端换成 SIP 网关或云呼叫中心的 Webhook 即可。5.1 定义电话工具首先创建一个phone_tools.py定义两个关键动作search_contact和place_call。# 文件路径src/phone_tools.py CONTACTS { 张总: {phone: 13800000001, department: 销售部}, 王经理: {phone: 13800000002, department: 项目组}, 李老师: {phone: 13800000003, department: 培训部}, } def search_contact(name: str) - dict: 根据人名查找通讯录返回联系人信息。 同名或未找到时应返回明确错误信息。 if name in CONTACTS: return {code: success, contact: CONTACTS[name]} return {code: not_found, message: f未找到联系人{name}} def place_call(phone_number: str, purpose: str) - dict: 发起外呼请求返回通话 ID 与状态。 真实项目中这里会调用线路网关 API。 call_id fcall_{phone_number[-4:]} return { code: ok, call_id: call_id, status: ringing, phone_number: phone_number, purpose: purpose, }这两个函数的设计很有代表性。search_contact暴露的是通讯录匹配逻辑place_call暴露的是通信能力。真正接入真实通信服务时替换这两个函数的内部实现即可模型侧代码无需大改。5.2 定义模型工具 SchemaFunction Calling 的关键在于你必须把工具描述成模型能看懂的 JSON Schema。这个描述越准确模型就越知道什么时候该调用、传什么参数。# 文件路径src/tool_schema.py TOOLS [ { type: function, function: { name: search_contact, description: 根据联系人姓名查找通讯录获取电话号码。找不到联系人时返回 not_found。, parameters: { type: object, properties: { name: { type: string, description: 联系人姓名, } }, required: [name], }, }, }, { type: function, function: { name: place_call, description: 向指定电话号码发起外呼并记录通话目的。, parameters: { type: object, properties: { phone_number: { type: string, description: 对方的手机号码, }, purpose: { type: string, description: 本次通话的目的用于话务系统记录, }, }, required: [phone_number, purpose], }, }, }, ]工具描述里最容易出错的是description。写得笼统模型就可能在不需要调用工具的时候乱调用写得含糊模型传参就会错误。一个实用的校验方法是把 description 读给另一个模型听看它能否准确判断“什么时候该调用这个函数”。5.3 主控循环接下来是 Agent 的核心。它完成的任务是在一个循环里不断执行“模型生成 - 判断是否有工具调用 - 执行工具 - 返回结果”的流程直到模型不再请求调用工具给出最终答复。# 文件路径src/agent_loop.py import json from openai import OpenAI from phone_tools import search_contact, place_call from tool_schema import TOOLS client OpenAI() # 工具名称到实际函数的映射 TOOL_MAP { search_contact: search_contact, place_call: place_call, } def run_agent(user_message: str) - str: messages [ { role: system, content: 你是一个电话助理助手。当用户要打电话时你先查找通讯录确认电话号码后再发起外呼。每一步都要基于工具返回结果继续。, }, {role: user, content: user_message}, ] for step in range(5): response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS, tool_choiceauto, ) choice response.choices[0].message if choice.tool_calls: messages.append(choice) for tool_call in choice.tool_calls: name tool_call.function.name args json.loads(tool_call.function.arguments) result TOOL_MAP[name](**args) messages.append( { role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse), } ) else: return choice.content return 已达到最大执行步数任务可能未能完成。 if __name__ __main__: result run_agent(帮我给张总打个电话问一下上周合同什么时候盖章) print(最终答复, result)这个主控循环是理解 Agent 的钥匙。模型输出一个 tool_call代码执行真实函数再把真实结果回传给模型。模型看到结果后决定继续调用还是给出最终回答。这个循环体现了“Agent”和“普通对话模型”的根本差别模型不再是唯一的信息来源外部工具的真实结果会进入模型的下一次判断。5.4 模拟一次工具冲突为了更直观地体现不同实现方式的差异加一个异常场景测试用户提供了通讯录里不存在的人名。# 文件路径src/run_contact_not_found.py from agent_loop import run_agent result run_agent(帮我给根本不存在的客户赵总打电话) print(最终答复, result)模型收到not_found的结果后正确的行为是向用户反馈“未找到联系人”而不是编造一个电话号码继续调用place_call。这一个简单的测试就能看出 Agent 的工具使用是否可靠——如果模型强行虚构号码并拨出就说明提示词约束不足需要在系统提示中强调必须基于工具返回值行动。6. 运行结果与效果验证示例写好后按以下顺序运行python src/run_contact_not_found.py预期输出应该是类似这样的逻辑最终答复抱歉我在通讯录里没有找到“赵总”。请确认一下联系人姓名是否正确或者告诉我更多的查找信息。这个结果说明 Agent 正确走完了“解析意图 - 调用 search_contact - 收到 not_found - 终止拨号”这条链路。再测试正常场景python src/agent_loop.py预期效果最终答复好的我已经为您查找了张总的电话并已发起外呼。通话目的已记录为“追问合同盖章进度”请留意通话状态。如果运行没达到预期不要急着改提示词。第一步先查看search_contact和place_call这两个函数的返回内容是否正常第二步打印messages列表确认每个 tool_call 是否拿到了正确的参数第三步确认模型服务是否真的返回了tool_calls字段。真正要做生产级验证时建议增加模拟网关层。下面是一个简单的事件回调服务# 文件路径src/mock_gateway.py import time import uvicorn from fastapi import FastAPI, Request app FastAPI() app.post(/call/status) async def call_status(request: Request): payload await request.json() print(收到通话状态回调, payload) return {code: ok} app.get(/call/{call_id}) async def get_call(call_id: str): # 模拟通话状态流转 return { call_id: call_id, status: completed, duration_seconds: 63, recording_url: fhttps://example.local/recordings/{call_id}.wav, } if __name__ __main__: uvicorn.run(app, host0.0.0.0, port8000)生产系统中线路提供方会通过 Webhook 推送ringing、answered、completed、failed等状态。Agent 要能接收这些状态并做出下一步动作。这一步决定了 Agent 是“会发指令”还是“会管理整场通话”。7. 常见问题与排查思路从实际项目经验看Agent 打电话相关的问题通常集中在下面几个点问题现象可能原因排查方式解决方案模型不调用工具直接编造电话号码工具描述不清晰或系统提示没有强调工具优先级打印模型原始返回检查 tool_choice 设置在系统提示中明确要求“必须通过工具查号和拨号”必要时设置tool_choice强制指定工具联系人匹配错误通讯录存在同名联系人或聊天记录中的称呼与通讯录备注不一致检查搜索函数入参确认模型提取的人员姓名在search_contact函数中返回多个候选值由模型进一步询问用户确认通话中 Agent 突然忘记之前的对话内容没有维护好通话级的消息上下文检查 messages 列表是否每轮都完整传递将通话记录以数组形式保存在会话对象中每次请求都携带完整上下文工具调用成功但结果没有传回模型代码遗漏了携带 tool_call_id 的 messages检查是否把工具返回内容追加到 messages确保构造roletool的消息时带上对应tool_call_id用户说话太口语化模型提取参数失败缺少对口语变体的示例引导增加 few-shot 示例或在函数描述中补充常见说法在系统提示中增加“用户可能说发微信、打个电话联系一下都视为打电话意图”语音识别把“张总”识别成“张宗”ASR 模型对专有名词识别不准查看 ASR 转写文本在 ASR 模型的热词表中加入通讯录人名通话状态不同步Agent 在未接通时就开始说话没有处理线路回调状态查看网关回调日志增加状态机只在 answered 状态下触发 TTS 播报排查时有一个通用顺序先看工具层有没有正确执行再看消息上下文有没有正确传递最后才优化提示词。大多数“Agent 行为诡异”的问题最终都出在前两层而不是模型本身的对话能力。8. 最佳实践与工程建议如果要把 Demo 变成生产可用的电话型 Agent下面几条建议能直接帮你少走弯路。8.1 用状态机管理通话生命周期别让模型来决定“现在能不能说话”。模型是概率系统有可能在电话未接通时就开始播报开场白也可能在用户沉默时陷入尴尬。更稳妥的做法是用状态机明确划分idle、dialing、ringing、answered、speaking、listening、terminated等状态只在特定状态允许模型输出语音内容。例如只有在answered状态才调用 TTS 合成开场白只有在listening状态才把用户语音送入 ASR 和模型。模型输出的文字内容只作为“说什么”的依据而“什么时候说”由状态机控制。8.2 工具函数要小、要单一每个工具函数只做一件明确的事。search_contact只查通讯录place_call只发起呼叫get_call_status只查询状态。不要设计一个do_everything函数否则模型很容易传错参数也难以复用。8.3 为对话建立持久化记录通话一旦结束要把整理后的对话摘要、意图、用户决策、待办事项写入业务系统。建议输出统一的结构化 JSON方便下游 CRM 或工单系统消费。摘要应由模型在挂断后生成而不是把原始语音识别文本直接写入。8.4 注意合法合规边界电话外呼涉及用户隐私、通话录音和营销合规问题。生产环境中必须在通话接通时明确告知对方“本通话可能被录音”并且对号码来源、用户授权、退订机制做完整设计。这里是不能含糊的硬边界技术再先进也不能绕过授权谈外呼。8.5 设置最大步骤数和兜底话术Agent 循环一定要有最大执行步数上限避免工具调用链死循环。同时配置兜底话术当模型超过步数或识别到多次无法理解用户意图时主动说“我为您转接人工座席”。有退路用户才不会在电话里干等。9. 总结与后续学习方向从表面看所有“希人”都在打电话但当通话状况偏离预设脚本时它们的行为会迅速分化。规则脚本会在第一个岔路口崩溃NLU 方案会丢失上下文而具备工具调用能力的 Agent则可以通过“工具结果反哺模型判断”的循环真正处理一个接一个的意外。本文通过一个最小示例完整展示了 Agent 打电话的架构骨架工具函数、Schema 描述、主控循环、事件回调以及各个节点上的工程细节。我相信对准备做电话型 Agent、数字人客服、AI 外呼系统的开发者来说这个骨架可以直接作为项目的第一版参考结构。接下来往三个方向深入会比较有价值。状态机设计把 call_id、状态字段、事件表设计成可复用的通话状态机模型。多轮对话的长期记忆如何把历史沟通记录、客户偏好、上次未完成事项注入到当前通话上下文中。实时语音交互链路的整合把 ASR、大模型、TTS 三个延迟点做并行优化缩短端到端的应答时延。如果你正在做 Agent 类项目“打电话”是最好的切入点因为它同时考验意图理解、工具使用、状态管理和异常恢复。把一个电话任务跑通你基本上就掌握了 Agent 工程最核心的那部分能力。