Ai-Agent

LangChain 详解 什么是 LangChain LangChain 是一个用于构建基于大语言模型（LLM）应用的开源框架。它提供了一套标准化的组件和工具，简化了 AI Agent、聊天机器人、问答系统等应用的开发过程。 核心理念：通过"链（Chain）“将多个组件连接起来，构建复杂的 LLM 应用。 官方仓库： Python：langchain-ai/langchain JavaScript/TypeScript：langchain-ai/langchainjs 核心组件 1. Models（模型） 支持多种 LLM 提供商： from langchain.llms import OpenAI, Anthropic, HuggingFaceHub from langchain.chat_models import ChatOpenAI, ChatAnthropic # OpenAI llm = OpenAI(temperature=0.7) # Claude chat = ChatAnthropic(model="claude-3-sonnet-20240229") # 本地模型 from langchain.llms import Ollama local_llm = Ollama(model="llama2") 2. Prompts（提示模板） 管理和复用提示词： from langchain.prompts import PromptTemplate, ChatPromptTemplate # 简单模板 prompt = PromptTemplate( input_variables=["product"], template="给{product}写一个广告语" ) # 聊天模板 chat_prompt = ChatPromptTemplate.from_messages([ ("system", "你是一个{role}"), ("human", "{user_input}") ]) # 使用 formatted = prompt.format(product="智能手表") result = llm(formatted) 3. Chains（链） 将多个组件串联： from langchain.chains import LLMChain, SimpleSequentialChain # 单个链 chain = LLMChain(llm=llm, prompt=prompt) result = chain.run(product="智能手表") # 顺序链 chain1 = LLMChain(llm=llm, prompt=prompt1) # 生成产品描述 chain2 = LLMChain(llm=llm, prompt=prompt2) # 生成广告语 overall_chain = SimpleSequentialChain( chains=[chain1, chain2], verbose=True ) result = overall_chain.run("智能手表") 4. Agents（代理） 动态决策和工具调用： ...

VSCode 扩展桥接 Copilot 模型 通过 VSCode 扩展可以将 GitHub Copilot 中的 Claude 模型桥接出来，供外部 AI Agent 调用。这种实现方式主要基于以下技术方案： 实现原理 VSCode Extension API 使用 VSCode 扩展开发框架创建自定义扩展 通过 vscode.languages 和 vscode.commands API 注册命令和服务 利用 Language Server Protocol (LSP) 实现与外部通信 GitHub Copilot API 调用 扩展内部通过 Copilot 的内部 API 访问 Claude 模型 使用 vscode.authentication 获取 GitHub 认证令牌 调用 Copilot Chat API 发送请求并接收响应 MCP (Model Context Protocol) 服务器 在扩展中实现 MCP 服务器，暴露标准化的接口 MCP 定义了统一的消息格式和通信协议 支持通过 stdio、HTTP 或 WebSocket 与外部 Agent 通信 核心实现步骤 创建 VSCode 扩展 // extension.ts import * as vscode from 'vscode'; export function activate(context: vscode.ExtensionContext) { // 启动 MCP 服务器 const mcpServer = new MCPServer(); mcpServer.start(); // 注册命令处理 Copilot 请求 context.subscriptions.push( vscode.commands.registerCommand('extension.queryCopilot', async (prompt) => { return await queryCopilotModel(prompt); }) ); } 实现 MCP 服务器 // mcp-server.ts import { Server } from '@modelcontextprotocol/sdk/server/index.js'; import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'; class MCPServer { private server: Server; constructor() { this.server = new Server({ name: 'copilot-bridge', version: '1.0.0' }, { capabilities: { resources: {}, tools: {}, prompts: {} } }); // 注册工具 this.server.setRequestHandler(ListToolsRequestSchema, async () => ({ tools: [{ name: 'query_claude', description: 'Query Claude model via Copilot', inputSchema: { /* ... */ } }] })); } async start() { const transport = new StdioServerTransport(); await this.server.connect(transport); } } 桥接 Copilot API // copilot-bridge.ts async function queryCopilotModel(prompt: string) { // 获取 Copilot Chat API const copilot = await vscode.lm.selectChatModels({ vendor: 'copilot', family: 'claude' }); // 发送请求 const messages = [ vscode.LanguageModelChatMessage.User(prompt) ]; const response = await copilot[0].sendRequest(messages); // 收集响应流 let result = ''; for await (const chunk of response.text) { result += chunk; } return result; } 外部 Agent 调用 # external_agent.py from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client async def call_copilot_claude(prompt: str): # 连接到 VSCode 扩展的 MCP 服务器 server_params = StdioServerParameters( command="code", args=["--extensionDevelopmentPath=/path/to/extension"] ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: # 初始化连接 await session.initialize() # 调用工具 result = await session.call_tool("query_claude", { "prompt": prompt }) return result 关键技术点 认证与权限 ...

