news 2026/5/8 15:35:09

AI助手工程化实战：从LLM对话到智能体架构的完整开发指南

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
AI助手工程化实战：从LLM对话到智能体架构的完整开发指南

1. 项目概述与核心价值

最近在GitHub上看到一个挺有意思的项目，叫Johnxjp/ai-assistant-course。光看这个名字，你可能会觉得这又是一个关于“如何调教AI”的教程合集，市面上这类内容已经多如牛毛了。但当我真正点进去，花时间梳理了它的结构、代码和文档后，我发现它的定位远比我想象的要精准和务实。这本质上不是一个教你“AI是什么”的科普课，而是一个面向开发者和有一定技术背景的产品经理的“AI助手工程化实战指南”。

简单来说，这个项目解决了一个非常具体的痛点：当你手里有OpenAI、Claude或者国内大厂的API密钥，也看过一些Prompt Engineering的基础教程后，下一步该怎么做？如何把这些零散的知识点，整合成一个稳定、可维护、能真正嵌入到业务流程或产品中的“智能助手”？ai-assistant-course就是试图回答这个问题。它通过一系列循序渐进的实战案例，带你从最简单的命令行对话机器人，一路走到具备记忆、工具调用、复杂工作流编排的智能体（Agent）系统。对于想快速上手AI应用层开发，却又被各种框架和概念搞得眼花缭乱的朋友来说，这个项目提供了一个非常清晰的“最小可行路径”。

我自己在尝试将AI能力集成到内部工具时，就踩过不少坑。比如，如何管理不同场景下的Prompt模板？如何低成本地为AI助手添加“长期记忆”？当需要AI执行具体操作（如查询数据库、发送邮件）时，代码架构该怎么设计？这个项目里的案例，几乎覆盖了这些工程化过程中的常见挑战。接下来，我就结合自己的实践经验，对这个项目进行一次深度拆解，聊聊每个模块背后的设计思路、关键实现以及那些教程里不会写的“坑”。

2. 课程结构与学习路径解析

2.1 模块化设计：从简到繁的认知阶梯

这个项目的结构非常清晰，采用了典型的“爬坡式”设计。它不是一股脑地把所有代码扔给你，而是分成了几个核心阶段，每个阶段解决一类问题，并作为下一阶段的基础。我们可以将其核心路径归纳为以下四个台阶：

  1. 基础对话层：专注于与大语言模型（LLM）API的稳定通信、基础对话循环的实现。这里的关键是学会处理流式响应、管理对话上下文（Context）以及实现简单的角色设定（System Prompt）。
  2. 记忆与上下文管理：当对话轮次变多，如何让AI记住之前的聊天内容？项目引入了“记忆”的概念，探讨了滑动窗口、关键信息摘要等不同的上下文管理策略，这是构建实用助手的关键一步。
  3. 工具调用与功能扩展：让AI从“能说”到“会做”。这部分教你如何为AI定义工具（例如：查天气、计算器、搜索数据库），并让AI学会根据用户需求自动规划和调用这些工具。这是智能体（Agent）能力的核心。
  4. 智能体与工作流编排：将前面所有能力组合起来，构建能够自主完成复杂任务的智能体。例如，一个能够理解用户需求、自动分解任务、调用不同工具、并最终生成报告的分析助手。

这种结构的好处在于，学习者可以随时在任何一个阶段停下来，都能获得一个可工作的、具有明确价值的产物。比如，学完第二阶段，你就能做出一个带有记忆功能的客服聊天机器人原型；学完第三阶段，就能做出一个可以查询内部知识库的问答助手。

2.2 技术栈选型：为什么是这些工具？

项目主要基于 Python 生态，这是目前AI应用开发最主流、资源最丰富的选择。我们来看看它核心依赖的几个库：

  • LangChain / LlamaIndex：这两个是高频出现的框架。很多人会困惑到底选哪个。在这个项目的语境里，它们的角色更像是“脚手架”或“灵感来源”，而不是必须严格遵守的规范。项目代码往往展示了如何使用它们的核心概念（如Chain, Agent, Tool），但又保持了相对简洁的实现，避免被框架的复杂性淹没。这对于理解底层原理至关重要。
  • OpenAI API (及兼容方案)：作为默认的LLM接口。项目会教你如何封装API调用，如何处理鉴权、重试和速率限制。更重要的是，它会引导你思考如何使代码“模型无关”，以便轻松切换到 Claude、通义千问或本地部署的模型。
  • 向量数据库（如Chroma, FAISS）：当项目进展到需要为助手提供“知识”时，向量数据库登场了。它用于存储和检索文档的嵌入向量，是实现“基于自有知识库问答”的关键。项目通常会从最简单的纯内存向量库开始演示，再过渡到持久化方案。
  • 轻量级Web框架（如FastAPI, Gradio）：为了展示成果，需要给AI助手一个交互界面。FastAPI用于构建RESTful API供前端调用，Gradio则能快速生成一个带Web界面的演示程序。选择它们是因为其简单、高效，符合快速原型开发的定位。

