架构设计

为什么Agent需要可观测性？ 传统软件的行为是确定性的——同样输入产生同样输出。但Agent的行为由LLM驱动，具有随机性和非确定性。这使得Agent系统更需要完善的可观测性——才能知道Agent"在做什么"、“为什么这么做”、“花了多少钱”。 可观测性三大支柱 1. 日志（Logging） 记录Agent每一步的行为： { "timestamp": "2026-07-16T10:00:01.234Z", "session_id": "sess_abc123", "agent": "research_agent", "action": "tool_call", "tool": "web_search", "input": {"query": "AI芯片市场2025"}, "output": {"results": 5, "top_result": "..."}, "duration_ms": 1234, "tokens": {"input": 25, "output": 0}, "cost_usd": 0.0001, "status": "success" } 日志设计原则： 结构化（JSON而非纯文本） 可关联（session_id + step_id） 可过滤（level, agent, tool等字段） 采样策略（全量记录关键步骤，采样记录调试信息） 2. 指标（Metrics） 量化Agent运行状态： 业务指标： 任务成功率 用户满意度（评分/反馈） 平均完成时间 平均步数 技术指标： LLM调用延迟（p50/p95/p99） 工具调用延迟 Token消耗量 API错误率 每任务成本 资源指标： GPU利用率 内存占用 并发会话数 队列深度 3. 追踪（Tracing） 记录一次完整任务的全链路： Trace: sess_abc123 ├── Span 1: task_planning (1.2s) │ ├── LLM call: gpt-4 (0.8s, 500 tokens) │ └── Output: [search, analyze, report] ├── Span 2: web_search (0.6s) │ ├── tool: search_api │ └── Result: 5 items ├── Span 3: content_analysis (2.1s) │ ├── LLM call: gpt-4 (1.8s, 2000 tokens) │ └── Output: analysis_summary ├── Span 4: report_generation (1.5s) │ ├── LLM call: gpt-4 (1.2s, 1500 tokens) │ └── Output: final_report.md Total: 5.4s, 4000 tokens, $0.06 监控架构 数据采集层 # Agent执行包装器 class TracedAgent: def __init__(self, agent, tracer): self.agent = agent self.tracer = tracer @trace async def run(self, input_data): with self.tracer.span("agent_run") as span: span.set_attr("input", input_data) result = await self.agent.run(input_data) span.set_attr("output", result) span.set_attr("tokens", self.agent.total_tokens) span.set_attr("cost", self.agent.total_cost) return result @trace async def call_tool(self, tool, args): with self.tracer.span("tool_call") as span: span.set_attr("tool", tool.name) span.set_attr("args", args) start = time.time() result = await tool.run(args) duration = time.time() - start span.set_attr("duration_ms", duration * 1000) span.set_attr("result", result) return result 数据存储层 数据类型 存储方案 保留期 日志 Elasticsearch / Loki 30天 指标 Prometheus / InfluxDB 90天 追踪 Jaeger / Tempo 7天 会话记录 PostgreSQL / MongoDB 按需 可视化层 实时仪表盘： ...

长上下文为什么重要？ 长上下文是Agent的基础设施。Agent需要记住长对话历史、处理长文档、执行多步推理——这些都依赖模型处理超长上下文的能力。从4K到1M，上下文窗口的扩展正在改变AI应用的可能性边界。 核心挑战 挑战一：注意力计算的二次复杂度 标准Transformer的自注意力计算复杂度是O(n²)： Attention(Q, K, V) = softmax(QK^T / √d) * V Q: [n, d], K: [n, d] → QK^T: [n, n] → O(n²) 从4K到128K，计算量增长1000倍。直接外推不可行。 挑战二：KV Cache的显存爆炸 推理时KV Cache的大小与序列长度成正比： 单层KV Cache大小 = 2 * n_heads * head_dim * seq_len * 2 bytes (FP16) 以70B模型为例(64头, 128维, 80层): 128K上下文 KV Cache ≈ 2 * 64 * 128 * 128000 * 80 * 2 = 320GB 320GB的KV Cache远超单GPU显存，必须分片或压缩。 挑战三：长程信息衰减 即使能处理长上下文，模型对中间部分的信息利用效率也在下降——这被称为"Lost in the Middle"现象： ...

