基于LangChain构建下一代AI应用

文章探讨了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 Agent：

1.理解：识别出两个核心任务：①查询服务器状态；②条件性创建定时任务。

2.规划：我需要先调用”服务器查询工具”，根据名称找到ID并获取监控数据。

3.执行：

• 调用监控工具：查询bridge9000的CPU负载 → 发现负载为92%。

• 决策：负载超过阈值（80%），需要安排重启。

• 调用定时任务工具：为bridge9000创建一条次日03:00执行的重启任务。

4.回复：“已确认游戏服本地测试9000（ID: 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理解意图 → 动态规划 → 调用工具 → 返回结果。

2

LLM-native架构核心组件

如下图所示：我们的下一代AI应用大体上的架构会分为：

应用层：也就是我们用户的直接操作入口

协调层：一般来说就是LLM(大语言模型)的能力，他要负责理解自然语言，做任务的拆解，工具的选择和决策 执行层：执行层可以认为是我们各类工具的封装，封装为LLM可以理解的格式，然后由LLM进行决策选择以后，再实际进行工具的调用

记忆层：因为AI应用往往会多次和LLM进行沟通，所以这里需要进行会话的记忆，来保证LLM可以正确理解全部的意图

数据层：提供各类数据的访问，检索，写入能力

3

LangChain：构建LLM-native应用的脚手架

目前构建AI应用的框架有很多， 比如dify，LlamaIndex等等，我这里选择使用LangChain来进行构建我们的AI应用。 简单来说，LangChain 是一个用于构建基于大语言模型应用的开源编排框架。它提供了一套标准化的组件和接口，帮助开发者：

1. 组件标准化：将LLM、提示词、工具、记忆等抽象为统一接口

2. 链式编排：将多个组件连接成可执行的”链”

3. 工具管理：简化工具的定义、注册和调用

4. 记忆管理：提供多种记忆存储和检索方式

而且LangChain还提供了从原型到生产的工具链支持：

1. LangSmith：一个强大的平台，用于调试、测试、评估和监控你的LLM 应用。你可以看到Agent每一步的思考过程，统计Token消耗，这对于复杂的AI应用开发极其重要。

2. 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应用架构至关重要。

2

AI Workflow

什么是AI Workflow？

AI Workflow是一种过程导向的设计模式。它将一个复杂的任务分解为一系列预定义的、结构化的步骤（节点）。数据按照预设的路径在这些节点之间流动。AI模型通常作为其中的一个或多个节点，负责处理特定的子任务（如总结、分类、提取）。

大家应该都写过类似的CICD工作流，比如代码提交前提交后的各种检查，各类策划表检查等等。AI Workflow其实就类似于CICD工作流，只不过是把其实部分节点的执行，判断等流程接入了LLM进行执行。

核心特征

• 确定性：路径是固定的。输入A经过流程必然得到输出B（除非中间的模型产生随机性，但流程本身是固定的）。

• 结构化编排：开发者拥有最大的控制权，精确定义了每一步的逻辑和条件分支。

优点

1. 高可靠性和可预测性：因为流程是写死的，系统行为非常稳定。对于企业级应用来说，结果的可控性至关重要。
2. 易于调试和维护：如果流程出错了，你可以精确地定位到是哪一个节点、哪一步出了问题。
3. 性能与成本优化：你可以针对每个特定的小步骤选择最合适的模型（例如，简单分类用小模型，复杂生成用大模型），从而精确控制Token消耗和响应时间。
4. 便于人类介入：可以在流程中显式地插入人工审核节点，确保关键步骤的安全。

缺点

1. 缺乏灵活性：面对预设流程之外的异常情况或新的输入类型，Workflow往往束手无策，容易报错。
2. 构建和维护成本高（针对复杂任务）：对于非常复杂的业务逻辑，设计一个面面俱到的工作流可能非常庞大且难以维护。你需要预判所有可能的分支。
3. 无法处理开放性问题：不适合需要探索、试错或没有固定解题路径的任务。

3

AI Agent

什么是AI Agent？

AI Agent是一种目标导向或声明式的设计模式。系统的核心是LLM，LLM作为Agent的大脑，它被赋予了一个高级目标和一组可用的工具。Agent通过自主的推理、规划、执行和观察结果来迭代地接近目标。

最经典的模式是ReAct循环，如下图所示：

核心特征

• 自主性：AI自己决定下一步做什么，而不是遵循预设的代码路径。
• 适应性：能够根据行动反馈的环境变化调整策略。
• 工具使用：具备调用外部API、搜索网络、查询数据库的能力。

