当前位置： 首页 > news >正文

AI助手联网搜索实战：基于Kagi API构建实时信息检索技能

news 2026/5/10 8:18:28

1. 项目概述：当AI助手学会“上网冲浪”

如果你和我一样，长期在AI应用开发的一线摸爬滚打，那你一定对“幻觉”（Hallucination）这个词深恶痛绝。无论是让AI助手帮你总结一篇最新的技术博客，还是查询某个开源项目的具体版本号，它都可能给你一个看似合理、实则完全错误的答案。这是因为大语言模型（LLM）的知识库存在“时间戳”和“范围”的限制——它的训练数据是静态的，无法实时获取外部世界的最新信息。

这正是wawa1154/kagi-skills这个项目试图解决的核心痛点。简单来说，它是一个为AI助手（特别是基于OpenAI API或兼容接口的助手）打造的“外挂技能包”，核心功能是联网搜索。它通过集成Kagi Search API，让原本“闭门造车”的AI模型，能够实时访问互联网，获取最新、最准确的信息来回答问题。想象一下，你正在开发一个客服机器人，用户问“你们产品最新的优惠活动是什么？”或者“我的订单物流现在到哪了？”，传统的AI模型只能基于过时的训练数据瞎猜，而集成了这个技能包的助手，则可以立刻去官网或物流平台查询，给出精准的答案。这不仅仅是功能的增强，更是AI应用从“玩具”走向“工具”的关键一步。

这个项目适合所有正在或计划构建基于LLM的智能应用的开发者、产品经理和技术爱好者。无论你是想做一个能聊新闻的聊天机器人，一个能帮你分析市场动态的智能助理，还是一个需要实时数据支持的内部知识库，kagi-skills提供的这套“联网”能力，都是你必须认真考虑的基础设施。

2. 核心架构与设计思路拆解

2.1 为什么是Kagi？—— 搜索API的选型逻辑

市面上提供搜索API的服务商不少，Google Programmable Search、Bing Search API，甚至一些聚合服务如SerpAPI都是常见选择。那么kagi-skills为何选择Kagi作为后端？这背后有几个非常实际的考量，也是我们在做技术选型时需要学习的思路。

首先，是结果质量与去广告化。Kagi Search 以其高质量的搜索结果和完全无广告的体验著称。对于AI应用来说，搜索结果的“信噪比”至关重要。如果返回的网页摘要里充斥着推广链接和无关信息，会严重干扰LLM对核心信息的提取和总结。Kagi的搜索结果通常更干净、更相关，这直接提升了AI回答的准确性和专业性。

其次，是API的友好性与成本可控性。相比Google或Bing的API，Kagi的API设计通常更简洁，配额和定价模式对中小型开发者和项目起步阶段更友好。它提供了清晰的按次计费模式，开发者可以精确控制成本，而无需面对复杂的企业级套餐。这对于需要快速验证想法（PoC）或开发个人项目的场景来说，门槛低了很多。

最后，是对开发者生态的重视。Kagi提供了相对完善的文档和开发者支持，其API返回的JSON结构清晰，包含了丰富的元数据（如网页标题、摘要、URL、发布时间预估等），这些数据非常适合作为“上下文”（Context）直接喂给LLM进行处理。kagi-skills项目正是看中了这一点，它本质上是一个“适配器”（Adapter），将Kagi API的原始响应，封装成LLM易于理解和利用的格式。

注意：选择Kagi并不意味着它是唯一或永远的最佳选择。如果你的应用场景对中文搜索结果有极高要求，或者需要图像、视频等垂直搜索，可能需要评估其他服务。kagi-skills的设计价值在于它提供了一种模式，未来完全可以扩展适配其他搜索API。

2.2 技能（Skills）的设计哲学：模块化与可组合性

项目名称中的“skills”一词点明了其核心设计思想：模块化。它没有把联网搜索做死成一个庞大的、不可分割的功能块，而是将其设计为一个独立的“技能”。这个技能可以像乐高积木一样，被轻松地“安装”到不同的AI助手框架中。

