使用 Git 的工作流程

配置

查看全局配置

git config --global --list

filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
user.name=军舰
user.email=wang-junjian@qq.com
http.postbuffer=524288000
http.version=HTTP/1.1

设置全局配置

git config --global user.name "军舰"
git config --global user.email wang-junjian@qq.com

初始化仓库

git init

Initialized empty Git repository in /Users/junjian/GitHub/wang-junjian/HelloGit/.git/

设置远程仓库

git remote add origin https://github.com/wang-junjian/HelloGit.git

基础

查看状态

开发

这是第一次开发 MCP Server，想着使用智能编码工具（GitHub Copilot、Cursor、Trae）进行氛围编程，发现真不容易，Claude 3.7 sonnet 效果不错，在 GitHub Copilot 没用多长时间超限制了；Cursor 没有达到之前那种随心的效果；Trae 要排长队，太有挫败感了。于是，开始了以人编码为主，大模型辅助的开发过程。

MCP Server 的工作流程

1. 初始化：加载环境变量，初始化 RAGFlow 客户端。
2. 工具注册：定义工具列表，描述工具的输入/输出。
3. 工具逻辑：实现工具的具体调用逻辑。
4. 服务器启动：通过 stdio 启动 MCP Server 并监听请求。

创建 RAGFlow MCP Server 项目

uvx create-mcp-server \
    --path ragflow-mcp-server \
    --name ragflow-mcp-server \
    --version 0.1.0 \
    --description "RAGFlow MCP Server" \
    --no-claudeapp
cd ragflow-mcp-server
uv sync --dev --all-extras
uv add ragflow-sdk

下载 MCP 开发文档和 RAGFlow Python API 文档

初始化

uv init RAGFlowAssistant
cd RAGFlowAssistant
uv add ragflow-sdk

运行

sh run.sh

RAGFlowAssistant

配置

知识库问答

核心代码

欢迎使用Visual Studio Code 2025年3月版本。此版本包含许多更新，我们希望您会喜欢，一些主要亮点包括：

• 代理模式
  • 代理模式现已在VS Code稳定版中可用。通过设置setting(chat.agent.enabled:true)启用（更多...）。
  • 通过模型上下文协议(MCP)服务器工具扩展代理模式（更多...）。
  • 尝试代理模式中的新内置工具，用于获取网页内容、查找符号引用和深度思考（更多...）。

• 代码编辑
  • 下一步编辑建议现已正式发布（更多...）。
  • 在编辑器中应用AI编辑时减少诊断事件等干扰（更多...）。

• 聊天
  • 在聊天中使用自己的API密钥访问更多语言模型（预览版）（更多...）。
  • 从统一的聊天体验中轻松切换问答、编辑和代理模式（更多...）。
  • 通过即时远程工作区索引体验提高工作区搜索速度和准确性（更多...）。

• 笔记本编辑
  • 借助编辑和代理模式的支持，像编辑代码文件一样轻松创建和编辑笔记本（更多...）。

如果您想在线阅读这些发布说明，请前往code.visualstudio.com上的更新页面。 Insiders版本： 想尽快尝试新功能吗？您可以下载每晚构建的Insiders版本，并在功能可用后立即尝试最新更新。

聊天

代理模式在 VS Code 稳定版中可用

设置：setting(chat.agent.enabled:true)

用户的问题

构建AI代理的新手指南，帮助您克服挑战。

AI代理正变得越来越复杂，能够自动化工作流程、做出决策并与外部工具集成。然而，在现实世界中部署AI代理面临着很多挑战，这些挑战会影响其可靠性、性能和准确性。现在优先建立AI代理设计的强大基础，将为未来可靠、安全的自主系统奠定基础。

👉 本指南探讨了开发人员在创建AI代理时面临的五个最常见障碍，以及克服这些障碍的实用解决方案。 无论您是刚刚入门的新手还是正在改进方法的资深开发人员，这些最佳实践都将帮助您设计出在复杂环境中更可靠、更具扩展性和更有效的AI代理。

让我们开始构建代理式AI吧！

1. 管理工具集成

随着AI代理变得越来越复杂，管理它们对各种工具的访问和使用变得越来越具有挑战性。每增加一个工具都会引入新的潜在故障点、安全考虑因素和性能影响。确保代理适当地使用工具并优雅地处理工具故障对于可靠运行至关重要。

