说明：本文讨论的是让 Agent 发起电话外呼时的工程处理，属于 AI Agent 落地话题，不涉及具体模型版本与价格。AI 领域版本迭代极快，凡涉及版本号、价格、可用性，请以你阅读时的官方页面为准。文中代码为结构示意，请按自己的技术栈调整后再上生产。

一、电话是一条窄带链路，不是"会说话的助手"

屏幕没了，兜底手段也没了

2026 年中我们接过一个需求：把内部那个能答问题的对话 Agent 接上电话，替业务同事做首次触达。团队的第一反应是"语音合成接一个拨号器就行"，一周就出了 Demo，然后在灰度第三天全部回滚。

问题不在模型，在于我们下意识把电话当成了"语音版对话框"，而两者的失败模型完全不同。

对话框里，用户看得见历史、看得见按钮、可以重发。电话里这些都没有：对方只有你的声音，任何一次沉默超过三四秒就会被理解成"对面是机器人"或者"掉线了"。

五个硬差异，决定了工程重心

把差异拉成一张表，比讲道理有用：

维度	对话框	电话
发起方	用户主动，意愿明确	系统主动，对方无预期
通道	双向可并发，可滚动	单向串行，说完才能听
时限	用户愿意等	对方耐心按秒计，随时可挂
兜底	有屏幕可看、可点	只有声音，无二次确认手段
身份	账号已登录，身份确定	接电话的是谁不知道

最后一行是最容易被低估的。界面上你知道对面是登录用户，电话里你只知道"这个号码有人接了"——可能是本人，可能是家人，可能是同事，也可能是一个共用号码的前台。

一通电话占一条话路，并发是硬上限

还有个和 LLM 完全不同的资源约束：话路是独占的。模型请求排队，最坏结果是慢；外呼排队排不上，结果是拨不出去。

这意味着容量规划不能用"QPS"这套思路。要看的是"同时在线通话数 × 平均通话时长"，再叠上运营时段——有效外呼窗口一天可能只有 8 小时，任务全挤在里面。我们第一次做容量估算时按全天摊平算，结果上午十点一到，队列直接堆到四位数。

所以外呼的第一层设计不是话术，是队列：什么任务先拨、什么任务今天干脆不拨、拨不出去的任务怎么在窗口关闭前收尾。

二、通话状态机：先把"没接通"拆成七种

只记"成功/失败"会直接污染业务判断

最早我们的回执只有两个值：接通、未接通。上线两周后业务方拿了张看板来找我们，说"拒绝率 60%，这个渠道不能用了"。

我们把原始记录翻出来重算：那 60% 里，真正明确表达拒绝的不到四分之一，剩下的是无人接听、关机、占线、空号、被拦截，全被归到了"未接通"。业务方看到的"拒绝率"，其实是"没打通率"。

这件事的根子在于状态空间的粒度定错了。状态机粒度直接决定下游动作能不能做对——重拨策略、号码治理、成本核算、名单清洗，全挂在这上面。

状态表：八种结果，八种下游动作

状态	判定依据	下游动作	可重拨
振铃中	已送出，未摘机	计时，超过 45 秒或 8 声转无人接听	—
接通	对方摘机	起录音、起计时，进身份确认	—
无人接听	振铃超时	记"未接触"，进重拨队列，间隔 ≥4 小时，最多 2 次	是
忙	线路忙音	短间隔重拨，15–30 分钟后，最多 2 次	是
空号	运营商返回不可用	号码治理：标不可用、回写主数据、永久停拨	否
关机	关机或不可达	与无人接听区分，间隔放到次日同一时段	是
被拦截	被对方或终端拦截	该号码永久停拨，并记线路维度	否
中途挂断	接通后对方挂机	按挂断时刻分两类，见下	分情况

"中途挂断"是最需要拆细的一格，我们按接通后经过的时长切两段：

• 接通 5 秒内挂断：绝大多数是对方听出是机器、或者看到陌生号码直接挂。这类不重拨——再拨一次只会让对方把你的号码拉黑。
• 说完关键信息后挂断：对方已经听到结论，挂断只是不想继续聊。这类按"已触达"处理，回执里写"信息已播报，未确认理解"，由业务方决定要不要换渠道补一次。