这种设计带来了巨大的灵活性：

  1. 即插即用：开发者不需要重写整个AI助手的逻辑，只需要引入这个技能模块，并进行简单的配置，就能让助手获得联网能力。
  2. 职责分离：搜索技能只负责一件事：根据查询词，调用Kagi API获取搜索结果并格式化。它不处理对话历史、不管理Token、不生成最终回复。这种单一职责原则（SRP）使得代码更清晰，也更易于测试和维护。
  3. 易于扩展：今天可以有一个“联网搜索”技能，明天就可以基于同样的模式，开发“查询数据库”、“调用内部API”、“执行计算”等更多技能。一个强大的AI助手，正是由这样一系列专注的“技能”组合而成的。

在kagi-skills的具体实现中，这个“技能”通常会以一个函数或类的形式存在。它接收用户的自然语言查询（例如：“帮我找找2024年关于Rust语言在嵌入式系统应用的最新文章”），内部将其转换为适合搜索引擎的关键词，调用Kagi API，然后将返回的多个网页摘要、标题和链接，整合成一段结构化的文本，作为“补充信息”提供给LLM的主流程。LLM再基于原始问题和这些实时信息，生成最终的回答。

3. 核心细节解析与实操要点

3.1 API密钥管理与安全配置

任何涉及第三方API调用的项目，安全都是第一位的。kagi-skills的核心配置就是Kagi API密钥。处理不当，轻则密钥泄露导致经济损失，重则成为攻击者利用的入口。

正确的密钥管理姿势：

  1. 环境变量是黄金标准：绝对不要将API密钥硬编码在源代码中，尤其是打算开源或上传到GitHub的项目。应该使用环境变量来存储。

    # 在部署环境或本地开发环境中设置 export KAGI_API_KEY='your_actual_api_key_here'

    在代码中通过os.getenv('KAGI_API_KEY')来读取。

  2. 使用配置文件（进阶）：对于更复杂的项目，可以使用.env文件配合python-dotenv库，或者使用专门的配置管理库（如pydantic-settings）。这便于管理多环境（开发、测试、生产）的不同配置。

    # .env 文件 KAGI_API_KEY=your_actual_api_key_here ENVIRONMENT=development
    # config.py from pydantic_settings import BaseSettings class Settings(BaseSettings): kagi_api_key: str environment: str = "development" class Config: env_file = ".env" settings = Settings()

  3. 密钥的权限隔离：如果可能，在Kagi账户中创建仅具有搜索权限的API密钥，而不是使用最高权限的账户密钥。这遵循了最小权限原则。

实操心得：在开发初期，我习惯在代码里写个api_key = "test_key"来快速测试，但无数次血泪教训告诉我，一定要在第一次提交代码前就改成从环境变量读取。否则，一个不经意的git push就可能让你在几分钟内收到天价账单的预警邮件。可以设置一个pre-commit钩子，检查代码中是否有明显的密钥字符串模式，防患于未然。

3.2 查询构造与结果过滤策略

用户的问题是自然语言，但搜索引擎更喜欢关键词。如何将“帮我总结一下特斯拉2024年第一季度的财报亮点”转换成有效的搜索查询，是影响结果质量的关键。

基础策略：

  • 提取实体和关键词：可以先用LLM本身对用户问题进行一个轻量级的分析，提取出核心实体（如“特斯拉”、“2024年Q1”、“财报”）和意图（“总结亮点”）。但这样会增加一次LLM调用和延迟。一个更简单直接的方法是，直接使用整个问题作为搜索词，Kagi等现代搜索引擎的自然语言处理能力已经很强。
  • 添加限定词：为了提高时效性和相关性，可以在查询中自动添加时间限定。例如，将原始查询拼接上“2024 最新”等字样。但这需要谨慎，避免扭曲用户原意。