注意：不要被这些工具吓到。项目的巧妙之处在于，它通常从一个最简单的、不用任何框架的openai库调用开始，让你先感受最原始的力量，然后再引入框架来解决随之而来的工程问题（如代码混乱、难以扩展）。这种“先体验痛点，再引入解决方案”的教学方式，非常符合学习规律。

3. 核心模块深度剖析与实操

3.1 对话引擎：不止是调用API

几乎所有教程都会教你用几行代码调用ChatCompletion API，但一个健壮的对话引擎远不止如此。我们来看看需要构建哪些组件：

1. 模型抽象层你不能把openai.ChatCompletion.create这样的调用写死在业务代码里。你需要一个模型抽象层，来统一不同厂商、不同型号LLM的调用方式。这个层至少需要处理：

  • 统一的消息格式：将用户输入、系统指令、历史对话转换成目标API要求的格式（如OpenAI的[{"role": "user", "content": "..."}]）。
  • 统一的参数配置：封装temperature, max_tokens等参数。
  • 统一的响应解析：从不同的API响应结构中，稳定地提取出所需的文本内容。
# 一个极简的模型抽象示例 class LLMClient: def __init__(self, model_type="openai", **kwargs): self.model_type = model_type self.api_key = kwargs.get("api_key") # 初始化不同模型的客户端 if model_type == "openai": self.client = OpenAIClient(self.api_key) elif model_type == "claude": self.client = AnthropicClient(self.api_key) # ... def chat(self, messages, **generation_params): """统一聊天接口""" if self.model_type == "openai": response = self.client.chat.completions.create( model=generation_params.get("model", "gpt-3.5-turbo"), messages=messages, stream=generation_params.get("stream", False), # ... ) return response.choices[0].message.content elif self.model_type == "claude": # 转换为Claude所需的格式... pass

2. 上下文管理这是对话助手的“大脑”。最简单的实现是一个列表，不断追加对话轮次。但问题很快会出现：上下文长度有限（如GPT-4 Turbo的128K），对话久了就会超出限制。

项目里会介绍几种策略：

  • 滑动窗口：只保留最近N轮对话。简单有效，但会“遗忘”早期的关键信息。
  • 关键信息摘要：当对话轮次达到一定阈值，让AI对之前的对话历史进行总结，然后用这个摘要代替原始历史，再继续后续对话。这能极大地扩展助手的“记忆跨度”。
  • 向量记忆：将历史对话中的重要信息（如用户偏好、事实陈述）转换为向量存入数据库，需要时进行检索。这属于更高级的长期记忆方案。

3. 流式输出处理如果响应需要好几秒，让用户看着空白屏幕等待体验很差。流式输出能逐词返回响应，像真人打字一样。实现上，你需要处理SSE（Server-Sent Events）或WebSocket，并在前端做相应的渲染。

# 一个FastAPI流式响应的后端示例 from fastapi import FastAPI, Request from fastapi.responses import StreamingResponse import asyncio app = FastAPI() async def generate_stream(prompt): # 模拟调用LLM的流式接口 async for chunk in your_llm_client.stream_chat(prompt): # chunk 可能是 {"text": "hello", "done": False} 格式 yield f"data: {chunk['text']}\n\n" await asyncio.sleep(0.05) # 控制流速，模拟打字效果 @app.post("/chat/stream") async def chat_stream(request: Request): data = await request.json() prompt = data.get("prompt") return StreamingResponse(generate_stream(prompt), media_type="text/event-stream")

3.2 记忆系统的工程实现