把这两类混在一起，会出现很难排查的现象：某批号码的重拨成功率异常低，因为第一次就被判成"可重拨"，第二次必然还是被秒挂。

代码：把重拨规则写在枚举旁边

状态和重拨策略必须放在一起维护。分开写的结果是：新增状态忘了同步策略表，线上就会出现某状态永不重拨、或无限重拨。

⚠️ 代码待验证

from enum import Enum


class CallState(str, Enum):
    QUEUED = "queued"              # 已入队，等话路
    RINGING = "ringing"            # 已送出，等摘机
    CONNECTED = "connected"        # 对方摘机
    NO_ANSWER = "no_answer"        # 振铃超时
    BUSY = "busy"                  # 线路忙
    INVALID = "invalid"            # 空号或号码不可用
    POWERED_OFF = "powered_off"    # 关机或不可达
    BLOCKED = "blocked"            # 被拦截
    DROPPED = "dropped"            # 接通后中途挂断
    DONE = "done"                  # 正常结束


# 重拨策略与状态放在同一处，新增状态时编译器会提醒你补这一项
RETRY_POLICY = {
    CallState.NO_ANSWER:   {"retry": True,  "min_gap_h": 4,  "max_times": 2},
    CallState.BUSY:        {"retry": True,  "min_gap_h": 0.5, "max_times": 2},
    CallState.POWERED_OFF: {"retry": True,  "min_gap_h": 20, "max_times": 2},
    CallState.DROPPED:     {"retry": False, "min_gap_h": None, "max_times": 0},
    CallState.INVALID:     {"retry": False, "min_gap_h": None, "max_times": 0},
    CallState.BLOCKED:     {"retry": False, "min_gap_h": None, "max_times": 0},
}

还有一条比代码更重要的约定：状态只能由信令侧写，不能由话术侧写。 我们踩过一次，模型在对话里听到对方说"行，那先这样"，就把状态改成了"完成"，而信令那边记录的是对方 40 秒后才挂机、中间一直在听。

三、接通之后先确认身份

三段式开场，十五秒内说完

接通之后最忌讳的是"一口气把事说完"。对方在最初的十秒里只判断三件事：你是谁、为什么打给我、我能不能现在挂掉。这三件事没说清，后面说什么都没用。

我们的开场固定三段，控制在 15 秒内：

1. 自报：机构名、我的角色、这通电话会录音以及用途。录音告知必须在这一步说，不能等对方问了才说。
2. 来意：一句话，不超过 25 个字。写不出来就说明这个场景不该用电话。
3. 退出：明确给出"现在不方便可以改时间"和"可以要求不再联系"两个出口。

第三段很多人会省掉，觉得是给自己找麻烦。实际相反——给了出口的通话，挂断率反而更低。对方知道可以随时叫停，防御姿态会松一档。

三档确认，对不上就降级

身份确认不是"问出身份证号"，那是把风险从系统转到对方身上。工程上要的是分档：

档位	做法	允许做什么
强确认	本人应答 + 一个只有本人知道的弱标识（尾号、单号后四位）	可以说明具体事项、可以记录承诺
弱确认	本人应答，弱标识对不上或不愿提供	只约回拨时间，不说具体事项
无法确认	明确表示不是本人、或拒答	只说"有一件需要本人确认的事"，结束

分档的意义在于：不同档位对应不同的信息暴露量。强确认下可以说金额和期限，弱确认下只能说"有个事需要跟您确认"，这条线必须写死在代码里。

家人接听是最高频的意外

上线第一个月，我们统计了一版接通后的分布，"非本人接听"占了将近三成——配偶、父母、同事、前台。它带来的不是技术问题，是信息泄露。

我们出过一次：坐席型话术里有一句"关于您名下的一笔账务"，家人接听后 Agent 照原样说了，对方追问，Agent 又补了一句具体金额。当天就有了投诉。

修正的做法很笨但有效：所有涉及具体信息的句子，前面都挂一个前置条件判断，条件不满足就整段跳过，而不是"换个说法"。整段跳过比改写安全得多，因为改写这件事本身就是模型在自由发挥。