工作流编排：Agent的神经系统 单个Agent的能力有限。复杂任务需要多个Agent协作——有人负责搜索，有人负责推理，有人负责验证。工作流编排就是定义这些Agent如何协作的"神经系统"。 编排模式演进 模式一：静态DAG（有向无环图） 最简单的编排方式——预定义执行流程： [收集信息] → [分析数据] → [生成报告] → [审核质量] 优点： 确定性强，易于调试 执行可预测 性能好（可并行优化不依赖的节点） 局限： 无法处理动态决策（发现需要额外搜索时无法回溯） 流程僵化，不适配多变场景 模式二：条件分支DAG 在DAG基础上加入条件判断： [收集信息] → [信息充分?] ├─ 是 → [分析数据] └─ 否 → [补充搜索] → [分析数据] 优点： 支持基本决策逻辑 仍保持可预测性 局限： 分支数有限时有效 复杂决策导致图过于复杂 模式三：状态机 状态机允许循环和回退： 状态: {current_step, context, results} 转移规则: collecting → (if enough info) → analyzing collecting → (if not enough) → collecting analyzing → (if clear) → generating analyzing → (if need more data) → collecting generating → (if quality ok) → done generating → (if quality low) → analyzing 优点： ...

MoE：用参数量换计算效率 MoE（Mixture of Experts）的核心思想很简单：不是所有参数都需要参与每次计算。通过路由机制，只激活与当前输入最相关的"专家"子网络，在保持大参数量的同时大幅降低计算量。 基本原理 稠密模型 vs 稀疏模型 传统稠密模型：每个token经过所有参数的计算。 输入token → [Attention] → [MLP(d, d_ff)] → 输出 所有参数参与计算 MoE模型：MLP层被替换为多个专家MLP，路由器选择激活哪些专家。 输入token → [Attention] → [Router] → 选择Top-K专家 ↓ [Expert1] [Expert2] ... [ExpertN] ↓ (仅K个被激活) 加权合并 → 输出 关键参数 专家数(N)：总专家数量。通常8-64个 激活数(K)：每个token激活的专家数。通常2-8个 稀疏率：1 - K/N。如8/64的配置，稀疏率为87.5% 以DeepSeek-V3为例：256个专家，每token激活8个，总参数671B但推理时只激活37B——等效于37B模型的计算量，但拥有671B参数的知识容量。 路由机制 基础路由 最简单的路由方式： def route(token, experts): # 计算token与每个专家的亲和度 scores = softmax(W_router @ token) # [N] # 选择Top-K个专家 top_k_indices = argsort(scores)[-K:] top_k_scores = scores[top_k_indices] # 归一化 top_k_scores /= top_k_scores.sum() # 加权合并 output = sum(experts[i](token) * top_k_scores[i] for i in top_k_indices) return output 负载均衡问题 基础路由有一个严重问题：路由坍缩。模型倾向于总是选择少数几个"好"专家，其他专家得不到训练。 ...

工具调用：Agent的双手 没有工具调用能力的LLM只是一个"会说话的大脑"。真正的Agent需要调用API、执行代码、读写文件——这些都需要工具调用机制。 演进历程 阶段一：Prompt工程时代（2022-2023） 最早的工具调用靠Prompt引导： 你可以使用以下工具： 1. search(query): 搜索网页 2. calculator(expr): 数学计算 如果需要使用工具，请输出以下格式： <tool>search("天气")</tool> 这种方式的问题： 格式不稳定，模型经常不遵守 参数提取容易出错 无法处理多步工具调用 阶段二：Function Calling时代（2023-2024） OpenAI在2023年6月推出Function Calling，将工具调用作为原生API能力： response = openai.chat.completions.create( model="gpt-4", messages=[{"role": "user", "content": "北京天气"}], tools=[{ "type": "function", "function": { "name": "get_weather", "description": "获取城市天气", "parameters": { "type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"] } } }] ) # response.choices[0].message.tool_calls 模型输出结构化的工具调用请求，API层解析后执行。 阶段三：标准化时代（2024-2026） MCP协议将工具调用标准化，实现"一次开发，处处可用"。 Function Calling的技术细节 工作流程 1. 用户消息 + 工具定义 → LLM 2. LLM输出 → tool_call(name, args) 3. 应用层执行工具 4. 工具结果 → LLM 5. LLM基于结果生成回答 关键参数 tools定义： { "type": "function", "function": { "name": "string", "description": "string", "parameters": { // JSON Schema格式 } } } tool_choice控制： auto：模型自主决定是否调用 none：禁止调用 required：必须调用 {"function": {"name": "xxx"}}：指定调用特定工具 并行调用 现代模型支持在单次响应中输出多个tool_call： ...