其他意图识别与工具调用方式 除了传统的 Slot Filling 和现代的 Function Calling，AI Agent 还有多种实现意图识别和工具调用的方式，各有特点和适用场景。 1. ReAct（Reasoning + Acting） ReAct 是一种让 LLM 交替进行推理（Reasoning）和行动（Acting）的方法，通过思维链（Chain of Thought）引导 LLM 一步步分析问题并选择工具。 工作原理 用户输入 → LLM 推理(Thought) → 决定行动(Action) → 执行工具 → 观察结果(Observation) → 继续推理 → ... 实现示例 react_prompt_template = """ 你是一个智能助手，可以使用以下工具： 1. search(query): 搜索信息 2. calculate(expression): 计算数学表达式 3. get_weather(city): 查询天气 请按以下格式回答： Thought: [你的思考过程] Action: [工具名称] Action Input: [工具参数] Observation: [工具返回的结果] ... (重复 Thought/Action/Observation 直到得出答案) Answer: [最终答案] 问题：{question} """ # 用户问题："北京明天的天气适合户外活动吗？" # LLM 输出： """ Thought: 我需要先查询北京明天的天气 Action: get_weather Action Input: {"city": "北京", "date": "明天"} Observation: 明天北京天气：晴，温度 22°C，微风 Thought: 根据天气信息，晴天、温度适中、微风，非常适合户外活动 Answer: 根据天气预报，北京明天天气晴朗，温度 22°C，微风，非常适合户外活动。 """ 优势 可解释性强：每一步推理过程都清晰可见 灵活性高：LLM 可以动态调整策略 支持复杂任务：可以进行多步推理和工具调用 劣势 Token 消耗大：每次推理都需要完整的对话历史 速度较慢：需要多次 LLM 调用 格式依赖：依赖 LLM 严格遵循输出格式 2. Prompt-based Tool Selection（基于提示的工具选择） 通过精心设计的 Prompt 让 LLM 直接输出工具调用的 JSON 或结构化文本。 ...

Output Constraint（输出约束） Output Constraint 是通过提示词、格式规范或模型能力，对 LLM 的输出内容、结构、长度、风格等进行约束，使输出结果可预期、可解析、可被下游系统直接消费的一类技术。 在 AI Agent 场景中，输出约束尤为重要——Agent 的输出往往需要被代码解析、传递给下一个工具，或渲染到 UI，任何格式偏差都可能导致流程中断。 约束维度 维度 说明 示例 格式约束 要求输出为特定结构 JSON、XML、Markdown 表格、YAML 内容约束 限定输出范围或值域 只能从给定选项中选择、不得包含某类内容 长度约束 限制输出的字数或条数 “不超过 100 字”、“恰好输出 3 条建议” 风格约束 限定语气、人称、语言 正式/口语、中文/英文、第一人称 Schema 约束 强制输出符合 JSON Schema 字段类型、必填项、枚举值 方式一：提示词约束（Prompt-based） 最简单直接的方式，在 System Prompt 或 User Prompt 中明确描述输出格式： system_prompt = """ 你是一个情感分析助手。 输出要求： - 只输出 JSON，不要有任何额外文字 - 格式如下： { "sentiment": "positive" | "negative" | "neutral", "confidence": 0.0 ~ 1.0, "reason": "简短理由（不超过 20 字）" } """ response = llm.call(system_prompt, user_input="这个产品真的太好用了！") # 输出：{"sentiment": "positive", "confidence": 0.95, "reason": "用户使用了强烈的赞美语气"} 优点：通用，任何模型都支持 缺点：无法 100% 保证格式，模型偶尔会"越界" ...

