一篇具体实践记录。去年我们给西南一家连锁零售品牌（鲜花与礼品品类，几十家门店，已脱敏）做了一个面向 C 端的客服与到店预约智能体。这篇按"问题背景 → 具体实践 → 成果与思考"的顺序，讲清楚我们怎么用阿里云百炼的应用/智能体能力、函数计算和通义千问把它做出来，中间踩了什么坑。产品能力以阿里云官方文档为准。
一、问题背景：不是缺一个聊天机器人，是缺一个"接得住"的系统
客户原来的客服模式是总部几个人守着公众号和几个平台的私信，痛点很具体：
咨询高度重复——门店地址、营业时间、花礼推荐、配送范围、优惠券规则，占了七成；
高峰期接不住——节日前一周咨询量是平时的数倍，排队流失严重；
线索是断的——顾客在对话里说了"想要 99 朵红玫瑰、下周婚礼用"，这类高意向信息散落在聊天记录里，没人结构化跟进；
门店没有统一的知识出口——各店活动、库存情况不一样，客服只能转述，还经常说错。
客户最初的需求是"上一个 AI 客服"。我们调研后把问题重新定义为：需要一个以智能体为核心的承接系统——前接各渠道咨询，中间基于统一知识库准确应答，后连会员、预约和券系统，并且高风险动作（发券、退款）不能让模型自己决定。
明确验收指标也很重要，当时定了三条：高频问题的自助解决率、转人工会话的信息完整度、预约/留资到店的可追踪率。没有承诺任何夸张数字，先跑一个月拿基线。
二、具体实践
- 为什么选百炼起步，而不是从零搭框架
团队评估后决定第一版直接建在阿里云百炼上：通义系列模型可以直接调用，应用/智能体编排、知识库（RAG）、插件工具这些能力都是现成的，不用自己维护推理服务和检索集群。对一个需要快速验证、且 IT 人手紧张的客户来说，先跑通比架构"纯粹"重要。
但我们在第一天就立了一条工程规矩：业务系统只和我们自己的一层后端服务对话，不直接耦合任何平台的私有 SDK。百炼的智能体作为"大脑"，知识库和工具通过标准接口挂接。这层抽象后来被证明非常关键——第三期我们把部分能力迁移、换模型时，门店端和渠道侧完全无感。
- 知识库：总部统一出口，门店差异单独建模
这是工作量最大、也最值钱的一块。我们把知识分成三类处理：
通用知识：品牌介绍、花艺养护、配送与售后政策，由总部维护，进主知识库；
门店知识：各店地址、营业时间、电话、可服务范围，结构化成一张"门店表"，不切成自然语言段落——因为这类信息需要精确匹配和计算（比如"离我最近的店"），靠向量召回既不准也没法算距离；
活动与券知识：全部带生效时间和适用门店标记，过期内容由发布流程直接下线，不允许历史活动留在召回库里。
分段上踩过坑：最早图省事按固定字数切，售后条款被切成两半，模型经常只引用上半句。后来改成按条款和 FAQ 条目结构化切分，表格单独解析。提示词里强约束：只依据知识库回答，价格、活动、配送时效必须引用条目，查不到就明说并引导人工或留电话，并要求答案附引用。客服主管可以点开引用核对，业务侧才敢放它直接面对顾客。
我们同步建了评测集，从真实会话里挑了四十多条问法，覆盖"有标准答案的""容易混的（A 店活动套到 B 店）""知识库里没有的"三类。每次改分段、换通义模型版本、调提示词，全量回归一遍。
- 工具层：用函数计算承载智能体的"手"
智能体光会答没用，得能办事。我们把对业务系统的操作封装成工具（插件）挂到百炼应用上，工具的后端服务全部部署在函数计算（FC） 上。选 FC 的原因很直接：这些调用是事件驱动的、峰谷极其明显（节日前暴涨、平时很闲），按调用付费、自动弹性，比养一台常驻服务器划算，也省掉运维。
一共做了四个工具，按风险分级：
find_nearest_store（只读）：传入用户位置，查门店表算最近门店与距离，返回地址电话；
query_order（只读）：凭订单号查配送状态，无单号必须先问，禁止模型臆造；
create_booking（写入）：多轮收集收花人信息、用途、预算、送达时间，关键字段复述确认后，调预约系统下单，服务端做字段校验和幂等（同一顾客同日同场景不重复建单，防止模型重试产生脏数据）；
apply_coupon（半写入）：模型没有发券权限。顾客满足活动条件时，工具只生成一条"发券申请"，进审批队列，门店店长在企业侧应用点确认后券才到账。退款类诉求同理，一律生成工单转人工，智能体不做任何承诺。
所有工具共用一套规矩：独立的最小权限服务账号、入参在函数侧二次校验（手机号、金额、枚举值）、调用全留痕（谁、什么时间、传了什么、返回了什么）。模型生成的参数在我们这里永远被当作不可信输入。
一个简化的工具函数骨架（脱敏示意）：
python
部署在函数计算上的 create_booking 工具入口（示意）
def create_booking(params: dict) -> dict:
if not valid_phone(params.get("recipient_phone")):
return {"ok": False, "msg": "联系方式格式有误，请顾客重新确认"}
if not params.get("budget") or not params.get("deliver_time"):
return {"ok": False, "need": ["budget", "deliver_time"]} # 触发继续追问
# 幂等：同人同日同用途不重复预约
if booking_exists_today(params["recipient_phone"], params["purpose"]):
return {"ok": True, "dedup": True, "booking_id": latest_id()}
booking = booking_system.create(
store_id=params["store_id"], purpose=params["purpose"],
budget=params["budget"], deliver_time=params["deliver_time"],
channel=params["channel"], transcript_summary=params.get("summary", ""),
)
# 高客单（婚礼/企业订单）实时通知门店店长跟进
if booking.estimated_amount >= HIGH_VALUE:
notify_manager(booking)
return {"ok": True, "booking_id": booking.id}
- 编排：意图分流，而不是让一个提示词包打天下
早期版本我们试过把所有规则塞进一个超长系统提示词，结果节日前一压测就原形毕露：规则互相打架，模型在退款场景里时而坚定转人工、时而去"安抚性承诺"。
后来改成显式的意图分流结构：
plaintext
1
2
3
4
5
6
7
用户消息
├─ 门店/配送/产品咨询 → RAG 应答（带引用，无结果转人工）
├─ 查订单 → 身份确认 → query_order
├─ 预订/定制意向 → 槽位收集 → 复述确认 → create_booking
├─ 优惠诉求 → 规则校验 → apply_coupon（生成申请，店长审批）
└─ 退款/投诉/争议 → 直接转人工，附带会话摘要与已检索资料
模型（通义千问）负责意图判断和多轮槽位填充，确定性的规则（券能不能发、退款走什么流程）放在我们的代码里，不交给模型自由裁量。把"可裁量"和"不可裁量"分开，是这次编排上最大的教训。
- 可观测与兜底：出问题要能回放
每个会话我们都存了完整链路：意图判定、召回的知识条目、调用的工具与出入参、最终回复、耗时与 token 消耗。函数计算侧的调用日志集中收集，工具超时设了短超时和降级（查门店服务异常时直接返回人工兜底话术，而不是转圈）。
转人工通道是一等公民：连续两轮意图置信度低、命中投诉/医疗相关敏感词、或用户明确要求人工，立即转接，并把结构化摘要一起带给客服——人工接手时看到的是"顾客是谁、要什么、已经聊到哪一步"，而不是从头问起。
- 数据回流：让智能体反哺经营
这部分是客户后来评价最高的。所有预约和留资都带渠道来源，沉淀回客户自己的会员/CRM 体系后，可以回答以前答不了的问题：哪个内容渠道进来的婚礼单多？哪类咨询转人工最多（说明知识库有缺口）？哪些券申请店长驳回率高（说明活动规则设计有问题）？
每周我们把三类数据整理回流：答不上来的问法补知识库，badcase 补评测集，高意向会话特征反馈给内容团队做选题。智能体不是一个孤立的客服工具，而是卡在"流量 → 咨询 → 预约 → 到店"链路上的数据节点。
三、成果与思考总结
项目跑了几个月，可以讲的不是某个夸张数字，而是几条被验证的工程判断：
智能体项目的瓶颈在知识和系统，不在模型。 我们花在资料治理、门店数据结构化上的时间，远超调模型的时间；效果提升也主要来自前者。
工具一定要分级，函数计算很适合这种峰谷型工具后端。 只读放开、写入校验加幂等、发券退款必须人工审批——这条红线一次都没破过，客户的财务和门店运营才敢真正用起来。
确定性规则写进代码，别写进提示词。 意图和对话交给模型，权限和流程交给工程，两者混在一个大 prompt 里迟早出事。
先平台验证、留好抽象层，后续不返工。 百炼让第一版几周内上线；因为业务侧只依赖我们自己的服务接口，后续无论换模型、加本地部署还是调整工具实现，门店和渠道都无感知。
上线只是开始。 知识更新机制、评测集回归、转人工会话复盘、门店培训，这些写进了交付合同的运营动作，才是系统几个月后还在正常运转的原因。
顺带说一句边界：这类实践适合标准化程度高的消费场景。医疗、金融等强监管领域的深度业务，需要更严格的合规与资质，不能照搬这套打法，非核心的辅助场景也要在合规前提下谨慎推进。
如果要给同类项目一句话建议：别急着做"全能员工"，先挑一个离成交最近、规则最清晰的场景，把知识、工具权限和回流链路做扎实，比什么都强。
作者：昆明一支企业 AI 落地工程师团队（奇崛 AGI 研究院），做大模型部署、RAG、行业 Agent 与企业内训，在阿里云、腾讯云、火山引擎、智谱等生态上落地。本文为脱敏实践记录，百炼、函数计算、通义等具体能力与参数请以阿里云官方文档为准。