⚠️ 代码待验证

def next_step(answered_by: str, verified: str) -> str:
    """answered_by: self / family / colleague / unknown
       verified:    strong / weak / none"""
    if answered_by != "self":
        # 非本人：不进入任何含具体信息的段落
        return "leave_minimal_notice"
    if verified == "strong":
        return "say_purpose"
    if verified == "weak":
        return "ask_callback_slot"
    return "close_politely"


# 调用处不要写成 if/else 散落在话术里，统一走这张表
BRANCH = {
    "leave_minimal_notice": "只说有事找本人，约定回拨时段",
    "ask_callback_slot":    "只约时间，不说事项",
    "say_purpose":          "进入主体段落",
    "close_politely":       "礼貌结束，回执记 wrong_person 或 pending",
}

四、说什么：话术的分段结构

每段一个能回答"是/否"的收口

一段连续说超过 30 秒的话术，在电话里等于什么都没说。对方的短期记忆撑不住，而且中间没有插话点，他只能用挂断来表达"我跟不上"。

我们的写法是：主体拆成若干段，每段结尾必须是一个能用"是"或"不是"回答的问题。不是为了收集信息，是为了拿到一个同步点——对方答了，说明还在听；对方不答，说明该停了。

⚠️ 代码待验证

[开场 0-15s]
  1. 自报：机构 + 角色 + 录音告知（用途）
  2. 来意：一句话，<= 25 字
  3. 退出：现在方便吗？不方便可改时间，也可要求不再联系

[主体]
  段 A：核对身份（只问弱标识，不问完整证件号）
  段 B：说明事项（一事一段，每段以一个是否问题收口）
  段 C：确认理解（复述关键数字，请对方确认一次）

[收尾]
  4. 结论复述 + 下一步 + 下次联系时间（给到具体日期与时段）
  5. 结束语（不追加任何新信息）

段 C 单独存在的理由：电话里没有书面确认，唯一手段是复述之后请对方点头。没这一步，回执里的"已告知"只是系统自述，不是事实。

被打断后从哪继续

电话里被打断是常态，不是异常。但这里说的不是音频层的打断检测——那是另一套东西，本账号有专篇写过。这里说的是内容层的恢复：被打断之后，从哪一句接着往下说。

最常见的错误实现是"重头再来"。对方刚说了句"你 etc 等"，Agent 又把开场白念一遍，第二遍基本就是被挂断。

正确做法是维护一个"已覆盖段落"的集合，比如 covered = ["opening", "identity", "seg_b"]。被打断后先响应对打断内容，再从 covered 之外的第一个段落继续。

⚠️ 代码待验证

def resume_point(covered: set[str]) -> str:
    order = ["opening", "identity", "seg_a", "seg_b", "seg_c", "closing"]
    for seg in order:
        if seg not in covered:
            return seg
    return "closing"

这个集合还有个副产品：它记录了通话实际说到了哪一段。回执里带上它，业务方才能判断"关键信息到底送到没有"，而不是只看一个"已接通"。

被反问时的三类兜底

对方反问的内容高度集中在三类，每一类都有固定的处理边界，不要让模型即兴：

• “你怎么有我电话”：只答来源类别（比如"您在我们这边留过联系方式"），不编具体渠道、不编具体时间。答不上来的细节，宁可说"我这里只看到登记记录，具体渠道我核实后回复您"。
• “这是不是诈骗”：不要辩解。给对方一条可自行核验的路径——挂断后拨官方公开号码，报出这通电话的编号。能主动邀请对方去核验的，反而更容易被信任。
• “我不需要”：一次挽留，不纠缠。挽留的话术只能是"那我记一下，后续不再打扰"，然后进结束语。第二次挽留的实际效果是负的。

五、录音、告知与留痕

开头十秒要说的话，版本化管理

录音告知属于开场第一段，不属于"后面补一句"。它必须包含两件事：这通电话会录音，录音用于什么用途。

用途要具体到能听懂。"用于服务质量改进"对方听不懂，也无法据此判断要不要继续；写成"用于内部核对这次沟通的内容"才有意义。

