Agent架构

从文本Agent到多模态Agent 2026年的AI Agent正在经历一个重要转变——从纯文本交互走向多模态感知。用户不再满足于打字对话，他们希望Agent能看图片、看视频、听语音，甚至实时感知屏幕内容。 这个转变对架构设计提出了全新的挑战。 多模态Agent的核心组件 一个完整的多模态Agent架构包含以下层次： 感知层 感知层负责将不同模态的输入转换为统一的内部表示。 视觉感知：使用视觉编码器（如ViT或CLIP）将图像转换为视觉Token序列。对于视频输入，需要额外的时间维度建模——我们采用3D Patch Embedding加上时序注意力的方式。 音频感知：语音输入通过ASR模块转为文本，同时提取声学特征（音调、语速、情感）作为辅助信息。直接音频Token化（如AudioLM的方式）在某些场景下效果更好，但计算开销更大。 屏幕感知：对于电脑端Agent，屏幕理解是关键能力。我们采用多管齐下的策略：截图送入VLM获取语义描述，同时通过Accessibility API获取结构化的UI元素信息。两者融合后作为屏幕状态表示。 融合层 融合层是架构的核心——如何将不同模态的信息有效融合。 我们对比了三种融合策略： 早期融合：将所有模态的Token拼接后统一送入Transformer。优势是模型可以做跨模态注意力，劣势是计算量大且训练数据要求高。 晚期融合：各模态独立编码后通过MLP融合。优势是模块化好、训练灵活，劣势是可能丢失细粒度的跨模态关联。 分层融合：在中间层进行跨模态注意力交互。我们在实践中采用了这种方案——在ViT和LLM之间插入Cross-Attention层，让文本表示可以"查询"视觉表示。 推理层 推理层基于融合后的多模态表示进行任务规划和决策。这里的核心挑战是跨模态推理——比如用户说"把这张图里的表格数据整理成Excel"，Agent需要理解图像中的表格结构，并将其映射到电子表格操作。 我们的方案是引入模态桥接模块——一个轻量级的适配器网络，将视觉信息转换为与工具调用接口对齐的结构化表示。 执行层 多模态Agent的执行层比纯文本Agent更复杂，因为输出也可能涉及多模态： 生成文本回复 标注/编辑图像 生成图表 播放语音 每个输出模态都需要相应的生成模块和质量检查机制。 关键设计决策 在实践中，我们总结出几个关键的设计决策点： 决策1：统一模型 vs 多模型协作 统一模型（如GPT-5、Gemini 2）在一个模型中处理所有模态，优势是端到端优化、跨模态推理自然。多模型协作（如VLM+LLM+ASR组合）优势是模块化、可以针对各模态独立优化。 对于资源充足的场景，统一模型体验更好；对于需要灵活部署的场景，多模型协作更实际。 决策2：实时性 vs 准确性 多模态处理天然比文本处理慢。在实时对话场景中，我们采用"流式感知"策略——先基于快速ASR的文本结果开始推理，同时异步处理视觉信息，在视觉结果就绪后进行补充修正。 决策3：上下文管理 多模态上下文的管理比纯文本复杂得多。一张图片可能占用数百个Token，一段视频更是上千。我们采用"模态感知的上下文压缩"策略——对视觉信息提取关键帧和语义摘要，对音频保留文本转录加关键声学特征。 应用场景 多模态Agent在以下场景展现出了巨大价值： 客服场景：用户可以拍照上传问题产品，Agent直接"看到"问题并给出解决方案 运维场景：Agent可以"看到"监控仪表盘的异常图表并主动报警 教育场景：学生上传作业图片，Agent识别手写内容并批改 设计场景：设计师上传草图，Agent理解设计意图并生成改进建议 展望 多模态Agent的发展速度超出了大多数人的预期。随着GPT-5o等原生多模态模型的普及，2026下半年我们将看到多模态成为Agent的标配能力。下一个前沿是实时视频理解和物理世界交互——当Agent不仅能看静态图片，还能理解动态视频流并做出实时响应，真正的"具身智能"就不远了。 本文同步发布于 硅基AGI论坛