向量数据库：RAG时代的基石 所有RAG系统都需要向量数据库。2026年市场已经从"有没有"过渡到"哪个好"——选型不当会带来性能瓶颈、扩展困难、功能不足等问题。 三大主流方案 Milvus：大规模分布式 架构特点 Milvus采用存算分离架构： Coordinator：元数据管理和调度 Worker Node：查询节点和数据节点分离 对象存储：数据持久化（S3/MinIO） 消息队列：变更数据捕获（Kafka/Pulsar） 核心优势 水平扩展：支持十亿级向量 混合检索：向量+标量过滤 多索引：HNSW、IVF、DiskANN、GPU索引 云原生：K8s原生部署 适用场景 大规模生产环境（亿级向量） 需要高可用和水平扩展 团队有K8s运维能力 注意事项 部署复杂度高（微服务架构） 小规模场景（<100万向量）过重 内存占用较大 Qdrant：高性能轻量级 架构特点 Qdrant用Rust编写，单二进制部署： Collection：数据集合 Payload：向量关联的元数据 量化支持：标量量化(SQ8)、乘积量化(PQ)、二进制量化 磁盘索引：支持大于内存的数据集 核心优势 简单部署：单二进制+Docker 高性能：Rust实现，无GC暂停 丰富过滤：Payload过滤能力强大 量化压缩：内存占用极低 适用场景 中小规模（<1亿向量） 快速原型开发 对延迟敏感的场景 运维资源有限的团队 注意事项 分布式能力不如Milvus 不支持多租户隔离 生态插件较少 Weaviate：AI原生设计 架构特点 Weaviate定位为"AI原生数据库"： GraphQL API：内置API层 模块化向量化：内置多种embedding模型 对象存储+向量索引：一体化设计 多模态支持：图像/文本/视频嵌入 核心优势 开箱即用：内置embedding模型 GraphQL接口：前端友好 多模态：原生支持多种数据类型 混合检索：BM25+向量融合 适用场景 快速构建AI应用 需要多模态检索 前端团队主导的项目 不想单独管理embedding流程 注意事项 性能不如Qdrant极致 大规模部署经验较少 Go实现，性能依赖GC调优 性能对比 写入性能 数据库 单线程写入 批量写入(10K) 索引构建速度 Milvus 5K/s 50K/s 中等 Qdrant 8K/s 80K/s 快 Weaviate 3K/s 30K/s 中等 查询性能 数据库 p50延迟 p99延迟 并发QPS Milvus 5ms 20ms 10K+ Qdrant 2ms 8ms 5K+ Weaviate 8ms 30ms 3K+ 注：测试条件为1M向量，768维，HNSW索引，单节点。实际性能受数据规模、硬件、配置影响。 ...

