企业官网建设流程全解析

淇县网站建设,韶关市住房和城乡建设局网站,wordpress review主题,坑梓网站建设哪家好文章探讨了AI应用从顾问到执行者的范式转变#xff0c;详细介绍了LLM-native应用的设计与实现方法。文章对比了AI Workflow和AI Agent两种模式#xff0c;通过案例展示了构建稳定工作流、自主智能体及混合架构的方法#xff0c;并介绍了MCP协议在连…文章探讨了AI应用从顾问到执行者的范式转变详细介绍了LLM-native应用的设计与实现方法。文章对比了AI Workflow和AI Agent两种模式通过案例展示了构建稳定工作流、自主智能体及混合架构的方法并介绍了MCP协议在连接AI应用与外部系统中的作用。强调真正的AI应用落地需要将大模型与业务系统深度集成实现从智能分析到智能执行的跨越。过去一两年ChatGPT 等 AI 聊天工具凭借强大信息处理能力成为工作中的 “万能顾问”高效搞定写邮件、解疑问等需求。但面对业务执行场景它们暴露短板仅能提供方案缺乏行动力、无法集成内部系统、难串联复杂流程始终是 “旁观者”。如今下一代 AI 应用正在打破困局化身 “智能执行者”具备理解、规划、调用工具、完成闭环的能力能直接落地业务结果。本文立足实践后续将拆解这类应用的设计、工作流构建与落地方法助力突破工作瓶颈抓住 AI 从 “顾问” 到 “执行者” 的变革风口。引言AI应用范式正在发生什么变化相信在过去的1-2年中许多人都已经体验过ChatGPT、Gemini、DeepSeek等AI对话工具的威力。我们惊叹于它们流畅的文笔、广博的知识和看似”理解”我们意图的能力。“帮我写周报”、“总结一下这篇文章的主题”、“解释这个技术概念”——这些任务AI聊天工具已经能出色地完成。然而当我们将目光转向日常工作中更核心、更复杂的业务场景时可能会遇到这样的困境你“ChatGPT帮我看看游戏服本地测试9000的CPU负载是不是太高了如果高就安排它凌晨3点重启一下。”ChatGPT“我理解您想监控服务器负载并安排重启的需求。这是一个很好的运维实践。您可以1. 登录服务器监控系统查看指标2. 如果确认负载过高登录定时任务系统创建重启任务3. 需要提供具体的服务器ID。请注意我无法直接访问或操作系统您可以联系您的运维团队…”然后我们就发现了问题即使是最先进的AI聊天机器人本质上仍然是一个被动的、封闭的信息处理与生成器。它就像一个无所不知的顾问能给你各种建议和方法却无法替你拿起工具执行哪怕最简单的第一步。1单纯AI聊天工具的局限性让我们明确一下当前这类工具的局限性1.缺乏行动力他们”知道”该怎么做但无法”动手”去做。无法调用API、无法操作系统、无法更改数据库里的一个字段。2.无法个性化集成他们与公司内部的各种系统各种知识是脱节的他们无法获取和理解公司内部的各种系统的能力与操作方式。3.流程断裂它们只能完成单次交互无法记住复杂任务的上下文也无法将多个步骤串联成一个自动化的工作流。这就是上一代AI****应用的核心特征它们是革命性升级但尚未成为业务系统本身的智能组成部分。2下一代AI应用从顾问到执行者那么什么是”下一代AI应用”它的核心范式是什么下一代AI应用是让大语言模型从一个只能指导你怎么做的顾问转变为一个具备理解和执行能力的智能中枢。它不会替代现有业务系统而是为它们装上统一的大脑和灵活的手脚。我们可以称他为LLM-native应用他是建立在LLM之上的一种全新产品范式。维度AI聊天工具(如 ChatGPT)下一代AI应用(LLM-native应用)核心角色信息顾问、内容生成器智能执行者、业务协调中枢工作模式一问一答被动响应理解目标主动规划调用工具执行与系统关系孤立、旁观者深度集成、参与者输出结果文本、代码建议真实的业务操作、状态变更、数据更新典型场景写邮件、解答疑问、文章总结自动化运维、智能客服工单处理、动态流程推进以我们开头的运维场景为例一个下一代AI应用会如何工作你“帮我看看游戏服本地测试9000的CPU负载是不是太高了如果高就安排它凌晨3点重启一下。”AI Agent1.理解识别出两个核心任务①查询服务器状态②条件性创建定时任务。2.规划我需要先调用”服务器查询工具”根据名称找到ID并获取监控数据。3.执行调用监控工具查询bridge9000的CPU负载 → 发现负载为92%。决策负载超过阈值80%需要安排重启。调用定时任务工具为bridge9000创建一条次日03:00执行的重启任务。4.回复“已确认游戏服本地测试9000ID: bridge9000当前CPU负载过高92%。已成功为其创建定时重启任务将于明日凌晨3点执行。”区别一目了然。 后者不再是给你一份操作指南而是直接替你完成了整个操作闭环。它将自然语言指令直接翻译成了对多个业务系统的精确调用和串联。如果大家对现在的AI应用有一些了解会发现像像 Chatbox 这类新一代 AI 个人助理应用的兴起。它们不再仅仅是一个网页窗口而是作为桌面级应用集成了本地知识库、具备了更强的文件处理能力甚至开始尝试调用系统级的 API。这代表了下一代 AI 应用的雏形AI 不再只是一个生成文本的工具而是一个具备感知、记忆、规划和行动能力的系统。正是在这样的视角下我们组目前已经在LLM-native应用这块开始了一些尝试和落地试用后续章节将逐步展开如何设计这样的AI应用、如何构建稳定的工作流、如何实现自主智能体以及如何通过混合架构与新兴标准如MCP将这一切连接为有机整体。01下一代AI应用架构与LLM的角色1传统架构 vs. LLM-native架构传统软件架构是”流程驱动”的用户输入 → 预设业务流程 → 调用API → 返回结果。LLM-native架构是”意图驱动”的用户输入 → LLM理解意图 → 动态规划 → 调用工具 → 返回结果。2LLM-native架构核心组件如下图所示我们的下一代AI应用大体上的架构会分为应用层也就是我们用户的直接操作入口协调层一般来说就是LLM(大语言模型)的能力他要负责理解自然语言做任务的拆解工具的选择和决策 执行层执行层可以认为是我们各类工具的封装封装为LLM可以理解的格式然后由LLM进行决策选择以后再实际进行工具的调用记忆层因为AI应用往往会多次和LLM进行沟通所以这里需要进行会话的记忆来保证LLM可以正确理解全部的意图数据层提供各类数据的访问检索写入能力3LangChain构建LLM-native应用的脚手架目前构建AI应用的框架有很多 比如difyLlamaIndex等等我这里选择使用LangChain来进行构建我们的AI应用。 简单来说LangChain 是一个用于构建基于大语言模型应用的开源编排框架。它提供了一套标准化的组件和接口帮助开发者组件标准化将LLM、提示词、工具、记忆等抽象为统一接口链式编排将多个组件连接成可执行的”链”工具管理简化工具的定义、注册和调用记忆管理提供多种记忆存储和检索方式而且LangChain还提供了从原型到生产的工具链支持LangSmith一个强大的平台用于调试、测试、评估和监控你的LLM 应用。你可以看到Agent每一步的思考过程统计Token消耗这对于复杂的AI应用开发极其重要。LangServer: 可以一键将写好的LangChain代码部署为标准的REST API。这篇分享中我不会特别多介绍LangChain的具体语法之类的内容因为这部分的内容其实去看官方文档也可以很快的理解和学习。更多的是介绍LangChain他能做什么我们要以一个什么思路去使用LangChain构建AI应用。02AI应用设计模式1两种设计模型AI Workflow VS AI Agent就像我们开发传统软件时往往会使用各种设计模型一样在构建下一代AI应用的过程中随着AI应用的逐渐复杂化我们也需要一定的应用设计模式。目前最主流的两种AI应用设计模式就是AI Workflow工作流和AI Agent智能体。AI Workflow就像是自动化流水线——每个工位节点做什么、怎么做、做完交给谁都是预先设计好的。AI在其中充当某个工位上的高效工人。AI Agent就像是一位被赋予了目标和工具的独立员工。你告诉他“把这个项目做完”他会自己去思考需要分几步、需要用什么工具、遇到问题该找谁直到达成目标。这两种范式并非对立关系而是互补的工具。理解它们的核心区别和适用场景对于设计正确的AI应用架构至关重要。2AI Workflow什么是AI WorkflowAI Workflow是一种过程导向的设计模式。它将一个复杂的任务分解为一系列预定义的、结构化的步骤节点。数据按照预设的路径在这些节点之间流动。AI模型通常作为其中的一个或多个节点负责处理特定的子任务如总结、分类、提取。大家应该都写过类似的CICD工作流比如代码提交前提交后的各种检查各类策划表检查等等。AI Workflow其实就类似于CICD工作流只不过是把其实部分节点的执行判断等流程接入了LLM进行执行。核心特征确定性路径是固定的。输入A经过流程必然得到输出B除非中间的模型产生随机性但流程本身是固定的。结构化编排开发者拥有最大的控制权精确定义了每一步的逻辑和条件分支。优点高可靠性和可预测性因为流程是写死的系统行为非常稳定。对于企业级应用来说结果的可控性至关重要。易于调试和维护如果流程出错了你可以精确地定位到是哪一个节点、哪一步出了问题。性能与成本优化你可以针对每个特定的小步骤选择最合适的模型例如简单分类用小模型复杂生成用大模型从而精确控制Token消耗和响应时间。便于人类介入可以在流程中显式地插入人工审核节点确保关键步骤的安全。缺点缺乏灵活性面对预设流程之外的异常情况或新的输入类型Workflow往往束手无策容易报错。构建和维护成本高针对复杂任务对于非常复杂的业务逻辑设计一个面面俱到的工作流可能非常庞大且难以维护。你需要预判所有可能的分支。无法处理开放性问题不适合需要探索、试错或没有固定解题路径的任务。3AI Agent什么是AI AgentAI Agent是一种目标导向或声明式的设计模式。系统的核心是LLMLLM作为Agent的大脑它被赋予了一个高级目标和一组可用的工具。Agent通过自主的推理、规划、执行和观察结果来迭代地接近目标。最经典的模式是ReAct循环如下图所示核心特征自主性AI自己决定下一步做什么而不是遵循预设的代码路径。适应性能够根据行动反馈的环境变化调整策略。工具使用具备调用外部API、搜索网络、查询数据库的能力。优点极强的灵活性和泛化能力能够处理模糊的指令和动态变化的环境。对于未曾见过的问题它能尝试去解决。解决开放性复杂问题适合那些步骤不确定、需要多步推理和外部信息辅助的任务。降低开发复杂度对于特定场景对于某些复杂任务你不需要写几千行if/else代码只需给Agent提供好的工具和清晰的目标提示即可。缺点不可预测性与幻觉风险你无法100%确定 Agent 会采取什么路径。它可能会陷入死循环或者自信地调用错误的工具产生破坏性后果比如错误删除了部分数据。高延迟和高成本Agent 通常需要进行多轮的思考和工具调用才能完成一个任务这会导致大量的 Token 消耗和较长的响应时间。调试困难当 Agent 失败时很难确定是因为推理错误、工具返回了误导信息、还是提示词不够清晰。它的决策过程通常是一个黑盒。安全风险赋予 Agent 自主调用工具的权限尤其是执行代码或修改数据库会带来巨大的安全隐患。4总结和对比我们理解了AI Workflow和AI Agent后我们可以通过下面的表格来清晰的了解这两种设计模式的区别。维度AI WorkflowAI Agent核心驱动预定义的流程逻辑 (Code/Graph)LLM 的推理与规划能力 (Prompt/ReAct)控制权在开发者手中(确定性高)在 AI 模型手中(自主性高)灵活性低高可预测性高低调试难度较低(容易定位节点)较高(推理过程黑盒)成本与延迟通常较低且可控通常较高且不可控(多轮迭代)最佳场景已知的、结构化的、需要保证结果的任务未知的、探索性的、需要创造性解决的任务5如何选择在实际的应用架构设计中这两者往往不是二选一的关系而是融合共存的。Workflow中嵌套Agent在一个大型的固定流程中某个特定的复杂节点比如需要上网搜索信息可以交给一个Agent去完成完成后返回结构化结果给主流程。Agent作为Workflow的调度器一个高级Agent负责理解用户意图然后选择并触发最合适的预定义Workflow来执行任务。如果你的业务流程非常清晰对于结果的确定性要求极高时请优先使用 Workflow。不要为了用Agent而用Agent可控性是工程的第一原则。 如果你的任务需要跨越多个系统、步骤不固定、且需要一定的创造性来解决可以考虑使用Agent。我在后面会结合我们组目前落地使用的两个AI应用以及一些常见的需求来详细介绍一下这两种设计模式的应用。03构建稳定性的AI Workflow我们在上一部分的时候提到过如果你的业务流程非常清晰对于结果的确定性要求极高时我们应该首选AI Workflow。这里我介绍一个我们组刚落地的一个简单案例美术资源流程管理AI Workflow。1业务背景我们组目前实现了一个美术资源流程管理系统PM可以在系统中创建美术资源的管理流程系统会自动创建POPO群并拉入所有相关的制作人员。PM在系统中配置了美术资源多个制作流程当某个流程完成时可以由对应的负责人在群里对应的关键字来触发对应的流程完成逻辑通知下一个阶段的负责人来实现美术资源的流程管理。2业务痛点系统要求 必须输入严格的枚举值例如 【首个模型制作完成 男】。实际情况可能往往会输入得很随意比如o男的初版模型做好了 - 首个模型制作完成 男o女版的时装确认OK了 - 时装验收通过 女所以传统的正则匹配根本无法覆盖这些口语化表达导致系统无法识别流程卡顿。对于需要操作系统的美术同学来说也需要额外记忆严格的关键字增加了不必要的负担。 所以我们这个AI Workflow的目标就是构建一个中间层把这些自然语言精准翻译成系统可以理解的内容。3架构设计在这个业务场景下我们的流程非常清晰我们需要它严格地在给定的几个状态值里做选择。因此这是一个非常标准的链式结构很适合用Workflow实现。LangChain节点设计我们可以将流程分拆为3个关键节点输入内容处理这里会把用户输入的内容进行一次简单的处理比如去掉POPO消息中的一些加粗字号字体标记等。LLM检查这里会使用API_KEY通过API的方式去调用LLM模型这里支持多种模型。ChatGptDeepSeek都可以把用户输入的内容还有系统可以接收的关键字列表结合我们写好的Prompt发送给LLM模型等待LLM模型的返回输出。结果判断和整合这里判断LLM模型返回的结果置信度情况判断结果是否可信然后整理结果并返回 LangChain生态系统提供了LangSmith工具可以清晰的看到你的AI应用的调用链。如图所示4LangChain实现这里我会简单介绍一下如何用LangChain去实现这套逻辑本篇分享不太会写较多的技术细节更多以介绍架构和思路为主。Step1: 定义状态State是在各个节点中进行流转的数据结构可以认为就是在流水线中进行流转的包裹这里我们需要定义各类输入和输出的数据class ArtAgentState(TypedDict): 美术资源通知Agent 状态 # 输入 raw_message: str # 原始消息 message_after_trans: str #处理后的消息 workflows: List[str] # 流程阶段列表 costume_types: List[str] # 时装类型列表 # 输出 is_valid: bool # 是否成功解析 workflow_stage: Optional[str] # 识别到的流程阶段 costume_type: Optional[str] # 识别到的时装类型 confidence: Optional[float] # 置信度 reasoning: Optional[str] # 推理过程 error_message: Optional[str] # 错误信息Step2: 构建各个节点在这里需要定义我们之前规划好的各个节点 * 输入内容处理def trans_input(state: ArtAgentState) - ArtAgentState: # 在这里处理输入内容然后重新写入到state中 return stateLLM检查: 这里是最关键的内容这里需要去构建system_prompt和user_prompt,然后调用LLM的能力规定LLM的返回格式并进行解析。下面是这个节点的关键部分内容。def check_art_notification(state: ArtAgentState) - ArtAgentState: system_prompt f你是一个资源流转命令解析助手。你的任务是从用户的自然语言输入中识别出: 1. 流程阶段 (workflow_stage) 2. 时装类型 (costume_type) 可用的流程阶段列表: {json.dumps(workflows, ensure_asciiFalse, indent2)} 可用的时装类型列表: {json.dumps(costume_types, ensure_asciiFalse, indent2)} 请以 JSON 格式返回结果: {{ workflow_stage: 识别到的流程阶段(必须是列表中的某一项), costume_type: 识别到的时装类型(必须是列表中的某一项), confidence: 0.0-1.0之间的置信度, reasoning: 你的推理过程 }} 如果无法识别某个字段,请将其设为 null。 user_prompt f用户输入: {raw_input} ai_result, result_text self.invoke_llm_without_tools(self.llm, system_prompt, user_prompt)结果判断和整合这里只需要对上一步LLM返回的内容进行一些判断比如置信度是否符合要求是否各个字段都进行了识别进行了返回, 然后整理输出结果。def finalize_art_notification(state: ArtAgentState) - Dict[str, Any]: # 进行各种判断和结果整合 return resultStep3: 组装图LangChain框架目前提供了LangGraph相关的接口让我们可以很简单的去把之前定义的各个节点组合成流程图如以下代码所示def create_art_notification_workflow() - CompiledStateGraph: 创建美术资源通知工作流 workflow StateGraph(ArtAgentState) # 添加节点 workflow.add_node(trans_input, trans_input) workflow.add_node(check_art_notification, check_art_notification) workflow.add_node(finalize_art_notification, finalize_art_notification) # 添加边 workflow.add_edge(START, trans_input) workflow.add_edge(trans_input, check_art_notification) workflow.add_edge(check_art_notification, finalize_art_notification) workflow.add_edge(finalize_art_notification, END) # 编译应用 graph workflow.compile() return graph这样我们就使用LangChain框架实现了一个AI Workflow应用而且这个应用还可以使用LangSmith去进行跟踪调试查看每一个节点的调用链每一步的输出等等信息开发和部署起来都非常方便。5效果和小结使用LangSmith进行整体调用的跟踪当我输入“男的初版模型做好了”时通过该AI Workflow就可以正常的进行解析出对应的关键字和时装类别。如图所示通过这个案例我们可以看到AI Workflow的巨大价值容错性高 它允许用户以最自然的方式模糊的自然语言与系统交互而不需要记忆僵硬的指令。不仅是对话AI在这里不是陪聊而是成为了业务逻辑中极其可靠的转换器。04构建自主的AI Agent在上一章我们用Workflow搞定了一个确定性的任务。但现实中还有很多任务是非确定性的。这里我举一个简单的场景比如我和AI应用说“帮我重启一下本地测试8服务器并设置为每天凌晨2点重启一次。”这里面就包含了多个跨系统的操作去服务器管理平台查询全部服务器列表找出本地测试8对应的服务器ID调用服务器管理平台的重启服务器接口传入本地测试8对应的服务器ID调用定时任务平台的接口创建一个重启服务器的定时任务 这是一个典型的AI Agent场景因为我们这服务器管理平台和定时任务平台的多个工具可以组合出非常多的调用链组合除了定时重启还有定时更新定时清理LOG等等所以我们希望AI需要自主规划而不是通过Workflow进行写死调用链。 接下来我会简单展示一下如何使用LangGraph来构建这样一个AI Agent应用。1定义工具首先我们需要把如何调用服务器管理平台和定时任务平台封装成具体的工具然后通过很详细的描述和类型注释让LLM能够理解工具的用法如下所示from langchain_core.tools import tool tool def get_server_list() - List[Dict[str, Any]]: 获取所有支持的服务器列表 返回包含服务器ID服务器中文名称服务器英文名称和状态的列表 Returns: List[Dict[str, Any]]: 服务器列表每个服务器包含ID中文名称英文名称和状态 # 这里调用服务器管理平台的接口获取server_list server_list xxxxx return server_list tool def restart_server(server_id: int) - str: 重启指定ID的服务器 Args: server_id (int): 服务器ID Returns: str: 重启结果信息 # 这里调用服务器管理平台的接口重启服务器 return f服务器ID {server_id} 已成功重启。 tool def create_restart_server_job(cron, server_id) - Dict[str, Any]: 创建重启某个服务器的定时任务 Args: cron (str): 定时任务的cron表达式 server_id (int): 服务器ID Returns: Dict[str, Any]: 创建结果包含任务ID和状态 # 这里调用定时任务平台的接口创建 return result这里我们定义了3种工具分别为获取所有支持的服务器列表的工具重启指定ID的服务器的工具还有创建重启某个服务器的定时任务的工具。2创建Agent接下来我们就可以直接调用LangGraph的create_agent方法来创建一个agent并把之前定义好的这些工具传给agent然后输入用户输入内容等待agent来自主决策并执行工具。agent create_agent( modelChatOpenAI(modeldeepseek-chat, temperature0) tools [get_server_list, create_restart_server_job,restart_server] ) user_input 帮我重启一下本地测试8服务器并设置为每天凌晨2点重启一次。 initial_state { messages: [HumanMessage(contentuser_input)] } response agent.invoke(initial_state, config{recursion_limit: 10})3执行流程然后我们还是可以通过LangSmith来跟踪整个AI Agent的执行过程我们可以看到在整个过程中大模型的思考过程LLM• 我们需要先知道本地测试8对应的服务器ID• Call Tool: get_server_listTools• 运行get_server_list方法LLM• 我已经找到了本地测试8对应的ID是8当前的状态是运行中然后设置每天凌晨2点的定时重启任务。首先重启服务器• Call Tool:restart_server, ‘args’: {‘server_id’: 8}Tools• 运行restart_server方法LLM• 很好服务器已经重启成功。现在我来设置每天凌晨2点的定时重启任务。每天凌晨2点的cron表达式是 0 2 * * *。• Call Tool: create_restart_server_job,‘args’: {‘server_id’: 8, ‘cron’: ‘0 2 * * *’}Tools• 运行create_restart_server_job方法这里其实LLM使用了一种叫做Function Calling的技术目前主流的大模型比如ChatGPTDeepSeek等等都支持了这项技术具体的实现这里就不再展开有兴趣的同学可以自主去了解一下可以简单的认为这项技术可以让大模型理解具体的方法调用方式以及按照标准的格式返回大模型自己决策需要调用的方法以及传入的参数等等信息。然后我们就可以根据大模型返回的Function Calling信息直接去调用具体的方法。4Agent设计的原则在刚才的演示中我们的Agent只包含了3个工具表现非常完美。但在实际企业级开发中大家很容易产生一种冲动“既然Agent这么好用不如把公司所有的100个API接口都塞给同一个Agent让它变成全能管家”千万不要这么做根据业界目前的最佳实践在设计Agent时我们需要遵守以下核心原则以确保系统的稳定性和可维护性单一职责原则规则 一个Agent最好只专注于一个特定的业务领域。反例 创建一个SuperBot既负责“查询服务器日志”又负责“撰写周报”还负责“订会议室”。为什么注意力分散LLM的注意力机制是有限的。当System Prompt过于复杂或者工具列表过长时模型很容易忽略关键指令导致指令遵循能力下降。幻觉风险激增 如果一个Agent手里有太多相似的工具比如delete_file和delete_database他误用的概率会指数级上升。明确的能力边界规则清晰定义Agent不该做什么。示例 对于一个“只读的监控Agent”不仅要在Prompt里写“你不能修改数据”更应该在代码层面就不给它挂载update或delete类的工具。为什么安全性就像sql存在sql注入一样提示词注入攻击更加防不胜防对于大模型来说仅仅依靠Prompt说不要做什么事情是不够的物理隔离也就是限制工具能力才是最安全的。调试便利性 当系统出问题时如果边界清晰我们能迅速定位是“运维Agent”出了问题而不是还要去排查是不是“会议室Agent”误操作了服务器。工具必须具备鲁棒性规则Agent调用的工具函数不要直接抛出异常返回值要对AI友好为什么比如当API调用报错时不要直接抛出异常应该捕获异常并返回一个字符串比如{“error”: “Connection failed, please try again later”}。这样Agent在获取到Tool的错误返回后有机会根据错误信息进行自我修正比如重试或者换一种参数调用而不是直接挂掉。工具定义即 Prompt规则所有工具函数必须具备严格的类型注解和 结构化、详尽的文档字符串也就是Docstrings。为什么LLM是通过阅读你的函数文档来理解“这个工具是干嘛的”以及“参数该怎么填”。模糊的描述如“获取信息”会导致LLM在不该调用的时候乱调用。LangChain框架会利用Python的类型注解生成Json Schema。如果缺乏类型注解可能会出现需要int类型时传入了string等问题。遵循上述原则我们会发现与其构建一个臃肿的全能Agent不如构建一群各司其职的专家Agent让他们协同工作。这里就会很类似我们人类的组织工作方式这非常类似人类社会的组织方式当面对一个复杂项目时我们会组建一支由不同专业人才构成的团队通过明确的分工与有效的项目管理最终高效完成整体目标。构建AI Agent系统也是如此。我们需要一套清晰的管理机制来协调这群专家Agent确保它们能像一支训练有素的团队一样有序协作、共同解决问题。这就引出了我们接下来要介绍的两个话题混合架构如何把这些各有所长的小Agent和Workflow组合起来解决复杂问题MCP协议当工具和能力分散在不同Agent中时如何通过统一的标准实现灵活、高效的管理与调用05Workflow与Agent结合的混合架构在前两章中我们分别介绍了AI Workflow和AI Agent两种AI应用的设计模型并举例展示了两种设计模型的应用场景。但在实际应用中这两者往往不是”非此即彼”的关系。事实上最优秀的AI系统往往是两者的有机结合——用Workflow提供确定性、可靠性的流程控制用Agent来实现高阶的工具处理能力。这一章我将通过我们组内刚刚实现的一个ItemReview AI工具来讲解一下这种混合架构的设计理念。1业务场景在我们的游戏中存在着大量的游戏道具这些游戏道具不但有文字描述还有实际的功能逻辑例如一个简单的一个回血药描述“【功效】回复气血2000”Action: AddHpDrup(2000)这里策划的配置错误一般可能会有两种描述中存在错别字语病等情况描述和Action不符比如描述中写【功效】回复气血2000但是实际Action中配置成了AddHpDrup(1000)而我们游戏中的道具又是成千上万级别的这种描述的错误如果全部依赖QA的人工测试很容易出现遗漏。但是如果使用传统的一些正则匹配代码判断的方式又基本无法检查出这类问题。所以为了解决这类问题我们也需要设计一个AI 应用他既要有Workflow的流程控制能力又要有Agent的语义判断能力。2架构设计这个系统的架构采用了经典的并行处理模式在LangGraph中我们称之为 Fan-out/Fan-in。如图所示整体流程解析路由节点route_checks这是一个任务分发模块他会根据读取Item的一些基本信息然后来判断这个Item需要执行哪些检查错别字检查节点typo_check_node这是一个专门用于检查错别字的Agent节点其中挂载了两个Tool一个会在策划表中模糊搜索某个词返回使用到该词的上下文信息另外一个Tool可以获取一个或多个Item的完整信息。然后Agent通过这两个Tool的能力一起判断Item中的描述是否存在语法和错别字相关问题。描述一致性检查节点 (action_description_check_node)该Agent用于检查Action与描述是否一致这里我们也给Agent挂载了两个Tool能力其中一个Tool可以解析Item Action的含义另外一个Tool用于获取Item的完整信息。通过这个Agent可以判断Action是否与描述一致等待节点 (wait_for_all_checks)该节点确保所有被触发的并行任务都跑完了才放行到下一步最终决策节点 (decide_final_result_node)汇总所有的检查节点意见格式化输出最后的结果3最终结果输出目前这个ItemReview工具还处于初期阶段后续还需要进行比如Prompt优化结果展示优化其他Agent开发和接入等等工作但是我们已经可以通过该工具发现一些Item配置错误的情况比如宝箱描述中产出道具的数量与Action实际产生的道具数量不一致Item描述错别字等等。4为什么选择混合架构在这个案例中我们看到了两种模式的完美融合Workflow确定了流程数据的流转方向是固定的输入 - 路由 - 并行 - 汇总我们通过route_checks严格控制了系统的行为边界避免AI对一个不需要测Action的物品瞎测一通节省Token减少幻觉。Agent提供了高级能力在具体的检查节点我们需要LLM和Tools自由结合的能力我们分别创建了专门负责错别字检查的Agent和负责描述Action检查的Agent来实现具体的检查。5组合使用的巨大优势对于测试部的AI工具开发这种架构带来了三个核心收益模块化与解耦如果我们以后还需要添加其他的Item检查内容比如敏感词检查我们只需要再去实现一个专门负责敏感词检查的Agent并在路由层注册一下完全不会影响到现有的两个检查逻辑。效率最大化通过Workflow的并行编排错别字检查和逻辑检查是同时进行的。这比传统的线性对话速度提升了很多。可控的自主性这里我们也符合了我们上一张所说的Agent设计原则每个Agent只负责自己那一块领域的工作这大大降低了上下文干扰让 AI 的表现更加精准、稳定。06连接的进化——引入 MCP在之前的部分我们通过Function Calling的方式手写Python代码让 Agent连接到了内部系统。这种方式虽然灵活但在企业级应用中它面临着重复造轮子和维护地狱的问题。比如我们多个组的Agent都要接入到权限平台我们每个组可能都需要针对权限平台的接口去实现一套Function Calling的实现。以及如果权限平台有一些接口发生了修改时我们各个组都需要去修改我们的Function Calling的实现所以现在权限平台的接口应该不太敢动。为了解决这个问题AI 行业引入了一个革命性的标准——MCP (Model Context Protocol)。1什么是MCPAI时代的USB协议如果把AI Agent比作一台电脑把外部系统数据库、redmine、服务器比作外设鼠标、键盘、打印机。没有MCP之前 每连接一个新设备你都需要自己写驱动程序。连接 redmine 要写一套 API 封装连接服务器要写一套。如果你换了个AI模型比如从GPT换到Claude可能还得调整代码。有了MCP之后 它就像USB协议。无论你是redmine还是自家开发的服务器管理平台只要你提供符合MCP标准的接口任何支持MCP的客户端无论是Cladue Desktop, ChatBox还是Cursor IDE还是我们自己开发的LangChain Agent都可以即插即用。2MCP服务是如何定义的一个标准的 MCP Server 不仅仅是简单的 API 包装它通过 JSON-RPC 协议向 AI 暴露了三个核心能力。这三个能力对应了 AI 认知的不同层面Resources (资源)定义被动读取的上下文数据。作用类似于文件读取。Agent可以直接读取这些内容作为Prompt的上下文。例子■ server://logs/error.log (服务器日志)■ file://test_cases/login_test.xlsx (本地测试用例)Tools(工具)定义可执行的函数能够改变系统状态或进行复杂计算。作用类似于API调用。例子■ restart_service(server_id8)■ query_prometheus(metric“cpu_usage”, duration“5m”)Prompts(提示词模板)定义服务启动的预定义交互模板帮助Agent快速启动特定的任务。作用将复杂的 Prompt 工程封装在服务端。例子app.prompt(翻译专家) async def translate_expert( target_language:str Chinese,) - str: return f你是一个翻译专家擅长将任何语言翻译成{target_language}。请翻译以下内容3动态发现机制Agent是如何获取能力的这是MCP最神奇的地方。Agent的代码里没有写死任何工具的名字。那么Agent是怎么知道“我能重启服务器”的呢 这依赖于MCP的 “握手与发现” 机制建立连接Agent(作为MCP Client) 启动通过stdio或SSE连接到 MCP Server例如ServerHub MCP。初始化Agent发送初始化请求。能力协商Server告诉Agent“我支持Resources和Tools功能。”拉取清单●Agent发送tools/list请求。●Server返回一个JSON列表详细描述他拥有的工具{ tools: [ { name: restart_server, description: 重启指定服务器, inputSchema: { ... } } ] }●Agent 同时也发送 resources/list 请求获取可用资源列表。动态挂载Agent里的LLM接收到这份JSON列表自动理解工具的用法并将其作为System Prompt的一部分。 这样MCP Server端只要有更新时Agent在下次连接时就会自动发现新能力不需要修改Agent端的代码。4繁荣的生态不要重复造轮子引入 MCP 的另一个巨大优势是我们可以直接复用社区已经构建好的高质量 MCP Server而不需要自己去对接繁琐的第三方 API。目前业界已经有很多流行的 MCP 服务我们可以直接拿来“武装”我们的 Agent开发工具类Git/GitHub MCP: 让Agent直接拥有读取代码库、提交PR、管理Issue 的能力。Postgres / SQLite MCP: 让Agent安全地以只读模式查询数据库进行数据分析。企业协作类Google Drive MCP: 让 Agent能够搜索和读取云端文档。Excel/Filesystem MCP: 让Agent直接读取本地的Excel文件通过自然语言来去操作Excel而不是写繁琐的openpyxl代码。运维监控类Grafana/Prometheus MCP让Agent能够直接执行PromQL查询监控指标或者获取Grafana仪表盘的状态。比如在压测过程中Agent可以实时监控某个服务器的CPU和内存使用率等等情况然后及时保存现场。Sentry MCP可以让Agent自动拉取最新的报错日志进行分析。 以上都是目前业界比较流行的MCP服务当然现在还有很多MCP服务在逐渐新增中。5解决数据孤岛如果对于我们公司内部的系统而言假设我们通过类似FastMcp这样的框架封装好了多个MCP服务。我们就可以通过Agent将这些系统串联起来构建跨系统的AI应用。 而如果有多个不同的Agent应用需要接入时MCP服务维护团队只需要维护一份MCP Server代码。各个Agent只需要在配置文件里添加一份MCP Server的地址。可以通过中间层统一进行细粒度的权限管理。不过换而言之如果我们的一些系统没有这样的需求不会有多个Agent同时接入他的能力其实也没有必要额外去维护这么一套MCP Server如无必要 勿增实体奥卡姆剃刀原理在这里一样适用。07总结与展望1站在QA视角的思考对于身处质量保障一线的我们而言这场技术变革最大的启示在于不要让 AI 仅仅停留在浏览器的聊天窗口里。我们很容易习惯于把 AI 当作一个全能的问答机器遇到问题问一下生成一段代码贴一下。但这只是 AI 潜力的冰山一角。真正的质变发生在我们将 AI 落地到日常测试工具的那一刻。拒绝空谈从最小的工具开始动手不要一开始就试图构建庞大的自动化平台我们可以从手边最琐碎的痛点开始写一个脚本让 AI 帮你自动分析那几千条报错日志的共性做一个插件让 AI 帮你生成那些复杂的边界测试数据搞一个 Workflow处理那些以前用正则表达式怎么也匹配不准的非结构化校验。只有实践才能看清边界AI 不是万能的。只有当你亲自去调用API、去设计Prompt、去调试Agent时你才能深刻理解当前AI的能力边界在哪里——它擅长什么语义理解、模糊推理不擅长什么精确计算、长逻辑链条。正是这种通过实践获得的认知能帮助我们把以前工作中那些觉得“无法自动化”、“只能靠堆人力”的硬骨头转化为一个个精准的AI应用从而真正实现测试效率与质量的双重飞跃。2结语迎接 AI 应用的 “iPhone 4 时刻”如今大模型LLM的推理能力与各类MCP Server的生态正在以惊人的速度进化。可以说构建下一代AI应用的基础设施——从大脑Model到神经LangChain再到手脚MCP——已基本铺设完毕。我相信下一代AI应用的 “iPhone 4 时刻” 即将到来。届时AI将不再是需要精心调教的极客玩具而是成为功能完备、体验丝滑、能真正解决复杂问题的超级助手。未来已来让我们拭目以待。吧~如何学习AI大模型 “最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。【保证100%免费】CSDN粉丝独家福利这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】读者福利CSDN大礼包《最新AI大模型学习资源包》免费分享 安全链接放心点击对于0基础小白入门如果你是零基础小白想快速入门大模型是可以考虑的。一方面是学习时间相对较短学习内容更全面更集中。二方面是可以根据这些资料规划好学习计划和方向。1.大模型入门学习思维导图要学习一门新的技术作为新手一定要先学习成长路线图方向不对努力白费。对于从来没有接触过AI大模型的同学我们帮你准备了详细的学习成长路线图学习规划。可以说是最科学最系统的学习路线大家跟着这个大的方向学习准没问题。全套教程文末领取哈2.AGI大模型配套视频很多朋友都不喜欢晦涩的文字我也为大家准备了视频教程每个章节都是当前板块的精华浓缩。3.大模型实际应用报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示。全套教程文末领取哈4.大模型实战项目项目源码光学理论是没用的要学会跟着一起做要动手实操才能将自己的所学运用到实际当中去这时候可以搞点实战项目来学习。全套教程文末领取哈5.大模型经典学习电子书随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。全套教程文末领取哈6.大模型面试题答案截至目前大模型已经超过200个在大模型纵横的时代不仅大模型技术越来越卷就连大模型相关的岗位和面试也开始越来越卷了。为了让大家更容易上车大模型算法赛道我总结了大模型常考的面试题。全套教程文末领取哈为什么分享这些资料?只要你是真心想学AI大模型我这份资料就可以无偿分享给你学习我国在这方面的相关人才比较紧缺大模型行业确实也需要更多的有志之士加入进来我也真心希望帮助大家学好这门技术如果日后有什么学习上的问题欢迎找我交流有技术上面的问题我是很愿意去帮助大家的这些资料真的有用吗?这份资料由我和鲁为民博士共同整理鲁为民博士先后获得了北京清华大学学士和美国加州理工学院博士学位在包括IEEE Transactions等学术期刊和诸多国际会议上发表了超过50篇学术论文、取得了多项美国和中国发明专利同时还斩获了吴文俊人工智能科学技术奖。目前我正在和鲁博士共同进行人工智能的研究。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。CSDN粉丝独家福利这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】读者福利CSDN大礼包《最新AI大模型学习资源包》免费分享 安全链接放心点击