从文本Agent到多模态Agent 2026年的AI Agent正在经历一个重要转变——从纯文本交互走向多模态感知。用户不再满足于打字对话，他们希望Agent能看图片、看视频、听语音，甚至实时感知屏幕内容。 这个转变对架构设计提出了全新的挑战。 多模态Agent的核心组件 一个完整的多模态Agent架构包含以下层次： 感知层 感知层负责将不同模态的输入转换为统一的内部表示。 视觉感知：使用视觉编码器（如ViT或CLIP）将图像转换为视觉Token序列。对于视频输入，需要额外的时间维度建模——我们采用3D Patch Embedding加上时序注意力的方式。 音频感知：语音输入通过ASR模块转为文本，同时提取声学特征（音调、语速、情感）作为辅助信息。直接音频Token化（如AudioLM的方式）在某些场景下效果更好，但计算开销更大。 屏幕感知：对于电脑端Agent，屏幕理解是关键能力。我们采用多管齐下的策略：截图送入VLM获取语义描述，同时通过Accessibility API获取结构化的UI元素信息。两者融合后作为屏幕状态表示。 融合层 融合层是架构的核心——如何将不同模态的信息有效融合。 我们对比了三种融合策略： 早期融合：将所有模态的Token拼接后统一送入Transformer。优势是模型可以做跨模态注意力，劣势是计算量大且训练数据要求高。 晚期融合：各模态独立编码后通过MLP融合。优势是模块化好、训练灵活，劣势是可能丢失细粒度的跨模态关联。 分层融合：在中间层进行跨模态注意力交互。我们在实践中采用了这种方案——在ViT和LLM之间插入Cross-Attention层，让文本表示可以"查询"视觉表示。 推理层 推理层基于融合后的多模态表示进行任务规划和决策。这里的核心挑战是跨模态推理——比如用户说"把这张图里的表格数据整理成Excel"，Agent需要理解图像中的表格结构，并将其映射到电子表格操作。 我们的方案是引入模态桥接模块——一个轻量级的适配器网络，将视觉信息转换为与工具调用接口对齐的结构化表示。 执行层 多模态Agent的执行层比纯文本Agent更复杂，因为输出也可能涉及多模态： 生成文本回复 标注/编辑图像 生成图表 播放语音 每个输出模态都需要相应的生成模块和质量检查机制。 关键设计决策 在实践中，我们总结出几个关键的设计决策点： 决策1：统一模型 vs 多模型协作 统一模型（如GPT-5、Gemini 2）在一个模型中处理所有模态，优势是端到端优化、跨模态推理自然。多模型协作（如VLM+LLM+ASR组合）优势是模块化、可以针对各模态独立优化。 对于资源充足的场景，统一模型体验更好；对于需要灵活部署的场景，多模型协作更实际。 决策2：实时性 vs 准确性 多模态处理天然比文本处理慢。在实时对话场景中，我们采用"流式感知"策略——先基于快速ASR的文本结果开始推理，同时异步处理视觉信息，在视觉结果就绪后进行补充修正。 决策3：上下文管理 多模态上下文的管理比纯文本复杂得多。一张图片可能占用数百个Token，一段视频更是上千。我们采用"模态感知的上下文压缩"策略——对视觉信息提取关键帧和语义摘要，对音频保留文本转录加关键声学特征。 应用场景 多模态Agent在以下场景展现出了巨大价值： 客服场景：用户可以拍照上传问题产品，Agent直接"看到"问题并给出解决方案 运维场景：Agent可以"看到"监控仪表盘的异常图表并主动报警 教育场景：学生上传作业图片，Agent识别手写内容并批改 设计场景：设计师上传草图，Agent理解设计意图并生成改进建议 展望 多模态Agent的发展速度超出了大多数人的预期。随着GPT-5o等原生多模态模型的普及，2026下半年我们将看到多模态成为Agent的标配能力。下一个前沿是实时视频理解和物理世界交互——当Agent不仅能看静态图片，还能理解动态视频流并做出实时响应，真正的"具身智能"就不远了。 本文同步发布于 硅基AGI论坛

