福田网站网页设计,个人可以做网站推广,免费dedecms企业网站模板,小众软件wordpress主题本文基于 Building Conversation Kernels for AI Agents 中的核心示意图与文字内容#xff0c;总结当前主流 Agent 架构的演进路径#xff0c;并结合图示拆解其设计动机、优缺点与适用场景。 一、背景#xff1a;为什么需要新的 Agent 架构#xff1f; 随着 AI Agent 从单…本文基于Building Conversation Kernels for AI Agents中的核心示意图与文字内容总结当前主流 Agent 架构的演进路径并结合图示拆解其设计动机、优缺点与适用场景。一、背景为什么需要新的 Agent 架构随着 AI Agent 从单轮问答演进到复杂、多轮、工具驱动任务传统的Single Agent SystemSAS暴露出明显问题上下文无限膨胀Context Pollution工具与指令耦合严重长对话下性能与稳定性下降复杂任务难以扩展为了解决这些问题Agent 架构逐步从单体 → 分工 → 编排 → 群体演进。二、On-Demand Tooling SAS按需加载技能的单体 Agent1. 核心思想在传统 SAS 的基础上引入Skill技能概念技能以独立SKILL.md形式存在描述功能、输入输出、可用工具Agent 在运行时按需学习并注入技能skill参考地址2. Agent 调用关系泳道图关键点Skill 一旦加载即进入长期上下文形成不可逆增长ToolsSkill LoaderSingle Agent (SAS)UserToolsSkill LoaderSingle Agent (SAS)User用户请求按需加载 SkillSkill 描述 和 Tool Schema调用工具工具结果回复结果3. 优点比静态工具集更灵活技能模块化、可复用降低初始上下文负担4. 致命问题上下文不可逆增长Irreversible Context Growth技能一旦注入为保持一致性就难以移除长会话后仍会走向 Context Pollution本质仍是“增强版单体 Agent”结论这是过渡方案而非终局。三、Context Engineer / Executor SAS双模型串行架构1. 架构拆分角色模型职责Context Engineer小模型Fast / SFT上下文工程、Query Rewrite、RAG、工具筛选Executor大模型Reasoning在“干净上下文”中执行 ReAct2. Agent 调用关系泳道图关键点Context Engineer 决定“给什么”Executor 决定“怎么做”ToolsExecutorRAG / DocsContext EngineerUserToolsExecutorRAG / DocsContext EngineerUser用户问题检索 / Query Rewrite相关文档精炼 Context Tool Schema调用工具工具结果最终回答3. 优点高效率小模型做“脏活累活”上下文干净Executor 不被污染成本可控4. 局限工具依赖 SFT扩展成本高Context Engineer 判断错误会被放大系统运维复杂双模型结论工程效率很高但灵活性不足。四、Multi-Agent SystemMAS多 Agent 分工协作MAS 是当前主流与未来趋势核心思想只有一句话让不同 Agent 各司其职而不是让一个 Agent 无所不能1、Basic Centralized MASDialog / Planner 双 Agent1.1 角色划分Dialog Agent与用户交互维护长期、干净记忆Planner Agent接收 Task Specification规划步骤、调用工具1.2 Agent 调用关系泳道图关键点Dialog 不碰工具Planner 不直接对话ToolsPlanner AgentDialog AgentUserToolsPlanner AgentDialog AgentUser用户输入Task Specification执行计划 / 调用工具执行结果Final Result用户可读回复1. 3 记忆策略Agent记忆特征Dialog长期、精简只保留最终结果Planner短期、深度完整执行链路1.4 优点指令竞争问题消失支持长期对话性能更稳定1.5 缺点单轮任务延迟略高信息传递存在损耗Planner 成为瓶颈单轮任务延迟略高信息传递存在损耗Planner 成为瓶颈2、Hierarchical Centralized MAS层级化 Agent 组织2.1 类似“公司组织结构”Dialog Agent前台Primary Planner老板Team Leader部门负责人Worker Agent执行者2.2 Agent 调用关系泳道图关键点任务逐层拆解结果逐层回传Worker AgentTeam LeaderPrimary PlannerDialog AgentUserWorker AgentTeam LeaderPrimary PlannerDialog AgentUser复杂任务请求高层 Task Spec子任务分解执行指令执行结果子任务完成汇总结果最终回复2.3 适用场景超复杂任务写书、市场调研长时间异步执行2.4 核心问题延迟高调试极难电话游戏效应只适合高价值任务延迟高调试极难电话游戏效应只适合高价值任务3、Orchestrator MAS编排者中心架构强烈推荐3.1 核心角色Orchestrator Agent全局状态机路由、调度、聚合结果Specialized Planner只做规划Coding / Writing / MathExecutor Agent具备重试、容错能力的“智能工具”3.2 Agent 调用关系泳道图关键点Orchestrator 统一决策Planner 与 Executor 完全解耦Executor AgentSpecialized PlannerOrchestratorDialog AgentUserExecutor AgentSpecialized PlannerOrchestratorDialog AgentUser用户请求Task Specification请求领域规划执行计划下发执行指令执行结果 / 重试聚合结果最终回复3.3 优点Planner 可独立优化CoT-SC / Critic扩展安全不影响全局Executor 更稳定3.4 核心挑战规划与执行可能脱节Orchestrator 本身要“足够聪明”结论这是当前工程实践中最平衡的 MAS 架构。4️⃣ 一个重要对比总结架构决策权执行权上下文控制SAS单 Agent单 Agent差Context/ExecutorContext EngineerExecutor好Basic MASPlannerPlanner很好Orchestrator MASOrchestratorExecutor Agent⭐⭐⭐⭐⭐五、总结架构选型建议场景推荐架构简单问答基础 SAS工具密集Context Engineer Executor长对话Basic MAS超复杂任务Hierarchical MAS通用 AI Agent 平台Orchestrator MAS⭐⭐⭐⭐⭐Agent 架构的本质不是模型有多强而是“谁在什么时候知道什么能做什么”。