结果过滤与排序：Kagi API通常会返回多个结果。全部扔给LLM会消耗大量Token（且贵），且可能包含冗余或低质信息。

  1. 按相关性评分（Score）筛选：Kagi的返回结果通常包含相关性分数，可以设定一个阈值，只保留分数高于阈值的结果。
  2. 按域名权威性过滤：对于需要高可信度的场景（如医疗、金融），可以维护一个可信域名白名单（如*.gov,*.edu, 知名新闻媒体域名），优先采用这些来源的结果。
  3. 去重：不同新闻网站可能报道同一事件。可以根据标题相似性或内容摘要进行简单的去重，避免信息重复。
  4. 数量控制：通常，3-5个最相关的结果片段就足够LLM合成一个高质量的回答了。这是一个成本与效果的平衡点。

代码示例示意：

def construct_search_query(user_query: str, add_time_constraint: bool = True) -> str: """构造搜索查询词""" query = user_query.strip() if add_time_constraint and looks_like_news_or_fact_query(query): # 一个简单的启发式判断：如果问题中包含“最新”、“今年”、“2024”等词，或涉及公司财报、科技新闻，则加强时效性 query = f"{query} 2024" return query def filter_and_rank_results(search_results: list, top_k: int = 3, min_score: float = 0.5) -> list: """过滤和排序搜索结果""" # 1. 按相关性分数过滤 filtered = [r for r in search_results if r.get('score', 0) > min_score] # 2. 按分数降序排序 filtered.sort(key=lambda x: x.get('score', 0), reverse=True) # 3. 返回前 top_k 个 return filtered[:top_k]

3.3 Token管理与上下文构建的平衡术

这是集成搜索技能时最容易被忽视，也最容易“爆预算”的环节。LLM的上下文窗口是有限的（如GPT-4 Turbo的128K），且输入Token需要计费。搜索返回的网页摘要可能很长，如何高效地将信息注入上下文？

策略一：摘要再摘要（Summarize-on-Summarize）不要直接把完整的搜索结果JSON或长文本塞进去。kagi-skills应该做一层预处理：

  1. 从每个搜索结果中提取最核心的字段：title（标题）、snippet（摘要片段）、url（链接）。
  2. 将这些信息拼接成一个格式清晰、紧凑的文本块。例如：
    [搜索结果 1] 标题：特斯拉发布2024年Q1财报，营收同比增长XX%。摘要：报告显示，汽车交付量达到... 链接：https://example.com/1 [搜索结果 2] 标题：分析师点评特斯拉Q1：利润率受挑战，AI投入是亮点。摘要：尽管营收增长，但降价策略影响了... 链接：https://example.com/2
  3. 这个文本块就是最终提供给LLM的“搜索上下文”。它信息密度高，结构清晰，便于LLM参考。

策略二：动态上下文窗口管理如果你的助手支持长对话，需要将搜索上下文、历史对话、系统指令都纳入考虑。一个常见的模式是采用“滑动窗口”：

  • 系统指令（固定）
  • 最近的几轮对话（最近N轮）
  • 本次的搜索上下文
  • 用户当前问题 当总Token数接近模型上限时，优先压缩或丢弃最早的对话历史，保留搜索上下文和最新对话，因为前者是回答当前问题的关键实时信息。

实操心得：我曾经在一个项目中，因为贪心地把10个搜索结果的完整摘要（每个都好几百字）都塞进了上下文，导致单次调用的输入Token超过了8000，成本飙升且速度变慢。后来优化为只取前3个结果，且每个结果只保留前150个字符的摘要，回答质量几乎没有下降，但成本和延迟降低了70%。“少即是多”在RAG（检索增强生成）场景下非常适用。务必在项目早期就加入Token计数和成本监控日志。

4. 实操过程与核心环节实现

4.1 环境搭建与依赖安装

假设我们使用Python作为开发语言，并基于一个常见的AI应用框架（如LangChain、LlamaIndex，或自定义的FastAPI服务）来集成kagi-skills。以下是标准的起步流程。

步骤1：创建项目并初始化环境

# 创建项目目录 mkdir my-ai-assistant && cd my-ai-assistant # 创建虚拟环境（推荐使用uv或conda） python -m venv venv # 激活虚拟环境 # On Windows: venv\Scripts\activate # On macOS/Linux: source venv/bin/activate # 安装基础依赖 pip install requests python-dotenv openai