告知文本必须版本化。我们当时的做法是给每版话术一个 disclosure_version，随回执落库。后来出现过一次争议，需要确认某通电话到底有没有告知，靠的就是这个版本号加录音时间段对齐——如果告知文本是直接改在代码里的，这件事根本查不清。

三个产物，一个主键

一通电话会产出三样东西：录音文件、转写文本、结构化回执。这三样必须能被同一个标识串起来，否则回溯时就是三份互不相干的文件。

主键用 call_id，格式带上日期和当日序号，比如 c_20261029_000731。不要用"号码+日期"，我们最早就是这么做的，结果同一号码一天拨两次，第二通的录音直接把第一通覆盖了——等业务方来问"上周那通到底说了什么"，文件已经没了。

字段	说明
call_id	主键，贯穿录音、转写、回执
number_hash	号码的哈希，不存明文
line_id	线路标识，用于按线路统计拦截率
started_at / ended_at	带时区的绝对时刻
state	第二章的状态枚举
disclosure_version	告知文本版本
script_version	话术版本
recording_path	录音对象存储路径
transcript_path	转写文本路径

存多久：分层，不要一律永久

三样产物的保留期不该相同：

• 录音：短期为主，比如 90 天；进入争议流程的单独立案归档，不受默认期限约束。
• 转写文本：比录音长一档。它的体积小得多，检索价值却最高。
• 结构化回执：最长。业务侧的对账、复访、统计都依赖它，而且它本身不含原文。

一律永久保存的代价很实在：录音是最大的一类存储。我们算过一次，日均几千通的场景，录音占掉整个通话域九成以上的存储。

⚠️ 代码待验证

# 以 call_id 为主键归档；目录按 UTC 日期分片；文件名不含人名与号码
SRC="/var/spool/calls/${CALL_ID}.wav"
DST="/archive/calls/$(date -u +%Y/%m/%d)/${CALL_ID}.wav"
mkdir -p "$(dirname "$DST")"
mv "$SRC" "$DST"
printf '%s\t%s\t%s\n' "$CALL_ID" "$DST" "$(date -u +%FT%TZ)" >> /archive/calls/index.tsv

文件名里带人名和号码，是我们最早犯的另一个错：归档目录一旦被同步到别处，等于把一份名单复制了出去。文件名只留 call_id，映射放在库表里。

完整版资料清单：本文用到的状态字段表、话术分段模板与回执结构都整理在里面了，扫码即可获取：

六、结果回执：把"我再想想"写成待定

结论只能是枚举

回执里最重要的字段是"结论"，而它最容易被写成自由文本。一旦自由文本进了库，下游就会把它当事实用——报表统计它、复访任务依赖它、名单清洗读它，而它其实只是模型的一次措辞。

所以结论字段只允许枚举，我们用的是五个值：

• agreed：明确同意，且能复述出同意的是什么
• refused：明确拒绝
• pending：未表态，需要再联系
• wrong_person：非本人接听
• not_reached：未接通（对应第二章的前七种状态）

自由文本只允许出现在 summary 字段里，且有长度上限。它给人看，不给程序读。

这里有个具体的坑："我再想想"被记成 agreed。这不是模型笨，是提示词的天然倾向——“我再想想"在语料里后面常跟着"好的”，模型很容易归到肯定一侧。我们的修法是给判定加一条硬规则：凡是回答中不含明确的动作承诺（“可以”“就这么办”“你发过来”），一律 pending，并强制要求填 next_contact_at。填不出下次联系时间的，说明这通电话本来就不该有结论。

承诺要留原话，也要留归一化结果

对方说的话，和我们理解的意思，是两件事，回执里两个都留：

• promise.raw_quote：原话片段，从转写里截取，带时间区间
• promise.normalized：归一化后的结构，比如 {"action": "submit_form", "deadline": "2026-11-05"}

只有原话，下游用不了；只有归一化，事后无法核对模型有没有理解错。两个都留，出问题时能一眼看出是"对方没说清"还是"我们听错了"。

normalized 允许为空。对方说"我这两天弄一下"，deadline 就是空的——不要为了填满字段，把"这两天"猜成一个具体日期。空着，下游自然会走"待确认"分支。