记忆是智能的基石。上面提到的上下文管理是一种“短期工作记忆”。而一个完整的记忆系统，通常包含以下层次：

  • 对话缓存：存储在内存或Redis中，键为用户会话ID，值为最近的对话列表。设置TTL（生存时间），实现会话的自动过期。
  • 摘要记忆：定期（如每10轮对话）触发一个后台任务，将当前对话历史发送给一个“总结专家”AI（通常使用更便宜、更快的模型，如gpt-3.5-turbo），生成一段浓缩的摘要。然后将这个摘要作为新的“系统提示”的一部分，或者存入数据库与用户ID关联。
  • 向量长期记忆：当用户提到“我喜欢吃辣”、“我住在北京”这类个人事实时，可以将其作为一条独立的“记忆片段”，转换为向量后存入向量数据库（如Chroma）。每条记忆附带元数据：用户ID、时间戳、置信度、标签等。当新对话开始时，可以将用户当前查询与向量记忆进行相似度检索，把相关的记忆片段动态注入到上下文提示中。
# 长期记忆检索的简化示例 class LongTermMemory: def __init__(self, vector_store): self.store = vector_store def add_memory(self, user_id, memory_text, tags=None): # 将文本转换为向量 embedding = get_embedding(memory_text) # 存入向量库，并记录元数据 self.store.add(embeddings=[embedding], metadatas=[{"user_id": user_id, "text": memory_text, "tags": tags}]) def retrieve_related_memories(self, user_id, query, top_k=3): # 将查询也转换为向量 query_embedding = get_embedding(query) # 从向量库中检索该用户最相关的记忆 results = self.store.query(query_embeddings=[query_embedding], where={"user_id": user_id}, n_results=top_k) return [item["metadata"]["text"] for item in results["matches"]] # 在对话前，检索相关记忆 related_memories = memory.retrieve_related_memories(user_id, current_user_input) if related_memories: # 将记忆作为额外上下文插入系统提示 enhanced_system_prompt = f"{base_system_prompt}\n\n关于用户的已知信息：{'; '.join(related_memories)}"

3.3 工具调用：让AI拥有“手脚”

工具调用（Function Calling）是AI从聊天机器人进化为智能助理的关键一跃。其核心思想是：你定义好工具（函数）的描述和参数格式，AI在理解用户意图后，可以主动请求调用某个工具，并生成符合格式的参数，然后由你的代码来执行这个工具，并将结果返回给AI，由AI组织最终的回答给用户。

1. 工具的定义与描述定义工具不仅仅是写一个Python函数。更重要的是如何向AI清晰地描述这个工具的功能、输入参数和输出。描述的质量直接决定了AI调用的准确率。

# 一个定义“获取天气”工具的示例 tools = [ { "type": "function", "function": { "name": "get_current_weather", "description": "获取指定城市的当前天气情况。", # 描述要清晰、具体 "parameters": { "type": "object", "properties": { "location": { "type": "string", "description": "城市名称，例如：'北京'，'San Francisco'。必须是一个明确的城市名。", }, "unit": { "type": "string", "enum": ["celsius", "fahrenheit"], "description": "温度单位。", } }, "required": ["location"], # 明确必填参数 }, }, } ]

2. 调用流程与错误处理标准的工具调用流程是一个循环：

  1. 将用户输入、系统提示、历史对话和工具定义发送给LLM。
  2. LLM判断是否需要调用工具。如果需要，它会返回一个结构化的调用请求（如{"name": "get_current_weather", "arguments": {"location": "北京"}}）。
  3. 你的代码解析这个请求，找到对应的本地函数，传入参数并执行。
  4. 将工具执行的结果（或错误信息）作为新的消息（role: “tool”）追加到对话历史中。
  5. 将整个更新后的历史再次发送给LLM，让它基于工具返回的结果生成面向用户的最终回答。

这个过程中，错误处理至关重要：

  • 工具执行失败：比如查询天气的API挂了。你应该将友好的错误信息（如“天气服务暂时不可用”）返回给AI，而不是抛出程序异常。
  • AI生成的参数不合法：比如城市名是“某个地方”。你的代码需要在调用真实工具前进行参数校验，如果无效，则返回一个指导性的错误信息给AI，让它重新生成或澄清。
  • 循环失控：要设置最大工具调用次数限制，防止AI陷入无限循环的自我对话。

3.4 智能体架构：从单步工具调用到多步规划