这里我们安装了requests用于调用Kagi API，python-dotenv管理环境变量，openai作为LLM客户端。

步骤2：获取并配置Kagi API密钥

  1. 访问Kagi官网，注册账号并进入仪表板。
  2. 在API设置部分，生成一个新的API密钥。妥善保存。
  3. 在项目根目录创建.env文件，并填入密钥：
    KAGI_API_KEY=your_kagi_api_key_here OPENAI_API_KEY=your_openai_api_key_here # 如果需要
  4. 创建.gitignore文件，确保.env被忽略。

步骤3：构建核心搜索技能模块创建一个名为kagi_search_skill.py的文件，实现核心功能：

import os import requests from typing import List, Dict, Optional from dotenv import load_dotenv load_dotenv() # 加载环境变量 class KagiSearchSkill: def __init__(self, api_key: Optional[str] = None): self.api_key = api_key or os.getenv("KAGI_API_KEY") if not self.api_key: raise ValueError("Kagi API key not found. Please set KAGI_API_KEY in your environment.") self.base_url = "https://kagi.com/api/v0/search" self.session = requests.Session() self.session.headers.update({ "Authorization": f"Bot {self.api_key}", "Content-Type": "application/json" }) def search(self, query: str, limit: int = 5) -> List[Dict]: """执行搜索并返回格式化后的结果列表""" params = { "q": query, "limit": limit } try: response = self.session.get(self.base_url, params=params) response.raise_for_status() # 如果状态码不是200，抛出HTTPError data = response.json() except requests.exceptions.RequestException as e: # 在实际项目中，这里应该有更完善的错误处理和重试逻辑 print(f"搜索请求失败: {e}") return [] except ValueError as e: print(f"解析JSON响应失败: {e}") return [] # 解析并格式化结果 formatted_results = [] for item in data.get('data', []): # 根据Kagi API实际返回的字段名进行调整 formatted_results.append({ 'title': item.get('title', 'No Title'), 'snippet': item.get('snippet', '')[:300], # 限制摘要长度 'url': item.get('url', ''), 'score': item.get('score', 0.0) # 假设有相关性分数 }) return formatted_results def format_results_for_llm(self, results: List[Dict]) -> str: """将搜索结果格式化为LLM易于理解的文本""" if not results: return "未找到相关的实时信息。" context_lines = ["以下是根据你的问题搜索到的实时信息："] for i, res in enumerate(results, 1): context_lines.append(f"{i}. 【{res['title']}】") context_lines.append(f" 摘要：{res['snippet']}") context_lines.append(f" 链接：{res['url']}\n") return "\n".join(context_lines) # 使用示例 if __name__ == "__main__": skill = KagiSearchSkill() query = "Python asyncio 在Web开发中的最佳实践" results = skill.search(query, limit=3) llm_context = skill.format_results_for_llm(results) print(llm_context)

4.2 与AI助手主流程集成

现在，我们需要将这个技能“挂载”到AI助手的主循环中。这里以简单的命令行聊天助手为例。

步骤1：构建助手核心创建一个assistant.py文件：