要解决这一挑战，请为代理工具箱中的每个工具创建精确的定义。包括何时使用该工具的明确示例、有效参数范围和预期输出。构建能够强制执行这些规范的验证逻辑，并从一小组定义明确的工具开始，而不是许多定义松散的工具。定期监控将帮助您识别哪些工具最有效，以及哪些定义需要完善。

2. 管理模型推理和决策

构建AI代理的一个基本挑战是确保一致可靠的决策。与遵循明确规则的传统软件系统不同，AI代理必须解释用户意图，对复杂问题进行推理，并最终基于概率分布做出决策。

参考资料

• 李宏毅生成式 AI 时代下的机器学习（2025）助教课：利用多张 GPU 训练大型语言模型——从零开始介绍 DeepSpeed、Liger Kernel、Flash Attention 及 Quantization
• 【生成式AI時代下的機器學習(2025)】助教課：利用多張GPU訓練大型語言模型—從零開始介紹DeepSpeed、Liger Kernel、Flash Attention及Quantization
• Excalidraw
• The Ultra-Scale Playbook: Training LLMs on GPU Clusters

git -C <目录> pull

这个命令用于从远程仓库获取最新代码并合并到当前分支。-C 选项允许你在指定的目录中运行 git 命令，而不需要先切换到那个目录。

下面是 MCP 相关的仓库

create-python-server
create-typescript-server
docs
inspector
python-sdk
quickstart-resources
servers
specification
typescript-sdk

更新所有仓库

方法一：手动更新

Continue 智能体

• 必须使用 Agent 模式才支持 MCP Server。
• Agent 模式不支持 DeepSeek 系列的模型（包括官方API和开源）。
• 大模型使用本地 Ollama 的模型：qwen2.5-coder:32b 和 qwq:latest。

申请 GitHub 个人访问令牌（Personal Access Token）

• 访问 GitHub 的 Settings 页面，点击 Developer settings。
• 点击 Personal access tokens，然后点击 Tokens (classic)。
• 点击 Generate new token 按钮。

Continue 配置

config.yaml 文件配置如下：

name: Local Assistant
version: 1.0.0
schema: v1
models:
  - name: Autodetect
    provider: ollama
    model: AUTODETECT
  - name: DeepSeek Chat
    provider: deepseek
    model: deepseek-chat
    apiKey: sk-xxx
  - name: DeepSeek Coder
    provider: deepseek
    model: deepseek-coder
    apiKey: sk-xxx
// ...

安装 Node.js 环境

brew install node

调试 GitHub MCP Server

export GITHUB_PERSONAL_ACCESS_TOKEN=github_pat_XXX
npx @modelcontextprotocol/inspector npx -y @modelcontextprotocol/server-github

用户界面

运行浏览器，访问 URL：http://127.0.0.1:6274/

参考资料

• GitHub MCP Server
• MCP Inspector

GitHub MCP 服务器

GitHub API 的 MCP 服务器，支持文件操作、仓库管理、搜索功能等。

功能特点

• 自动分支创建：创建/更新文件或推送更改时，如果分支不存在则自动创建
• 全面的错误处理：对常见问题提供清晰的错误信息
• Git 历史保留：操作保持适当的 Git 历史记录，不强制推送
• 批量操作：支持单文件和多文件操作
• 高级搜索：支持搜索代码、议题/PR 和用户

工具

1. create_or_update_file
   • 在仓库中创建或更新单个文件
   • 输入：
     • owner (字符串)：仓库所有者（用户名或组织）
     • repo (字符串)：仓库名称
     • path (字符串)：创建/更新文件的路径
     • content (字符串)：文件内容
     • message (字符串)：提交消息
     • branch (字符串)：要在其中创建/更新文件的分支
     • sha (可选字符串)：被替换文件的 SHA（用于更新）
   • 返回：文件内容和提交详情

2. push_files
   • 在单个提交中推送多个文件
   • 输入：
     • owner (字符串)：仓库所有者
     • repo (字符串)：仓库名称
     • branch (字符串)：要推送到的分支
     • files (数组)：要推送的文件，每个包含 path 和 content
     • message (字符串)：提交消息
   • 返回：更新的分支引用

search_repositories 搜索 GitHub 仓库 输入： query (字符串)：搜索查询

⚠️ Trae 试用感受

• 热门模型（Claude-3.7-sonnet）需要排队
• 在当前会话中，我引用过一个文件，接着提问还需要添加引用，太麻烦了。
• 都知道它是中国字节开发的，有一种亲切感，确让我翻墙来用她。

