首页 文章 精选 留言 我的

精选列表

搜索[agentic]，共1488篇文章
优秀的个人博客,低调大师

Agentic Search深入解析：大模型自主决策搜索动作，解决长链路多步骤信息查询难题27.5

如今我们向大模型问一个复杂问题，如果直接丢给普通大模型，要么它只会调用训练截止前的陈旧知识，要么单次搜索只查一个关键词，得到碎片化信息，最后答案片面、遗漏关键数据，甚至出现幻觉。传统的检索增强生成RAG，本质上是用户提问→提取关键词→一次性检索文档→交给大模型总结，全程是被动的。关键词是谁定的？是模型一次性提取。搜几次？大多只搜一轮。发现信息不够、资料矛盾怎么办？传统RAG没有自主处理能力，只能输出现有内容。
2026-11-14
优秀的个人博客,低调大师

【第四部分：Agentic 智能体设计模式】15.为什么 Agent 也需要设计模式

上一篇我们完成了企业知识助手的综合实践，将 Context、RAG 、Tool Calling、State、Memory 和权限控制等能力组合到一个完整的 Agent 应用中。 但随着任务复杂度增加，仅具备这些能力还不够。例如，用户要求企业知识助手对比新旧采购制度、分析受影响的业务流程、查询相关合同并生成调整建议，系统可能需要完成多次检索、并行分析、结果校验和内容修订。如果完全依赖自由 Agent Loop，虽然可以动态调用工具、持续执行任务，但执行路径、结果质量、运行成本和完成时间都不容易控制。因此，除了 Agent 的基础能力和运行时框架，还需要一套可复用的任务组织方法，也就是 **Agent Design Patterns（Agent 设计模式）**。 本篇重点介绍常见 Agent 设计模式的分类、适用场景及工程实现思路，为后续的提示链、路由、并行、反思、规划和多智能体协作等专题建立基础。 ## 一、Agent 设计模式的引入背景 传统软件开发通过设计模式解决反复出现的设计问题，例如工厂模式用于对象创建，策略模式用于算法切换，观察者模式用于事件通知。 Agent 同样存在大量可以复用的执行结构，但与传统程序相比，Agent 的一部分处理逻辑由模型动态决定，执行路径具有一定的不确定性。这种不确定性使 Agent 更适合处理开放式任务，同时也给复杂业务场景带来了新的工程问题。 | 典型问题 | 可能出现的情况 | 对应的处理方式 | | --- | --- | --- | | 复杂任务 | 遗漏步骤、执行顺序不合理 | Planning、Prompt Chaining | | 多种任务类型 | 所有请求使用同一处理流程 | Routing | | 多个独立子任务 | 串行执行造成额外延迟 | Parallelization | | 结果质量不稳定 | 内容错误、遗漏或相互矛盾 | Reflection | | 外部系统操作 | 工具选择错误、重复调用或越权 | Tool Use、Human-in-the-Loop | | 长时间任务 | 执行中断、反复重试、无法恢复 | Recovery、Checkpoint | | 跨领域任务 | 单个 Agent 承担过多职责 | Multi-Agent | 这些问题不能仅靠优化 Prompt 解决。开发者还需要设计任务拆分、路由、并发、反馈、终止条件和异常恢复等机制。 **Agent 设计模式的作用，就是针对这些反复出现的问题，提供可复用的任务编排和执行策略。**设计模式并不消除模型的不确定性，而是通过更加明确的任务组织方式，使 Agent 的行为更容易理解、控制和评估。 ## 二、设计模式与 Framework、Harness 的关系 前面的文章已经分别介绍了 Agent Framework 和 Agent Harness。设计模式与它们属于不同的抽象层次。 | 概念 | 主要职责 | 典型内容 | | --- | --- | --- | | Agent Design Pattern | 定义任务如何组织和执行 | Routing、Reflection、Planning | | Agent Framework | 提供模式实现所需的开发组件 | Spring AI、LangChain4j、LangGraph | | Agent Harness | 提供稳定运行所需的工程机制 | Session、Sandbox、Hooks、Permission、Trace | 例如，一个需求分析 Agent 在生成需求后，需要进行质量检查，低于指定标准时自动修改并重新检查。这种方式属于 **Reflection / Evaluator-Optimizer** 模式。 实现时可以使用 LangGraph 的节点和条件边，也可以通过 Java 中的循环和条件判断实现；如果需要持久化、异常恢复、执行追踪和权限控制，则还要进一步依赖 Framework 或 Harness 提供的运行时能力。因此，同一种设计模式可以采用不同的技术实现，而同一个 Agent Framework 也可能支持多种设计模式。 **设计模式解决任务组织问题，Framework 解决开发实现问题，Harness 解决运行保障问题。**它们并不是相互替代的技术，而是可以组合使用的不同工程抽象。 ## 三、常见 Agent 设计模式 结合目前主流 Agent 开发实践，可以按照任务组织方式，将常见设计模式归纳为以下几类。 | 设计模式 | 主要用途 | 典型应用 | | --- | --- | --- | | Prompt Chaining（提示链） | 将任务拆成顺序执行的步骤 | 文档提取、分析、生成 | | Routing（路由） | 根据请求选择处理路径 | 意图分类、模型与工具选择 | | Parallelization（并行化） | 同时处理相互独立的子任务 | 多文档分析、多来源查询 | | Reflection（反思） | 检查结果并进行有限次数修订 | 质量检查、代码审查 | | Tool Use（工具使用） | 选择、组合并执行外部程序能力 | 业务 API、数据库、文件操作 | | Planning（规划） | 拆解复杂目标并管理任务依赖 | 研究分析、长任务执行 | | Human-in-the-Loop（人在回路） | 在关键节点引入人工决策 | 审批、付款、发布 | | Recovery（异常恢复） | 处理失败、重试、中断和补偿 | 异步任务、长时间执行 | | Memory & Adaptation（记忆与适应） | 利用历史信息和经验调整行为 | 偏好复用、经验沉淀 | | Multi-Agent（多智能体协作） | 由多个专业 Agent 分工处理任务 | 研发协作、综合分析 | 这些模式并不是十种独立的 Agent 产品，也不存在固定的复杂度顺序。 例如，Prompt Chaining 和 Parallelization 都可以在完全确定性的 Workflow 中实现，不一定需要自由 Agent Loop；Reflection 可以嵌入某个生成节点，Planning 则可以结合 Tool Use 动态执行任务。 Multi-Agent 也不是必然比单 Agent 更高级。只有当任务确实需要不同的专业能力、执行环境或上下文隔离时，拆分多个 Agent 才可能带来收益。因此，**设计模式应根据具体任务需要组合，而不是按模式数量衡量 Agent 的复杂程度。** ## 四、设计模式组合：企业采购制度变更分析 继续使用上一篇的企业知识助手作为案例。假设用户提出： > 对比 2025 年和 2026 年的采购制度，分析付款、审批和合同管理方面的变化，查询目前仍在执行的相关合同，并生成调整建议。 这个任务涉及制度检索、业务数据查询、文档对比和报告生成，已经超出简单 RAG 问答的范围。 ### 任务路由与规划 首先通过 Routing 识别请求类型，将其归入复杂业务分析，而不是普通制度问答或单次数据库查询。 随后通过 Planning 拆解任务，明确需要获取哪些资料、哪些步骤可以独立执行、哪些结果需要相互依赖。例如，新旧制度的检索与有效合同查询可以分别执行，而合同风险分析必须等待相关证据准备完成。 ### 并行获取资料 对于没有直接依赖关系的任务，可以采用 Parallelization，同时检索两版采购制度，并通过 Business API 查询有效合同。 这里不一定需要三个独立 Agent。调用三个普通 Tool，或者通过线程池、异步任务执行三个函数，同样可以实现并行。 关键是区分：**任务是否独立，与任务是否需要独立 Agent，是两个不同的问题。** ### 结果检查与修订 获得资料以后，Agent 对比制度条款、识别差异，再结合合同内容判断潜在影响。 如果发现某些结论缺少证据，可以通过 Reflection 检查证据完整性，并使用 Tool 再次检索。但这种循环应该受到最大检索次数、Token 预算和终止条件的约束，避免重复搜索。 最终报告应包含相关制度条款、合同来源以及调整建议。对于缺少可靠证据的内容，应明确标记，而不是让模型自行补全。 ### 业务操作与人工确认 如果用户只需要分析报告，系统可以直接交付结果；如果进一步要求修改合同、发送通知或提交审批，就进入 Tool Use 和 Human-in-the-Loop。 这些操作会改变真实业务状态，不能仅因为模型认为“分析已经完成”就自动执行，还需要权限校验、参数验证和必要的人工确认。 ![](https://developer.qcloudimg.com/http-save/yehe-12085712/8a51dcc4dd8e482d6bf49efe0055c754.png) 以上通过BaseMetas EKA企业知识助手架构图展示 Routing、Planning、Parallelization、Reflection、Tool Use 和 Human-in-the-Loop 之间的关系，重点体现普通问答、复杂分析和业务操作三类任务采用不同处理策略，而不是所有请求都进入同一条执行链。 这个案例说明：一个完整的 Agent 应用可以同时使用多种设计模式，但每一种模式都应该解决一个明确的工程问题。 ## 五、设计模式的选择依据 实际开发中，通常不应该先决定采用哪个 Agent Framework，再围绕框架提供的功能设计业务流程，而应该先分析任务特点，确定执行策略，再选择合适的实现工具。 | 任务特征 | 优先考虑的方案 | | --- | --- | | 单次模型调用即可完成 | Direct LLM Call | | 多个顺序执行、结果可检查的步骤 | Prompt Chaining | | 输入类型差异明显 | Routing | | 多个独立任务可以同时执行 | Parallelization | | 输出需要检查和修改 | Reflection | | 执行路径无法提前完全确定 | Agent Loop、Planning | | 存在不可逆或高风险操作 | Human-in-the-Loop | | 需要等待外部事件或中断恢复 | Checkpoint、Recovery | | 多个专业领域需要独立处理 | 专业 Tool、Skill，必要时 Multi-Agent | 这里需要特别注意 **Workflow 与 Agent 的边界**。如果一个任务可以被预先定义为固定步骤，而且每一步都有明确的输入输出，那么普通 Workflow 通常更加简单、稳定。例如，将合同文本转换成结构化 JSON，校验 Schema 后写入数据库，并不一定需要引入 Agent。 但如果执行过程中需要根据已有结果动态调整查询策略、选择工具或重新规划后续步骤，Agent 的自主决策才具有更明显的价值。因此，在任务选型时应该优先考虑：**确定性程序 → Workflow → 单 Agent → 多 Agent**。这不是技术演进的固定顺序，而是控制复杂度的一种原则。能够采用更简单方式解决的问题，没有必要直接使用复杂编排架构。 ## 六、主流框架中的模式实现 截至 2026 年 10 月，主流 Agent 框架已经把许多常见设计模式逐渐封装为可以组合的开发能力，但不同项目的关注点存在明显差异。 ### OpenAI Agents SDK：Tool 与 Agent 编排 OpenAI Agents SDK 提供 Agent、Tool、Handoff、Guardrail、Session 和 Tracing 等基础能力。 其中，多 Agent 编排主要存在两种不同方式。 **Agents as Tools** 适合由一个主 Agent 统一负责目标和最终结果，其他专业 Agent 作为可调用工具完成子任务。 **Handoff** 则用于将当前任务的后续处理交给另一个 Agent，例如支持系统根据用户请求把问题交给订单、退款等专业 Agent。 两者都属于多 Agent 协作，但控制权和任务责任不同。因此设计多 Agent 时，首先要明确哪个 Agent 负责最终结果，而不是简单增加 Agent 数量。 ### LangGraph：显式 Workflow 与动态 Agent LangGraph 采用 State、Node 和 Edge 组织任务，在官方文档中提供了 Prompt Chaining、Routing、Parallelization、Orchestrator-Worker 和 Evaluator-Optimizer 等常见模式。 例如，Routing 可以通过结构化输出决定进入哪个节点；Parallelization 可以并发执行相互独立的任务；Evaluator-Optimizer 可以让检查节点依据结果决定是否重新进入生成节点。 这些机制也可以与 Checkpoint、Interrupt 和持久化结合，用于构建具有明确流程边界的复杂 Agent。 ### DeepSeek Harness：自由循环与插件化扩展 DeepSeek Harness 采用基于 Cordis 的插件化架构，将 Agent Loop、Tool Registry、Model Adapter、Session Log 等拆成可以独立扩展的组件。 其核心仍然是模型调用、工具执行和 Observation 反馈，但可以通过插件、事件和运行时扩展点加入额外处理机制。它与 LangGraph 的显式状态图属于不同的组织方式：LangGraph 更适合预先定义执行关系，DeepSeek Harness 则更适合在自由 Agent Loop 周围扩展工具、运行控制和执行环境。 这些项目共同说明，**设计模式正在从抽象的编排经验转变为框架可直接组合的工程能力**。但框架只提供实现机制，是否使用、何时使用以及如何组合，仍然需要开发者根据任务特点决定。 ## 七、执行边界与异常处理 Agent 设计模式不能只描述正常执行路径，还需要定义失败和终止行为。例如，Reflection 不能简单实现为“检查不通过就继续修改”，Planning 也不能只关注任务拆解而忽略执行预算。任何包含动态决策的模式，都应该明确以下几个方面。 | 设计要素 | 工程要求 | | --- | --- | | 触发条件 | 明确什么情况下启用该模式 | | 输入输出 | 定义节点之间的数据契约 | | 执行边界 | 限制循环次数、Token 和耗时 | | 终止条件 | 明确成功、失败及部分完成状态 | | 异常处理 | 提供重试、降级、补偿或人工介入 | | 权限控制 | 对有副作用的 Tool 执行前置检查 | | 可观测性 | 记录关键决策、工具调用和执行结果 | 例如，在文档质量检查场景中，可以将最大自动修订次数限制为三次。如果多次修订以后仍然未达到质量要求，系统应转人工处理，而不是无限调用模型。 对于可能重复执行的业务 Tool，还要考虑幂等性。例如支付或审批提交操作发生超时，并不能直接认为执行失败后重新提交，否则可能产生重复操作。因此，模式解决任务结构问题，**执行可靠性仍然需要 Runtime、业务规则和权限体系共同保障**。 ## 八、设计模式的评估与优化 引入设计模式并不意味着系统一定会更加高效。例如，将一个分析任务从单 Agent 改造成 Planning + Parallelization + Reflection 后，虽然可能提高复杂任务的完成率，但也可能因为规划、检查和多次模型调用而增加整体耗时与 Token 成本。因此应通过实际任务数据评估模式是否有效，而不是仅凭执行流程是否更加完整来判断。 | 评估维度 | 主要指标 | | --- | --- | | 任务效果 | 完成率、正确率、遗漏率 | | 工具调用 | 工具选择准确率、参数正确率 | | 执行效率 | 响应时间、步骤数、并行收益 | | 运行成本 | Token、模型请求数、工具调用成本 | | 稳定性 | 失败率、超时率、重试次数 | | 可观测性 | Trace 完整性、错误定位能力 | | 人工介入 | 审批次数、人工修正率 | 例如，对于一组固定的企业采购分析任务，可以分别运行“单 Agent”和“Planning + Parallelization + Reflection”两个方案，再比较结果正确率、执行时间、模型调用次数和人工修改量。 如果增加模式以后正确率没有明显改善，反而显著增加延迟和成本，就应该重新评估架构复杂度。这种评估方式也延续了前一篇企业知识助手中的 Trace/Eval 思路：**不仅检查最终答案，还要分析整个执行过程是否合理。** ## 九、设计模式的工程化使用原则 在实际项目中，Agent 设计模式应以任务目标和工程收益为依据，而不是以模式数量或系统复杂度为目标。对于简单任务，优先采用确定性程序或少量模型调用；对于需要多个明确步骤的任务，可以先采用 Prompt Chaining；对于需要动态选择处理路径的任务，再引入 Routing 或 Agent Loop。 当任务包含独立子任务时，可以考虑并行化；需要质量反馈时，增加 Reflection；存在明确的执行依赖与长时间运行需求时，再采用 Planning、Checkpoint 或状态机编排。Multi-Agent 更应该谨慎使用。只有当单 Agent 已经难以承担任务，或者确实需要专业能力隔离、独立上下文和任务委派时，才有必要进一步拆分。 这些原则可以概括为：**先确定任务结构，再选择设计模式，最后确定 Framework 和 Runtime 实现。**不要把框架能够实现的所有模式都组合到一个 Agent 中。系统设计的最终目标仍然是以合理的成本、延迟和复杂度可靠完成任务。 ## 十、本篇小结 从第 10 篇手写最小 Agent 开始，我们已经逐步学习了 Agent Loop、Framework、State Machine、Memory，并完成了企业知识助手的综合实践。这些内容主要解决 Agent 的基础能力和工程实现问题，而 Agent 设计模式进一步关注如何组织复杂任务，以及不同执行方式之间的取舍。 目前常见的 Prompt Chaining、Routing、Parallelization、Reflection、Planning 和 Multi-Agent 等模式，并不依赖某一个特定框架，也不应该作为固定组件全部引入。真正需要掌握的是根据任务特征判断：哪些步骤应该顺序执行，哪些任务适合并行，什么时候需要模型决策，什么时候应该交给确定性代码，以及怎样通过反馈、验证和异常处理控制整个执行过程。因此可以将几类工程能力作如下区分：**Model 提供理解、推理和生成能力；Design Pattern 负责组织任务和决策；Framework 提供开发抽象；Harness 保障执行过程的稳定、安全与可观测。** 后续文章将围绕这些模式逐篇展开，结合代码和实际业务案例，分析它们的实现方式、适用场景以及工程限制。 **上一篇：** [【第三部分：第一个 Agent 应用】14. 开发一个完整的企业知识助手：从 RAG 到 Agent-腾讯云开发者社区-腾讯云](https://cloud.tencent.com.cn/developer/article/2755169) **下一篇：提示链模式——将复杂任务拆成多个步骤。** 将从最容易落地的 Prompt Chaining 开始，重点介绍任务拆分、中间结果校验、上下文隔离与失败处理，进一步说明如何通过确定性的多步骤编排提高大模型应用的稳定性。
2026-10-14

资源下载

更多资源
优质分享App

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

时间: 2026-11-13 大小: 4.36MB 下载: 25次
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-10-18 大小: 211.28KB 下载: 56次
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册