import openai from kagi_search_skill import KagiSearchSkill import os from dotenv import load_dotenv load_dotenv() class AISearchAssistant: def __init__(self, llm_model: str = "gpt-3.5-turbo"): self.llm_client = openai.OpenAI(api_key=os.getenv("OPENAI_API_KEY")) self.llm_model = llm_model self.search_skill = KagiSearchSkill() # 简单的对话历史管理 self.conversation_history = [ {"role": "system", "content": "你是一个有帮助的AI助手，可以访问实时网络信息来回答问题。请基于提供的搜索信息，给出准确、简洁的回答，并在必要时注明信息来源。"} ] def _needs_search(self, user_input: str) -> bool: """一个简单的启发式判断：用户问题是否需要联网搜索""" # 这里可以做得更复杂，比如用一个小型分类器 need_search_keywords = ['最新', '今天', '2024', '新闻', '股价', '天气', '实时', '当前'] if any(keyword in user_input for keyword in need_search_keywords): return True # 或者判断问题是否涉及事实性、时效性内容 # 这是一个简化版，实际应用中可能需要更精细的策略 return False def generate_response(self, user_input: str) -> str: """生成助手的回复""" # 1. 判断是否需要搜索 search_context = "" if self._needs_search(user_input): print("(检测到需要实时信息，正在搜索...)") search_results = self.search_skill.search(user_input, limit=3) search_context = self.search_skill.format_results_for_llm(search_results) # 将搜索上下文作为一条特殊的历史消息加入 self.conversation_history.append({"role": "user", "content": f"用户问题：{user_input}\n\n{search_context}"}) else: # 不需要搜索，直接加入用户问题 self.conversation_history.append({"role": "user", "content": user_input}) # 2. 调用LLM生成回复 try: response = self.llm_client.chat.completions.create( model=self.llm_model, messages=self.conversation_history, temperature=0.7, max_tokens=500 ) assistant_reply = response.choices[0].message.content # 3. 将助手回复加入历史，并管理历史长度（防止超出Token限制） self.conversation_history.append({"role": "assistant", "content": assistant_reply}) # 简单的历史长度控制：只保留最近10轮对话（含系统指令） if len(self.conversation_history) > 11: # 系统指令 + 10轮对话 self.conversation_history = [self.conversation_history[0]] + self.conversation_history[-10:] return assistant_reply except Exception as e: return f"抱歉，生成回复时出现错误：{e}" # 运行一个简单的交互循环 if __name__ == "__main__": assistant = AISearchAssistant() print("AI搜索助手已启动。输入'退出'或'quit'结束对话。") while True: try: user_input = input("\n你：") if user_input.lower() in ['退出', 'quit', 'exit']: print("助手：再见！") break reply = assistant.generate_response(user_input) print(f"助手：{reply}") except KeyboardInterrupt: print("\n对话结束。") break

4.3 效果优化与高级功能集成

基础功能跑通后，我们可以从以下几个方向进行优化，打造更强大、更智能的助手。

1. 搜索触发策略智能化上面的_needs_search方法非常简陋。更优的方案是使用LLM本身来判断。我们可以设计一个“路由”（Routing）机制：

  • 准备一个简化的系统指令：“判断用户问题是否需要实时网络信息来回答。只需回答‘是’或‘否’。”
  • 将用户问题发送给一个快速、廉价的模型（如gpt-3.5-turbo）进行判断。
  • 根据返回的“是/否”来决定是否触发搜索。这样更准确，但会增加一点延迟和成本。

2. 结果后处理与引用溯源为了让回答更可信，可以让LLM在回答中引用来源。在format_results_for_llm中，给每个结果一个明确的编号（如[1],[2]）。然后，在给LLM的系统指令中要求：“请在回答中，对于引用的信息，在句末用方括号标注来源编号，例如‘据某报道[1]...’”。这样生成的回答会自带引用，方便用户查证。

3. 缓存与去重对于常见或重复的问题（例如多人问同一个新闻），频繁搜索会造成浪费。可以引入一个简单的缓存机制（如使用functools.lru_cache或Redis），将(query, limit)作为键，搜索结果作为值，缓存一段时间（例如10分钟）。这能显著降低API调用次数和响应延迟。

4. 错误处理与降级方案网络请求可能失败，Kagi API可能有速率限制。一个健壮的系统需要：

  • 重试机制：对于网络错误或5xx服务器错误，进行指数退避重试。
  • 降级方案：如果搜索完全失败，可以回退到不使用实时信息的模式，并坦诚告知用户“目前无法获取最新信息，以下回答基于我的通用知识”。
  • 监控与告警：记录搜索失败率、延迟等指标，设置阈值告警。

5. 常见问题与排查技巧实录

在实际集成和使用kagi-skills这类功能时，你会遇到一些典型问题。下面是我踩过坑后总结的排查清单。

5.1 搜索无结果或结果质量差