当任务变复杂，比如“帮我规划一个北京三日游，预算5000元，并列出每天的行程和餐厅推荐”，单次工具调用就不够了。这就需要智能体（Agent）出场。智能体的核心是“思考-行动-观察”的循环。

1. ReAct模式这是最经典的智能体模式之一。ReAct代表 Reasoning + Acting。智能体在每一步会：

  • 思考（Thought）：分析当前情况、目标和可用工具，决定下一步做什么。
  • 行动（Action）：根据思考，调用一个工具（或直接给出最终答案）。
  • 观察（Observation）：获取工具执行的结果。 然后循环，直到任务完成或达到步数限制。
# 一个极简的ReAct智能体循环伪代码 def react_agent(user_query, tools, max_steps=10): history = [{"role": "user", "content": user_query}] for step in range(max_steps): # 1. 思考与决策：让LLM根据历史和工具定义，决定下一步 llm_response = call_llm(history, tools, instruct="请逐步思考并决定下一步行动。") # 解析llm_response，看它是想调用工具还是直接回答 if llm_response.actions: # 假设解析出想调用工具 tool_name = llm_response.actions[0].name tool_args = llm_response.actions[0].args # 2. 行动：执行工具 observation = execute_tool(tool_name, tool_args) # 3. 观察：将结果加入历史 history.append({"role": "tool", "content": observation}) else: # LLM认为可以给出最终答案了 final_answer = llm_response.final_answer return final_answer return "任务未能在指定步数内完成。"

2. 规划与分解对于复杂任务，一个优秀的智能体应该先进行任务分解（Planning）。例如，对于旅游规划任务，它可以先规划出：“第一步，搜索北京的主要景点；第二步，根据景点位置规划三天的路线；第三步，根据路线和预算查找附近的餐厅；第四步，汇总成报告。” 然后按部就班地执行每一步。这通常通过一个更强大的“规划器”LLM（或同一个LLM在特定提示下）来实现。

3. 工具的选择与编排智能体需要从众多工具中选择合适的。项目可能会展示如何通过工具描述的自然语言相似度（结合嵌入向量）来推荐工具，或者如何让LLM自己根据工具描述进行选择。更复杂的场景还会涉及工具的并行调用和结果合并。

4. 项目实战：构建一个数据分析助手

让我们结合以上所有概念，构想一个实战项目：一个能理解自然语言、自动执行数据查询与分析并生成报告的数据分析助手。

4.1 需求与架构设计

核心需求：

  1. 用户用自然语言提问，如“上个月销售额最高的三个产品是什么？”。
  2. 助手能理解问题，将其转换为数据库查询（SQL）。
  3. 执行查询，获取数据。
  4. 对数据进行分析（计算、排序、统计）。
  5. 用文本和图表（如图表）的形式生成分析报告。

系统架构：

  • 前端：一个简单的Web界面（用Gradio或Streamlit快速搭建），包含输入框和显示区域。
  • 后端（AI核心）：
    • 意图识别与任务规划模块：判断用户问题是简单查询还是复杂分析，并分解步骤。
    • SQL生成工具：根据用户问题和数据库Schema，生成安全的SQL查询语句。（这是关键且危险的一步，必须严格控制）
    • SQL执行器：连接数据库，执行生成的SQL，返回结果集。
    • 数据分析工具：对结果集进行加工（如排序、分组、计算百分比）。
    • 可视化工具：调用Matplotlib或Plotly生成图表。
    • 报告生成器：将数据结果和图表整合成一段连贯的文字报告。
  • 数据库：一个示例数据库（如SQLite或PostgreSQL），包含销售数据。

4.2 关键实现与安全考量

1. 安全的SQL生成这是最大的风险点。绝对不能让AI直接生成并执行任意SQL。必须采取以下措施：

  • 严格限制数据库权限：为AI助手创建一个仅有SELECT权限的数据库用户，并且只能访问特定的视图（View），而非原始表。
  • 使用Schema描述：不要直接将数据库连接暴露给AI。而是预先提取出相关的表名、字段名、字段类型和简单的描述，作为上下文提供给AI。例如：
    { "tables": [ { "name": "sales", "description": "销售记录表", "columns": [ {"name": "product_id", "type": "int", "description": "产品ID"}, {"name": "product_name", "type": "varchar", "description": "产品名称"}, {"name": "sale_date", "type": "date", "description": "销售日期"}, {"name": "amount", "type": "decimal", "description": "销售金额"} ] } ] }
  • SQL语法校验与白名单：在执行生成的SQL前，用简单的解析器检查是否只包含SELECT语句，是否包含DROP、DELETE、UPDATE等危险关键词。更安全的做法是使用像SQLAlchemy这样的ORM，让AI生成的是对ORM的调用描述，而非原始SQL字符串。
  • 查询行数限制：在执行查询时，强制加上LIMIT 100之类的子句，防止AI无意中触发查询海量数据的操作。