LlamaIndex 详解 什么是 LlamaIndex LlamaIndex（原名 GPT Index）是一个专注于数据连接和检索的开源框架，主要用于构建 RAG（检索增强生成）应用。与 LangChain 相比，LlamaIndex 更专注于数据索引、检索和查询，是构建知识库和文档问答系统的首选工具。 核心定位：数据框架（Data Framework for LLM Applications） 官方仓库：run-llama/llama_index 设计哲学： LangChain：通用的 LLM 应用框架（Chain、Agent、Memory 等） LlamaIndex：专注于数据摄入、索引和检索 ⚠️ 名称说明：LlamaIndex vs Llama2 重要澄清：LlamaIndex 与 Meta 的 Llama2/Llama3 开源模型没有任何关系，它们是完全独立的项目： 项目 类型 开发者 功能 LlamaIndex 开发框架 LlamaIndex 团队（原 run-llama） 数据索引和检索框架 Llama2/Llama3 大语言模型 Meta（Facebook） 开源 LLM 模型 为什么叫 “Llama”？ LlamaIndex 的命名来自"Large Language Model Applications"的缩写 与 Meta 的 Llama 模型纯属巧合（命名冲突） 实际关系： LlamaIndex 框架可以使用 Llama2/Llama3 作为底层 LLM 但 LlamaIndex 也支持 OpenAI、Claude、Gemini 等任何 LLM 两者是"框架"与"模型"的关系，而非从属关系 示例： ...

AI Agent 的意图识别与工具调用 AI Agent 的一个核心应用场景是自然语言理解 → 意图识别 → 工具调用。这本质上是一个分类问题，即将用户的自然语言输入分类到不同的意图类别，然后路由到相应的工具执行具体任务。 固定 FAQ、按钮选项等不必每次都调大模型：见 Agent Token Routing（本地匹配 → 轻量分类 → 缓存 → LLM）。 工作流程 自然语言理解（NLU） 用户输入：自然语言查询或指令 Agent 使用 LLM 理解语义和上下文 意图识别（Intent Recognition） LLM 的核心作用：理解自然语言并映射到预定义的意图分类 将用户输入分类到预定义的意图类别 例如：查询天气、预订餐厅、发送邮件、查询数据库等 这是一个多分类任务 参数提取（Slot Filling） LLM 的第二个作用：从自然语言中提取关键参数供工具使用 从用户输入中提取关键参数 例如：“明天北京的天气” → 时间=明天, 地点=北京 LLM 能理解各种自然语言表达方式并提取结构化参数 工具调用（Tool Calling） 根据识别的意图，调用对应的预开发工具或函数 传递提取的参数给工具 获取工具执行结果 结果组织与返回 将工具返回的结果组织成自然语言 返回给用户 实现示例 # 意图识别与工具调用示例 class IntentBasedAgent: def __init__(self, llm): self.llm = llm self.tools = { "weather": get_weather_tool, "email": send_email_tool, "database": query_database_tool, "calendar": schedule_meeting_tool } async def process(self, user_input: str): # 1. 意图识别（分类） intent_prompt = f""" 分析用户意图，返回意图类别和参数： 用户输入：{user_input} 可选意图：weather, email, database, calendar 返回 JSON 格式：{{"intent": "...", "params": {{...}}}} """ response = await self.llm.query(intent_prompt) intent_data = json.loads(response) intent = intent_data["intent"] params = intent_data["params"] # 2. 根据意图调用相应工具 if intent in self.tools: tool = self.tools[intent] result = await tool(**params) return result else: return "抱歉，我无法理解您的意图" # 使用示例 agent = IntentBasedAgent(llm) # 用户输入："查询明天北京的天气" # 意图识别结果：intent="weather", params={"date": "明天", "city": "北京"} # 调用工具：get_weather_tool(date="明天", city="北京") 意图识别的实现方式 1. 基于 LLM 的意图识别（推荐） # 使用 Function Calling / Tool Use tools_schema = [ { "name": "get_weather", "description": "查询天气信息", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称"}, "date": {"type": "string", "description": "日期"} } } }, { "name": "send_email", "description": "发送邮件", "parameters": { "type": "object", "properties": { "to": {"type": "string"}, "subject": {"type": "string"}, "body": {"type": "string"} } } } ] # LLM 自动识别意图并返回应调用的工具 response = llm.chat( messages=[{"role": "user", "content": user_input}], tools=tools_schema ) # LLM 返回：tool_call = {"name": "get_weather", "arguments": {"city": "北京", "date": "明天"}} 2. 传统分类模型（轻量级场景） # 使用文本分类模型 from transformers import pipeline classifier = pipeline("text-classification", model="intent-classifier") result = classifier("查询明天北京的天气") # 输出：{"label": "weather", "score": 0.95} 3. 基于规则的意图识别（简单场景） # 关键词匹配 intent_patterns = { "weather": ["天气", "温度", "下雨"], "email": ["发邮件", "发送邮件", "写邮件"], "database": ["查询", "数据", "统计"] } def match_intent(user_input): for intent, keywords in intent_patterns.items(): if any(kw in user_input for kw in keywords): return intent return "unknown" 核心优势 解耦设计 ...