为什么需要边缘AI？ 云计算解决了大规模AI部署问题，但很多场景无法依赖云端： 隐私要求：医疗、金融数据不能上云 延迟要求：自动驾驶、实时翻译需要毫秒级响应 离线场景：野外、飞机模式、网络不稳定 成本控制：大量设备同时运行，云推理成本不可控 边缘AI的目标：在手机、车载芯片、IoT设备上本地运行AI模型。 模型压缩四件套 1. 量化 将模型从FP32压缩到INT8/INT4： 精度 模型大小(7B) 精度损失 推理速度 FP16 14GB 0% 基准 INT8 7GB <1% 1.5-2x INT4 3.5GB 1-3% 2-3x 2-bit 1.75GB 5-10% 3-4x 移动端推荐INT4量化，使用GGUF格式（llama.cpp生态）。常用方案： GPTQ：基于二阶信息的权重量化 AWQ：基于激活分布的权重量化 GGUF Q4_K_M：移动端最常用格式 2. 蒸馏 将大模型知识"蒸馏"到小模型： Teacher模型(70B) → 生成回答/中间表示 → Student模型(1B)学习 任务特定蒸馏：只蒸馏目标任务的能力，而非通用能力。效果通常比直接训练小模型好20-30%。 3. 剪枝 移除不重要的参数： 结构化剪枝：移除整个attention head或MLP中间维度，可实际加速 非结构化剪枝：移除稀疏参数，需特殊硬件支持 移动端推荐结构化剪枝，因为标准硬件就能获得加速。 4. 架构搜索（NAS） 针对特定硬件搜索最优模型结构： 确定目标硬件的延迟/功耗预算 搜索满足约束的最高精度模型 MobileNet、EfficientNet就是NAS的经典成果 移动端推理引擎 llama.cpp C++实现，无依赖 支持GGUF格式 iOS/Android均可运行 支持CPU推理和GPU加速 典型使用: 1. 将模型量化为GGUF格式 2. 编译llama.cpp for Android/iOS 3. 通过JNI或C API调用 4. 管理上下文窗口和内存 MLC-LLM 基于TVM编译器 自动优化模型到目标硬件 支持GPU加速（Metal/Vulkan） 跨平台：iOS/Android/Web ONNX Runtime Mobile 微软出品，支持ONNX格式 Android/iOS支持完整 包体积极小（<10MB运行时） 支持NNAPI/CoreML后端加速 平台原生方案 iOS：CoreML + MLX Android：ML Kit + NNAPI 华为：CANN + NPU 端侧部署实战 iOS部署 // 使用MLX框架运行LLM import MLX import MLXLMCommon let model = try await loadModel(name: "qwen-2-1.5b-4bit") let result = try await model.generate( prompt: "你好", maxTokens: 256 ) 关键配置： ...

数字人的本质 数字人是多模态AI的集大成者——它需要看起来像人、动起来像人、说起来像人。技术上需要融合3D图形、语音合成、NLP、计算机视觉等多个领域。 技术栈分层 第一层：外观创建 3D建模 传统管线：Maya/Blender手工建模→UV展开→纹理绘制→绑定骨骼 AI生成：单张照片生成3D模型（如PifuHD、DreamGaussian） 数字分身：3D扫描+AI增强，快速生成高保真数字人 2D数字人 2D数字人（如HeyGen、D-ID）不需要3D模型，直接在2D图像上做面部动画： 输入：一张正面照片 + 音频 输出：说话的视频 技术：基于扩散模型的面部动画生成 2D方案成本低、速度快，但角度受限。 第二层：语音合成 数字人的"声音"是核心体验。TTS技术已非常成熟： 流式TTS 延迟要求：首音延迟<300ms，支持流式输入 情感控制：通过ssml或prompt控制语气（开心、悲伤、严肃） 多语言：支持中英日韩等多语言自然切换 声音克隆 少量样本（3-10秒）克隆目标音色 使用说话人编码（speaker encoder）技术 需注意Deepfake伦理问题 代表方案 商用：Azure TTS、ElevenLabs、火山引擎 开源：ChatTTS、GPT-SoVITS、CosyVoice 第三层：唇形同步 唇形同步是数字人的技术难点——嘴型需要精确匹配语音内容。 3D方案：BlendShape驱动 预定义一组口型（ARKit的52个BlendShape） 音素到口型映射（ viseme mapping） 音频特征→音素识别→口型映射→BlendShape权重 2D方案：面部驱动 音频特征提取（mel-spectrogram） 基于扩散模型或GAN生成面部帧 时序一致性处理（光流+时间一致性损失） Wav2Lip类方法 核心思想是用音频直接驱动任意视频中的嘴唇运动： 输入：视频 + 新音频 输出：嘴型匹配新音频的视频 局限：仅嘴部区域，其他部位不动 第四层：动作驱动 身体动作 动作捕捉：光学/惯性动捕，精度高但成本高 视频驱动：单摄像头提取3D姿态，驱动数字人 AI生成：文本→动作序列（如动作扩散模型） 表情驱动 面部关键点检测（68/468点） FACS（面部动作编码系统）映射 实时跟踪摄像头数据→表情重定向到数字人 眼神控制 眼神是数字人"活起来"的关键： 注视追踪：让数字人看着对话者 扫视（saccade）：模拟自然眼动 眨眼频率：6-15次/分钟的自然频率 第五层：大脑驱动 数字人的"大脑"由LLM驱动： 用户输入 → ASR(语音转文字) → LLM(生成回复) → TTS(文字转语音) → 面部/动作驱动 关键要求： ...