优点

1. 极强的灵活性和泛化能力：能够处理模糊的指令和动态变化的环境。对于未曾见过的问题，它能尝试去解决。
2. 解决开放性复杂问题：适合那些步骤不确定、需要多步推理和外部信息辅助的任务。
3. 降低开发复杂度（对于特定场景）：对于某些复杂任务，你不需要写几千行if/else代码，只需给Agent提供好的工具和清晰的目标提示即可。

缺点

1. 不可预测性与幻觉风险：你无法100%确定 Agent 会采取什么路径。它可能会陷入死循环，或者自信地调用错误的工具产生破坏性后果，比如错误删除了部分数据。
2. 高延迟和高成本：Agent 通常需要进行多轮的思考和工具调用才能完成一个任务，这会导致大量的 Token 消耗和较长的响应时间。
3. 调试困难：当 Agent 失败时，很难确定是因为推理错误、工具返回了误导信息、还是提示词不够清晰。它的决策过程通常是一个黑盒。
4. 安全风险：赋予 Agent 自主调用工具的权限（尤其是执行代码或修改数据库）会带来巨大的安全隐患。

4

总结和对比

我们理解了AI Workflow和AI Agent后，我们可以通过下面的表格来清晰的了解这两种设计模式的区别。

维度	AI Workflow	AI 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模型，这里支持多种模型。ChatGpt，DeepSeek都可以，把用户输入的内容还有系统可以接收的关键字列表，结合我们写好的Prompt发送给LLM模型，等待LLM模型的返回输出。
• 结果判断和整合：这里判断LLM模型返回的结果置信度情况，判断结果是否可信，然后整理结果并返回 LangChain生态系统提供了LangSmith工具可以清晰的看到你的AI应用的调用链。如图所示：

4

LangChain实现

这里我会简单介绍一下如何用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 state

• LLM检查: 这里是最关键的内容，这里需要去构建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_ascii=False, indent=2)}
可用的时装类型列表:
{json.dumps(costume_types, ensure_ascii=False, indent=2)}
请以 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 result

Step3: 组装图

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点重启一次。”这里面就包含了多个跨系统的操作：

1. 去服务器管理平台查询全部服务器列表，找出本地测试8对应的服务器ID
2. 调用服务器管理平台的重启服务器接口，传入本地测试8对应的服务器ID
3. 调用定时任务平台的接口，创建一个重启服务器的定时任务 这是一个典型的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(
model=ChatOpenAI(model="deepseek-chat", temperature=0)
tools = [get_server_list, create_restart_server_job,restart_server]
)
user_input = "帮我重启一下本地测试8服务器，并设置为每天凌晨2点重启一次。"
initial_state = {
"messages": [HumanMessage(content=user_input)]
}
response = agent.invoke(initial_state, config={"recursion_limit": 10})

3

执行流程

然后我们还是可以通过LangSmith来跟踪整个AI Agent的执行过程：

我们可以看到在整个过程中，大模型的思考过程：

1. LLM

• 我们需要先知道本地测试8对应的服务器ID

• Call Tool: get_server_list

2. Tools

• 运行get_server_list方法

3. LLM

• 我已经找到了本地测试8对应的ID是8，当前的状态是运行中，然后设置每天凌晨2点的定时重启任务。首先重启服务器：

• Call Tool:restart_server, ‘args’: {‘server_id’: 8}

4. Tools

• 运行restart_server方法

5. LLM

• 很好！服务器已经重启成功。现在我来设置每天凌晨2点的定时重启任务。每天凌晨2点的cron表达式是 0 2 * * *。

• Call Tool: create_restart_server_job,‘args’: {‘server_id’: 8, ‘cron’: ‘0 2 * * *’}

6. Tools

• 运行create_restart_server_job方法

这里其实LLM使用了一种叫做Function Calling的技术，目前主流的大模型比如ChatGPT，DeepSeek等等都支持了这项技术，具体的实现这里就不再展开，有兴趣的同学可以自主去了解一下，可以简单的认为这项技术可以让大模型理解具体的方法调用方式，以及按照标准的格式返回大模型自己决策需要调用的方法，以及传入的参数等等信息。然后我们就可以根据大模型返回的Function Calling信息，直接去调用具体的方法。

4

Agent设计的原则