回执的六个部分

⚠️ 代码待验证

{
  "call_id": "c_20261029_000731",
  "state": "done",
  "conclusion": "pending",
  "summary": "对方表示需与家人商量后再答复，未给出明确时间",
  "promise": {
    "raw_quote": "我这两天看一下，你先别催",
    "normalized": null,
    "span": [128, 141]
  },
  "todos": [
    {"owner": "agent", "action": "send_summary_sms", "due": "2026-10-29T18:00:00+08:00"}
  ],
  "next_contact_at": "2026-11-02T10:00:00+08:00",
  "covered_segments": ["opening", "identity", "seg_a", "seg_b"],
  "disclosure_version": "d-07",
  "script_version": "s-12"
}

回执里最后两个字段最容易被漏，但它们恰好是"下一通电话能不能接得上"的关键——没有 covered_segments，第二通会从开场白重新讲一遍；没有 next_contact_at，pending 就变成了一个永远不会被处理的死状态。

七、边界与上线顺序

四道闸门：时段、频次、告知、拒呼

这四件事都是工程约束，做法上以"拨号前拦住"为原则，而不是"拨完之后记录"。

• 时段：按被叫方所在时区判断，不是按你的服务器时区。工作日的可拨窗口设成 9:00–20:00，节假日表单独维护——节假日表不能靠 weekday() 推，调休一多就会错。
• 频次：同一号码 7 天内不超过 N 次，且要跨号码合并计数。同一个人留了两个号码，分别拨就算两次，这是最容易被投诉的一种"重复骚扰"。
• 告知：版本化管理，话术变更即版本 +1，回执里记版本号。
• 拒呼名单：三个入口——通话中口头要求、事后申诉、内部标记。生效必须是即时的，且查询点在拨号前，不在拨号后。

第三条和第四条经常被做成"事后过滤"：先拨出去，发现名单里有，再标记。这在工程上无效——电话已经打出去了。

⚠️ 代码待验证

def can_dial(contact, now, policy) -> tuple[bool, str]:
    local = now.astimezone(contact.tz)          # 按被叫方时区判断
    if local.strftime("%Y-%m-%d") in policy["holidays"]:
        return False, "holiday"
    if not (policy["window"][0] <= local.hour < policy["window"][1]):
        return False, "out_of_window"
    if contact.person_key in policy["denylist"]:   # 按人，不按号码
        return False, "denylisted"
    if contact.attempts_7d >= policy["max_per_7d"]:
        return False, "frequency_cap"
    if contact.last_attempt_at and (now - contact.last_attempt_at) < policy["min_gap"]:
        return False, "too_soon"
    return True, "ok"

注意 denylist 查的是 person_key 而不是号码。按号码查的话，对方换一个号码就绕过去了，而这恰恰是最需要拦住的情形。

上线顺序：先让系统学会"不打"

我们的上线顺序是按"风险由低到高"排的，每一步都留了一周观察期：

阶段	范围	观察什么
一	内部号码，只做告知型通话	状态机判定是否准确、挂断率
二	内部号码，加身份确认与回执	回执结论与人工抽听的一致率
三	外部小比例，单一场景，非高峰时段	拦截率、投诉率、重拨命中率
四	外部放量，多场景	频次闸门是否被绕过
五	接入业务系统自动触发	触发源异常时的熔断

第一阶段只做"告知型"通话，是有意为之：告知型不索取任何信息，即使状态判定错了、话术说岔了，损失也可控。等状态机和挂断率稳定了，再放开"确认型"——需要对方回答并形成承诺的那种。

第三阶段限定"非高峰时段"也有讲究：上午十点和下午三点的接通率区间完全不同，先在最稳的时段跑，才能把话术问题和时段问题分开。

出问题时的兜底，不是转人工坐席

这里说清边界：转人工坐席系统不在本文范围，它涉及排队、技能组、工单流转。

电话 Agent 真正需要的兜底是通话之后的：凡是状态为 dropped、或者结论为 pending 且对方有明确诉求的，进人工复核队列，由人看转写、听录音片段，决定要不要换一种方式再联系。这一步不需要实时，本质是一个异步的质检与补救流程。

