业务Agent设计
业务Agent设计
本文是 业务Agent介绍 之前做的一些设计，聚焦「智询」的方案设计：业务能力如何划分、应用与数据如何分层设计、技术栈如何落地、Agent 运行时如何闭环。
一、落地主线
业务 Agent 不宜一上来做成「万能助手」。智询的落地路径是：先选高频可标准化场景 → 沉淀技能与工具 → 打通编排与人机兜底 → 再横向复制到相邻业务域。
实践上可按三条线并行推进：
| 主线 | 做什么 | 验收信号 |
|---|---|---|
| 场景线 | 登录 / 支付 / 风控等高频事件先跑通 | 自动完结率、转人工率、平均响应时长 |
| 能力线 | 意图、检索、工具、权限、审计可复用 | 新场景接入以「技能包」方式交付，不推翻主链路 |
| 治理线 | 脱敏、权限、观测、评测 | 每次调用可回溯；无工具支撑时能明确降级 |
设计原则可以压缩成一句话：能查的先查清，能办的带确认，不能办的说清楚并转人。
二、业务架构设计
业务架构回答的是：服务谁、解决什么问题、能力落在哪些 Agent 上，以及底层依赖哪些企业数据与保障体系。
自上而下可以读成四层：
1. 价值层
对齐业务结果，而不是对齐「调了多少次模型」。降本增效、交付提速、质量与稳定性、决策智能化，都是后续评测与迭代的尺子。
2. 应用层（智能体阵列）
按业务域拆 Agent，而不是做一个超级 Bot：
| Agent | 典型能力 | 对应真实场景（介绍文） |
|---|---|---|
| 登录认证 Agent | 认证知识查询、日志分析、业务问题处理 | 改密仍失败、登录锁关不了、扫码登录异常 |
| 支付业务 Agent | 支付知识、日志分析、补单、退款问题 | 充错区/充错号、退款、开票 |
| 部门业务对接 Agent | 能力查询、对接指导、异常排查 | 跨部门口径对齐、接入方联调 |
| 风控 / 财务 / 前端等 | 按需扩展 | 风控次数、短信受限、客户端自检 |
同一条用户话术，先路由到业务域 Agent，再在域内做工具编排，比「一个大 Prompt 包打天下」更容易控权限、做评测、做演进。
3. 能力层（AI Agent 核心引擎）
意图理解 → 知识检索 → 推理决策 → 工具调用 → 工作流编排 → 学习优化。上层各业务 Agent 共用这套引擎，差异主要在技能包、工具集与权限策略。
4. 数据层 + 保障体系
认证 / 支付 / 风控 / 社区 / 计费等业务数据经治理与集成后，才进入 Agent 可用范围；右侧的安全、权限、监控、持续优化，保证「能用」之外还能「敢用、可运营」。
三、应用架构设计
应用架构把业务能力落成可部署的模块：入口在哪、请求怎么进、任务怎么调度、运行时做什么、状态落哪里。
建议按「自上而下读请求、自下而上看依赖」的方式理解：
渠道入口
Vue 工作台、飞书 / 内部聊天、商城、工单系统——同一套编排能力，多入口接入，避免每个渠道各写一套机器人。
网关层
负载均衡、FastAPI 接入、SSE 流式回写、LLM Gateway（模型路由）。流式回写很关键：排查类任务往往多步调用，用户需要看到「正在查锁状态 / 正在检索规则」而不是长时间白屏。
编排调度层
服务治理（限流、会话锁、幂等）+ Agent Run Queue + Worker + 事件流。长任务进队列，避免同步接口被工具调用拖死；会话锁与幂等则防止「同工单连点两次 → 重复写操作」。
Agent 运行时
意图理解 / 规划路由、Memory、能力与工具（沙箱执行）、权限控制。这是业务差异最大的一层，也是下一章「运行时设计」展开的重点。
数据访问与持久化
RAG 检索、Checkpoint、会话 / 长期记忆、评测投递；底层 PostgreSQL、Redis、向量索引、Langfuse。左右两侧的配置中心与注册中心，支撑 Prompt / Skill / Worker / Tool 的动态发布与发现。
一句话概括：网关管入口形态，队列管吞吐与可靠，运行时管智能，存储与观测管可运营。
四、数据架构设计
Agent 再聪明，没有干净、可授权、可追溯的数据，也只能「猜」。数据架构解决的是：数据从哪来、怎么清洗、怎么流转、怎么被 Agent 安全消费。
六层分工可以记成：
| 分层 | 职责 | 对 Agent 的意义 |
|---|---|---|
| 数据应用层 | AI Agent、风控、BI、运营等消费方 | Agent 是应用之一，不是旁路脚本 |
| 数据服务层 | API 网关、数据 / 标签 / 指标服务 | 工具调用走服务，而不是直连生产库 |
| 数据开发层 | ETL、建模、调度、质量、血缘 | 保证口径一致、可追溯 |
| 数据资产层 | ODS → DWD → DWS → ADS + 标准 / 元数据 | 查类问题优先打 ADS / 指标，少扫明细 |
| 数据集成层 | 批 / 流 / API / 文件 / MQ | 覆盖日志、工单、文档、业务库等多源 |
| 数据存储层 | 湖仓、缓存、向量库、图库 | RAG、会话、图谱能力的底座 |
和智询场景强相关的几条落地约定：
- 知识类问题（开票、退款政策、接入规范）走向量检索 + 权威文档，回答需可引用。
- 状态类问题（登录锁、风控次数、短信是否受限）走业务 API / 指标服务，禁止用过期文档「猜状态」。
- 写操作（加风控次数、关锁）必须鉴权、审计，并默认「建议 + 确认」或转人工。
- 脱敏与最小权限：日志、手机号、账号等进入 Prompt / Trace 前先脱敏；工具按角色开放。
五、技术架构设计
技术架构把应用分层映射到具体技术选型与部署边界，方便研发落地与横向扩展。
分层要点：
展示层
Web 工作台、IM、工单、Open API（含 SSE 客户端），覆盖「图形化界面」和「系统对接」两类入口。
通讯层
ALB / Nginx、HTTPS、SSE、可选 WebSocket。Agent 对话与工具执行进度优先 SSE，兼容现有 HTTP 体系。
服务层（核心）
- 接入：FastAPI / SSE Gateway
- 业务集群：Agent Worker、业务 Service、MCP Server、RAG 服务
- 保护：链路追踪、队列监控、安全沙箱
- 治理：注册中心、限流降级与幂等、Prompt / Skill 配置
- 异步：Run Queue、Redis 会话锁、评测队列、模型服务（如 DeepSeek / Qwen）
数据层
PostgreSQL（主数据与 Checkpoint）、Redis（会话）、向量索引（RAG）、Langfuse（Trace / Score）。
选型上刻意保持「薄接入、厚编排」：渠道只负责收发；智能集中在 Worker + 工具网关；观测与评测从第一天就进主链路，而不是事后补日志。
六、Agent运行时设计
运行时回答一次请求在进程内如何被「理解 → 规划 → 行动 → 反思」地跑完，以及技能、工具、记忆、环境如何协作。
可以按「外层输入 / 中环决策 / 下挂能力 / 底座支撑」来读：
输入理解（感知）
意图、实体、上下文、视觉 / OCR、历史、外部事件。客服话术往往口语化且夹账号、手机号、区服，槽位抽取质量直接决定后面工具能不能点对。
核心运行（ReAct 循环）
Observe → Think → Plan → Act → Observe → Reflect，直到任务完成或触发降级。配套状态、上下文、记忆、自检、错误处理、成本与日志，避免「调了工具却不校验结果」或「死循环烧 Token」。
智能大脑（LLM）
模型路由（按任务 / 成本 / 性能）、推理引擎（理解 / 推理 / 规划 / 决策 / 生成 / 反思）、提示词工程（系统提示、场景模板、Few-shot、动态优化）。查类与办类可以走不同模型或不同温度策略。
技能 · 工具 · 环境
- Skills：业务技能包（登录排查、支付补单、风控查询等）
- Tools：工具网关（鉴权、限流、日志、重试）+ MCP / 函数调用 + 执行沙箱
- Environment：文件系统、Shell、数据库、浏览器、外部服务
工具一律经网关，写操作进沙箱与权限闸门——这是业务 Agent 与「Demo 聊天机器人」的本质差别。
记忆与基础设施
短期 / 长期 / 向量 / 结构化 / 企业知识库 / 工作记忆，配合模型、向量库、关系库、对象存储、缓存、MQ、监控与日志，支撑可恢复、可审计、可扩展。
七、小结
智询的设计可以收束为四句话：
- 业务上按域拆 Agent，价值对齐可量化结果。
- 应用上多入口统一编排，队列化执行，配置与注册可动态演进。
- 数据上湖仓分层 + 服务化供给，知识走检索、状态走 API、写操作强审计。
- 运行时上ReAct 闭环 + 工具网关 + 人机降级，保证「提效」与「可控」同时成立。