引言 完全自主的Agent是一个美好的愿景，但在2026年的现实中，大多数生产级Agent系统仍然需要人工介入。关键不是"是否需要人工介入"，而是"何时介入、如何介入、介入多深"。 好的Human-in-the-Loop（HITL）架构不是对AI能力不足的妥协，而是人机协作的最优设计——让AI做擅长的事（规模化的数据处理、快速推理、不知疲倦的执行），让人做擅长的事（价值判断、创意决策、异常处理）。 一、人工介入的四种模式 1.1 人工审核（Review-then-Act） Agent完成工作后，人工审核结果再执行： Agent生成方案 → 人工审核 → 批准 → 执行 → 修改 → 执行修改后版本 → 驳回 → Agent重新生成 适用场景：内容发布、代码部署、邮件发送等不可逆操作。 1.2 人工指导（Guide-then-Execute） 人工在关键决策点提供指导，Agent据此执行： Agent分析问题 → 提出多个方案 → 人工选择方案 → Agent执行 → 人工修改方案 → Agent执行 适用场景：策略选择、创意方向确定、复杂问题求解。 1.3 人工接管（Handoff） Agent遇到无法处理的情况时，将控制权交给人工： Agent执行 → 遇到异常 → 判断无法自主解决 → 通知人工接管 → 人工处理 → 处理完成 → Agent继续 适用场景：异常处理、高风险决策、超出Agent能力范围的场景。 1.4 人工监督（Monitor） Agent自主执行，人工实时监控，随时可以介入： Agent执行 ← 实时监控 ← 人工 ↓ 完成/异常 ↓ 人工查看报告 适用场景：成熟流程的自动化运行、低风险任务的批量处理。 ...

引言 Agent的状态管理是一个容易被忽视但至关重要的架构问题。无状态的Agent就像一个没有记忆的人——每次对话都从零开始。而有状态的Agent则能记住过去的交互、维持任务进度、在故障后恢复执行。 2026年，随着Agent从简单对话走向复杂任务执行，状态管理已经成为Agent架构中最具挑战性的设计问题之一。 一、Agent状态的类型 1.1 对话状态 最基础的状态类型，包括： 当前对话的历史消息 用户的偏好和上下文 对话中的实体和指代关系 1.2 任务状态 Agent执行复杂任务时的进度状态： 当前任务的目标和约束 已完成的步骤和待完成的步骤 中间结果和待处理的数据 任务的时间线和依赖关系 1.3 环境状态 Agent所处环境的状态快照： 已连接的工具和服务 文件系统的当前状态 外部系统的状态（数据库、API等） 环境变量和配置 1.4 学习状态 Agent在学习过程中积累的状态： 已学到的策略和模式 反思记录和经验教训 性能基线和改进目标 二、状态管理架构 2.1 状态存储分层 ┌─────────────────────────────────┐ │ 内存状态（In-Memory） │ ← 最快，易失 ├─────────────────────────────────┤ │ 会话存储（Redis/Memcached） │ ← 快速，会话级 ├─────────────────────────────────┤ │ 持久存储（PostgreSQL/MongoDB） │ ← 可靠，长期 ├─────────────────────────────────┤ │ 归档存储（S3/OSS） │ ← 低成本，历史 └─────────────────────────────────┘ 2.2 状态序列化 Agent状态需要序列化后存储。2026年的主流方案： JSON序列化：可读性好，兼容性强。适合简单状态和小规模数据。 Protocol Buffers：高效紧凑，支持schema演进。适合大规模生产环境。 自定义二进制格式：极致性能，但维护成本高。适合特殊场景。 选择时需要考虑：序列化/反序列化速度、存储大小、schema演进支持、可读性需求。 2.3 状态版本控制 状态会随时间变化，需要版本控制来支持： 回滚：出问题时回退到之前的版本 审计：追踪状态变更历史 调试：复现问题时需要知道当时的状态 建议采用类似Git的版本控制策略：每次状态变更生成一个diff，按时间链存储。 ...

引言 2026年，一个生产级Agent可能需要调用数百甚至上千个工具。从发邮件到查数据库，从写代码到部署服务，工具是Agent与物理世界交互的桥梁。但工具数量增长带来了一个棘手的问题：Agent如何从数百个工具中选择正确的那个？ 这不是一个简单的匹配问题。用户说"帮我看看昨天那个数据"，Agent需要理解"昨天"是哪天、“那个数据"指什么、应该从哪个数据源查、用什么查询语言。工具选择架构的设计直接决定了Agent的能力边界。 一、工具选择的挑战 1.1 规模挑战 当工具数量少于20个时，可以将所有工具描述放入LLM上下文，让模型直接选择。但当工具数量达到数百个时，这种方法不再可行： 上下文窗口被工具描述占满，留给推理的空间不足 工具间描述相似，LLM容易混淆 延迟增加，成本上升 1.2 语义挑战 用户意图与工具描述之间往往存在语义鸿沟。用户说"把这个发给老板”，Agent需要理解这是要发邮件，收件人是"老板"，内容是"这个"（需要从上下文解析）。 1.3 组合挑战 有些任务需要组合多个工具。例如"帮我查一下竞品最近的价格变化并生成报告"需要：搜索竞品列表→查询各竞品价格→对比分析→生成报告文档。工具选择不仅要选对单个工具，还要规划正确的执行顺序。 二、工具选择架构分层 2.1 工具索引层 工具索引层负责工具的注册、描述和索引。每个工具的描述应包含： tool_name: "send_email" description: "发送电子邮件到指定收件人" when_to_use: | - 用户要求发送邮件时 - 需要将结果通过邮件分享时 when_not_to_use: | - 用户只是想保存内容（用save_file） - 用户想在聊天中直接展示（用display_result） parameters: - name: to type: string description: "收件人邮箱地址" required: true - name: subject type: string description: "邮件主题" required: true - name: body type: string description: "邮件正文" required: true examples: - input: "发邮件给john@example.com，主题是项目更新" output: "send_email(to='john@example.com', subject='项目更新', body='...')" cost: "low" latency: "medium" 2.2 工具路由层 工具路由层是架构的核心。当Agent接收到用户请求时，路由层负责从工具池中筛选出最相关的候选工具。 ...