问题表现：AI助手回答“未找到相关信息”，或者给出的回答明显基于过时/错误的信息。排查步骤：

  1. 检查查询词：首先打印出实际发送给Kagi API的查询词。它可能被意外截断、编码错误，或者添加了不合适的限定词。确保查询词准确地反映了用户意图。
  2. 手动验证：将打印出的查询词直接粘贴到Kagi的网页搜索中，看是否能得到预期结果。如果网页有结果而API没有，可能是API参数问题（如地区限制、安全搜索过滤等）。
  3. 调整搜索参数：Kagi API可能支持更多高级参数，如region（地区）、safe_search（安全搜索等级）。尝试调整这些参数。例如，对于技术问题，关闭安全搜索可能获得更多论坛、代码仓库的结果。
  4. 结果数量（limit）：默认的limit可能太小（比如5）。对于宽泛的问题，可能需要增加到10才能覆盖足够的信息源。
  5. 关键词 vs 自然语言：如果用户问题很长且口语化（如“我听说最近有个叫Sora的AI很火，它能做什么？”），直接作为查询词可能效果不佳。尝试让LLM先提取关键词（“Sora AI 功能”），再用关键词搜索。

实操心得：不要完全信任AI的“判断”。初期我让AI自动判断是否搜索，发现它有时会对明确需要实时信息的问题（如“现在几点了？”——虽然这个问题本身奇怪）选择不搜索。后来我在系统指令里加入了强制规则：“如果用户问题中包含具体日期、时间、‘最新’、‘当前’等明确表示需要实时信息的词汇，则必须执行搜索。” 规则与AI判断相结合，可靠性大大提升。

5.2 回答未有效利用搜索结果

问题表现：虽然搜索到了相关信息，但AI的回答似乎完全忽略了它们，或者只是机械地复述片段，没有进行整合推理。排查步骤：

  1. 检查上下文格式：将最终构建的、准备发送给LLM的完整消息列表（包括系统指令、历史、搜索上下文、当前问题）打印出来。确保搜索上下文被正确地放置在消息序列中，并且格式清晰易读。混乱的格式会让LLM困惑。
  2. 强化系统指令：系统指令是引导LLM行为的关键。指令需要明确告诉LLM：“你必须优先使用提供的搜索信息来回答问题。只有在搜索信息不足时，才使用你的内部知识。请综合多个来源的信息，给出连贯的回答。” 指令的措辞需要反复调试。
  3. 调整上下文位置：尝试将搜索上下文放在更靠近用户当前问题的位置。有些模型对消息序列末尾的内容更敏感。可以尝试将历史对话放在前面，然后是搜索上下文，最后是当前问题。
  4. 使用更强大的模型：如果使用的是gpt-3.5-turbo，尝试切换到gpt-4-turbo。更大的模型在遵循复杂指令、综合多段信息方面的能力通常更强，当然成本也更高。

5.3 成本失控与性能瓶颈

问题表现：API调用费用快速增长，或用户感觉助手响应变慢。排查与优化：

  1. 实施Token计数与限流：
    • 在每次调用LLM前，计算本次请求的Token数（可以使用tiktoken库）。记录并监控。
    • 为每个用户或每个会话设置Token消耗上限或搜索次数上限，防止滥用。
  2. 优化搜索策略：
    • 缓存：如前所述，实现查询缓存。
    • 选择性搜索：并非每个问题都需要搜索。优化你的_needs_search判断逻辑，减少不必要的搜索调用。
    • 结果裁剪：严格限制返回给LLM的搜索结果片段长度和数量。通常前3个结果的摘要前150字符就足够了。
  3. 异步处理：如果您的应用是Web服务，考虑将搜索操作改为异步。即先快速返回一个“正在为您查询…”的提示，在后台执行搜索和LLM调用，再通过WebSocket或轮询将最终结果推送给用户。这能极大提升用户体验。
  4. 监控与告警：设置关键指标的监控，如：
    • 日均/月均搜索调用次数
    • 平均每次对话的Token消耗
    • API错误率
    • 95分位响应延迟 当这些指标出现异常时，及时触发告警。

5.4 安全性、隐私与内容合规