在刚才的演示中，我们的Agent只包含了3个工具，表现非常完美。但在实际企业级开发中，大家很容易产生一种冲动：“既然Agent这么好用，不如把公司所有的100个API接口都塞给同一个Agent，让它变成全能管家？”

千万不要这么做

根据业界目前的最佳实践，在设计Agent时，我们需要遵守以下核心原则，以确保系统的稳定性和可维护性：

1. 单一职责原则

• 规则： 一个Agent最好只专注于一个特定的业务领域。

• 反例： 创建一个SuperBot，既负责“查询服务器日志”，又负责“撰写周报”，还负责“订会议室”。

• 为什么：

• 注意力分散：LLM的注意力机制是有限的。当System Prompt过于复杂，或者工具列表过长时，模型很容易忽略关键指令，导致指令遵循能力下降。

• 幻觉风险激增： 如果一个Agent手里有太多相似的工具（比如delete_file和delete_database），他误用的概率会指数级上升。

2. 明确的能力边界

• 规则：清晰定义Agent不该做什么。

• 示例： 对于一个“只读的监控Agent”，不仅要在Prompt里写“你不能修改数据”，更应该在代码层面就不给它挂载update或delete类的工具。

• 为什么：

• 安全性：就像sql存在sql注入一样，提示词注入攻击更加防不胜防，对于大模型来说仅仅依靠Prompt说不要做什么事情是不够的，物理隔离，也就是限制工具能力才是最安全的。

• 调试便利性： 当系统出问题时，如果边界清晰，我们能迅速定位是“运维Agent”出了问题，而不是还要去排查是不是“会议室Agent”误操作了服务器。

3. 工具必须具备鲁棒性

• 规则：Agent调用的工具函数，不要直接抛出异常，返回值要对AI友好

• 为什么：

• 比如当API调用报错时，不要直接抛出异常，应该捕获异常并返回一个字符串，比如{“error”: “Connection failed, please try again later”}。这样Agent在获取到Tool的错误返回后，有机会根据错误信息进行自我修正，比如重试，或者换一种参数调用，而不是直接挂掉。

4. 工具定义即 Prompt

• 规则：所有工具函数必须具备严格的类型注解和 结构化、详尽的文档字符串也就是Docstrings。

• 为什么：

• LLM是通过阅读你的函数文档来理解“这个工具是干嘛的”以及“参数该怎么填”。模糊的描述（如“获取信息”）会导致LLM在不该调用的时候乱调用。

• LangChain框架会利用Python的类型注解生成Json Schema。如果缺乏类型注解，可能会出现需要int类型时传入了string等问题。

遵循上述原则，我们会发现：与其构建一个臃肿的全能Agent，不如构建一群各司其职的专家Agent，让他们协同工作。这里就会很类似我们人类的组织工作方式，这非常类似人类社会的组织方式：当面对一个复杂项目时，我们会组建一支由不同专业人才构成的团队，通过明确的分工与有效的项目管理，最终高效完成整体目标。

构建AI Agent系统也是如此。我们需要一套清晰的管理机制，来协调这群专家Agent，确保它们能像一支训练有素的团队一样，有序协作、共同解决问题。

这就引出了我们接下来要介绍的两个话题：

1. 混合架构：如何把这些各有所长的小Agent和Workflow组合起来解决复杂问题？

2. MCP协议：当工具和能力分散在不同Agent中时，如何通过统一的标准，实现灵活、高效的管理与调用？

05Workflow与Agent结合的混合架构

在前两章中我们分别介绍了AI Workflow和AI Agent两种AI应用的设计模型，并举例展示了两种设计模型的应用场景。但在实际应用中，这两者往往不是”非此即彼”的关系。事实上，最优秀的AI系统往往是两者的有机结合——用Workflow提供确定性、可靠性的流程控制，用Agent来实现高阶的工具处理能力。这一章我将通过我们组内刚刚实现的一个ItemReview AI工具来讲解一下这种混合架构的设计理念。

1

业务场景

在我们的游戏中，存在着大量的游戏道具，这些游戏道具不但有文字描述，还有实际的功能逻辑，例如一个简单的一个回血药：

• 描述：“【功效】回复气血2000”
• Action: AddHpDrup(2000)

这里策划的配置错误一般可能会有两种：

1. 描述中存在错别字，语病等情况
2. 描述和Action不符，比如描述中写【功效】回复气血2000，但是实际Action中配置成了AddHpDrup(1000)