功能界面

操作

提示词

使用 Streamlit UI 库开发一个连接 RAGFlow 的客户端应用，左边列出可选的知识库，右边是聊天对话框。

• Example Clients

本页概述了支持模型上下文协议(Model Context Protocol, MCP)的应用程序。每个客户端可能支持不同的MCP功能，从而实现与MCP服务器的不同级别的集成。

功能支持矩阵

• Example Servers

本页展示了各种模型上下文协议(MCP)服务器，这些服务器展示了该协议的功能和多样性。这些服务器使大型语言模型(LLM)能够安全地访问工具和数据源。

参考实现

这些官方参考服务器展示了核心 MCP 功能和 SDK 用法：

数据和文件系统

• 文件系统 - 具有可配置访问控制的安全文件操作
• PostgreSQL - 具有架构检查功能的只读数据库访问
• SQLite - 数据库交互和商业智能功能
• Google Drive - Google Drive 的文件访问和搜索功能

开发工具

• Git - 读取、搜索和操作 Git 仓库的工具
• GitHub - 仓库管理、文件操作和 GitHub API 集成
• GitLab - GitLab API 集成，支持项目管理
• Sentry - 从 Sentry.io 检索和分析问题

Web 和浏览器自动化

• Brave 搜索 - 使用 Brave 的搜索 API 进行网络和本地搜索
• Fetch - 为 LLM 使用优化的网络内容获取和转换
• Puppeteer - 浏览器自动化和网页抓取功能

生产力和通信

• Slack - 频道管理和消息功能
• Google Maps - 位置服务、方向和地点详情
• Memory - 基于知识图谱的持久记忆系统

AI 和专业工具 EverArt - 使用各种模型的 AI 图像生成 Sequential Thinking -

• Exploring Generative AI

大型语言模型(LLM)的工作原理根植于模式匹配和对下一个词元的统计预测("随机鹦鹉")。从这种方法中产生的一个有些出人意料的能力是它们也能在一定程度上"推理"解决问题。有些模型的推理能力比其他模型更强，OpenAI的"o1"和"o3"模型是两个突出的推理模型，而DeepSeek的"R1"最近引起了很大轰动。但是当我们在编码任务中使用AI时，这种能力发挥什么作用呢？

剧透提醒：我还没有答案！但我有问题和想法。

我将从两个方面开始讨论，这两个方面在我的理解中是推理能力的限制，而且这些限制在编码环境中是相关的。然后我将分享我的想法，即推理在哪些编码任务中可能有用，在哪些任务中可能没用。

上下文至关重要，尤其是对推理而言

苹果公司去年发表的一篇关于大型语言模型推理局限性的论文引起了广泛关注。作者引入了一个新的基准测试，用来测试LLM在"数学推理"方面的能力。他们的基准测试基于一个已有的包含小学数学问题的测试集。他们选取了100个问题，将其转化为带有变量占位符的模板，然后为每个模板创建了50个变体，形成了一个包含5,000个问题的数据集。在第二步中，他们还创建了一个新的数据集，在问题中添加了无关信息。

他们发现：

• Exploring Generative AI

生成式人工智能和特别是大型语言模型（LLM）已迅速进入公众意识。像许多软件开发人员一样，我对其可能性感到好奇，但不确定它最终对我们的职业意味着什么。我现在在Thoughtworks担任一个角色，协调我们关于这项技术将如何影响软件交付实践的工作。我将在这里发布各种备忘录，描述我和同事们正在学习和思考的内容。

随着智能代理编码助手变得越来越强大，反应各不相同。有些人从最近的进步推断并声称，"一年后，我们将不再需要开发人员。"其他人则对AI生成代码的质量以及为初级开发人员准备应对这一变化的挑战表示担忧。

在过去几个月中，我定期使用Cursor、Windsurf和Cline中的智能代理模式，几乎完全用于更改现有代码库（而不是从头创建井字游戏）。总体而言，我对IDE集成的最新进展以及这些集成如何极大地提升工具辅助我的方式印象深刻。它们

• 执行测试和其他开发任务，并尝试立即修复出现的错误
• 自动识别并尝试修复代码检查和编译错误
• 能够进行网络研究
• 有些甚至集成了浏览器预览功能，可以捕获控制台错误或检查DOM元素

所有这些都带来了与AI令人印象深刻的协作会话，有时帮助我在创纪录的时间内构建功能和解决问题。

