系统设计

🧠 一、设计一个企业智能客服 Agent

1.1 业务目标与核心挑战

企业智能客服不只是“问答机器人”，它需要：

• 理解企业私有知识（产品文档、FAQ、工单历史）

• 执行操作（查询订单、退换货、转人工）

• 多轮对话中保持上下文，控制幻觉

• 支持多渠道（Web、企微、钉钉）接入，且答案可审计

1.2 整体架构（四层模型）

┌─────────────────────────────────────────────┐
│              接入层 (Gateway)                 │
│   WebChat / 企微 / API  统一鉴权 & 限流       │
└──────────────────┬──────────────────────────┘
                   ▼
┌─────────────────────────────────────────────┐
│           对话编排层 (Agent Core)             │
│  ┌─────────┐ ┌──────────┐ ┌──────────────┐  │
│  │ 意图识别 │ │ 路由决策  │ │ 多轮对话管理 │  │
│  └────┬────┘ └─────┬────┘ └──────┬───────┘  │
│       └────────────┼─────────────┘           │
│                    ▼                         │
│  ┌──────────────────────────────────────┐    │
│  │        安全护栏 (Guardrails)          │    │
│  │   敏感词过滤 / 越狱检测 / 事实核查     │    │
│  └──────────────────────────────────────┘    │
└──────────────────┬──────────────────────────┘
                   ▼
┌─────────────────────────────────────────────┐
│            能力层 (Tools & Skills)            │
│  ┌──────┐ ┌──────┐ ┌──────┐ ┌───────────┐  │
│  │知识库│ │订单API│ │FAQ检索│ │人工转接    │  │
│  │ RAG  │ │调用  │ │      │ │(排队/路由)│  │
│  └──────┘ └──────┘ └──────┘ └───────────┘  │
└──────────────────┬──────────────────────────┘
                   ▼
┌─────────────────────────────────────────────┐
│          数据层 (Memory & Knowledge)          │
│  ┌────────┐ ┌────────┐ ┌────────────────┐   │
│  │对话历史│ │向量知识│ │业务数据库 (订单) │   │
│  │Redis   │ │Milvus │ │ MySQL / PG     │   │
│  └────────┘ └────────┘ └────────────────┘   │
└─────────────────────────────────────────────┘

1.3 核心技术选型与要点

查看内嵌表格

1.4 流程示例（退货场景）

1. 用户：“我买的打印机坏了，要退货”

2. 意图识别 → return_order，提取实体（商品：打印机）

3. Agent 调用订单 API 查最近订单（Tool），确认商品和日期，生成确认卡片：“是您 5 月 20 日购买的 HP 打印机吗？”

4. 用户确认，Agent 调用退货 API 创建退单，返回运单号和预计上门取件时间。

5. 整个会话以结构化卡片呈现，系统记录完整轨迹。

企业客服 Agent 的本质不是“让 AI 代替人”，而是 让 AI 处理标准、重复的流程，把人解放出来处理复杂共情。因此设计中我花最多精力的是安全护栏和转人工的平滑衔接——这才是企业信任 AI 客服的底线。

---

🔬 二、设计一个 Deep Research Agent

2.1 业务定义

Deep Research Agent 需要能接受一个开放研究主题（如“量子计算在药物研发中的应用前景”），自动进行：

• 分解子问题

• 搜索并阅读多源信息（网页、论文、数据库）

• 分析、对比、综合

• 生成带引用的研究报告（万字级别）

这已不是简单的 RAG，而是一个 多步推理 + 工具使用 + 长期记忆 的自主智能体。

2.2 核心架构：Plan-Execute-Reflect 循环

2.3 各组件设计细节

① 规划器（Planner）

• 输入：研究主题 + 用户要求（字数、风格、领域）

• 输出：多级大纲树，每个叶子节点是一个待研究的子问题

• 技术：用 GPT-4o 或 Claude 的结构化输出能力，生成 JSON 大纲。示例：

{
  "title": "量子计算在药物研发中的应用前景",
  "sections": [
    {"heading": "背景", "sub_questions": ["量子计算基本原理", "传统药物研发痛点"]},
    {"heading": "应用场景", "sub_questions": ["分子模拟", "蛋白质折叠", "药物筛选"]}
  ]
}

• 可人工干预修改大纲，然后确认执行。

② 执行器（Executor）— 最复杂的部分

每个子问题执行流程：

• 搜索：调用 Tavily / Google Search API，同时查询学术数据库（Semantic Scholar、arXiv），获取 URL 列表。

• 浏览与提取：用 Playwright 或 Jina Reader 获取网页正文，LLM 提取关键信息和数据点，形成结构化笔记（包含来源 URL、引用片段）。

• 工具扩展：涉及数据计算时，可调用 Python REPL 执行分析；涉及实体关系，可查询知识图谱（如 Wikidata）。

• 并行控制：无依赖的子问题可并发执行，但需限制并发数（防止 API 限流和成本爆炸）。使用任务队列（如 Celery）管理。

③ 反思器（Reflector）

• 检查每个子问题是否已收集到“足够高质量”的信息。标准：至少 N 个独立来源，信息一致性高，无重大空白。

• 若不足，生成补充搜索查询，返回执行器再次搜索，设置最大重试次数（如 2 次） 避免死循环。

• 反思过程中 LLM 还会标记“信息冲突”，提醒撰写器注意。

④ 撰写器（Writer）

• 按大纲顺序，将每个部分的笔记草稿整理成连贯段落，并插入引用标记（如 [1]、[2]）。

• 采用分层撰写：先生成各小节，再合成大节，最后写引言和总结，保证整体连贯。

• 引用链接自动附在文末，来源有效性可追溯。

• 可选的“批判性检查”：让另一个 LLM 角色对报告草稿进行质疑，修正夸大或错误陈述。

2.4 关键非功能需求

• 长上下文管理：研究笔记可能极长，使用向量数据库存储笔记，撰写时动态检索相关片段而非全量塞入 Prompt。

• 成本控制：设置单次研究最大 Token 预算（如 10M），达到上限后自动总结已得信息生成简要报告，避免天价账单。

• 人类在环（Human-in-the-loop）：大纲确认、重要关键信息提取（如专利号）、最终报告均可设置人审节点，提高可靠性。

• 可复现性：所有搜索 query、浏览 URL、提取结果均日志落盘，研究过程可回放、可审计。

2.5 技术栈选型

查看内嵌表格

Deep Research Agent 不是简单的“多步 RAG”，它是一个 自主研究流水线。设计中我特别强调人类在环和成本边界——因为研究型任务往往有很长链条，不加控制的自主行为很容易变成昂贵的随机漫步。

真正的挑战在于“什么时候该停”——反思器不仅要判断信息是否足够，还得学会接受“当前证据下最优答案”，这本身就是一门需要工程和产品共同打磨的艺术。

---