2. 工具链的编排我们需要定义一系列工具：

  • generate_sql(query: str, schema_context: str) -> str：根据自然语言问题和Schema生成SQL。
  • execute_sql(sql: str) -> List[Dict]：执行SQL并返回JSON格式的结果。
  • analyze_data(data: List[Dict], analysis_instruction: str) -> Dict：对数据进行指定的分析（如排序、求Top N、计算总和）。
  • create_chart(data: List[Dict], chart_type: str) -> str：生成图表，返回图片的保存路径或Base64编码。
  • generate_report(data_analysis_result: Dict, chart_path: str, user_question: str) -> str：生成文字报告。

然后，设计一个智能体来协调这些工具。对于“上个月销售额最高的三个产品”这个问题，智能体的执行链可能是：用户提问->意图识别（识别为“数据查询与分析”）->调用 generate_sql 工具->调用 execute_sql 工具->调用 analyze_data 工具（指令为“按金额降序取前三”）->调用 create_chart 工具（类型为“柱状图”）->调用 generate_report 工具->返回最终报告（文字+图片）给用户。

4.3 前端展示与交互

使用Gradio可以快速构建界面：

import gradio as gr def chat_with_assistant(message, history): # history 是Gradio维护的对话历史列表 # 1. 将用户消息和必要的历史上下文发送给后端智能体 agent_response = call_agent_api(message, history) # 2. 智能体返回的结果可能包含文本和图片路径 if agent_response.get("chart_image"): # 如果是图文混合回复，Gradio支持返回元组 (文本, 图片) return agent_response["text"], agent_response["chart_image"] else: return agent_response["text"], None # 构建一个带聊天历史和图片显示功能的界面 demo = gr.ChatInterface( fn=chat_with_assistant, additional_inputs=[ gr.File(label="上传数据文件（可选）", type="filepath") # 可以扩展文件上传功能 ], multimodal=True # 支持多模态输出 ) demo.launch()

5. 部署、优化与避坑指南

5.1 部署考量

  • 环境配置：使用requirements.txt或Pipenv/Poetry严格管理依赖。考虑使用Docker容器化部署，确保环境一致性。
  • API密钥管理：绝对不要将API密钥硬编码在代码中。使用环境变量（.env文件）或专业的密钥管理服务（如AWS Secrets Manager, HashiCorp Vault）。在代码中通过os.getenv("OPENAI_API_KEY")读取。
  • 服务化：将AI助手核心逻辑封装成RESTful API（使用FastAPI）。这样前端（Web、移动端、桌面端）都可以方便地调用。API应设计得清晰，例如POST /v1/chat处理对话，POST /v1/agent/task处理复杂任务。
  • 并发与性能：LLM API调用通常是毫秒级甚至秒级。对于Web服务，必须使用异步框架（如FastAPI本身支持async/await）来处理并发请求，避免阻塞。考虑实现请求队列和限流，防止突发流量击垮服务或导致API费用暴涨。

5.2 性能与成本优化

  • 提示词优化：这是最有效的优化手段。精简System Prompt，移除不必要的指令。使用更具体的指令来减少AI的“废话”和无效思考，从而减少输出的token数。
  • 缓存：对于频繁出现的、结果确定的用户查询（例如“你是谁？”），可以将AI的回复缓存起来（使用Redis或内存缓存），下次直接返回，节省API调用。
  • 模型阶梯使用：并非所有任务都需要最强大、最昂贵的模型（如GPT-4）。可以用小模型（如gpt-3.5-turbo）处理意图分类、简单问答，用大模型处理复杂推理和创作。在智能体架构中，可以让一个便宜的“路由Agent”先判断任务类型，再分发给不同的“专家Agent”。
  • 上下文压缩：积极使用前面提到的对话摘要技术，这是应对长上下文成本高的最主要方法。

5.3 常见问题与排查实录

在开发这类AI助手时，你几乎一定会遇到下面这些问题：

