案例 01：企业官网智能客服 Agent（智能体）
项目背景
官网客服的典型痛点是重复问题多、响应不稳定、人工值守成本高。这个项目适合从常见问题开始做，不急于处理所有售后和订单问题。
客户表面上要的是“自动化”，真实目标通常是减少重复劳动、降低遗漏、统一标准和保留追溯证据。这个案例属于“客服与售后”场景，重点讲制作方法和交付边界。本案例通过制作方法、交付边界和可验证证据，说明如何完成该场景。
目标用户
- 官网访客
- 售前客服
- 售后客服
- 运营负责人
典型输入
- 访客问题
- 所在页面
- 产品或服务类别
- 可选的订单号或联系方式
期望输出
- 带依据的回答
- 转人工原因
- 工单草稿
- 用户问题分类和风险等级
资料清单
- 官网页面、产品介绍、价格说明、服务条款、售后规则、FAQ（常见问题）、历史客服对话
推荐技术流
推荐组合：
- 聊天入口或客服工作台。
- FastAPI（后端接口框架） Agent（智能体）服务。
- 企业知识库 RAG（检索增强生成）。
- 订单和工单只读工具。
- 人工转接与质检日志。
- Trace ID（追踪编号）全链路追踪。
案例专用工具：
- 知识库检索工具
- 订单状态只读查询工具
- 工单创建工具
- 人工转接工具
为什么这样选：
- 客服问题必须有资料依据，RAG（检索增强生成）能减少编造。
- 订单、工单等业务动作需要受控工具，不能让模型直接写系统。
- 高风险售后、退款、投诉要转人工，日志能支持质检和复盘。
对“案例 01：企业官网智能客服 Agent（智能体）”来说，这条技术流的价值是先证明“官网访客提出产品、价格、售后问题时自动回答，并在高风险问题上转人工。”这条业务闭环能被解释和验收。真实开发时先做 Mock（模拟）模式和字段契约，再逐步接入真实模型、真实资料和真实业务系统。
Agent（智能体）角色设计
在“案例 01：企业官网智能客服 Agent（智能体）”里，Agent（智能体）的任务不是替业务人员做最终决定，而是围绕“官网访客提出产品、价格、售后问题时自动回答，并在高风险问题上转人工。”整理输入、依据、风险和下一步动作，让人能复核后再执行。
核心任务：
- 理解用户输入和业务上下文。
- 从资料、表格、系统或历史记录中找到依据。
- 生成结构化结果，方便前端、表格或业务系统读取。
- 在资料不足、权限不足或风险较高时拒答、降级或转人工。
工具与系统接口
- 知识库检索工具
- 订单状态只读查询工具
- 工单创建工具
- 人工转接工具
本案例的接口先从只读和草稿能力做起；凡是会改变业务事实、发送消息或触发审批的动作，都必须加权限校验、日志和人工确认。
权限与风险边界
- 不编造价格和交付周期
- 不自动承诺退款、赔付或合同条款
- 没有资料依据时拒答或转人工
制作步骤
- 清洗官网和 FAQ（常见问题）资料，删除过期资料。
- 把问题分成产品咨询、价格咨询、售后、投诉、合作和未知。
- 建立知识库检索和引用规则。
- 设计转人工和创建工单的条件。
- 用 50 条历史咨询做验收样例。
- 上线后按失败问题补充资料。
字段契约与配置说明
本案例不放完整代码，只说明实现时需要稳定下来的字段和配置。
| 类型 | 建议字段 | 说明 |
|---|---|---|
| 输入字段 | 用户问题、业务对象、时间范围、身份权限 | 用来确定上下文和可访问资料 |
| 输出字段 | 摘要、依据、置信度、风险等级、下一步动作 | 用来给前端、表格或业务系统读取 |
| 日志字段 | 请求编号、用户、工具调用、资料来源、人工确认状态 | 用来复盘质量和排查问题 |
| 配置项 | 模型供应商、知识库范围、工具权限、转人工规则 | 用来控制成本、权限和安全边界 |
验收标准
- 常见问题回答准确且能给出来源。
- 投诉、退款、账号、合同问题能转人工。
- 每次回答都有对话和工具调用日志。
通用验收还包括：无资料依据时不编造，高风险动作需要人工确认，日志能追溯输入、资料、工具调用和输出。
报价与工期参考
- 轻量版本：1-2 周，适合资料少、接口少、只做内部试点。
- 标准版本：2-4 周，包含资料整理、智能体流程、工具接口、日志和验收样例。
- 增强版本：4-8 周以上，包含权限、前端工作台、多系统接入、监控和多轮迭代。
报价“案例 01：企业官网智能客服 Agent（智能体）”时，不能只按页面数量或模型调用次数估算；还要把样例资料整理、客户访谈、验收样例、上线培训和后续维护计入成本。
常见风险
- 官网资料过期导致错误回答。
- 访客把智能体回答当正式合同承诺。
- 客服系统接口权限未开放。
面试官可能追问与参考回答
1. 你为什么给“企业官网智能客服 Agent（智能体）”选择这条技术流？
参考回答： 我会先说明这个项目的业务目标是“官网访客提出产品、价格、售后问题时自动回答，并在高风险问题上转人工”，所以技术上优先选择 聊天入口或客服工作台、FastAPI（后端接口框架） Agent（智能体）服务、企业知识库 RAG（检索增强生成）。原因是这套路线能把资料依据、业务流程、工具调用、人工确认和日志追踪放在同一个交付闭环里。面试时不要只说“用了大模型”，要强调它如何降低编造、越权和不可追溯风险。
2. 这个项目里 Agent（智能体）、Workflow（工作流）和 RAG（检索增强生成）怎么分工？
参考回答： 在“案例 01：企业官网智能客服 Agent（智能体）”里，Workflow（工作流）负责把“官网访客提出产品、价格、售后问题时自动回答，并在高风险问题上转人工。”拆成稳定步骤；RAG（检索增强生成）负责找资料依据；Agent（智能体）负责理解输入、组织上下文、选择工具并生成结构化结果。这样回答比只说“接了模型”更能体现工程分工。
3. 如果 知识库检索工具 调用失败，你怎么处理？
参考回答： 我会把“知识库检索工具”失败当成正常分支，而不是异常崩溃。系统要记录 Trace ID（追踪编号）、工具名称、输入摘要和错误原因；对用户输出可理解的降级结果；如果影响“官网访客提出产品、价格、售后问题时自动回答，并在高风险问题上转人工。”，就转人工或生成待处理任务。
4. 这个项目最大的风险是什么？
参考回答： 我会先说风险是“官网资料过期导致错误回答”，然后说明防线：资料来源要治理，输出要引用依据，高风险动作要人工确认，日志要能复盘。再补一句：如果上线后发现误判，会把失败样例加入验收集，更新规则和提示词，而不是只调模型参数。
5. 为什么边界里要写“不编造价格和交付周期”？
参考回答： 因为本案例明确存在“不编造价格和交付周期”这类限制。边界写出来，是为了把建议、草稿、人工确认和禁止动作分清楚，避免把模型输出误当成最终业务承诺。
6. 你会怎么验收这个项目？
参考回答： 我会用业务样例验收，而不是只看页面能不能打开。核心验收包括：常见问题回答准确且能给出来源；无资料依据时不编造；高风险动作能转人工；每次输出能追溯资料、工具调用和人工确认。这样能把模型效果变成可交付标准。
7. 如果面试官问你做过没有完整源码的项目，怎么回答？
参考回答： 我会把“案例 01：企业官网智能客服 Agent（智能体）”定位为作品集方案和演示项目，不包装成完整生产经历。讲解时围绕“官网访客提出产品、价格、售后问题时自动回答，并在高风险问题上转人工。”展开：需求来源、技术流、字段契约、工具边界、验收样例和下一步实现计划。
可扩展方向
- 客服质检
- 销售线索识别
- 热点问题看板
- 多渠道接入
交付物清单
- 需求范围说明。
- 资料清单和权限说明。
- 智能体角色、提示词和工具清单。
- 字段契约和转人工规则。
- 验收样例和测试记录。
- 上线说明、运维说明和后续迭代清单。
相关术语
- AI Agent（人工智能体）
- Workflow（工作流）
- Prompt（提示词）
- Structured Output（结构化输出）
- Guardrail（护栏）
- Trace ID（追踪编号）
- RAG（检索增强生成）
本案例差异化制作提示
这个案例的项目特色是：官网访客即时答疑。做成作品集时，不能只套通用 Agent（智能体）页面，要把这个特色做成首屏可见的证据。
| 维度 | 本案例要特别做出来的东西 |
|---|---|
| 首屏重点 | 必须展示来源引用、风险转人工和页面来源上下文 |
| 样例资料 | 至少准备 5 条正常样例、3 条边界样例、2 条失败样例，让 Codex（智能编程代理）能演示不同分支。 |
| 最容易扣分 | 只做一个聊天框，看不出官网资料、服务条款和转人工边界。 |
| 面试讲法 | 先讲业务目标，再讲为什么这个案例不能只靠聊天框，最后讲资料、工具、权限、日志和验收如何支撑。 |
给 Codex（智能编程代理）的补充提示词：
请检查这个案例是否体现“官网访客即时答疑”的项目特色。不要只做通用聊天页面。请补充：首屏证据、样例资料、失败分支、日志字段、人工确认点和 1 分钟面试演示路线。
Codex（智能编程代理）提示词驱动制作流程
通用的空文件夹启动、修复和验收方法见：Codex（智能编程代理）从空文件夹到成品。本案例只保留需要替换进提示词的业务差异，避免每个案例重复同一套教程。
1. 本案例最小闭环
| 要素 | 本案例写法 |
|---|---|
| 项目目录 | case-01-agent |
| 业务目标 | 官网访客提出产品、价格、售后问题时自动回答，并在高风险问题上转人工。 |
| 首屏证据 | 必须展示来源引用、风险转人工和页面来源上下文 |
| 样例资料 | 至少准备 5 条正常样例、3 条边界样例、2 条失败样例，让 Codex（智能编程代理）能演示不同分支。 |
| 最容易扣分 | 只做一个聊天框，看不出官网资料、服务条款和转人工边界。 |
2. 项目启动提示词
复制下面这条给 Codex（智能编程代理），先让它输出方案和文件结构，不要立刻铺大功能：
你是我的 AI Agent（人工智能体）项目搭建助手。我要从空文件夹开始做一个“案例 01：企业官网智能客服 Agent（智能体）”作品集项目。请先从项目规划开始，帮我完成项目理解和制作计划。
项目目标：官网访客提出产品、价格、售后问题时自动回答，并在高风险问题上转人工。
本案例的首屏重点：来源引用、风险转人工和页面来源上下文
样例资料：至少准备 5 条正常样例、3 条边界样例、2 条失败样例，让 Codex（智能编程代理）能演示不同分支。
容易扣分的做法：只做一个聊天框，看不出官网资料、服务条款和转人工边界。
约束：不要讲代码语法，不要一次性生成大而全系统，先做最小可运行版本。
请输出：业务流程、核心页面、样例数据、字段契约、失败分支、第一轮文件结构和验收标准。
3. 最小可运行版本提示词
第二条提示词只要求 Codex（智能编程代理）实现能演示的闭环：
请按刚才的计划，只实现“案例 01：企业官网智能客服 Agent（智能体）”的最小可运行版本。
最小版本必须包含：一个可打开的页面、一个主要输入入口、一组样例数据、一次 Agent（智能体）处理结果、一个依据或日志展示区域、一个失败或转人工提示。
首屏要展示：来源引用、风险转人工和页面来源上下文
暂时不要接真实企业系统，不要做复杂登录，不要做完整权限中心。
完成后请告诉我：如何启动、如何演示、哪些地方是 Mock（模拟）模式、下一轮应该补什么。
4. 成品验收
- 页面能打开，主样例能跑通。
- 输出能解释依据、风险和下一步动作。
- 至少有一个失败或高风险样例，证明系统不会盲目回答。
- 面试时按这个顺序讲：先讲业务目标，再讲为什么这个案例不能只靠聊天框，最后讲资料、工具、权限、日志和验收如何支撑。