Function Calling（函数调用）详解 Function Calling 是现代大语言模型（如 GPT-4、Claude）提供的一项高级能力，允许 LLM 自动识别用户意图、提取参数，并生成标准化的函数调用请求。它是 AI Agent 实现工具调用的最先进方式。 什么是 Function Calling Function Calling 是 LLM 的一种特殊输出模式：不是直接返回文本，而是返回一个结构化的函数调用指令，包含： 要调用的函数名称 函数所需的参数（JSON 格式） 核心流程： 用户输入 → LLM 分析 → 返回函数调用指令 → 执行函数 → 返回结果 → LLM 生成自然语言响应 Function Calling vs 传统 Slot Filling 传统 Slot Filling 的局限 需要多步处理 步骤1：意图识别（调用一次 LLM） 步骤2：参数提取（再调用一次 LLM 或使用 NER） 步骤3：手动组装函数调用 容易出错 意图识别可能不准确 参数提取可能遗漏或错误 需要额外的数据验证逻辑 开发成本高 需要编写意图识别逻辑 需要编写参数提取和验证代码 需要维护多个处理步骤 Function Calling 的优势 一步到位 用户输入 → LLM → 直接返回完整的函数调用（包含意图和参数） 内置验证 ...

思维链（Chain of Thought，CoT） CoT 是 Chain of Thought（思维链）的缩写。 思维链是一种让大语言模型在给出最终答案之前，先逐步输出中间推理过程的提示技术，是 ReAct、Tree of Thoughts 等众多 Agent 推理框架的基础。 用一句话概括：思维链就是通过提示词告诉模型"先把推理步骤写出来，再给结论"。 一个直观的比喻：就像项目管理里不直接说"把产品做出来"，而是拆成"需求 → 设计 → 开发 → 测试 → 上线"这几个里程碑节点——CoT 提示词做的就是这件事：告诉模型"达到最终答案之前，先经过哪几个中间节点"。模型拿到这些节点后，自己填充每个节点之间的具体内容，而不是直接跳到终点。里程碑节点越清晰合理，模型走偏的概率就越低。 CoT 是提示词概念还是模型推理概念 CoT 同时横跨两个层面，两者不可分离： 提示词层面：在提示词里给出推理结构框架（先分析已知条件、再逐步推理、最后给结论），但不需要也不可能提前写出每一步的具体内容 模型推理层面：模型接收到结构约束后，在逐 token 生成 response 的过程中自己填充每一步的具体内容 关键在于：LLM 是逐 token 生成的，每生成一个 token 都会参考前面所有已输出的内容。写出推理步骤不是推理完成后的附加结果，而是推理本身的载体： 写出"步骤 1：..." → 这段文字进入上下文 ↓ 生成"步骤 2：..."时参考步骤 1 → 推理被约束在正确方向上 ↓ 生成最终结论时参考所有步骤 → 结论更准确 如果不写出步骤，中间推理只存在于模型的隐式状态（注意力权重）里，无法作为显式上下文影响后续生成，更容易偏移。 因此，CoT 的本质是：显式约束 vs 隐式依赖： 不用 CoT：完全依赖模型训练出来的内部权重，简单问题通常没问题 用 CoT：在上下文层面施加显式约束，对复杂、多步骤任务效果提升明显 CoT 的收益与任务复杂度正相关——越复杂的推理任务，CoT 的价值越显著。 ...

