从RAG到Agentic RAG：构建生产级可信AI Agent的工程实践

30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度1. 背景与核心概念从 RAG 到 Agentic RAG 的演进在构建基于大语言模型LLM的智能应用时检索增强生成RAG已成为解决模型“幻觉”和知识过时问题的标准范式。然而传统的 RAG 系统通常是一个静态的“检索-生成”管道其能力边界在系统设计之初就已划定。当面对复杂、多步骤或需要动态决策的查询时这种静态性便显得力不从心。这正是Agentic RAG要解决的问题。它不是一个新名词而是将智能体Agent的思维范式引入 RAG 工作流所带来的系统性升级。简单来说Agentic RAG 让 RAG 系统“活”了起来使其能够自主规划任务、调用工具、评估结果并迭代优化最终完成一个复杂目标。核心区别传统 RAG用户提问 → 检索相关文档 → LLM 基于检索内容生成答案。这是一个线性的、被动的响应过程。Agentic RAG用户提出复杂目标 →Agent 理解目标并制定计划→ 执行计划可能涉及多次、多策略的检索、调用计算器、调用 API、编写代码等→评估中间结果→ 调整计划或继续执行 → 最终整合信息生成可靠答案或执行动作。这是一个循环的、主动的求解过程。为什么需要工程化的 Agentic RAG当我们将 Agentic RAG 从演示原型推向生产环境时会面临一系列严峻挑战可靠性Agent 的决策链可能很长任何一步失败都可能导致整个任务崩溃。如何确保系统的稳定性和鲁棒性可信度生成的答案或执行的动作必须有据可循。如何向用户或审计系统证明其决策过程的合理性与信息来源的可信性效率与成本自主的规划与工具调用可能产生大量的 LLM 调用和外部 API 请求如何控制延迟与成本可观测性当系统出现错误或产生意外输出时如何像调试传统软件一样清晰地追踪 Agent 的“思考”过程因此工程化 Agentic RAG 系统的核心就是构建一个具备规划、执行、工具调用、记忆、评估能力同时满足生产环境对可靠性、可观测性、安全性和成本要求的智能系统。本文将以一个从“利用 Google Search 获取实时信息”到构建“生产级可信 AI Agent”的完整案例拆解其中的技术实现与工程实践。2. 环境准备与版本说明本文将基于 Python 生态进行构建使用 LangChain 作为 Agent 框架的核心因其工具生态和抽象较为成熟并搭配 Chroma 作为向量数据库。请注意版本依赖是生产部署中第一道坎务必记录并锁定。基础环境操作系统Ubuntu 20.04 LTS / macOS Monterey 及以上Linux 推荐用于生产部署Python3.10 或 3.113.12 需注意部分包的兼容性包管理Poetry 或 pip virtualenv核心依赖及版本示例# requirements.txt 或 pyproject.toml 关键部分 langchain0.1.0 langchain-community0.0.10 langchain-core0.1.0 # 使用 OpenAI 模型作为 Agent 的“大脑” openai1.6.1 # 向量数据库与嵌入模型 chromadb0.4.22 langchain-chroma0.1.0 sentence-transformers2.2.2 # 用于网页抓取与解析 beautifulsoup44.12.2 requests2.31.0 # 结构化输出与验证增强可靠性 pydantic2.5.0 # 异步支持提高吞吐量 httpx0.25.2 # 日志与监控 structlog23.2.0关键工具说明LLM 提供商本文示例使用 OpenAI GPT-4生产环境中可根据需求替换为 Anthropic Claude、本地部署的 Llama 3 等。关键是要选择支持“函数调用”Function Calling或“工具使用”Tool Use能力的模型。向量数据库Chroma 轻量易用适合原型和中小规模。生产级可考虑 Weaviate、Qdrant、Pinecone 等。搜索工具我们将封装 Google Search API如 SerpAPI或利用duckduckgo-search等开源包作为 Agent 获取实时信息的工具。开发与部署本地开发使用 Jupyter Notebook 或 IDE 进行调试。生产部署建议使用 Docker 容器化并通过 FastAPI 或 LangServe 暴露为 API 服务。3. 核心架构与原理拆解一个工程化的 Agentic RAG 系统通常包含以下核心模块其交互关系如下图所示概念图用户请求 | v [输入解析与意图识别] | v [任务规划器 (Planner)] ——— (制定多步骤计划) | v [工具执行器 (Executor)] —— [工具库 (Tools)] | | | v | [检索工具 (RAG)] | [搜索工具 (Search)] | [计算器 (Calculator)] | [代码执行器 (Code)] | v [状态记忆与评估 (Memory Evaluator)] ——— (评估结果决定继续或重规划) | v [响应生成与格式化] | v 最终输出 (附溯源引用)3.1 智能体Agent的核心循环ReAct 模式目前最主流的 Agent 推理模式是ReAct (Reason Act)。它让 LLM 在思考Reason和行动Act之间交替进行。一个典型的 ReAct 步骤思考LLM 分析当前情况、目标和可用工具决定下一步该做什么。行动LLM 选择并调用一个工具传入相应参数。观察获取工具执行的结果成功或失败。循环基于观察结果再次进入“思考”步骤直到任务完成或无法继续。LangChain 的AgentExecutor本质上就是实现了这个循环并处理了工具调用、解析、错误处理等繁琐逻辑。3.2 工具Tools的抽象与设计工具是 Agent 延伸能力的“手脚”。每个工具都应被设计为功能单一一个工具只做一件事。接口明确有清晰的输入参数描述和输出格式。鲁棒性强包含必要的错误处理和超时机制。对于 Agentic RAG 系统以下几类工具至关重要检索工具从内部知识库向量数据库中查找相关信息。搜索工具从互联网如 Google获取实时、外部信息。计算/处理工具进行数学计算、数据格式化、文本摘要等。验证工具检查信息的完整性、一致性或安全性。3.3 记忆Memory与状态管理Agent 需要记住之前的交互历史以避免重复操作和维持对话上下文。生产系统中记忆管理需考虑短期记忆保存在当前会话中用于管理多轮对话的上下文窗口。长期记忆可能需持久化到数据库用于记录跨会话的用户偏好或学习到的知识。关键信息提取不是所有对话都需要记忆需要设计策略来提取和存储关键决策点、事实和用户反馈。3.4 可信性与可观测性这是工程化的灵魂。溯源系统必须能记录每个事实片段的来源来自哪份文档、哪个网页、哪个 API并在最终答案中引用。思维链记录完整保存 Agent 的思考过程、工具调用记录及结果用于调试和审计。置信度评估对生成答案的置信度进行量化例如基于检索片段的相关性分数对于低置信度结果可以触发人工审核或保守回答。4. 完整实战构建一个生产级可信 AI Agent让我们构建一个能回答复杂、需要实时信息查询的 AI Agent。任务示例“请对比特斯拉 Cybertruck 和 Rivian R1T 在2024年的最新售价、续航里程和主要评测观点并给出一个购买建议。”4.1 项目结构与初始化创建项目目录并初始化虚拟环境。mkdir agentic-rag-system cd agentic-rag-system python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate pip install -r requirements.txt创建核心文件结构agentic-rag-system/ ├── app/ │ ├── __init__.py │ ├── agent/ │ │ ├── __init__.py │ │ ├── core_agent.py # Agent 核心定义 │ │ └── tools/ # 工具目录 │ │ ├── __init__.py │ │ ├── search_tool.py │ │ ├── rag_tool.py │ │ └── calculator_tool.py │ ├── memory/ │ │ ├── __init__.py │ │ └── conversation_memory.py │ ├── knowledge/ # 知识库相关 │ │ ├── __init__.py │ │ └── vector_store.py │ └── utils/ │ ├── __init__.py │ ├── logger.py # 结构化日志 │ └── safety_checker.py # 安全与内容检查 ├── config/ │ └── settings.py # 配置文件 ├── tests/ # 单元测试 ├── docker-compose.yml # 容器编排 ├── Dockerfile ├── requirements.txt └── main.py # 应用入口4.2 配置管理与工具定义首先在config/settings.py中管理配置# config/settings.py import os from pydantic_settings import BaseSettings class Settings(BaseSettings): # OpenAI openai_api_key: str os.getenv(OPENAI_API_KEY) openai_model: str gpt-4-turbo-preview # 使用支持函数调用的模型 # 搜索 API (示例用 SerpAPI) serpapi_api_key: str os.getenv(SERPAPI_API_KEY) # 向量数据库 chroma_persist_directory: str ./data/chroma_db embedding_model: str all-MiniLM-L6-v2 # 日志 log_level: str INFO class Config: env_file .env settings Settings()接下来定义几个核心工具。首先是搜索工具我们使用duckduckgo-search作为免费替代方案生产环境建议使用授权 API 以保证稳定性# app/agent/tools/search_tool.py from langchain.tools import BaseTool from pydantic import Field from duckduckgo_search import DDGS import asyncio from app.utils.logger import get_logger logger get_logger(__name__) class WebSearchTool(BaseTool): name: str web_search description: str ( Useful for when you need to answer questions about current events, real-time information, or topics not in the internal knowledge base. Input should be a clear search query string. ) num_results: int Field(default5, descriptionNumber of search results to return) def _run(self, query: str) - str: Synchronous run method. try: with DDGS() as ddgs: results [r for r in ddgs.text(query, max_resultsself.num_results)] if not results: return No relevant search results found. # 格式化结果包含标题、链接和摘要 formatted_results [] for i, r in enumerate(results[:3], 1): # 只取前3个详细显示 formatted_results.append( f[{i}] Title: {r.get(title, N/A)}\n f Link: {r.get(href, N/A)}\n f Snippet: {r.get(body, N/A)[:200]}... ) full_output fSearch results for {query}:\n \n---\n.join(formatted_results) logger.info(fWebSearchTool executed for query: {query}) return full_output except Exception as e: logger.error(fWebSearchTool error: {e}) return fSearch failed due to an error: {str(e)} async def _arun(self, query: str) - str: Asynchronous run method. # 简单包装实际生产应用应使用异步HTTP客户端 return await asyncio.to_thread(self._run, query)然后是RAG 检索工具。假设我们已有一个存储了公司内部产品文档的向量数据库# app/agent/tools/rag_tool.py from langchain.tools import BaseTool from pydantic import Field from langchain_chroma import Chroma from langchain_huggingface import HuggingFaceEmbeddings from app.config.settings import settings from app.utils.logger import get_logger logger get_logger(__name__) class InternalKnowledgeTool(BaseTool): name: str query_internal_knowledge description: str ( Useful for when you need to answer questions about our companys internal products, policies, documentation, or historical data. Input should be a clear question or keyword string. ) k: int Field(default3, descriptionNumber of document chunks to retrieve) def __init__(self, **kwargs): super().__init__(**kwargs) # 初始化嵌入模型和向量库 self.embeddings HuggingFaceEmbeddings( model_namesettings.embedding_model ) self.vectorstore Chroma( persist_directorysettings.chroma_persist_directory, embedding_functionself.embeddings ) self.retriever self.vectorstore.as_retriever(search_kwargs{k: self.k}) def _run(self, query: str) - str: 检索内部知识库. try: docs self.retriever.invoke(query) if not docs: return No relevant information found in the internal knowledge base. formatted_docs [] for i, doc in enumerate(docs, 1): # 假设文档有 metadata 包含 source source doc.metadata.get(source, unknown) formatted_docs.append( f[Doc {i} from {source}]:\n{doc.page_content[:300]}... ) full_output fInternal knowledge for {query}:\n \n---\n.join(formatted_docs) logger.info(fInternalKnowledgeTool retrieved {len(docs)} docs for query: {query}) return full_output except Exception as e: logger.error(fInternalKnowledgeTool error: {e}) return fFailed to query internal knowledge: {str(e)}4.3 构建核心 Agent我们将使用 LangChain 的create_react_agent来构建一个 ReAct 模式的 Agent。# app/agent/core_agent.py from langchain import hub from langchain.agents import AgentExecutor, create_react_agent from langchain_openai import ChatOpenAI from langchain.memory import ConversationBufferMemory from app.agent.tools.search_tool import WebSearchTool from app.agent.tools.rag_tool import InternalKnowledgeTool from app.agent.tools.calculator_tool import CalculatorTool # 假设有一个计算器工具 from app.config.settings import settings from app.utils.logger import get_logger from app.utils.safety_checker import SafetyChecker logger get_logger(__name__) class ResearchAgent: def __init__(self): # 1. 初始化 LLM self.llm ChatOpenAI( modelsettings.openai_model, temperature0, # 降低随机性提高可靠性 api_keysettings.openai_api_key ) # 2. 初始化工具 self.tools [ WebSearchTool(), InternalKnowledgeTool(), CalculatorTool() # 用于可能的数值比较 ] # 3. 从 LangChain Hub 拉取一个优化的 ReAct 提示词模板 # 提示词工程对 Agent 性能至关重要 self.prompt hub.pull(hwchase17/react-chat) # 4. 创建带有记忆的 Agent self.memory ConversationBufferMemory( memory_keychat_history, return_messagesTrue ) # 5. 创建 Agent self.agent create_react_agent( llmself.llm, toolsself.tools, promptself.prompt ) # 6. 创建执行器这是核心循环控制器 self.agent_executor AgentExecutor( agentself.agent, toolsself.tools, memoryself.memory, verboseTrue, # 生产环境应设为 False通过日志记录 handle_parsing_errorsTrue, # 优雅处理解析错误 max_iterations10, # 防止无限循环 early_stopping_methodgenerate, # 达到最大迭代或 Agent 决定停止时生成最终答案 ) # 7. 安全与内容检查器 self.safety_checker SafetyChecker() logger.info(ResearchAgent initialized successfully.) async def run(self, user_input: str) - dict: 运行 Agent 处理用户输入。 返回一个包含答案、溯源和思维链的字典。 logger.info(fAgent received query: {user_input}) # 安全检查 safety_result self.safety_checker.check_input(user_input) if not safety_result[is_safe]: return { answer: I cannot process this request due to safety policy restrictions., sources: [], chain_of_thought: [], error: safety_result[reason] } try: # 执行 Agent response await self.agent_executor.ainvoke({ input: user_input, chat_history: self.memory.chat_memory.messages }) final_answer response.get(output, No answer generated.) # 从记忆或自定义回调中提取思维链和工具调用记录 # 这里需要扩展 LangChain 的回调系统来捕获详细信息 chain_of_thought self._extract_chain_of_thought(response) sources self._extract_sources(chain_of_thought) # 对最终答案进行事实性和安全性后检查 final_answer self.safety_checker.post_check(final_answer) logger.info(fAgent completed query. Answer length: {len(final_answer)}) return { answer: final_answer, sources: sources, chain_of_thought: chain_of_thought, agent_steps: response.get(intermediate_steps, []) } except Exception as e: logger.exception(fAgent execution failed: {e}) return { answer: An error occurred while processing your request. Please try again or rephrase your question., sources: [], chain_of_thought: [], error: str(e) } def _extract_chain_of_thought(self, response) - list: 从 Agent 响应中提取思维链。实际实现需依赖回调。 # 简化示例从 verbose 输出或中间步骤解析 steps response.get(intermediate_steps, []) chain [] for action, observation in steps: chain.append({ action: str(action), observation: str(observation)[:500] # 截断长文本 }) return chain def _extract_sources(self, chain_of_thought) - list: 从思维链中提取信息来源如链接、文档ID。 sources [] for step in chain_of_thought: obs step.get(observation, ) # 简单正则匹配 URL生产环境需更精细的解析 import re urls re.findall(rhttps?://[^\s]|www\.[^\s], obs) sources.extend(urls) # 去重 return list(set(sources))4.4 运行与验证创建一个简单的 FastAPI 应用来暴露 Agent 服务并添加可观测性端点。# main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from app.agent.core_agent import ResearchAgent import uvicorn from app.utils.logger import get_logger logger get_logger(__name__) app FastAPI(titleProduction Agentic RAG API) agent ResearchAgent() # 注意生产环境应考虑生命周期管理如使用lifespan class QueryRequest(BaseModel): question: str user_id: str | None None # 用于记忆和审计 class QueryResponse(BaseModel): answer: str sources: list[str] success: bool request_id: str processing_time_ms: int | None None app.post(/query, response_modelQueryResponse) async def query_agent(request: QueryRequest): import time start_time time.time() request_id freq_{int(start_time)} logger.info(fRequest {request_id}: {request.question}) try: result await agent.run(request.question) processing_time int((time.time() - start_time) * 1000) response QueryResponse( answerresult[answer], sourcesresult.get(sources, []), successerror not in result, request_idrequest_id, processing_time_msprocessing_time ) # 记录完整的思维链和结果到结构化日志或数据库审计追踪 logger.info( Agent response, request_idrequest_id, user_idrequest.user_id, questionrequest.question, answer_lengthlen(result[answer]), sources_countlen(result.get(sources, [])), processing_time_msprocessing_time, has_errorerror in result ) return response except Exception as e: logger.error(fRequest {request_id} failed: {e}) raise HTTPException(status_code500, detailInternal agent error) app.get(/health) async def health_check(): return {status: healthy, service: agentic-rag} if __name__ __main__: uvicorn.run(main:app, host0.0.0.0, port8000, reloadTrue)使用curl或 Postman 进行测试curl -X POST http://localhost:8000/query \ -H Content-Type: application/json \ -d {question: 对比特斯拉 Cybertruck 和 Rivian R1T 在2024年的最新售价、续航里程和主要评测观点并给出一个购买建议。, user_id: test_user_1}预期输出结构{ answer: 基于当前信息特斯拉 Cybertruck 后轮驱动版起售价约为...而 Rivian R1T 起售价...。在续航方面...。主要汽车评测媒体认为...。\n\n**购买建议**如果您更看重...可以选择 Cybertruck如果...R1T 可能更合适。\n\n注价格和评测可能随时变化建议购买前查阅官网最新信息。, sources: [ https://www.tesla.com/cybertruck, https://www.rivian.com/r1t, https://www.motortrend.com/reviews/..., [内部文档] 2024_EV_Market_Analysis.pdf ], success: true, request_id: req_1712345678901, processing_time_ms: 12456 }4.5 结果说明通过上述流程我们构建的 Agent 会执行类似以下的步骤规划理解问题需要实时价格、规格和主观评测。执行调用WebSearchTool搜索 “Tesla Cybertruck 2024 price”。调用WebSearchTool搜索 “Rivian R1T 2024 range”。调用WebSearchTool搜索 “Cybertruck vs R1T review 2024”。可能调用InternalKnowledgeTool查询公司内部关于电动汽车市场的分析报告。调用CalculatorTool计算价格差或续航比例。评估与整合评估搜索结果的充分性整合信息权衡利弊最终生成附带引用的答案和建议。整个过程的每一步包括思考、工具调用和结果都被记录在chain_of_thought和日志中实现了可观测性。5. 常见问题与排查思路在生产中部署和运行 Agentic RAG 系统时你会遇到一系列典型问题。问题现象可能原因排查步骤与解决方案Agent 陷入循环或达到最大迭代1. 提示词引导不佳Agent 无法做出最终决定。2. 工具返回的结果无法满足 Agent 的决策条件。3. 任务本身过于开放或模糊。1.检查提示词在react-chat提示词中强化“当你拥有足够信息时请直接给出最终答案”的指令。2.优化工具输出确保工具返回结构化、清晰的信息避免噪音。3.设置更严格的停止条件降低max_iterations如设为 6并实现基于置信度的早期停止。工具调用失败或超时1. 外部 API 不可用或速率限制。2. 网络问题。3. 工具函数内部异常。1.实现重试与降级为工具调用添加指数退避重试机制。对于关键工具准备备用方案如搜索失败时返回“无法获取实时信息以下基于知识库回答”。2.添加超时控制为每个工具调用设置合理的超时时间如 10 秒。3.完善错误处理工具内部应捕获所有异常并返回对 Agent 友好的错误信息如“搜索服务暂时不可用”而不是抛出异常导致整个 Agent 崩溃。生成答案缺乏可信引用1. Agent 未能正确关联信息与来源。2. 工具返回的结果未包含可溯源的标识。1.改造工具输出格式强制要求每个工具返回的结果都包含来源标识。例如搜索工具返回[来源: URL]RAG 工具返回[来源: 文档ID]。2.在最终生成步骤强制引用在给 LLM 的最终生成提示词中明确要求它必须基于提供的、带有引用的上下文来回答并在答案中注明[1],[2]。答案包含事实错误或“幻觉”1. 检索或搜索到的信息本身有误。2. LLM 在整合信息时产生了误解或捏造。3. 上下文窗口过长导致关键信息被忽略。1.实施 RAG-Fusion 或 HyDE使用更先进的检索技术如 RAG-Fusion提高检索相关性。使用 HyDE 让 LLM 先生成一个假设答案再用它去检索提高精度。2.添加验证步骤在 Agent 工作流末尾增加一个“事实核查”子任务让另一个轻量级 LLM 或规则系统检查答案中的关键事实是否与提供的上下文一致。3.优化上下文管理对检索到的文档进行智能摘要或提取最关键句子而不是一股脑全部塞给 LLM。系统延迟过高1. 串行的工具调用。2. LLM 生成速度慢。3. 网络延迟。1.并行化工具调用如果多个工具调用之间没有依赖关系使用asyncio.gather并行执行。2.使用更快的模型对于规划步骤可以使用速度更快的模型如 GPT-3.5-turbo仅在最终生成时使用更强的模型如 GPT-4。3.实现流式输出对于长答案采用流式传输让用户先看到部分结果。成本失控1. Agent 步骤过多导致大量 LLM Token 消耗。2. 调用了收费昂贵的第三方 API。1.精细化成本核算记录每次请求的 Token 使用量和工具调用成本。2.设置预算和熔断为用户或会话设置 Token 预算超出后触发熔断返回“查询过于复杂”提示。3.缓存策略对常见的查询和工具结果进行缓存注意缓存实时性要求高的信息。6. 最佳实践与工程建议将 Agentic RAG 系统投入生产需要超越“能跑通”的层面关注可靠性、安全性和可维护性。6.1 提示词工程标准化模块化提示词不要将所有指令写在一个巨型提示词里。将系统指令、工具描述、格式要求、示例等分开管理便于维护和 A/B 测试。少样本学习在提示词中提供 2-3 个高质量的思考过程示例Few-shot能极大提升 Agent 执行复杂任务的准确性。输出结构化要求 LLM 以 JSON 等结构化格式输出其“思考”和“最终答案”便于后续程序化处理。6.2 可观测性与监控结构化日志使用structlog或类似库为每个请求记录唯一的request_id并记录完整的思维链、工具调用、耗时、Token 使用和最终结果。这不仅是调试的利器也是成本核算和效果评估的基础。链路追踪集成 OpenTelemetry 等分布式追踪系统可视化一个用户请求在 Agent 内部各个组件LLM 调用、工具执行、检索的流转和耗时。关键指标监控监控平均响应时间、错误率、工具调用失败率、Agent 迭代次数分布、高成本查询等。6.3 安全与合规输入/输出过滤在 Agent 处理前后必须进行内容安全过滤防止生成有害、偏见或不合规的内容。可以集成像Presidio这样的敏感信息识别库。工具权限控制不是所有用户或所有场景都需要所有工具。实现基于角色或上下文的工具权限控制例如禁止普通用户调用“执行数据库写入”的工具。数据隐私如果 Agent 会处理用户个人数据确保检索和生成过程中数据被妥善匿名化或脱敏并遵守 GDPR 等数据保护法规。6.4 性能与成本优化智能路由并非所有查询都需要启动完整的 Agent。可以前置一个分类器将简单、事实型查询直接路由到更便宜的普通 RAG 或问答接口仅将复杂、需要推理和多步操作的问题交给 Agent。缓存层层递进对 LLM 响应、工具结果、检索结果实施多级缓存。使用向量数据库的缓存功能或集成 Redis。异步化与并发如前所述将无依赖的工具调用并行化。整个 Agent 服务框架如 FastAPI也应采用异步模式提高吞吐量。6.5 测试与评估单元测试工具为每个工具编写单元测试模拟各种成功和失败场景。集成测试工作流构建一个涵盖典型用户查询的测试集定期运行评估 Agent 端到端的准确性和可靠性。基于人的评估定期抽样一些查询和答案由领域专家进行人工评估评估维度包括答案正确性、引用准确性、逻辑连贯性和有用性。用这些反馈持续优化提示词和工具。构建工程化的 Agentic RAG 系统是一场持久战其核心在于认识到你是在构建一个软件系统而不仅仅是调优一个模型。它需要软件工程的所有最佳实践清晰的架构、健壮的代码、全面的测试、细致的监控和持续的迭代。从 Google Search 工具集成起步到构建一个能在生产环境中可靠、可信、高效运行 AI Agent每一步都考验着开发者对技术深度和工程广度的把握。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度