Agent 架构是定义AI智能体组件与交互方式的蓝图,让Agent得以感知环境、进行推理并采取行动。 主流 Agent 架构可分为以下类别: 反应式架构 审慎式架构 混合式架构 神经符号式架构 认知式架构 — 2 — LangGraph Agent 设计模式 Agent 架构与设计模式紧密相关,但属于 关注系统构建的"方法"——底层机制及数据/控制流 Agent 设计模式:解决特定问题的高层可复用策略/模板,不聚焦内部细节而指导跨场景行为交互(类似"配方") 关注"what"与"why"——你希望该智能体展现出什么样的行为或能力 多智能体监督:LLM协调调度各智能体 跟网络架构类似,但采用监督智能体(而非路由器)来协调各智能体 层次化智能体团队 当单个智能体无法完成任务时,监督智能体协调多个由多智能体组成的团队 — 4 — ——从传统反应式、审慎式模型到混合式、神经符号式及认知式架构,并通过LangGraph实现展示了规划、协作、反思等设计模式。
近两年深度搜索Agent发展很快各家的实现思路也越来越成熟,围绕这两个问题业界逐渐沉淀出几种主流架构:从最基础的Planner-Only,到加入评估反馈的双模块设计,再到Sentient Labs提出的递归式方案 这篇文章将整理这些架构并顺便附上一些实用的prompt模板。 迭代式搜索Agent 在讨论更复杂的架构之前,先回顾一下最基础的迭代式搜索Agent。 这样Planner输出的计划才足够具体,下游的执行Agent才能照着执行。 Planner承担的任务复杂度高是整个架构的核心节点。 所以强烈建议用推理能力强的模型来做Planner,比如GPT-4o、Claude 3.5 Sonnet或者专门的推理模型如o1、DeepSeek-R1等。 递归搜索Agent 前面介绍的架构本质上都是迭代式的,但从算法角度看迭代能做的事递归也能做,而且递归天然适合处理可分解的层次化问题。
其设计目标是发现缺陷、提出改进建议并提供结构化反馈 这种关注点分离非常有效,因为它避免了 Agent 审查自身工作时可能产生的"认知偏差"。 我们使用 gpt-4o 以获得更好的推理。 ## 使用较低的温度以获得更确定性的输出。 generator Agent 设计用于创建关于给定主题的初始草稿段落,被指示撰写简短信息丰富的文章,并将其输出保存至状态键 drafttext。 当任务需要通用生产者 Agent 可能遗漏的高客观性或专门评估时,使用独立评审者 Agent 视觉摘要 ** ** 图 1:反思设计模式,自我反思 ** ** 图 2:反思设计模式,生产者和评审者 此评估可由 Agent 自身(自我反思)执行,或通常更有效地由不同评审者 Agent 执行,这代表了模式内的关键架构选择 虽然完全自主的多步反思过程需要强大的状态管理架构,但其核心原理可在单个生成-评审
添加允许使用的工具 safe_globals.update(global_vars) # 4. _': iter, '_iter_unpack_sequence_': guarded_iter_unpack_sequence, } # 4. 写Python代码调用工具 4. 从输出中提取关键信息 5. 我见过太多项目因为没做沙箱,导致Agent删库、泄露数据。安全不是事后补救,是事前设计。 第二,标准化。 工具接口不统一,Agent就会乱。50个工具有50种接口风格,LLM根本记不住。 设计的时候就要考虑动态发现、自动注册,不要每次加工具都改prompt。 工具调用是Agent最实用的能力,也是最容易出问题的地方。 用好了,Agent能干很多事;用不好,Agent就是个定时炸弹。
本文将在langchain4j官方示例基础上(不熟悉langchain4j的朋友,请移步langchain4j学习系列),介绍几个主要模式的用法,今天先来看最基本的Agent如何实现 为方便讨论,先交待一下这一系列的业务背景 、最基础的Agent示例 1 /** 2 该示例演示了如何实现一个基础Agent(改编自langchain4j官网示例) 3 注意:Agent只有与其他Agent结合使用时才更有用,后续步骤中将展示这一点。 4 如果只有一个Agent,使用 AiService 会是更好的选择。 5 这个基础Agent将用户的个人简介转换成一个简洁而完整的简历。 \ Anthropic [译] AI Workflow & AI Agent:架构、模式与工程建议(Anthropic,2024) Agents and Agentic AI | LangChain4j
Hermes Agent 技术架构深度解析:110K+ Star,自进化 AI Agent 架构设计 2026 年「术哥无界」系列实战文档 X 篇原创计划 第 91 篇,Hermes 最佳实战第 1 篇大家好 这篇文章从源码出发,把 Hermes Agent 的架构拆开来看。重点不是介绍它有什么功能(README 写得够详细了),而是分析它为什么这样设计,以及这些设计决策背后的取舍。1. 图 2:Agent 循环流程图 — 迭代预算控制、并行工具执行、中断与转向机制4. 图 4:子 Agent 委托架构 — 父子隔离、并行执行、深度控制说实话,子 Agent 并发最多 3 个这个限制,社区里有人吐槽过。对于复杂的并行场景,3 个子 Agent 确实不够用。 并发上限 3 个,复杂并行场景受限项目迭代节奏很快 - 不到 3 周发布了 4 个大版本,稳定性需要观察Windows 原生不支持,必须通过 WSL2关于抄袭的争议(中国团队指控架构级抄袭)目前还没有最终结论从架构设计上看
二、设计原则:从问题到方案的推导Missions架构的大多数设计决策都源于上述核心观察。 关键升级为:每个已完成功能都会生成专属的代码审查Agent。这些审查Agent运行前未见相关代码,无实现偏见,审查过程从设计之初即为对抗性。 52.5%的代码量为测试代码,89.25%的语句覆盖率,这些数字共同说明:质量不是事后检查出来的,而是架构设计进去的。六、结构化交接与知识累积多Agent系统在长周期运行中最大的风险是上下文丢失。 软件工程的瓶颈正在从代码编写能力转向架构设计能力与人类注意力管理。 Missions所代表的,不仅是技术的进步,更是一种全新的工程哲学:当智能体能够可靠地协作、验证和自我修正,人类的角色将从执行者转变为架构师 —— 设计系统,然后让系统自行运转。
概述 目标读者:技术负责人 / 平台架构师 / 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.
本文从架构师视角,拆解一个自托管 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平台在技术选型和工程实践上的一些新思路。
导读:《架构设计》系列为极客时间李运华老师《从0开始学架构》课程笔记。本文为第三部分,主要介绍 FMEA 方法,以及如何将 FMEA 方法应用于架构设计之中以提高服务可用性。 什么是FMEA FMEA(Failure mode and effects analysis,故障模式与影响分析)又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等 在架构设计领域,FMEA 的具体分析方法 给出初始的架构设计图 假设架构中某个部件发生故障 分析此故障对系统功能造成的影响 根据分析结果,判断架构是否需要进行优化 FMEA 分析表 功能点 当前的 FMEA 分析涉及的功能点, 个人理解 FMEA 方法是一种分析问题的方法,一共列出了 11 个点,我们在分析架构问题的时候,按照每个点逐一去适配、分析。 reference 从 0 开始学架构
本框架致力于在人类领导与底层模型原始能力间建立最纯净对话通道,确保每个 Agent 均以峰值潜力运行。 该框架构建为专业化 Agent 团队,每个 Agent 针对开发生命周期中的核心功能专门设计。 核心组件架构 为高效运用前沿大语言模型,本框架将不同开发角色分配给专业化 Agent 团队。这些 Agent 并非独立应用,而是通过精心设计的角色特定提示与上下文在 LLM 中调用的概念化人格。 最终,此人类主导模式在开发者战略规划与 Agent 战术执行间建立强大协同效应。开发者得以从常规任务中解放,将专业智慧聚焦于创造最大价值的创意性挑战与架构设计。 ** ** 图 1:编码专家角色示意图 增强型团队领导原则 成功驾驭此框架需实现从独立贡献者向人机协作团队领导者的角色转型,遵循以下核心原则: 坚守架构主导权 您的核心职责是制定战略方向并掌控高层架构设计 通过将战术执行委派予 Agent,开发者得以将认知资源聚焦于真正核心领域:战略创新、韧性架构设计,以及打造用户惊喜产品所需的创造性问题破解。
{ 2 3 @Agent(name = "hrReviewer", description = "审查简历以评估候选人是否符合HR要求,提供反馈和评分") 4 @SystemMessage \r\n\r\n**职责:**\r\n* 设计、实现并维护能够处理大规模支付与对账业务的后端服务。 技能缺失:缺乏云平台(AWS/Azure)或微服务架构经验,可能限制在高度分布式团队中的贡献。无明显危险信号。 技能缺失:缺乏云平台(AWS/Azure)或微服务架构经验,可能限制在高度分布式团队中的贡献。无明显危险信号。" 82行,即为3个评审Agent并行执行的结果。 Anthropic [译] AI Workflow & AI Agent:架构、模式与工程建议(Anthropic,2024) Agents and Agentic AI | LangChain4j
这次我们不再讨论前文的招聘场景,而是学习一种更为广泛使用的Agent模式:ReACT (推理+行动)。先来看示意图: 这跟人类解决问题的思考方式很像:loop(思考-行动)。 定义ReAct Agent 1 public interface ReActAssistant { 2 @SystemMessage(""" 3 你是一个使用ReAct 13 """) 14 @UserMessage("问:{{request}}") 15 @Agent("基于用户提供的问题进行思考和回答") 16 String 参考: Building Effective AI Agents \ Anthropic [译] AI Workflow & AI Agent:架构、模式与工程建议(Anthropic,2024) Agents and Agentic AI | LangChain4j
❝当 AI Agent 需要的知识越来越多,把一切都塞进 System Prompt 显然不是个好主意。本文从架构设计的角度出发,深入探讨一种优雅的解法——「Skill 渐进式加载机制」。 干扰」:在多 Agent 协作场景中,不同 Agent 加载的技能可能互相"串台" 那么,如何设计一套机制,让 Agent 能够 「按需加载」 技能内容,同时 「对 Token 友好」、「对缓存友好」 五、模块二:Session State Key 设计 Session State 是 Skill 加载状态的持久化存储。Key 的设计直接影响多 Agent 隔离和查询效率。 「关键架构决策」:Tool 的执行函数(Call)和 State 写入(StateDelta)是 「分离的」。 " │ ├─ 4. 从 State 读取已加载的 Skill 列表 │ ├─ 5. 限制最大加载数量(如超限,按最近使用排序保留) │ ├─ 6.
上篇学习了ReACT,今天继续学习PlanAndExecute模式 与ReACT模式的关键区别如下: 对比维度 ReAct Agent Plan-and-Execute Agent 思考模式 单步思考- 16 """) 17 @UserMessage("{{step}}") 18 @Agent("基于用户提供的问题生成计划") 19 String executeStep 25乘以4的结果是100.00。 请提供下一步指令。 参考: Building Effective AI Agents \ Anthropic [译] AI Workflow & AI Agent:架构、模式与工程建议(Anthropic,2024) Agents and Agentic AI | LangChain4j
今天我准备再录一个视频来讲解一下企业架构规划设计中的4A架构之间的关系和集成。 我昨天分享过一个视频,就有朋友给我留言说有些内容看不懂,因为我讲的很多视频它是需要有一定前导知识的,类似于我今天讲4A架构集成,那你至少应该对企业架构,对TOGAF,对企业架构规划的元模型有大概的一些了解 我们常说的4A架构就是业务架构、数据架构、应用架构和技术架构,其实去理解4A架构的集成核心,你仍然要去参考企业架构这本书里面谈到的企业架构元模型。 业务架构到应用架构集成 我们刚才讲到了,在业务建模里面会拆分出业务对象、业务活动、业务规则、业务角色这4个核心的要素。这4个核心的要素我们去详细考虑it实现的时候,一定会映射到它相关的应用功能。 所以说物理模型最终落地落地到我的数据库的架构设计底层存储上面,所以说基于这个图我们就能够更加清楚业务架构、数据架构、应用架构和技术架构之间的关联和映射关系。
前言:Human-in-the-Loop(HIL)是一种AI系统设计模式,它允许人类在AI Agent的决策过程中介入并提供反馈或决策。 这种模式特别适用于高风险或敏感的操作场景一、HIL架构的核心价值与挑战在金融交易、数据库管理、医疗诊断等高危场景中,AI Agent的自主决策存在两类核心风险:不可逆操作(如删除数据库记录 而HIL架构通过精准断点控制,仅在关键节点介入,实现效率与安全的动态平衡。二、LangGraph的四大创新设计1. builder.compile(checkpointer=memory, interrupt_before=["execute_users"])保存运行时上下文(变量/环境/执行位置)人类决策后从断点精确恢复执行4. [-4:])笔者结语:随着AI技术的不断进步,AI Agent将在更多领域发挥重要作用。
我们从这样一个前提开始:构建智能 Agent 就像在技术画布上创作一幅复杂的艺术作品——这个过程不仅需要一个强大的认知引擎(如大型语言模型),还需要一套稳健的架构蓝图。 虽然每种模式都针对特定的设计挑战,但可以通过将它们归类到反映智能 Agent 核心能力的基础类别中来整体理解它们。 核心执行和任务分解: 在最基本的层面上,Agent 必须能够执行任务。 为复杂系统组合模式 Agentic 设计的真正力量不是来自孤立地应用单一模式,而是来自巧妙地组合多种模式以创建复杂的多层系统。 协作分析和写作: 单个 Agent 可能会处理这个问题,但更稳健的架构将采用多 Agent 协作。"研究员" Agent 可以负责执行搜索计划和收集原始信息。 它们提供了将大型语言模型的原始认知能力转变为可靠且有目的的系统所需的架构规范。
这些技术适用于构建从简单聊天机器人到复杂多 Agent 系统的各类应用,能够显著提升 Agentic 应用的性能和可靠性。 Agentic 模式是构建智能系统的架构蓝图,在主要章节中已有详细阐述。 例如,一个经过上下文工程设计的 Agent 在响应查询前,会整合用户的日历可用性(工具输出)、与邮件收件人的专业关系(隐式数据)以及过往会议记录(检索文档)。 使用 Google Gems Google 的 AI"Gems"(见图 1)代表其大型语言模型架构中的用户可配置功能。 底层模型设计为在整个对话过程中始终遵循这些预定义指令。 这允许为专注应用创建高度专业化的 AI Agent。例如,可配置 Gem 作为仅引用特定编程库的代码解释器。 超越示例范畴,使用明确角色、系统级指令和清晰分隔符构建提示,为精细控制模型提供了必要的架构层次。 这些技术在构建自主 Agent 的背景下变得至关重要,它们为复杂多步骤操作提供了必要的控制与可靠性。