对客 AI Agent 平台建设思路

Mon, 09 Feb 2026 00:00:00 +0000

内部效率类的 AI 应用怎么做都不算太难，做错了也就是员工少用几次。对客不一样：一句话说错可能就是投诉、监管问询甚至赔付。这篇记录我们做对客 Agent 平台时的思路，重点不在模型，在约束。

对客场景的特殊约束

先把约束写清楚，架构自然就出来了。

不能瞎说。产品收益率、费率、期限这类数字，只要模型自由生成就一定会出错。这类回答必须来自系统数据，不能来自模型记忆。
不能越权。查余额要认证到本人，代客操作要有明确授权链路。Agent 调用工具时的身份必须是真实用户身份，不是服务账号。
要能复盘。每一次对话的输入、检索命中、工具调用、最终输出都要能查到，而且要留存到合规要求的期限。
延迟有上限。用户在 App 里等超过三秒基本就退出了。多轮反思、多次检索这些提升准确率的手段，成本是延迟。
要能降级。模型服务不可用时，必须能退回到规则问答或人工客服，不能白屏。

对客 Agent 的技术难点不是让它更聪明，而是让它在不确定的地方老实承认不知道，并且把用户交给正确的下一环节。

平台分层：从模型到业务

我们最后落在四层。分层的目的很实际：业务方只关心自己那层，不用理解底下的模型细节。

网关层

统一的模型接入层，屏蔽底层模型差异。做三件事：

多模型路由与降级（主模型超时自动切备用模型）
配额与限流（按业务方、按用户维度双重限流）
计费与用量统计（按 token 归集到业务方成本中心）

这一层不允许有任何业务逻辑。它唯一的职责是让上层调用模型像调用一个稳定的内部服务。

编排层

Agent 的运行时。定义一个 Agent 需要：系统提示词、可用工具集、知识库范围、护栏规则、降级策略。我们用配置描述而不是写代码，业务方在控制台就能改提示词并灰度发布。

agent:
 code: retail-product-consult
 name: 零售产品咨询助手
 model:
 primary: qwen-max
 fallback: internal-7b
 temperature: 0.2
 timeout_ms: 2500
 autonomy: tool_calling  # 可选 qa_only / tool_calling / multi_step
 max_steps: 3
 knowledge:
 collections: [product-manual, faq-retail]
 top_k: 5
 min_score: 0.62
 tools:
 - code: query_product_rate
 auth: user_token  # 以真实用户身份调用
 - code: query_my_balance
 auth: user_token
 require_mfa: true
 guardrail:
 input: [prompt_injection, sensitive_topic]
 output: [pii_mask, number_grounding, disclaimer_append]
 fallback:
 on_model_error: rule_based_faq
 on_low_confidence: transfer_human

工具层

工具就是被包装成模型可调用形式的业务接口。我们的规范是：工具必须是幂等查询，或者是带确认步骤的操作。没有确认步骤的写操作一律不开放给 Agent。

银行 on 追风笔记

对客 AI Agent 平台建设思路

对客场景的特殊约束

平台分层：从模型到业务

网关层

编排层

工具层