而我们游戏中的道具又是成千上万级别的，这种描述的错误如果全部依赖QA的人工测试，很容易出现遗漏。但是如果使用传统的一些正则匹配，代码判断的方式，又基本无法检查出这类问题。所以为了解决这类问题，我们也需要设计一个AI 应用，他既要有Workflow的流程控制能力，又要有Agent的语义判断能力。

2

架构设计

这个系统的架构采用了经典的并行处理模式，在LangGraph中，我们称之为 Fan-out/Fan-in。如图所示：

整体流程解析

1. 路由节点（route_checks）

• 这是一个任务分发模块，他会根据读取Item的一些基本信息，然后来判断这个Item需要执行哪些检查

2. 错别字检查节点（typo_check_node）

• 这是一个专门用于检查错别字的Agent节点，其中挂载了两个Tool，一个会在策划表中模糊搜索某个词，返回使用到该词的上下文信息，另外一个Tool可以获取一个或多个Item的完整信息。然后Agent通过这两个Tool的能力一起判断Item中的描述是否存在语法和错别字相关问题。

3. 描述一致性检查节点 (action_description_check_node)

• 该Agent用于检查Action与描述是否一致，这里我们也给Agent挂载了两个Tool能力，其中一个Tool可以解析Item Action的含义，另外一个Tool用于获取Item的完整信息。通过这个Agent可以判断Action是否与描述一致

4. 等待节点 (wait_for_all_checks)

• 该节点确保所有被触发的并行任务都跑完了，才放行到下一步

