Arch Day 108
Arch Day 108: AI Agent系统架构
Arch Day 108: AI Agent系统架构
2026-03-29
第四阶段 - 高阶融合AIAgent多Agent编排RAGToolUseMCPGuardRails安全
日期: 2026-03-29 (Day 108) 阶段: 第四阶段 - 高阶融合 标签: #AIAgent #多Agent编排 #RAG #ToolUse #MCP #GuardRails #安全
核心概念
一句话定义
AI Agent不是一个"更聪明的Chatbot"——它是一个能自主规划、使用工具、执行任务、并根据反馈迭代的自治软件系统。2026年的Agent架构已经从单一Agent进化到多Agent编排，从简单RAG进化到Agentic RAG，从硬编码工具调用进化到MCP标准化协议。
为什么关注
AI Agent正在从实验走向生产，成为企业软件的核心模式：
- 2026关键趋势：AI Agent已占AI总价值的17%（2025），预计2028年达到29%（BCG研究）
- 框架成熟：LangGraph 1.0稳定版（2025年10月），CrewAI/AG2/OpenAgents竞争格局形成
- MCP标准化：Model Context Protocol正在成为"Agent的USB接口"——工具连接的统一标准
- 金融场景：智能投顾、自动合规检查、实时风控辅助——Agent落地最活跃的领域
- 面试高频：2026年高级架构面试几乎必问Agent架构设计
误区与反模式
| 误区 | 现实 |
|---|---|
| "Agent就是LLM+工具调用" | Agent的核心是规划(Planning)和状态管理(State)，不只是调工具 |
| "多Agent一定比单Agent好" | 多Agent引入协调开销——简单任务单Agent更可靠 |
| "RAG准确率不够就加更多数据" | RAG的瓶颈通常在检索质量和Prompt设计，不在数据量 |
| "Guard Rails只是过滤脏话" | Guard Rails是多层防御体系：注入检测/幻觉检测/权限控制/审计 |
| "用最新框架就行" | 框架选择取决于场景——简单任务用CrewAI，复杂流程用LangGraph |
知识点详解
一、Agent架构模式
1.1 核心架构模式演进
Agent架构模式演进（2023-2026）：
2023: ReAct (基础)
└── 思考→行动→观察→思考→行动→...（单步循环）
2024: Plan-and-Execute
└── 先规划全局→逐步执行→根据结果调整计划
2025: Multi-Agent
└── 多个专业Agent协作→Orchestrator协调
2026: Hierarchical + Agentic RAG
└── 分层Agent + 自适应检索 + 标准化工具协议(MCP/A2A)
1.2 ReAct模式
ReAct（Reason + Act）：
┌────────────────────────────────────────┐
│ ReAct Agent │
├────────────────────────────────────────┤
│ │
│ 用户输入: "帮我查一下AAPL最新股价 │
│ 并计算过去30天的收益率" │
│ │
│ ┌──────────────────────────────────┐ │
│ │ Step 1: 思考(Thought) │ │
│ │ "我需要先获取AAPL当前价格， │ │
│ │ 再获取30天前价格，然后计算收益率" │ │
│ ├──────────────────────────────────┤ │
│ │ Step 2: 行动(Action) │ │
│ │ 调用 get_stock_price("AAPL") │ │
│ ├──────────────────────────────────┤ │
│ │ Step 3: 观察(Observation) │ │
│ │ 返回: $185.50 │ │
│ ├──────────────────────────────────┤ │
│ │ Step 4: 思考(Thought) │ │
│ │ "现在获取30天前的价格" │ │
│ ├──────────────────────────────────┤ │
│ │ Step 5: 行动(Action) │ │
│ │ 调用 get_historical_price( │ │
│ │ "AAPL", "2026-02-27") │ │
│ ├──────────────────────────────────┤ │
│ │ Step 6: 观察(Observation) │ │
│ │ 返回: $172.30 │ │
│ ├──────────────────────────────────┤ │
│ │ Step 7: 思考+回答(Final Answer) │ │
│ │ "AAPL当前价格$185.50， │ │
│ │ 30天前$172.30， │ │
│ │ 收益率 = (185.50-172.30)/ │ │
│ │ 172.30 = 7.66%" │ │
│ └──────────────────────────────────┘ │
└────────────────────────────────────────┘
优点：简单直观，易于调试
缺点：每步都调LLM，延迟高；无全局规划
1.3 Plan-and-Execute模式
Plan-and-Execute：
┌──────────────────────────────────────────────────┐
│ Plan-and-Execute Agent │
├──────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ Planner (规划器) │ │
│ │ 输入: 用户请求 │ │
│ │ 输出: 有序任务列表 │ │
│ │ │ │
│ │ Plan: │ │
│ │ 1. 查询AAPL当前股价 │ │
│ │ 2. 查询AAPL 30天前股价 │ │
│ │ 3. 计算30天收益率 │ │
│ │ 4. 查询同期S&P500收益率(对比) │ │
│ │ 5. 生成分析报告 │ │
│ └──────────────┬───────────────────────────┘ │
│ │ │
│ ┌──────────────┴───────────────────────────┐ │
│ │ Executor (执行器) │ │
│ │ 逐步执行Plan中的每个任务 │ │
│ │ 如果某步失败 → 返回Planner重新规划 │ │
│ └──────────────┬───────────────────────────┘ │
│ │ │
│ ┌──────────────┴───────────────────────────┐ │
│ │ Re-planner (重规划器) │ │
│ │ 根据已完成步骤和结果 │ │
│ │ 判断是否需要调整后续计划 │ │
│ └──────────────────────────────────────────┘ │
└──────────────────────────────────────────────────┘
优点：全局视野，效率更高（步骤可并行）
缺点：规划质量依赖LLM能力；复杂计划容易出错
1.4 Multi-Agent模式
Multi-Agent架构模式：
模式A: Orchestrator → Specialist（中央协调）
┌─────────────────────────────────────────────┐
│ Orchestrator Agent │
│ (理解意图/分配任务/汇总结果) │
└────┬──────────┬──────────┬─────────────────┘
│ │ │
┌────┴───┐ ┌───┴────┐ ┌──┴──────┐
│Research│ │Analysis│ │Writing │
│Agent │ │Agent │ │Agent │
│(检索) │ │(分析) │ │(生成) │
└────────┘ └────────┘ └─────────┘
模式B: Peer-to-Peer（对等协作）
┌────────┐ 消息 ┌────────┐
│Agent A │◄═════════►│Agent B │
└───┬────┘ └────┬───┘
│ │
│ ┌────────┐ │
└────►│Agent C │◄─────┘
└────────┘
模式C: Hierarchical（层级式）
┌──────────────────────────┐
│ Manager Agent │
└────┬──────────┬──────────┘
┌────┴───┐ ┌───┴────┐
│Team │ │Team │
│Lead A │ │Lead B │
└──┬──┬──┘ └──┬──┬──┘
┌──┴┐┌┴──┐ ┌──┴┐┌┴──┐
│W1 ││W2 │ │W3 ││W4 │
└───┘└───┘ └───┘└───┘
二、Agent框架对比（2025-2026）
2.1 主流框架
| 维度 | LangGraph | CrewAI | AG2(AutoGen) | OpenAgents |
|---|---|---|---|---|
| 架构 | 图状态机 | 角色化团队 | 会话式多Agent | 互操作Agent |
| 核心创新 | 持久化状态+图编排 | 角色抽象直觉化 | 多种对话模式 | 原生MCP+A2A |
| 成熟度 | 1.0稳定版(2025.10) | 生产就绪 | v0.4架构重写中 | 新锐 |
| 状态管理 | 内置持久化(最强) | 基础 | 中等 | 中等 |
| MCP支持 | 需插件 | 支持A2A | 待集成 | 原生 |
| 学习曲线 | 高(需理解图编程) | 低(角色直觉) | 中等 | 中等 |
| 适合场景 | 复杂有状态工作流 | 业务流程自动化 | 研究/对话系统 | 跨框架互操作 |
| 社区规模 | 最大 | 大 | 大(微软背景) | 快速增长 |
2.2 选型决策
Agent框架选型决策树：
START
│
├── 需要复杂状态管理+循环/分支？
│ ├── YES → LangGraph ★
│ └── NO → 继续
│
├── 业务流程自动化（角色清晰）？
│ ├── YES → CrewAI ★
│ └── NO → 继续
│
├── 需要跨框架/跨组织Agent互操作？
│ ├── YES → OpenAgents (MCP+A2A原生) ★
│ └── NO → 继续
│
├── 研究/原型/对话系统？
│ ├── YES → AG2/AutoGen ★
│ └── NO → 继续
│
└── 默认 → LangGraph（最成熟+最大社区）
2026趋势：框架正在趋同到图编排模式
├── LangGraph 率先采用
├── CrewAI/AG2也在向图模型靠拢
└── 图模型天然表达循环、分支、并行
三、Tool Use设计
3.1 Function Calling
Function Calling流程：
用户: "帮我转账100元给张三"
Step 1: LLM识别意图 → 需要调用transfer工具
Step 2: LLM生成结构化参数:
{
"tool": "transfer",
"parameters": {
"recipient": "张三",
"amount": 100,
"currency": "CNY"
}
}
Step 3: 系统执行工具调用
Step 4: 返回结果给LLM
Step 5: LLM生成自然语言回复
关键设计要素：
├── 工具描述要精确 → LLM靠描述选择工具
├── 参数Schema要清晰 → 减少生成错误
├── 错误处理要完善 → 工具调用失败的降级策略
├── 确认机制 → 高风险操作(如转账)需要用户确认
└── 超时控制 → 工具执行超时的处理
3.2 MCP协议(Model Context Protocol)
MCP是2024年底由Anthropic提出、2025-2026快速被行业采纳的Agent工具标准化协议——被称为"Agent的USB接口"。
MCP架构：
┌─────────────────────────────────────────────────┐
│ MCP Architecture │
├─────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ │
│ │ MCP Client │ (Agent/LLM应用) │
│ │ ├── 发现Server │
│ │ ├── 调用Tool │
│ │ ├── 读取Resource │
│ │ └── 使用Prompt模板 │
│ └──────┬───────┘ │
│ │ JSON-RPC over stdio/SSE │
│ ┌──────┴───────┐ │
│ │ MCP Server │ (工具/数据提供者) │
│ │ ├── Tools: 可执行的操作 │
│ │ │ 例: query_database, send_email │
│ │ ├── Resources: 可读取的数据 │
│ │ │ 例: file://docs/readme.md │
│ │ ├── Prompts: 预定义的Prompt模板 │
│ │ │ 例: summarize_document │
│ │ └── Sampling: 请求LLM生成(反向调用) │
│ └──────────────┘ │
│ │
│ MCP的核心价值： │
│ ├── 标准化: 一个协议连接所有工具 │
│ ├── 发现: Agent自动发现可用的工具 │
│ ├── 安全: 统一的权限和审计 │
│ └── 互操作: 不同Agent框架共享工具 │
│ │
│ 实际生态（2026）： │
│ ├── Anthropic Claude → 原生MCP Client │
│ ├── Cursor/Windsurf → MCP Client │
│ ├── 数千个开源MCP Server │
│ │ ├── GitHub MCP Server │
│ │ ├── PostgreSQL MCP Server │
│ │ ├── Slack MCP Server │
│ │ ├── Ethereum MCP Server (Web3场景) │
│ │ └── ... │
│ └── OpenAgents → 唯一原生MCP+A2A框架 │
└─────────────────────────────────────────────────┘
3.3 A2A协议(Agent-to-Agent)
A2A vs MCP：
MCP: Agent ←→ Tool（Agent调用工具）
A2A: Agent ←→ Agent（Agent之间通信）
A2A协议要素：
├── Agent Card: Agent的"名片"(能力描述/支持的消息类型)
├── Task: 跨Agent的任务生命周期管理
├── Message: Agent间的结构化消息
└── Artifact: 任务产出物(文件/数据/结果)
A2A场景示例：
金融分析Agent → 发送A2A消息 → 数据查询Agent
数据查询Agent → 返回数据 → 金融分析Agent
金融分析Agent → 发送A2A消息 → 报告生成Agent
报告生成Agent → 返回PDF → 金融分析Agent
四、RAG架构深度
4.1 RAG演进路线
RAG演进（2020-2026）：
Stage 1: Naive RAG（2020-2022）
├── 简单的检索→拼接→生成
├── 问题：检索质量差、上下文窗口限制、无法处理复杂查询
└── 架构：Query → Embedding → Top-K → LLM → Answer
Stage 2: Advanced RAG（2023-2024）
├── 查询改写(Query Rewriting)
├── 混合搜索(Dense + Sparse)
├── Re-ranking(重排序)
├── 滑动窗口分块(Chunking优化)
└── 架构：Query → Rewrite → Hybrid Search → Rerank → LLM
Stage 3: Modular RAG（2024-2025）
├── 模块化可组合架构
├── 可替换的Retriever/Reranker/Generator
├── 条件路由(简单查询走快路径，复杂查询走深度检索)
└── 架构：Query → Router → [Module A | Module B | ...] → LLM
Stage 4: Agentic RAG（2025-2026） ★ 当前前沿
├── LLM作为推理引擎决定检索策略
├── 循环迭代而非单次Pipeline
├── 多数据源动态选择
├── 自我反思和验证
└── 架构：Query → Agent[Plan→Retrieve→Reflect→...Loop] → Answer
4.2 Agentic RAG架构详解
Agentic RAG架构：
┌──────────────────────────────────────────────────────────┐
│ Agentic RAG System │
├──────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Query Understanding Agent │ │
│ │ ├── 意图分类: 事实查询/分析/对比/摘要 │ │
│ │ ├── 查询分解: 复杂问题→子问题 │ │
│ │ ├── 查询扩展: 添加同义词/相关概念 │ │
│ │ └── 难度评估: 简单(直接检索) vs 复杂(多轮) │ │
│ └────────────────────┬───────────────────────────────┘ │
│ │ │
│ ┌────────────────────┴───────────────────────────────┐ │
│ │ Retrieval Agent │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │
│ │ │向量检索 │ │关键词检索 │ │知识图谱(GraphRAG)│ │ │
│ │ │(Dense) │ │(Sparse) │ │(实体关系) │ │ │
│ │ └────┬─────┘ └────┬─────┘ └────────┬─────────┘ │ │
│ │ │ │ │ │ │
│ │ ┌────┴────────────┴────────────────┴──────────┐ │ │
│ │ │ Re-ranking Agent │ │ │
│ │ │ ├── Cross-encoder重排序 │ │ │
│ │ │ ├── 相关性打分 + 新鲜度加权 │ │ │
│ │ │ └── 去重和多样性保证 │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ └────────────────────┬───────────────────────────────┘ │
│ │ │
│ ┌────────────────────┴───────────────────────────────┐ │
│ │ Generation Agent │ │
│ │ ├── 基于检索结果生成回答 │ │
│ │ ├── 标注引用来源 │ │
│ │ └── 置信度评估 │ │
│ └────────────────────┬───────────────────────────────┘ │
│ │ │
│ ┌────────────────────┴───────────────────────────────┐ │
│ │ Verification Agent ★关键 │ │
│ │ ├── 幻觉检测: 回答是否有检索证据支持 │ │
│ │ ├── 事实核查: 与知识库交叉验证 │ │
│ │ ├── 一致性检查: 多次生成是否一致 │ │
│ │ └── 不够好? → 返回Retrieval Agent迭代 │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ 反馈循环: Verification → Query Understanding → 迭代 │
│ 终止条件: 置信度>阈值 OR 迭代次数>上限 │
└──────────────────────────────────────────────────────────┘
4.3 RAG优化策略清单
| 阶段 | 优化点 | 具体方法 |
|---|---|---|
| 分块 | Chunk策略 | 语义分块(而非固定长度)、递归分块、按文档结构分块 |
| 分块 | Chunk大小 | 256-512 tokens(检索)、1024+(生成上下文) |
| 索引 | 多层索引 | 摘要索引(粗)→段落索引(细)→句子索引(精) |
| 检索 | 混合搜索 | Dense(语义) + Sparse(关键词) + BM25 |
| 检索 | 查询变换 | HyDE(生成假设答案再检索)、Multi-query |
| 排序 | Re-ranking | Cross-encoder(最准)、ColBERT(平衡) |
| 生成 | 提示工程 | 要求引用来源、限制基于检索内容回答 |
| 验证 | 幻觉检测 | NLI模型检测、多次生成一致性 |
| 反馈 | 用户反馈 | 点赞/点踩 → 调整检索权重 |
五、Guard Rails设计
5.1 多层防御架构
Agent Guard Rails多层防御：
┌──────────────────────────────────────────────────────────┐
│ Guard Rails Architecture │
├──────────────────────────────────────────────────────────┤
│ │
│ Layer 1: 输入防御 (Input Guard) │
│ ├── Prompt Injection检测 │
│ │ ├── 模式匹配: "ignore previous instructions" │
│ │ ├── ML分类器: 训练专门的注入检测模型 │
│ │ └── Canary Token: 在System Prompt中埋入标记 │
│ ├── PII检测与脱敏 │
│ │ ├── 正则匹配: 手机号/身份证/银行卡 │
│ │ └── NER模型: 识别人名/地址/邮箱 │
│ ├── 话题边界检查 │
│ │ └── 分类器: 是否属于允许的话题范围 │
│ └── 输入长度/Token预算检查 │
│ │
│ Layer 2: 执行防御 (Execution Guard) │
│ ├── 工具调用白名单 │
│ │ └── Agent只能调用预注册的工具 │
│ ├── 参数验证 │
│ │ └── 工具参数必须符合Schema + 业务规则 │
│ ├── 操作确认 │
│ │ └── 高风险操作(写/删/转账)需用户确认 │
│ ├── 速率限制 │
│ │ └── 单次会话最多调用N次工具 │
│ └── 超时控制 │
│ └── 单步执行/全局执行超时 │
│ │
│ Layer 3: 输出防御 (Output Guard) │
│ ├── 幻觉检测 │
│ │ ├── 与检索内容交叉验证(RAG场景) │
│ │ ├── 多次生成一致性检查 │
│ │ └── 实体级事实核查 │
│ ├── 有害内容检测 │
│ │ ├── 毒性分类器(Perspective API等) │
│ │ └── 合规检查(金融/医疗场景) │
│ ├── 格式验证 │
│ │ └── JSON Schema验证/markdown格式检查 │
│ └── 数据泄露检测 │
│ └── 输出中不应包含System Prompt/内部数据 │
│ │
│ Layer 4: 审计层 (Audit Layer) │
│ ├── 完整对话日志(含内部推理过程) │
│ ├── 工具调用记录(参数+返回值) │
│ ├── 决策追踪(为什么选择这个工具/这个回答) │
│ └── 异常告警(触发Guard Rails的事件) │
│ │
└──────────────────────────────────────────────────────────┘
5.2 金融场景特殊Guard Rails
金融Agent额外防御层：
1. 合规检查(Compliance Guard)
├── 投资建议免责声明 → 自动附加
├── 适当性检查 → 根据客户风险等级过滤建议
├── 反洗钱检查 → 大额交易自动触发
└── 监管报告 → 特定操作自动报送
2. 金额限制(Amount Guard)
├── 单笔限额检查
├── 日累计限额检查
├── 异常金额告警(偏离历史均值)
└── 双人复核(超过阈值)
3. 市场影响(Market Guard)
├── 避免给出具体价格预测
├── 避免构成市场操纵
├── 波动市场自动降低建议激进度
└── 收盘前/开盘后的特殊规则
六、Agent安全权限控制
6.1 最小权限原则
Agent权限设计（类比Web3 Session Keys概念）：
┌──────────────────────────────────────────────────────────┐
│ Agent Permission Framework │
├──────────────────────────────────────────────────────────┤
│ │
│ 权限层级： │
│ │
│ Level 0: 只读 (Read-Only) │
│ ├── 查询数据库 │
│ ├── 搜索文档 │
│ └── 获取外部API数据 │
│ │
│ Level 1: 有限写 (Limited Write) │
│ ├── 创建草稿(不发布) │
│ ├── 添加标签/备注 │
│ └── 更新非关键字段 │
│ │
│ Level 2: 受控写 (Controlled Write) │
│ ├── 发送消息(需用户确认) │
│ ├── 创建/更新记录(需审批) │
│ └── 执行交易(需二次确认+限额) │
│ │
│ Level 3: 自主 (Autonomous) — 极少使用 │
│ ├── 自动执行交易(在预设规则内) │
│ ├── 自动回复客户(标准场景) │
│ └── 自动触发流程 │
│ │
│ 权限控制机制： │
│ ├── Session Keys: 每次会话生成临时权限令牌 │
│ │ ├── 有效期: 最长4小时 │
│ │ ├── 操作范围: 仅限本次任务所需 │
│ │ └── 自动过期: 不会累积权限 │
│ ├── 操作白名单: 预定义允许的操作集合 │
│ ├── 熔断机制: 异常行为自动禁止后续操作 │
│ │ ├── 连续3次工具调用失败 → 暂停 │
│ │ ├── 累计金额超过阈值 → 停止 │
│ │ └── 检测到异常模式 → 人工接管 │
│ └── 审计日志: 所有操作可追溯 │
└──────────────────────────────────────────────────────────┘
6.2 安全架构模式
Agent安全架构（Defense in Depth）：
用户请求
│
┌──────┴──────┐
│ 认证/鉴权 │ ← 谁在操作？权限是什么？
└──────┬──────┘
│
┌──────┴──────┐
│ 输入安全检查 │ ← 注入检测/PII脱敏
└──────┬──────┘
│
┌──────┴──────┐
│ Agent推理 │ ← System Prompt隔离
│ │ 上下文注入防护
└──────┬──────┘
│
┌──────┴──────┐
│ 工具调用审批 │ ← 白名单/参数校验/确认
└──────┬──────┘
│
┌──────┴──────┐
│ 执行沙箱 │ ← 隔离环境/超时/资源限制
└──────┬──────┘
│
┌──────┴──────┐
│ 输出安全检查 │ ← 幻觉/有害/泄露检测
└──────┬──────┘
│
┌──────┴──────┐
│ 审计日志 │ ← 全链路追踪
└──────┬──────┘
│
用户响应
七、多Agent编排
7.1 编排模式选择
| 模式 | 特点 | 适用场景 | 框架支持 |
|---|---|---|---|
| Orchestrator→Specialist | 中央控制，清晰分工 | 业务流程(审批/处理) | LangGraph/CrewAI |
| Peer-to-Peer | 灵活协作，无中心 | 研究/讨论/辩论 | AG2/OpenAgents |
| Hierarchical | 层级管理，大规模 | 企业级复杂系统 | LangGraph |
| Pipeline | 串行处理，简单 | ETL/文档处理 | CrewAI |
| Supervisor | 动态分配+质量控制 | 需要质量把关 | LangGraph |
7.2 多Agent通信设计
Agent通信架构：
方式1: 共享状态(State-based)
┌──────────────────────┐
│ Shared State │
│ ┌────────────────┐ │
│ │ messages: [...] │ │
│ │ context: {...} │ │
│ │ artifacts: [...] │ │
│ └────────────────┘ │
└──────┬────┬────┬─────┘
│ │ │
Agent A B C
(都可读写共享状态)
→ LangGraph的默认模式
→ 简单直观，但需要状态冲突处理
方式2: 消息传递(Message-based)
Agent A ──消息──→ Agent B ──消息──→ Agent C
←消息── ←消息──
→ A2A协议的模式
→ 解耦好，但需要消息格式标准化
方式3: 事件驱动(Event-based)
┌────────────┐
│ Event Bus │
└──┬──┬──┬───┘
│ │ │
Agent A B C
(发布/订阅事件)
→ 大规模Agent系统
→ 最解耦，但调试复杂
八、实操：设计"智能金融助手"Agent系统
智能金融助手Agent系统架构：
┌──────────────────────────────────────────────────────────────┐
│ Smart Financial Assistant │
├──────────────────────────────────────────────────────────────┤
│ │
│ ┌─── 接入层 ─────────────────────────────────────────────┐│
│ │ ├── Web Chat / Mobile App / 企业微信 ││
│ │ ├── 认证: OAuth2.0 + 客户身份验证 ││
│ │ └── 输入Guard Rails: 注入检测 + PII脱敏 ││
│ └──────────────────────────────────────────────────────────┘│
│ │ │
│ ┌─── Orchestrator Agent ──┴────────────────────────────────┐│
│ │ ├── 意图识别 → 路由到专业Agent ││
│ │ ├── 会话管理 → 多轮对话上下文 ││
│ │ └── 结果汇总 → 综合多个Agent结果回复用户 ││
│ └──────────┬──────────┬──────────┬──────────┬──────────────┘│
│ │ │ │ │ │
│ ┌──────────┴┐ ┌──────┴────┐ ┌──┴────────┐ ┌┴────────────┐ │
│ │ 查询Agent │ │ 分析Agent │ │ 交易Agent │ │ 合规Agent │ │
│ │ │ │ │ │ │ │ │ │
│ │ 工具: │ │ 工具: │ │ 工具: │ │ 工具: │ │
│ │ -账户查询 │ │ -行情分析 │ │ -下单API │ │ -适当性检查 │ │
│ │ -交易记录 │ │ -风险评估 │ │ -转账API │ │ -反洗钱检查 │ │
│ │ -产品信息 │ │ -报告生成 │ │ -申赎API │ │ -监管规则 │ │
│ │ │ │ │ │ │ │ │ │
│ │ 权限:L0 │ │ 权限:L0 │ │ 权限:L2 │ │ 权限:L0 │ │
│ │ (只读) │ │ (只读) │ │ (受控写) │ │ (只读) │ │
│ └───────────┘ └───────────┘ └───────────┘ └─────────────┘ │
│ │ │
│ ┌─── RAG系统(Agentic RAG) ┴────────────────────────────────┐│
│ │ ├── 向量DB(Qdrant): 产品文档/FAQ/政策文件 ││
│ │ ├── 知识图谱(Neo4j): 产品关系/客户关系 ││
│ │ ├── 结构化DB(PostgreSQL): 账户/交易数据 ││
│ │ └── Retrieval Agent: 多源检索+重排序+验证 ││
│ └──────────────────────────────────────────────────────────┘│
│ │ │
│ ┌─── 安全+审计 ──────────┴──────────────────────────────┐ │
│ │ ├── Guard Rails: 全链路输入输出防御 │ │
│ │ ├── 操作审计: 所有Agent决策和工具调用可追溯 │ │
│ │ ├── 熔断机制: 异常行为自动停止 │ │
│ │ └── 合规报告: 定期生成监管合规报告 │ │
│ └──────────────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────────────┘
面试题精选
面试题1：AI Agent如何保证安全性？
30秒版本： Agent安全需要Defense in Depth——输入层防注入/脱敏，执行层白名单/限额/确认，输出层幻觉检测/合规检查，全链路审计日志。核心原则是最小权限(Session Keys)和熔断机制(异常自动停止)。
2分钟版本： 我把Agent安全分为四层：
-
输入安全：Prompt Injection是Agent最大的安全威胁。我采用三重防御——正则模式匹配(快速过滤)、ML分类器(准确检测)、Canary Token(事后检测)。同时对PII进行自动脱敏。
-
执行安全：核心是最小权限原则。类比Web3的Session Keys概念——每次会话生成临时权限令牌，只授予本次任务所需的最小权限，自动过期。高风险操作(如转账)必须经过用户确认。设置熔断机制——连续失败或异常行为自动停止。
-
输出安全：幻觉是Agent输出的最大风险。对于RAG场景，检查回答是否有检索证据支持。对于金融场景，自动附加免责声明、过滤不合规建议。
-
审计：金融场景的合规要求所有Agent决策必须可追溯——记录完整的推理链路、工具调用参数和返回值。这也是"可解释性"的基础。
追问：如何处理Prompt Injection？ 多层防御。首先用模式匹配快速过滤已知攻击模式。然后用专门训练的分类器检测变种攻击。最后在System Prompt中埋入Canary Token——如果输出中出现这个Token，说明System Prompt被泄露了。另外，将用户输入和System Prompt严格隔离（使用不同的XML标签或分隔符）。
面试题2：RAG架构如何优化准确性？
30秒版本： 从四个方面优化——分块策略(语义分块而非固定长度)、检索质量(混合搜索+重排序)、生成约束(要求引用来源+限制基于检索内容回答)、验证机制(幻觉检测+多次生成一致性检查)。
2分钟版本： RAG准确性问题的根因通常有三个，我逐一优化：
-
检索不到正确内容（最常见）：
- 分块优化：使用语义分块而非固定512 tokens——按段落/章节/逻辑单元切分
- 查询改写：用HyDE（先让LLM生成假设答案，再用假设答案检索）
- 混合搜索：Dense向量(捕捉语义) + Sparse BM25(捕捉关键词)
- 多层索引：摘要级→段落级→句子级的分层索引
-
检索到了但排序不对：
- Re-ranking：用Cross-encoder对Top-20重新排序，选Top-5
- 多样性保证：MMR(Maximal Marginal Relevance)，避免检索结果太相似
-
检索到了但生成出错（幻觉）：
- Prompt约束："只基于以下参考内容回答，如果参考内容中没有相关信息，请说'我不确定'"
- 引用标注：要求模型标注每句话的来源[1][2]
- 验证循环：生成后用Verification Agent检查——回答中的每个事实是否都有检索证据支持
在金融场景，我还会加一层合规验证——确保生成的金融建议符合监管要求。
今日总结
核心要点
- Agent架构从ReAct演进到Plan-and-Execute再到Multi-Agent，核心是规划和状态管理
- MCP正在成为Agent工具调用的标准协议——"Agent的USB接口"
- RAG从Naive演进到Agentic RAG——LLM作为推理引擎动态决定检索策略
- Guard Rails是多层防御体系，不只是"过滤脏话"
- Agent安全的核心是最小权限+熔断机制+全链路审计
- 框架选择：复杂流程用LangGraph，角色化团队用CrewAI，互操作用OpenAgents
明日预告
Day 109将探讨AI+传统系统融合——如何为存量系统渐进式增加AI能力，而不是推倒重来。
参考资源
- CrewAI vs LangGraph vs AutoGen vs OpenAgents 2026
- Definitive Guide to Agentic Frameworks in 2026
- Agentic RAG: A Survey (arXiv)
- The Ultimate RAG Blueprint 2025/2026
- The Evolution of RAG and AI Technology Trends for 2026
- A Detailed Comparison of Top 6 AI Agent Frameworks in 2026
- Top 5 Agentic AI Frameworks to Watch in 2026