1. AI不按预期调用工具，或者参数总是出错

  • 可能原因：工具描述不够清晰；提示词（System Prompt）中没有明确要求AI使用工具；示例（Few-shot）不够好。
  • 排查：首先，检查AI在收到请求时的完整提示（包括系统指令、历史、工具定义）。把这个提示打印出来，看看是否清晰。其次，在工具描述中多使用“必须”、“例如”、“特别是”等词语来强调重点。最后，在System Prompt中提供几个完美的工具调用示例（Few-shot Learning），效果立竿见影。

2. 响应速度慢

  • 可能原因：网络延迟；LLM API本身慢；智能体循环次数过多；本地代码有阻塞操作。
  • 排查：
    • 用time函数记录每个步骤的耗时：网络请求、LLM生成、工具执行。
    • 如果是智能体循环慢，考虑设置更低的max_tokens来限制AI每次思考的输出长度，或者优化任务规划，减少不必要的循环。
    • 确保所有I/O操作（数据库查询、文件读写、网络请求）都是异步的。

3. 对话突然“失忆”或逻辑混乱

  • 可能原因：上下文长度超限，被截断；记忆摘要过程出错，丢失了关键信息；向量记忆检索到了不相关的信息，干扰了AI。
  • 排查：实现上下文长度的监控和报警。检查摘要生成的提示词，确保它被要求保留“关键事实”和“用户明确偏好”。检查向量记忆检索的相似度阈值，过滤掉低分结果。

4. 费用失控

  • 可能原因：提示词过长；流式输出未正确关闭导致重复计费；有死循环导致无限调用API；被恶意用户攻击。
  • 对策：
    • 为API密钥设置使用量和频率限制。
    • 在代码层面，为每个用户或每个会话设置token消耗计数器，并设置硬性上限。
    • 对用户输入进行基本的过滤和鉴权。
    • 详细记录每一条API调用的消耗，便于分析和优化。

5. SQL生成工具产生危险查询

  • 原因：尽管有Schema描述，但AI仍可能生成带有DELETE或DROP的语句，或者产生笛卡尔积查询。
  • 终极安全策略：除了前文提到的权限限制和语法检查，最安全的方法是不直接生成SQL。而是训练AI将用户问题映射到一组预定义的、安全的查询模板ID和参数上。例如，你预先定义好10个查询模板（如“查询某时间段Top N产品”），AI只需要识别出意图并填充参数（如start_date,end_date,N），然后由你的代码来组装安全的SQL。这牺牲了一些灵活性，但换来了绝对的安全。

构建一个成熟的AI助手是一个持续迭代的过程。Johnxjp/ai-assistant-course这样的项目提供了绝佳的起点和思维框架。我的建议是，不要试图一次性实现所有功能。先从最简单的、能解决一个具体问题的版本开始，比如一个带记忆的聊天机器人。然后，当你和用户实际使用它时，会发现真正的痛点在哪里——是上下文不够长？还是回答不够准确？或者是无法执行特定操作？再针对性地引入工具调用、记忆系统或智能体规划。这种小步快跑、持续迭代的方式，远比一开始就设计一个庞大复杂的系统要高效和可靠得多。最终，你会发现，最重要的不是掌握了多少种框架，而是深刻理解了如何将LLM的强大能力，通过扎实的工程化手段，可靠、安全、高效地交付到用户手中。

版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
网站建设 2026/5/8 15:34:59

caj2pdf终极指南：轻松将CAJ学术文献转为可编辑PDF的完整教程

caj2pdf终极指南：轻松将CAJ学术文献转为可编辑PDF的完整教程 【免费下载链接】caj2pdf Convert CAJ (China Academic Journals) files to PDF. 转换中国知网 CAJ 格式文献为 PDF。佛系转换，成功与否，皆是玄学。 项目地址: https://gitcode.…

作者头像 李华
网站建设 2026/5/8 15:33:52

Spring AI Alibaba ReactAgent 调用Tool 实现多轮对话

官方文档:https://java2ai.com/docs/overview 前期准备及环境 apiKey: 阿里百炼大模型apiKey, 百度千帆apiKey OS:Win11 idea:2025.1 JDK:17 SpringBoot: 3.2.12 Maven: 3.8.5 代码结构: 详细代码 1.pom.xml <?xml version"1.0" encoding"UTF-8&qu…

作者头像 李华