然而。

即使在那些成功的会话中，我也一直在干预、纠正和引导。而且我经常决定不提交更改。

什么是生成式AI？

生成式AI是指能够根据提示或指令创建新内容的AI系统。这些系统被训练于大量数据，学习识别模式并生成类似于训练数据的新输出。现代生成式AI多为基于神经网络架构的深度学习系统。

目前主导生成式AI讨论的是大型语言模型（LLMs）。这些是经过大量文本训练的模型，可以生成连贯的文本，预测给定上下文中最可能的下一个词。尽管基础架构可能很复杂，但我们可以将其视为一个复杂的自动补全系统。

LLMs展现出的能力远超过以前的生成系统，它们能够：

• 以难以与人类创作区分的方式撰写文章、小说、诗歌或代码
• 回答问题、提供建议、编写报告、总结文档
• 理解上下文并保持对话连贯性
• 同时处理多种语言
• 理解代码并生成新代码

关键应用领域

生成式AI已经在许多领域展示出其应用潜力：

代码生成和编程辅助

开发人员正在使用生成式AI工具（如GitHub Copilot、Amazon CodeWhisperer和Google Duet AI）来加速编码过程。这些工具可以：

• 生成样板代码
• 提出完整函数和算法
• 帮助编写测试
• 解释现有代码
• 重构代码以提高质量
• 生成文档

内容创建和营销

生成式AI可以产生各种形式的内容：

• 博客文章、社交媒体更新和营销文案
• 个性化电子邮件和通信
• 产品描述和目录
• 视频脚本和广告文案

客户服务和支持

生成式AI正在改变企业与客户的互动方式： 聊天机器人和虚拟助手 智能响应建议 自动票务分类和路由 知识库生成和

服务器通过MCP提供了为语言模型添加上下文的基本构建块。这些原语支持客户端、服务器和语言模型之间的丰富交互：

• 提示（Prompts）：预定义的模板或指令，用于指导语言模型交互
• 资源（Resources）：为模型提供额外上下文的结构化数据或内容
• 工具（Tools）：可执行函数，允许模型执行操作或检索信息

每个原语可以在以下控制层次结构中概括：

原语	控制方	描述	示例
提示	用户控制	由用户选择调用的交互式模板	斜杠命令、菜单选项
资源	应用程序控制	由客户端附加和管理的上下文数据	文件内容、Git历史
工具	模型控制	向LLM公开以执行操作的函数	API POST请求、文件写入

提示词

模型上下文协议（MCP）提供了一种标准化方式，使服务器能够向客户端公开提示词模板。提示词允许服务器提供结构化消息和与语言模型交互的指令。客户端可以发现可用的提示词，获取其内容，并提供参数来自定义它们。

用户交互模型

提示词设计为用户控制的，这意味着它们从服务器暴露给客户端，目的是让用户能够明确选择使用它们。

通常，提示词会通过用户界面中的用户发起命令触发，这允许用户自然地发现和调用可用的提示词。

例如，作为斜杠命令：

然而，实现者可以自由地通过任何适合其需求的界面模式来公开提示词——协议本身不强制要求任何特定的用户交互模型。

能力

支持提示词的服务器必须在初始化期间声明prompts能力：

模型上下文协议（Model Context Protocol）由几个协同工作的关键组件组成：

• 基础协议：核心 JSON-RPC 消息类型
• 生命周期管理：连接初始化、能力协商和会话控制
• 服务器功能：服务器提供的资源、提示和工具
• 客户端功能：客户端提供的采样和根目录列表
• 实用工具：跨领域关注点，如日志记录和参数补全

所有实现必须支持基础协议和生命周期管理组件。其他组件可以根据应用程序的特定需求来实现。

这些协议层在实现客户端和服务器之间丰富交互的同时，建立了明确的关注点分离。模块化设计允许实现精确支持所需的功能。

消息

MCP 客户端和服务器之间的所有消息必须遵循 JSON-RPC 2.0 规范。协议定义了以下类型的消息：

请求（Requests）

请求从客户端发送到服务器，或者从服务器发送到客户端，用于启动操作。

{
  jsonrpc: "2.0";
  id: string | number;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

• 请求必须包含字符串或整数 ID。
• 与基本 JSON-RPC 不同，ID 不得为 null。
• 请求 ID 不得在同一会话中被请求者先前使用过。

响应（Responses）

响应是对请求的回复，包含操作的结果或错误。