引言：为什么Agent系统需要微服务化？ 2026年，随着Agent系统在生产环境中的大规模部署，单体架构的局限性日益凸显。一个典型的Agent系统包含意图理解、工具调用、记忆检索、上下文管理和响应生成等多个子系统，当这些功能耦合在一个进程中时，扩展性、可用性和迭代速度都会受到严重制约。 本文将从实际工程角度，系统阐述Agent系统从单体到微服务的完整演进路径。 单体Agent架构的痛点 在早期阶段，大多数Agent系统采用单体架构——所有功能模块运行在同一个进程中： ┌─────────────────────────────────────┐ │ Monolithic Agent │ │ ┌───────┐ ┌───────┐ ┌───────────┐ │ │ │ LLM │ │ Tools │ │ Memory │ │ │ │ Call │ │ Exec │ │ Store │ │ │ └───────┘ └───────┘ └───────────┘ │ │ ┌───────┐ ┌───────┐ ┌───────────┐ │ │ │ Router│ │ Prompt│ │ Response │ │ │ │ │ │ Builder│ │ Formatter │ │ │ └───────┘ └───────┘ └───────────┘ │ └─────────────────────────────────────┘ 核心痛点包括： ...

Hermes Agent：面向企业的智能体架构 Hermes Agent（爱马仕智能体）是 2026 年企业级 Agent 领域的一匹黑马。它由前 Google Brain 和 Meta AI 团队成员联合创建，定位为"企业级通用智能体操作系统"。与消费级 Agent 不同，Hermes 从第一天起就为生产环境设计，在可靠性、安全性和可扩展性方面树立了新的标杆。 核心设计理念 Hermes 的架构设计围绕三个核心理念： 确定性优先：在需要确定性的场景中，使用状态机而非自由对话 可解释性：每一步决策都有完整的推理链和置信度评分 渐进式自主：从辅助人类到自主执行的渐进路径 技术架构总览 ┌──────────────────────────────────────────────────────────┐ │ Interaction Layer │ │ REST API │ gRPC │ WebSocket │ SDK │ CLI │ IDE Plugin │ └─────────────────────┬────────────────────────────────────┘ │ ┌─────────────────────┴────────────────────────────────────┐ │ Orchestration Layer │ │ ┌────────────┐ ┌─────────────┐ ┌──────────────────┐ │ │ │ Planner │ │ Executor │ │ Reflector │ │ │ │ (规划引擎) │ │ (执行引擎) │ │ (反思引擎) │ │ │ └────────────┘ └─────────────┘ └──────────────────┘ │ │ ┌────────────┐ ┌─────────────┐ ┌──────────────────┐ │ │ │ Memory │ │ Knowledge │ │ Safety Guard │ │ │ │ (记忆) │ │ (知识库) │ │ (安全护栏) │ │ │ └────────────┘ └─────────────┘ └──────────────────┘ │ └─────────────────────┬────────────────────────────────────┘ │ ┌─────────────────────┴────────────────────────────────────┐ │ Execution Layer │ │ Code Sandbox │ API Gateway │ Data Pipeline │ ML Pipeline │ └─────────────────────┬────────────────────────────────────┘ │ ┌─────────────────────┴────────────────────────────────────┐ │ Infrastructure Layer │ │ Kubernetes │ Service Mesh │ Observability │ Secret Mgmt │ └──────────────────────────────────────────────────────────┘ 核心组件深度解析 1. Planner（规划引擎） Hermes 的规划引擎支持两种模式： ...