AI Agent 开发的本质 开发 AI Agent 的核心是将已验证的知识和流程固化成可执行的规则和指令。 具体来说： 知识固化 - 把专家经验、最佳实践、业务规则编码成 Agent 可以遵循的指令 流程自动化 - 将重复性的决策流程转化为确定性的执行步骤 质量保障 - 通过固化的规则确保每次执行的一致性，避免人为疏忽 迭代优化 - 每次发现新问题或更好的做法，就更新这些"固化的知识"，Agent 的能力随之提升 本质上是把隐性知识显性化，把经验驱动变成规则驱动。 这也意味着 Agent 的质量上限取决于你固化进去的知识质量。垃圾进，垃圾出；好的经验进，稳定的高质量输出。 为什么需要固化知识 LLM 的知识覆盖面极广，解决同一个问题可能有多条路径，但其中只有少部分是最佳实践。具体输出什么内容，很大程度上取决于提示词的质量。 把已验证的解决方案固化到 Agent 里，能让 Agent 在特定领域有更稳定、更优质的表现——相当于给 LLM 划定了一条"黄金路径"，避免它在众多可能性中随机游走。 常用技术栈 编程语言 Python（主流，生态丰富） JavaScript/TypeScript（Web/Node.js Agent） Go、Java（高性能/企业级） 大语言模型与 API OpenAI GPT-4/3.5、Claude、Llama Hugging Face Transformers LangChain、LlamaIndex（Agent 框架） Web 框架与服务 FastAPI、Flask（Python） Express.js（Node.js） Django 数据存储 Redis、MongoDB、PostgreSQL、SQLite 向量数据库：Milvus、Pinecone、Weaviate 消息队列与异步任务 Celery、RabbitMQ、Kafka 容器与部署 Docker、Kubernetes 云服务：AWS、Azure、GCP 前端交互 React、Vue.js WebSocket、RESTful API 其他 Prompt 工程、工具插件系统 OAuth2、JWT（安全认证） 日志与监控：Prometheus、Grafana Python 调用模型方式 AI Agent 用 Python 开发时，可以调用本地模型或云端模型： ...

问题 聊天类 Agent 里，不少问答是相对固定的模式：营业时间、退款入口、帮助说明、菜单选项等。若一律调用大模型，既费 token，又容易把标准话术写飘。 常见做法有两种： 正则或规则匹配用户输入，命中则返回固定回答 在模型前加缓存，对特定提示词返回已有内容 这两层有用，但不够。省 token 的核心不是「再找一种缓存技巧」，而是做分层路由：能确定性处理的绝不进模型。 分层路由 用户输入 → L0 本地确定性匹配（规则 / FAQ / 按钮 / 命令） → L1 轻量意图分类（小模型 / embedding / 关键词） → L2 提示词 / 响应缓存（相同或近似请求） → L3 完整 LLM（复杂推理、开放对话、工具编排） 每一层命中就短路返回；只有前面都 miss 才往下走。 层 手段 适用场景 省什么 L0 本地匹配 正则、精确字符串、按钮 payload、slash 命令、状态机固定选项 话术固定、歧义低、可穷举 零 LLM 成本 L1 轻量分类 小分类模型、embedding 相似度、关键词 + 规则 说法多变但意图有限 用便宜模型代替大模型 L2 缓存 精确 cache key、semantic cache、prompt prefix cache 输入或 system prompt 重复率高 省重复推理 L3 LLM 完整对话 / function calling 开放问答、多步推理、需工具、强个性化 正确性优先 L0：本地匹配 适合： ...

AI Agent AI Agent（人工智能代理）是一个能够感知环境、自主决策并采取行动以完成目标的软件系统。 与普通程序不同，AI Agent 的核心特征是自主性：它不只是被动地响应单次输入，而是能够： 制定多步骤计划 调用外部工具（搜索、代码执行、API 调用等） 根据执行结果动态调整策略 持续循环直到目标完成 AI Agent 的定义 从学术角度，Agent 的经典定义来自 Russell & Norvig（《人工智能：一种现代方法》）： Agent 是任何能够通过传感器感知环境、并通过执行器对环境采取行动的事物。 在 LLM 时代，AI Agent 的定义更具体： AI Agent 是以大语言模型为核心推理引擎，能够自主规划任务、调用工具、与外部系统交互，并通过反馈循环完成复杂目标的自治系统。 Agent 的四个核心要素 要素 说明 感知（Perception） 接收输入：多模态用户指令、工具返回结果、系统状态、历史记忆 规划（Planning） 将目标分解为可执行的子任务序列 行动（Action） 调用工具、执行代码、调用 API、操作文件等 记忆（Memory） 短期记忆（上下文窗口）+ 长期记忆（向量数据库等） 感知的来源 感知不只是用户输入那一句话，Agent 每次推理前收到的完整上下文都属于"感知"： 来源 说明 多模态输入 用户的文本指令（最常见）、图片、音频、视频等 工具返回结果 搜索结果、API 响应、代码执行输出、数据库查询结果 系统状态 文件内容、环境变量、当前任务进度 历史记忆 短期记忆（上下文窗口中的对话历史）+ 长期记忆（从向量数据库检索） 这四类来源最终都会被拼装进 LLM 的上下文窗口，LLM 基于这个完整上下文做出下一步决策。因此，感知本质上是构建 LLM 输入上下文的过程。 上下文窗口：感知的硬性约束 能放入上下文的信息量取决于模型的上下文窗口大小（以 token 计）： ...