问题表现：助手可能搜索并传播有害、偏见或虚假信息，或处理了用户隐私数据。应对策略：

  1. 输入过滤与审查：在将用户查询发送给搜索API前，进行一层基本的审查。过滤明显的攻击性、仇恨性或非法的关键词。这可以在应用层快速实现一个轻量级的黑名单。
  2. 输出审核：对于高风险领域的应用（如医疗、法律、金融），考虑在LLM生成最终回答后，再经过一个内容安全过滤器（可以是规则，也可以是另一个审核模型），检查是否有不实信息或不当内容。
  3. 隐私保护：明确告知用户对话可能会用于联网搜索。避免在搜索查询中嵌入任何可识别个人身份的信息（PII）。如果应用日志记录了搜索查询，要做好日志脱敏。
  4. 使用API的安全特性：充分利用Kagi API可能提供的安全搜索（SafeSearch）等参数，从源头上过滤掉大部分不良内容。

最后一点体会：给AI装上“联网搜索”这个技能，就像给一个博学的学者配了一部随时能上网的手机。它极大地扩展了能力的边界，但也引入了新的复杂性——信息过载、噪音干扰、成本控制、响应延迟。成功的集成不在于功能的有无，而在于如何在“智能”与“可控”、“强大”与“高效”之间找到那个精妙的平衡点。wawa1154/kagi-skills提供了一个优雅的起点，而真正的挑战和乐趣，在于你如何基于它，去构建那个真正理解用户、快速准确、并且安全可靠的智能体。

http://www.jsqmd.com/news/788251/

相关文章：

  • 【技术趣闻 | AI Agent Skill】为什么 AI 总绕着同一个脑回路转？多语言思维采样：让 Agent 从“给一个答案”变成“给一组方案”
  • 从数字设计到实体创造：SketchUp STL插件如何重新定义你的3D打印工作流
  • 纯前端临时邮箱服务构建：基于第三方API的隐私保护方案
  • 艾尔登法环2026最新免费破解版绿色下载
  • Haft：AI编码时代的工程治理框架，让决策可追溯、可验证
  • 基于Python与向量数据库构建个人知识库：从文档处理到语义检索实战
  • WecoAI/aideml：面向垂直领域的MLOps平台实战部署与调优指南
  • 5分钟掌握B站视频转文字：高效内容提取的智能解决方案
  • WELearn网课助手终极指南：如何3分钟告别熬夜赶网课的烦恼
  • Balena Etcher：安全可靠的跨平台镜像烧录工具技术解析
  • Cursor AI 代码生成规则配置指南：提升开发效率与代码一致性
  • ncmdump开源工具：解锁数字音乐资产自由的技术解决方案
  • DevTaskFlow：基于AI智能体的自动化软件开发流水线实践
  • 2026年口碑好的西安铁道技师学院招生宣传方面电话推荐 - myqiye
  • Luxtorpeda：Linux Steam游戏原生引擎自动管理工具详解
  • DLSS Swapper深度指南：如何通过3个维度掌控游戏画质与性能的平衡术
  • PM实践，学习日志：大数据开发学习 实时进度课程表分享
  • [具身智能-607]：树莓派 4B/5 或 RK3568/RK3588 开发板的电机电气接口与通信协议
  • JDspyder京东抢购脚本：3步实现秒杀自动化的完整教程
  • DLSS Swapper完全指南：3步掌握游戏性能优化神器
  • 西安铁道技师学院选购攻略 - myqiye
  • Toggler：轻量级状态切换工具的设计原理与多框架实践
  • Claude子智能体实战：模块化提示工程提升AI编程效率与代码质量
  • GEO系统可以监测哪些指标？2026最新用户口碑看广拓时代GEO
  • 开源情报聚合器：构建自动化OSINT调查系统的核心架构与实践
  • 基于AI与WordPress的自动化博客系统：架构设计与实战指南
  • 2026年科发豆芽机创新能力怎么样？靠谱吗？ - myqiye
  • NestJS微服务架构实战：从模块化设计到AI辅助开发
  • [具身智能-607]：直流电机 / 步进电机 / 伺服电机 与主控开发板（树莓派 4B/5、RK3568/RK3588）控制接口、信号定义、电气协议全详解
  • FastGPT与Dify应用迁移实战：适配器原理、使用与问题排查