5. 最终决策节点 (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工具开发，这种架构带来了三个核心收益：

1. 模块化与解耦：

• 如果我们以后还需要添加其他的Item检查内容，比如敏感词检查，我们只需要再去实现一个专门负责敏感词检查的Agent，并在路由层注册一下，完全不会影响到现有的两个检查逻辑。

2. 效率最大化：

• 通过Workflow的并行编排，错别字检查和逻辑检查是同时进行的。这比传统的线性对话速度提升了很多。

3. 可控的自主性：

• 这里我们也符合了我们上一张所说的Agent设计原则，每个Agent只负责自己那一块领域的工作，这大大降低了上下文干扰，让 AI 的表现更加精准、稳定。

06连接的进化——引入 MCP

在之前的部分，我们通过Function Calling的方式，手写Python代码让 Agent连接到了内部系统。这种方式虽然灵活，但在企业级应用中，它面临着重复造轮子和维护地狱的问题。比如我们多个组的Agent都要接入到权限平台，我们每个组可能都需要针对权限平台的接口去实现一套Function Calling的实现。以及如果权限平台有一些接口发生了修改时，我们各个组都需要去修改我们的Function Calling的实现（所以现在权限平台的接口应该不太敢动）。

为了解决这个问题，AI 行业引入了一个革命性的标准——MCP (Model Context Protocol)。

1

什么是MCP？AI时代的USB协议

如果把AI Agent比作一台电脑，把外部系统（数据库、redmine、服务器）比作外设（鼠标、键盘、打印机）。

• 没有MCP之前： 每连接一个新设备，你都需要自己写驱动程序。连接 redmine 要写一套 API 封装，连接服务器要写一套。如果你换了个AI模型（比如从GPT换到Claude），可能还得调整代码。
• 有了MCP之后： 它就像USB协议。无论你是redmine还是自家开发的服务器管理平台，只要你提供符合MCP标准的接口，任何支持MCP的客户端无论是Cladue Desktop, ChatBox还是Cursor IDE还是我们自己开发的LangChain Agent，都可以即插即用。

2

MCP服务是如何定义的

一个标准的 MCP Server 不仅仅是简单的 API 包装，它通过 JSON-RPC 协议向 AI 暴露了三个核心能力。这三个能力对应了 AI 认知的不同层面：

1. Resources (资源)

• 定义：被动读取的上下文数据。
• 作用：类似于文件读取。Agent可以直接读取这些内容作为Prompt的上下文。
• 例子：

■ server://logs/error.log (服务器日志)

■ file://test_cases/login_test.xlsx (本地测试用例)

2. Tools(工具)

• 定义：可执行的函数，能够改变系统状态或进行复杂计算。
• 作用：类似于API调用。
• 例子：

■ restart_service(server_id=8)

■ query_prometheus(metric=“cpu_usage”, duration=“5m”)

3. Prompts(提示词模板)

• 定义：服务启动的预定义交互模板，帮助Agent快速启动特定的任务。
• 作用：将复杂的 Prompt 工程封装在服务端。
• 例子：

@app.prompt('翻译专家')
async def translate_expert(
target_language:str = 'Chinese',) -> str:
return f'你是一个翻译专家，擅长将任何语言翻译成{target_language}。请翻译以下内容：'

3

动态发现机制：Agent是如何获取能力的

这是MCP最神奇的地方。Agent的代码里没有写死任何工具的名字。那么，Agent是怎么知道“我能重启服务器”的呢？ 这依赖于MCP的 “握手与发现” 机制：

1. 建立连接：Agent(作为MCP Client) 启动，通过stdio或SSE连接到 MCP Server（例如ServerHub MCP）。

2. 初始化：Agent发送初始化请求。

3. 能力协商：Server告诉Agent：“我支持Resources和Tools功能。”

4. 拉取清单：

●Agent发送tools/list请求。

●Server返回一个JSON列表，详细描述他拥有的工具：

{
"tools": [
{
"name": "restart_server",
"description": "重启指定服务器",
"inputSchema": { ... }
}
]
}

●Agent 同时也发送 resources/list 请求，获取可用资源列表。

5. 动态挂载：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应用需要接入时：

1. MCP服务维护团队只需要维护一份MCP Server代码。
2. 各个Agent只需要在配置文件里添加一份MCP Server的地址。
3. 可以通过中间层统一进行细粒度的权限管理。

不过换而言之，如果我们的一些系统没有这样的需求，不会有多个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%免费】🆓

优快云粉丝独家福利

这份完整版的 AI 大模型学习资料已经上传优快云，朋友们如果需要可以扫描下方二维码&点击下方优快云官方认证链接免费领取 【保证100%免费】

读者福利： 👉👉优快云大礼包：《最新AI大模型学习资源包》免费分享 👈👈

（👆👆👆安全链接，放心点击）

对于0基础小白入门：

如果你是零基础小白，想快速入门大模型是可以考虑的。

一方面是学习时间相对较短，学习内容更全面更集中。
二方面是可以根据这些资料规划好学习计划和方向。

👉1.大模型入门学习思维导图👈

要学习一门新的技术，作为新手一定要先学习成长路线图，方向不对，努力白费。

对于从来没有接触过AI大模型的同学，我们帮你准备了详细的学习成长路线图&学习规划。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。（全套教程文末领取哈）

👉2.AGI大模型配套视频👈

很多朋友都不喜欢晦涩的文字，我也为大家准备了视频教程，每个章节都是当前板块的精华浓缩。

👉3.大模型实际应用报告合集👈

这套包含640份报告的合集，涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示。（全套教程文末领取哈）

👉4.大模型实战项目&项目源码👈

光学理论是没用的，要学会跟着一起做，要动手实操，才能将自己的所学运用到实际当中去，这时候可以搞点实战项目来学习。（全套教程文末领取哈）

👉5.大模型经典学习电子书👈

随着人工智能技术的飞速发展，AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型，如GPT-3、BERT、XLNet等，以其强大的语言理解和生成能力，正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。（全套教程文末领取哈）

👉6.大模型面试题&答案👈

截至目前大模型已经超过200个，在大模型纵横的时代，不仅大模型技术越来越卷，就连大模型相关的岗位和面试也开始越来越卷了。为了让大家更容易上车大模型算法赛道，我总结了大模型常考的面试题。（全套教程文末领取哈）

为什么分享这些资料?

只要你是真心想学AI大模型，我这份资料就可以无偿分享给你学习，我国在这方面的相关人才比较紧缺，大模型行业确实也需要更多的有志之士加入进来，我也真心希望帮助大家学好这门技术，如果日后有什么学习上的问题，欢迎找我交流，有技术上面的问题，我是很愿意去帮助大家的！

这些资料真的有用吗?

这份资料由我和鲁为民博士共同整理，鲁为民博士先后获得了北京清华大学学士和美国加州理工学院博士学位，在包括IEEE Transactions等学术期刊和诸多国际会议上发表了超过50篇学术论文、取得了多项美国和中国发明专利，同时还斩获了吴文俊人工智能科学技术奖。目前我正在和鲁博士共同进行人工智能的研究。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

优快云粉丝独家福利

这份完整版的 AI 大模型学习资料已经上传优快云，朋友们如果需要可以扫描下方二维码&点击下方优快云官方认证链接免费领取 【保证100%免费】

读者福利： 👉👉优快云大礼包：《最新AI大模型学习资源包》免费分享 👈👈

（👆👆👆安全链接，放心点击）