我们第一版没做这个队列，所有"说了但没落实"的通话都沉在库里，业务方唯一的感知是"这个渠道打了没用"。加上之后，同样一批号码的转化提升了——不是因为 Agent 变强，是因为该被跟进的通话终于有人跟进。

回到最开始那句话：电话是对方随时会挂的窄带链路。把话说得像人只是入场券，真正决定能不能用的是接通判定、身份确认与结果回执。

完整版资料清单：本文用到的状态字段表、话术分段模板与回执结构都整理在里面了，扫码即可获取：

附表 A：关键取舍一览

取舍	本文结论	判断依据	位置
容量规划口径	按"并发话路 × 时长"算，不按 QPS	话路独占，排不上就是拨不出	第一章
开场长度	15 秒内说完自报、来意、退出	超时即被判定为机器人	第三章
录音告知位置	开场第一段，不后补	后补的告知无法证明已告知	第五章
状态粒度	未接通拆成七种，不合并	合并会污染拒绝率与重拨策略	第二章
状态写入方	只由信令侧写	话术侧写会与信令记录冲突	第二章
中途挂断	按接通时长分两类处理	秒挂与听完再挂的处置相反	第二章
空号与拦截	永久停拨并回写主数据	重拨只会加速被拉黑	第二章
身份确认	三档分级，对应不同信息暴露量	一档到底必然泄露或必然无效	第三章
非本人接听	整段跳过含具体信息的句子	改写等于让模型自由发挥	第三章
主体话术	每段以是否问题收口	长段无插话点，对方只能挂断	第四章
打断后恢复	按已覆盖段落续说，不重头念	重念开场白是第二大挂断原因	第四章
录音命名	只用 call_id，不带人名号码	号码+日期会互相覆盖	第五章
保留期	录音短、转写中、回执长	录音占九成存储且检索价值低	第五章
结论字段	枚举，不允许自由文本	自由文本会被下游当事实用	第六章
“再想想”	一律 pending，并强制填下次时间	模型天然把它归到肯定侧	第六章
拒呼名单查询点	拨号前，按人而非按号码	事后过滤等于已经打出去了	第七章
频次计数	跨号码按人合并	一人两号会被算成两次触达	第七章
上线第一步	内部号码 + 只做告知型	告知型不索取信息，错了损失可控	第七章
兜底形态	通话后的人工复核队列	实时坐席属于另一套系统	第七章

附表 B：术语速查表

术语	含义
话路	一条可承载单通电话的通道，独占使用，并发数有硬上限
摘机	被叫方接起电话，信令上表现为接通
振铃超时	已送出呼叫但对方未接，超过设定时长后判为无人接听
空号	运营商返回号码不可用，通常意味着号码已注销或错号
被拦截	呼叫被对方终端或拦截服务阻断，与空号在信令上可区分
中途挂断	接通后对方主动挂机，需按接通时长细分处置
弱标识	只有本人容易答出、泄露风险低的核对项，如单号后四位
强确认 / 弱确认	身份核对的档位，决定可以说多少具体信息
已覆盖段落	本通电话实际播报到的段落集合，用于续说与回执
拒呼名单	明确表示不再接受联系的名单，拨号前必须查询
频次闸门	对同一对象在时间窗内的触达次数上限
告知版本	录音与用途告知文本的版本号，随回执落库
结论枚举	回执中表示通话结果的固定取值集合，不接受自由文本
归一化结果	把对方原话转成结构化字段，允许为空，不允许猜

---

写在最后：这篇用到的资料

写这篇文章时，我把几个模型的官方文档、参数表和实测记录都对了一遍，顺手整理成几份配套的东西：

• 大模型学习路线图：从 LLM 基础到 Agent 开发，各阶段该学什么、用什么资料
• 大模型全套教程：按主题分好的视频与文档清单
• 大模型实战好书：24 本，附每本适合的阶段

资料是我自己整理的，放在下面这个码上，扫码即可获取：

添加时备注「大模型」，优先通过。

拿到之后建议先看学习路线图那一份，先定位自己在哪个阶段，再决定学什么，比一上来就啃框架效率高得多。