Agent应用概要
大模型应用设计就是将 LLM 作为核心大脑，通过 RAG 获取知识，通过 Tools 执行动作，由 Agent 进行自主决策，并用 Workflow 编排复杂流程。
Agent如何处理用户一次请求
1. 请求接收与解析
-
功能：接收用户输入（文本、语音、文件等），进行格式标准化
-
操作：
-
如果是语音，转文字（ASR）
-
如果是文件，提取文本内容
-
解析消息中的附件、元数据（如用户ID、会话ID）
-
-
输出：结构化的请求对象
2. 安全与合规检查
-
功能：确保请求内容安全，符合使用政策
-
操作：
-
内容过滤：检测并拦截恶意提示（prompt injection）、敏感信息、违法内容
-
权限验证：确认用户是否有权限执行该操作
-
速率限制：检查是否超过调用频率限制
-
成本控制：预估本次调用可能消耗的token，与预算限制对比
-
-
输出：通过/拒绝/降级处理
3. 上下文构建
-
功能：组装当前会话的上下文信息
-
操作：
-
加载系统提示词（system prompt）：定义Agent的角色、能力边界、行为准则
-
加载会话历史：最近N轮对话（通常从数据库或缓存中读取）
-
加载用户画像：用户的偏好、历史行为、权限级别
-
加载当前状态：Agent正在执行的任务状态、未完成的步骤
-
-
输出：包含系统设定+历史+用户画像的上下文对象
4. 记忆检索
-
功能：从长期记忆中检索相关信息（区别于会话历史）
-
操作：
-
向量检索：将用户请求向量化，在向量数据库中检索相关记忆
-
语义搜索：检索历史对话中的关键信息（如用户之前提到的偏好、长期目标）
-
知识库检索：如果需要专业知识，提前准备RAG检索（但这里只是规划，实际检索可能稍后触发）
-
-
输出：检索到的相关记忆片段
5. 路由决策
-
功能：决定本次请求的处理方式（这是Agent架构的关键环节）
-
操作：
-
意图识别：判断用户意图（简单问答？复杂任务？需要工具调用？）
-
模式选择：
-
简单问题 → 直接调用LLM回答
-
需要专业知识 → 标记需要RAG
-
复杂任务 → 进入Agent循环
-
工具调用 → 准备Function Calling
-
-
模型选择：根据任务复杂度选择不同模型（如快速模型vs高级推理模型）
-
-
输出：处理策略（包含是否进入Agent循环、是否需要工具、使用哪个模型）
6. Prompt工程
-
功能：将上述所有信息组装成最终的prompt
-
操作：
-
将系统提示词、记忆、历史、用户请求、可用工具列表等按格式拼接
-
如果是Function Calling模式，附加工具定义（JSON Schema）
-
如果是ReAct模式，附加推理示例（few-shot examples）
-
进行token计数，如果超限则进行摘要压缩或滑动窗口截断
-
-
输出：完整的prompt（准备送入LLM）
实例：
假设用户请求：“帮我总结最近3天关于AI的新闻，并整理成邮件发给 team@company.com”
预处理流程：
-
请求解析：识别出这是一条文本消息
-
安全检查：无恶意内容，用户有邮件发送权限
-
上下文构建：加载系统提示词（“你是一个智能助理...”），加载最近5轮对话历史
-
记忆检索：从向量数据库中检索到用户之前提到“关注AI领域”的偏好
-
路由决策：
-
意图识别为“复杂多步任务”
-
需要调用工具（新闻检索 + 邮件发送）
-
进入Agent模式，选择高级推理模型（如GPT-4）
-
-
Prompt工程：
-
组装包含工具定义的prompt（新闻API、邮件API）
-
加入few-shot示例展示如何使用工具
-
token计数：约2500 tokens，在限制内
-
-
调用LLM：发送prompt，等待模型输出（通常会输出“调用新闻检索工具”的指令）
7.多Agent应用
单Agent容易造成的问题：
- 上下文混杂：它分不清"TAPD 里写的"和"它自己推断的"
- 天然缺乏制衡：它写的方案它自己审，几乎不会否决
- 倾向往前推进：它会主动找理由说"问题不大，继续吧" 。 Agent 不会主动停下来。它会反复说服自己继续。
- token 爆炸：单Agent跑长流程从头到尾会造成上下文长度越来越长
多Agent效果：
多Agent协作完成任务。职责拆分，每个Agent专注完成自己的工作，划清责任边界。
浙公网安备 33010602011771号