Agent 架构是定义AI智能体组件与交互方式的蓝图,让Agent得以感知环境、进行推理并采取行动。 主流 Agent 架构可分为以下类别: 反应式架构 审慎式架构 混合式架构 神经符号式架构 认知式架构 — 2 — LangGraph Agent 设计模式 Agent 架构与设计模式紧密相关,但属于 关注系统构建的"方法"——底层机制及数据/控制流 Agent 设计模式:解决特定问题的高层可复用策略/模板,不聚焦内部细节而指导跨场景行为交互(类似"配方") 关注"what"与"why"——你希望该智能体展现出什么样的行为或能力 即整合了多推理工具实现自适应,效率远超单一方法 核心优势: 推理模块:按特定顺序组合基础推理步骤 无需人工:自主生成策略,无需任务标注 任务自适应:类人式规划最优解 可迁移性:策略可跨语言模型复用 — 6 — 结语 本文系统探讨了智能体架构的演进——从传统反应式、审慎式模型到混合式、神经符号式及认知式架构,并通过LangGraph实现展示了规划、协作、反思等设计模式。
Google DeepResearch Google Gemini DeepResearch(见图 1)是一个基于 Agent 的系统,设计用于自主信息检索和综合。 它通过多步 Agent 管道运行,动态和迭代地查询 Google 搜索以系统地探索复杂主题。该系统设计用于处理大量基于网络的资源,评估收集的数据的相关性和知识差距,并执行后续搜索以解决它们。 图 1:Google Deep Research Agent 生成使用 Google 搜索作为工具的执行计划。 关键的架构组件是系统异步管理此过程的能力。 视觉摘要 ** ** 图 4;规划设计模式 关键要点 规划使 Agent 能够将复杂目标分解为可操作的顺序步骤。 它对于处理多步任务、工作流自动化和导航复杂环境至关重要。 明确提示或设计任务以要求规划步骤会在 Agent 框架中鼓励这种行为。 Google Deep Research 是一个代表我们分析使用 Google 搜索作为工具获得的来源的 Agent。
这是"Agent设计模式"系列文章的最后一篇。 可扩展:新增功能只需添加新Agent 二、Agent角色设计:职责分离 Multi-Agent系统的第一步是角色定义。 每个Agent必须明确: 它负责什么 它的输入是什么 它的输出是什么 它和其他Agent如何交互 ▪ 代码审查系统的角色设计 # agent_roles.py from dataclasses import 其他Agent定义 } ▪ 角色设计原则 单一职责每个Agent只负责一个明确的领域 边界清晰输入输出定义明确,避免职责重叠 可替换性相同角色的Agent可以互换 可测试性角色定义应该便于单元测试 三、 ) 个人助理Agent(日程、邮件、笔记) 数据分析Agent(读取、分析、可视化) 客服Agent(问答、转接、知识库) 结语 Multi-Agent模式是Agent设计的高阶形态,它让我们能够构建更强大
架构设计模式—6大设计原则架构设计是软件开发中非常重要的一环,良好的架构可以提高软件系统的可维护性、可扩展性和可重用性。在架构设计过程中,遵循一定的设计原则可以帮助我们构建合理的架构。 本文介绍6大常用的架构设计原则,他们是:单一职责原则(Single Responsibility Principle, SRP) 单一职责原则要求一个类或模块只负责完成一项职责。 以上6大设计原则是架构设计过程中常用的准则,不同的原则可以结合使用,根据具体的应用场景进行选择。遵循这些原则可以帮助我们构建高质量的软件系统。 这样设计的好处是,我们可以方便地添加新的形状,而不会影响到已有的代码功能。
架构设计原则 6大设计原则 Single Responsibility Principle : 单一职责原则 Liskov Substitution Principle : 里氏替换原则 6 内容耦合: 这是最高程度的耦合,也是最差的耦合。当一个模块直接使用另一个模块的内部数据,或通过非正常入口而转入另一个模块内部。 内聚性又称块内联系。 6 功能内聚: 这是最强的内聚,指模块内所有元素共同完成一个功能,缺一不可。与其他模块的耦合是最弱的。 image 1、GOF在书中说:设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述; 设计模式就是不断反省,将软件开发经验抽象积累成解决问题的预案。 3、设计模式中广泛遵循了两条设计原则:面向接口编程,而不是实现;优先使用组合,而不是继承。 ........
今天,我将结合Spring AI Alibaba和AgentScope等主流框架的最佳实践,跟大家一起聊聊AI Agent开发中6种最实用的设计模式。 希望对你会有所帮助。 一、AI Agent的架构演进 在深入具体模式之前,我们先花一分钟理解Agent系统的核心架构。 任何一个成熟的Agent系统,都由以下几个核心模块组成: 在这个架构基础上,学术界和工业界总结出了多种设计模式。 从最简单的单体Agent到复杂的多智能体协作,每种模式都有其独特的优势和适用场景。 缺点:架构复杂度高;Agent间通信协调有额外开销。 适用场景:大型企业系统、多部门协同业务、复杂流程自动化。 希望这份设计模式指南能帮你构建出更加稳定、可靠、智能的AI Agent系统。
Hermes Agent 技术架构深度解析:110K+ Star,自进化 AI Agent 架构设计 2026 年「术哥无界」系列实战文档 X 篇原创计划 第 91 篇,Hermes 最佳实战第 1 篇大家好 这篇文章从源码出发,把 Hermes Agent 的架构拆开来看。重点不是介绍它有什么功能(README 写得够详细了),而是分析它为什么这样设计,以及这些设计决策背后的取舍。1. 系统架构总览架构上的几个关键设计决策:Agent 循环和工具执行在同一进程:通过 run_agent.py 中的 AIAgent 类管理整个生命周期,没有用微服务那套东西工具自注册模式:每个工具文件在模块级别调用 这是一个多级检索的设计,不同类型的记忆走不同的通道。图 3:记忆与学习闭环 — 五阶段循环 + 三层记忆架构 + 多级检索链路你在项目中用过类似的记忆持久化方案吗?欢迎在评论区聊聊。6. 这在 Agent 框架领域是比较少见的。如果你在做 Agent 相关的架构设计,Hermes Agent 的闭环学习和上下文管理部分值得细看。
二、设计原则:从问题到方案的推导Missions架构的大多数设计决策都源于上述核心观察。 步骤6:里程碑验证。一个里程碑内的所有功能完成后,运行器触发验证,使用全新的Agent。 关键升级为:每个已完成功能都会生成专属的代码审查Agent。这些审查Agent运行前未见相关代码,无实现偏见,审查过程从设计之初即为对抗性。 52.5%的代码量为测试代码,89.25%的语句覆盖率,这些数字共同说明:质量不是事后检查出来的,而是架构设计进去的。六、结构化交接与知识累积多Agent系统在长周期运行中最大的风险是上下文丢失。 软件工程的瓶颈正在从代码编写能力转向架构设计能力与人类注意力管理。
概述 目标读者:技术负责人 / 平台架构师 / SRE / 数据工程负责人undefined设计取向:平台无关(K8s/VM/Serverless/DB/网关皆可接入),以 MAPE‑K 闭环为核心,强调安全 设计原则(Design Tenets) 平台无关:统一抽象(Asset/App/BusinessService/Environment/Case/Plan/Observation…)。 推荐架构:“Redpanda 承载观测流量 + NATS 承载控制面事件”,兼顾吞吐与时延,简化隔离域与配额治理。 AI Agent Workflow 阈值机制 θ(分析置信度阈值): 结合统计显著性、图谱证据、向量相似度、LLM 自信度。 观测与治理(Ops of the Agent) 自监控: 队列积压(ops.
导读:《架构设计》系列为极客时间李运华老师《从0开始学架构》课程笔记。本文为第六部分,主要介绍高可用计算架构,介绍了高可用架构设计的要点以及不同架构方式的优缺点。 高可用计算架构 设计思想:通过增加更多服务器来达到计算高可用 设计复杂度:主要体现在任务管理方面,即当任务在某台服务器上执行失败后,如何将任务重新分配到新的服务器进行执行 哪些服务器可以执行任务 每个服务器都可以执行任务 ,服务器执行完任务后,需要向任务管理器反馈任务执行结果,任务管理器根据任务执行结果来决定是否需要将任务重新分配到另外的服务器上执行 架构设计 主备 主备架构是计算高可用最简单的架构,和存储高可用的主备复制架构类似 ),增加新的机器作为从机,新的从机准备就绪后,任务分配器继续按照原有的设计策略分配任务 优缺点 优点:主从架构的从机也执行任务,发挥了从机的硬件性能。 存储高可用集群把双机架构和集群架构进行了区分;而在计算高可用集群架构中,2 台服务器的集群和多台服务器的集群,在设计上没有本质区别,因此不需要进行区分 对称集群 通俗的叫法是负载均衡集群。
Datetime类型,但你强转为int,编译时是没问题的,但一运行就报错,泛型约束能有效减少这种情况 完善ObservableList 到目前为止,我们自定义的动态数据集合ObservableList是非常好的设计
本文从架构师视角,拆解一个自托管 AI 网关的核心设计决策。 这里的顺序很重要,前者从 AI 出发设计架构,后者只是在旧瓶里装新酒。 二、核心架构:三层模型 2.1 网关层:单一进程,多路复用 设计决策:一个 Gateway 进程管理所有渠道连接,而不是每个渠道一个服务。 六、AI-Native 架构的思考 6.1 什么是 AI-Native? 不是"加了 LLM 的系统",而是从 LLM 的特性出发重新设计架构。 但自托管、多渠道、Agent 原生的设计方向,值得架构师们思考。 最后送上一句: 在 AI 时代,最好的架构不是最优雅的,而是最能适应不确定性的。
我从AIP平台架构设计Agent产品经验软件架构师罗小东,多年架构和平台产品设计经验,目前在Agent场景落地结合中。 这里的经验更多偏向于架构设计与工程实践,每个架构师有自己的思路,我有我思。前期的时候,也是考虑了很久,觉得企业级AI智能体平台在架构设计上相对来说是会有些不一样的。 模型中立架构的设计与权衡前期的时候,AI平台都是绑定单一模型的,比如只用GPT-4或者只用Claude。 插件式扩展的架构优势AIP平台支持插件式扩展,这个设计有意思。插件式扩展意味着用户可以灵活添加功能模块,不需要改动核心代码。 这个设计体现了平台的灵活性——不同场景有不同的需求,平台需要提供足够的配置空间。总结总的来说,AIP智能体平台的架构设计是一个阶段性的反馈,体现了企业级AI平台在技术选型和工程实践上的一些新思路。
❝当 AI Agent 需要的知识越来越多,把一切都塞进 System Prompt 显然不是个好主意。本文从架构设计的角度出发,深入探讨一种优雅的解法——「Skill 渐进式加载机制」。 干扰」:在多 Agent 协作场景中,不同 Agent 加载的技能可能互相"串台" 那么,如何设计一套机制,让 Agent 能够 「按需加载」 技能内容,同时 「对 Token 友好」、「对缓存友好」 五、模块二:Session State Key 设计 Session State 是 Skill 加载状态的持久化存储。Key 的设计直接影响多 Agent 隔离和查询效率。 限制最大加载数量(如超限,按最近使用排序保留) │ ├─ 6. 为找不到匹配 Tool Result 的 Skill 构建回退内容 │ └─ 6. 必要时插入回退的 System Message 「为什么这样设计?」
这些技术适用于构建从简单聊天机器人到复杂多 Agent 系统的各类应用,能够显著提升 Agentic 应用的性能和可靠性。 Agentic 模式是构建智能系统的架构蓝图,在主要章节中已有详细阐述。 例如,一个经过上下文工程设计的 Agent 在响应查询前,会整合用户的日历可用性(工具输出)、与邮件收件人的专业关系(隐式数据)以及过往会议记录(检索文档)。 使用 Google Gems Google 的 AI"Gems"(见图 1)代表其大型语言模型架构中的用户可配置功能。 底层模型设计为在整个对话过程中始终遵循这些预定义指令。 这允许为专注应用创建高度专业化的 AI Agent。例如,可配置 Gem 作为仅引用特定编程库的代码解释器。 超越示例范畴,使用明确角色、系统级指令和清晰分隔符构建提示,为精细控制模型提供了必要的架构层次。 这些技术在构建自主 Agent 的背景下变得至关重要,它们为复杂多步骤操作提供了必要的控制与可靠性。
配置完监控插件后,要重启agent Note: 如果不重启,就读不到新添的配置,从服务端尝试获取信息,会出现如下报错 [root@zbx-server zabbix_agentd.d]# zabbix_get [root@zbx-server zabbix_agentd.d]# 重启agent [root@zbx-target zabbix_agentd.d]# /etc/init.d/zabbix-agent restart Shutting down Zabbix agent: [ OK ] Starting Zabbix agent: ,创建 Graphs ,拼接 Screens 就可以展示出非常炫目的dashboard效果 ---- 命令汇总 wget http://repo.zabbix.com/zabbix/2.4/rhel/6/ x86_64/zabbix-release-2.4-1.el6.noarch.rpm zabbix_get -s zbx-target -p 10050 -k "system.cpu.load[all,
本框架致力于在人类领导与底层模型原始能力间建立最纯净对话通道,确保每个 Agent 均以峰值潜力运行。 该框架构建为专业化 Agent 团队,每个 Agent 针对开发生命周期中的核心功能专门设计。 核心组件架构 为高效运用前沿大语言模型,本框架将不同开发角色分配给专业化 Agent 团队。这些 Agent 并非独立应用,而是通过精心设计的角色特定提示与上下文在 LLM 中调用的概念化人格。 最终,此人类主导模式在开发者战略规划与 Agent 战术执行间建立强大协同效应。开发者得以从常规任务中解放,将专业智慧聚焦于创造最大价值的创意性挑战与架构设计。 ** ** 图 1:编码专家角色示意图 增强型团队领导原则 成功驾驭此框架需实现从独立贡献者向人机协作团队领导者的角色转型,遵循以下核心原则: 坚守架构主导权 您的核心职责是制定战略方向并掌控高层架构设计 通过将战术执行委派予 Agent,开发者得以将认知资源聚焦于真正核心领域:战略创新、韧性架构设计,以及打造用户惊喜产品所需的创造性问题破解。
Agent Skill Script 架构设计指南 本指南面向 Skill 架构师与 Agent 开发者,聚焦"何时用 Script"与"如何设计 Tool-Like 模块" 1. Script 架构设计原则(Tool-Like 思维) 优秀的 Skill Script 应像一个标准的 API 工具,遵循以下六大原则: 2.1 黑盒封装 隐藏实现细节:内部逻辑、密钥、第三方依赖对 6. Script 的设计目标不是"永不出错",而是"出错时可被 Agent 理解与处理"。 最终目标:通过 Tool-Like 的 Script 架构,让 Agent 从"会聊天的 AI"进化为"能可靠执行任务的数字化员工"。
前言:Human-in-the-Loop(HIL)是一种AI系统设计模式,它允许人类在AI Agent的决策过程中介入并提供反馈或决策。 这种模式特别适用于高风险或敏感的操作场景一、HIL架构的核心价值与挑战在金融交易、数据库管理、医疗诊断等高危场景中,AI Agent的自主决策存在两类核心风险:不可逆操作(如删除数据库记录 而HIL架构通过精准断点控制,仅在关键节点介入,实现效率与安全的动态平衡。二、LangGraph的四大创新设计1. 安全增强设计# 四眼原则审批实现def quadruple_approval(state): approvals = state.get("approvals", []) if len(approvals 由于文章篇幅有限,关于AI Agent相关技术知识点,我整理成了一个2W字的文档,粉丝朋友自行领取:《想要读懂AI Agent(智能体),看这里就够了》如果本次分享对你有所帮助,记得告诉身边有需要的朋友
我们从这样一个前提开始:构建智能 Agent 就像在技术画布上创作一幅复杂的艺术作品——这个过程不仅需要一个强大的认知引擎(如大型语言模型),还需要一套稳健的架构蓝图。 虽然每种模式都针对特定的设计挑战,但可以通过将它们归类到反映智能 Agent 核心能力的基础类别中来整体理解它们。 核心执行和任务分解: 在最基本的层面上,Agent 必须能够执行任务。 为复杂系统组合模式 Agentic 设计的真正力量不是来自孤立地应用单一模式,而是来自巧妙地组合多种模式以创建复杂的多层系统。 协作分析和写作: 单个 Agent 可能会处理这个问题,但更稳健的架构将采用多 Agent 协作。"研究员" Agent 可以负责执行搜索计划和收集原始信息。 它们提供了将大型语言模型的原始认知能力转变为可靠且有目的的系统所需的架构规范。