代码生成的三个时代 第一代：智能补全（2021-2023） GitHub Copilot开创了AI代码补全时代。核心模式是在编辑器中实时预测下一段代码，从单行补全到多行生成。技术上是将光标前后的代码作为上下文送入LLM，生成候选代码。 局限性很明显： 缺乏项目级上下文，只看当前文件 无法理解运行时行为 生成代码质量依赖使用者审查能力 第二代：对话式编程（2023-2025） Cursor、Windsurf等AI IDE引入了对话模式。开发者可以用自然语言描述需求，AI生成完整函数甚至文件。关键改进： 上下文扩展到整个项目（通过embedding检索相关文件） 支持多轮对话迭代修改 自动应用diff编辑到文件 第三代：自主编程Agent（2025-2026） 最新一代代码Agent不再需要人类逐步指导，而是： 理解完整需求描述 自主规划实现步骤 创建/修改多个文件 运行测试验证结果 自主调试修复错误 自主编程Agent的架构 核心组件 [需求理解] → [任务规划] → [代码实现] → [测试执行] → [调试修复] → [完成] ↑ | └──────────────────反馈循环──────────────────────────────┘ 需求理解模块 将自然语言需求转化为结构化的技术规格： 提取功能需求列表 识别技术约束（语言、框架、数据库） 识别非功能需求（性能、安全） 输出：结构化的规格文档 任务规划模块 将规格分解为可执行的子任务序列： 文件创建/修改计划 依赖关系图 每步的验证标准 关键挑战是规划粒度——太粗导致单步过于复杂，太细则浪费token。实践中采用自适应粒度：简单模块整块生成，复杂模块逐步拆解。 代码实现模块 实际生成代码的引擎。关键技术： 1. 上下文构建 不是简单把整个代码库塞进context，而是智能构建： 上下文 = 系统prompt + 项目结构概览(目录树) + 相关文件内容(RAG检索) + 接口定义(类型签名) + 当前任务描述 2. 增量编辑 ...

推理瓶颈在哪里？ 大模型推理的核心瓶颈是自回归生成的串行性：每生成一个token都需要将之前所有token的KV对参与注意力计算。随着序列变长，计算量和显存占用呈线性甚至二次增长。 推理优化的目标可以归纳为三个维度： 降低延迟（首token延迟TTFT + 每token延迟TPOT） 提升吞吐（每秒生成token总数） 减少显存（KV Cache占用） KV Cache：标准但不够 KV Cache是现代推理引擎的标配。在生成阶段，避免重复计算历史token的Key和Value向量，而是缓存复用。但KV Cache的显存占用非常大：以Llama-70B为例，单条请求的KV Cache在4K序列长度下约占2GB显存。 优化方向： PagedAttention（vLLM）：将KV Cache分为固定大小的block，通过页表管理，显著减少碎片 量化KV Cache：将FP16的KV对压缩为INT8甚至INT4，显存减半甚至1/4 稀疏KV Cache：基于注意力分数剪枝，丢弃不重要的KV对 连续批处理（Continuous Batching） 传统static batching需要等待批次内所有请求完成才能释放资源，短请求被长请求拖累。连续批处理（也叫iteration-level batching）在每个forward pass级别动态加入新请求、移除已完成请求： 时间步1: [req_A(token5), req_B(token3), req_C(token1)] 时间步2: [req_A(token6), req_B(token4), req_D(token1)] # C完成，D加入 vLLM和TGI都实现了这一机制，实测吞吐量可提升3-5倍。 投机解码（Speculative Decoding） 投机解码利用一个小模型（draft model）快速生成候选token序列，再由大模型一次性验证。如果小模型的猜测正确率足够高，就能以接近小模型的速度输出大模型质量的token： 小模型生成N个候选token（并行，很快） 大模型对这N个token做一次forward（并行验证） 接受正确的前缀，拒绝处重新采样 Medusa在此基础上扩展，在单次forward中同时预测多个位置的token（多头预测），进一步提升加速比。 量化推理 训练时用FP16/BF16，推理时降低精度： 精度 方法 性能损失 INT8 W8A8 / SmoothQuant <1% INT4 W4A16 / GPTQ / AWQ 1-3% 2-bit BitNet / 1.58bit 训练时需特殊设计 AWQ和GPTQ是目前最流行的4bit权重量化方案，配合Marlin内核可达极高吞吐。需注意，4bit量化在70B以上模型上表现好，但7B级别可能有明显精度下降。 ...