斯是陋室

1. 设计目标与整体思路 Qwen-Agent 路由层（Router）的核心目标是： 将多种能力（对话 / 图片 / 代码 / 文档 / 工作流）统一暴露为 单一入口 让 LLM 自动决策使用哪个 Agent 保证多轮对话中的 Agent identity 延续 保持低耦合、可扩展、可插拔 🔷 整体架构图 🔷 核心链路图 2. 核心组件说明 2.1 QwenAgentRouter（路由器） 路径：agents/core/routing/router.py 职责： 继承 FnCallAgent → 让 LLM 决策 继承 MultiAgentHub → 持有子 Agent 队列 强制输出格式 Call: 通过 stop=[’\n’] 限定只读第一行 🔷 QwenAgentRouter 内部逻辑图 2.2 子 Agent 类型 Agent 名称 文件 能力 基础对话助手 agents/chat/basic_chat_agent.py 通用问答、兜底 多模态助手 agents/multimodal/image_agent.py 图像识别、图像生成 规划助手 agents/planning/planning_agent.py 多步骤工作流拆解 代码助手 agents/code/code_agent.py 代码执行、调试、生成 文档助手（可扩展） 自定义 文件阅读、检索、翻译 3. 消息流与路由流程（核心链路） 🔷 路由行为时序图 ...

📘 Qwen-Agent 框架架构解析 对应源码仓库： https://github.com/QwenLM/Qwen-Agent 文档包含架构图、循环图、多 Agent 协作图、Memory RAG 数据流图、工具体系图与异常处理图。 所有流程均严格基于源码实现，无推测成分。 1. 🎯 设计理念（Design Philosophy） Qwen-Agent 的核心目标是： 通过统一抽象、模块化组件与 LLM+工具闭环，实现可扩展且可编排的智能 Agent 体系。 核心理念 统一抽象：所有 Agent 都继承 Agent，通过 _run 处理消息，上层只依赖统一入口。 LLM+工具闭环：FnCallAgent 完成 “LLM 推理 → 工具决策 → 工具执行 → 回写上下文” 的完整循环。 模块化扩展：工具、Memory、子 Agent 可自由组合，可复用性强。 默认流式：全链路支持流式输出，提高交互体验。 文件/RAG 模块独立：Memory 负责文件抽取、解析与检索。 2. 🧩 核心组件结构（Core Components） 2.1 Agent 基类（骨架层） Agent.run() 负责： 标准化消息 自动插入 system prompt 自动语言检测（如中文 → lang=zh） 统一构建 LLM 请求参数 调用子类 _run 2.2 Message Schema（所有信息流的基础） 来自 llm/schema.py，Qwen-Agent 完全兼容 OpenAI 格式。 ...

How to Run Ollama on Linux with AMD MI50 Tested Environment: Ubuntu 22.04 Quick Start Summary # 1. Install ROCm driver (ROCm 5.7.1 for MI50) sudo mkdir -p /etc/apt/keyrings wget https://repo.radeon.com/rocm/rocm.gpg.key -O - | gpg --dearmor | sudo tee /etc/apt/keyrings/rocm.gpg > /dev/null sudo tee /etc/apt/sources.list.d/amdgpu.list <<'EOF' deb [arch=amd64 signed-by=/etc/apt/keyrings/rocm.gpg] https://repo.radeon.com/amdgpu/5.7.1/ubuntu jammy main EOF sudo tee /etc/apt/sources.list.d/rocm.list <<'EOF' deb [arch=amd64 signed-by=/etc/apt/keyrings/rocm.gpg] https://repo.radeon.com/rocm/apt/5.7.1 jammy main EOF echo -e 'Package: *\nPin: release o=repo.radeon.com\nPin-Priority: 600' | sudo tee /etc/apt/preferences.d/rocm-pin-600 sudo apt update sudo apt install amdgpu-dkms rocm-hip-libraries sudo reboot # 2. Install Ollama curl -LO https://ollama.com/download/ollama-linux-amd64.tgz sudo tar -C /usr -xzf ollama-linux-amd64.tgz # 3. Install ROCm package for Ollama curl -L https://ollama.com/download/ollama-linux-amd64-rocm.tgz -o ollama-linux-amd64-rocm.tgz sudo tar -C /usr -xzf ollama-linux-amd64-rocm.tgz # 4. Run Ollama ollama serve Install ROCm Driver If you want to run Ollama on Linux with an AMD MI50 GPU, you need to install the AMD graphics driver first. ...

今年以来，科技圈里最火的莫过于 DeepSeek 的横空出世了，无疑是震惊中外的一个突破 但随着大批用户涌入 DeepSeek，本就节衣缩食的 DeepSeek 更是出现了频繁的「服务器繁忙」，甚至出现了如下图的调侃 👇 那么除了官方的入口之外，还有什么比较好的可以快速使用 DeepSeek 的方式吗？ 当然有！让我们感谢开源！ 虽然 DeepSeek 已经开源了，但普通用户想用上，还是不知道该怎么去做。 于是 Ollama 出现了 👇 只需一行命令即可在你的电脑上使用 DeepSeek，但问题也随即而来 可以看到，ollama 提供的是使用 deepseek-r1 蒸馏过的 qwen2 模型，而非原版的 deepseek-r1，效果上说实话，肯定是不如原版的 deepseek 好用，那么还有没有其他的可以使用到原版 deepseek 的方法呢？ 当然有，那就是我们接下来要说的本文的主角了—— Nvidia NIM 什么是 NIM 官网介绍：NIM 提供用于跨云、数据中心和工作站自行托管 GPU 加速微服务的容器，用于预训练和自定义 AI 模型。这些容器可以使用单个命令进行部署，并自动公开行业标准 API，以快速集成到应用程序、开发框架和工作流程中。其中一个示例是基于大型语言模型（LLM）的 NIM 微服务的 OpenAI API 规范。 一句话总结就是：NIM 是英伟达提供的一套算力平台！！只要你注册了 Nvidia 的开发者账户，你就可以获得英伟达给你提供的 1000 次免费推理服务！ ...

前情提要 2023 年 6 月 6 日凌晨，苹果在 WWDC23 上发布了旗下首款 MR 产品 Apple Vision Pro，售价为 3499 美元。仅三个月后的 2023 年 9 月 28 日，Meta 在其召开的 Meta Connect 大会上发布了 Meta Quest 3 头显，售价 499 美元。二者都不约而同的强调 了自己在 MR（混合现实）方面的能力和表现，都希望自己可以将整个世界带入“空间计算”的时代。但和 Quest3 不同的是，Apple Vision Pro 直到 2024 年 2 月 2 日才正式在北美开售，如今各路评测视频都已经放出，笔者也购入了被大多数人誉为“Vision Pro 最佳平替”的 Meta Quest3，想借着自己实际的使用体验聊一聊“空间计算”这个全新的概念。喜欢的朋友不妨点个赞关注一下哦 😯 我为什么购买 Quest3 我为什么会购买 Quest3，说不是心血来潮肯定是有假，但是说一时兴起也不完全对。之前看过很多 Quest3 的测评，都说相较之前代有很大提升，直到这次 Vision Pro 正式开售，我又才重新关注起来。笔者本身就是一个数码爱好者，生活中也经常会和朋友们聊些这个，这也算是我第一次尝试写个简单的测评文章。 Quest3 实际使用简评 首先结论先行，Quest3 是一个很好的头显，画质很棒，影音效果也很棒，游戏体验不错，有一定的沉浸感，舒适度一般，带久了脖子难受，我最期待的 MR 能力形同虚设（这还是发布会上 Meta 重点宣传的内容）。说实话如果不是因为代购的，不能退货，以及价格确实还是可以接受的，不然肯定是会退货的。 ...

小伙伴们新年好啊，颓废的 2023 年总算是过去了，过去这一年因为自己的状态不太好，一直也没怎么更新，2024 年是时候重新拾起行囊再出发啦！ 前言 去年年底我写过一篇《大模型小助手，Mac 工程师如何拥有自己的人工智能》，在那篇文章里我介绍了如何利用自己手头的计算资源（Mac 电脑）快速拥有一个人工智能助手，然而大多数人手头的算力是很孱弱的，以至于大家千方百计搭桥建梯想要拿到 OpenAI 这艘大船的船票。这无可厚非，但我们知道，在我们这个伟大的国家，科技一定是要讲究自主研发的，不然谈何遥遥领先。因此在去年 8 月，随着《生成式人工智能服务管理暂行办法》的正式实施， 中国自人己的生成式人工智能之路，终于从政策上给出了要求和肯定，让 AIGC 行业发展不再迷茫。 现如今经历了一年多的发展，国产 AI 已经慢慢地走向成熟，其智能体的效果已经具备了产业应用场景落地的基本条件。因此今天我准备从自己的实际需求入手，抛弃 OpenAI，使用我们国内的 AI 平台，展示一下如何使用 LlamaIndex 框架和智谱 AI 结合起来处理常见的应用场景——知识库检索。 大炼钢铁——国产大模型间的军备竞赛 ChatGPT 及其背后的 GPT4 大火之后，国内迅速刮起一阵自主研发大模型的风，先不管开源与否，目前市面上叫得上名号的就不止以下这些（排名不分先后）： 机构/公司 模型名称 百度 文心大模型 抖音 云雀大模型 智谱 GLM 大模型 中国科学院 紫东太初大模型 百川智能 百川大模型 商汤 日日新大模型 MiniMax ABAB 大模型 上海人工智能实验室 书生通用大模型 科大讯飞 星火认知大模型 腾讯 混元大模型 阿里巴巴 通义千问大模型 吕布之后，人人皆有吕布之勇。 国产大模型亦是如此，GPT4 与大国政策双向奔赴后，这些 AI 厂商都想在国内大模型这场军备竞赛中占得一席之地。 这些 AI 厂商一般有三种提供服务的方式： 模型私有部署：直接部署开源或者闭源的模型（需要显卡）； AI 开发平台：很多平台提供了 LLM 服务，可以在线进行模型测试、开发、部署、微调等服务（直接付费即可）； API 调用：这个就和 OpenAI 早期的服务模式一样，提供 API 的调用。 在上一篇文章中，我们选择了清华大学与智谱合作开发且开源的 ChatGLM3 作为私有化部署的模型。鉴于对其开源产品的丰富产品线以及较好的使用体验，这次我们仍然选择智谱 AI 作为本文的大模型底座。 ...

前言 历史的车轮滚滚向前，大模型的发展让 AI 离每个人都更近了一步。今年 3 月的时候简单聊了一下 AIGC，现如今半年多过去了，ChatGPT 依旧大放异彩。无论是百度的文心一言还是阿里的通义千问，在 GPTs 面前都变成了拙劣的模仿。 现如今每隔几天就有新鲜的技术出炉，让人目不暇接，同时具备可玩性和想象空间的各种应用和开源库，仿佛让自己回到了第一次设置 JAVA_HOME 的日子，于是我便蹦出了一个对自己的工作和生活可能有帮助的想法——“拥有自己的人工智能”。 目标是搭建出一个不依赖云端服务，可以在本地运行，且效果可以接受的类 ChatGPT 服务。为什么要在本地搭建而不是直接采用现成的云服务呢？从数据安全的角度看，一些数据还是不太方便随意上传至云端的，而且云端的问题回答也会经过各个服务商审核，不可避免的会出现降智的情况。另一方面，这些在线的云服务成本较高，chatGPT plus 每个月 20 美元，还要熟练掌握各种上网技巧，虽然能力很强大，但是再没有一个完美的变现渠道的情况下，对于我的荷包来说还是有很大负担。最后对于一个工程师来说，能自己搭建一个完整的方案，使用一个自己调教出来的 AI，也是出于对技术探索的本能使然。 方案概述 由于是在本地运行的，选择一个好的设备则是第一步要考虑的事情了。笔者家中刚好有一台 2020 年 M1 芯片的 Mac Mini，一直作为家里的 homelab 长期运行。除了平时在家里用他编译代码、还会用它来设置苹果的内容缓存，提高局域网内苹果服务的连通性。如今廉颇尚未老矣，还是可以再战 AI 的。 由于 M1 芯片的统一内存架构和开源社区对 Apple 芯片在 AI 方面的支持， 如今用它作为一个本地运行大模型的载体再合适不过了。 我的方案如下图所示 👇。 在这套方案中，我采用实力排上游、并且在使用上对学术和商业都友好的国产大模型 ChatGLM3-6B 对话模型，同时使用 chatglm.cpp 对 ChatGLM3-6B 进行量化加速以及 API 协议的兼容；通过 Cloudflare 的 Tunnels 将运行在家中 HomeLab 的 service 映射至公网；使用 ChatGPT Next Web 作为 UI 层并通过 Vercel 托管网页（当然这里也可以选择下载 ChatGPT Next Web 的 desktop App 直接使用）。最后的效果如下图所示。 ...

引言 软件工程领域的设计模式，就像是建筑师手中的设计蓝图，它们是经验的总结，指导开发者如何在面对层出不穷的编程难题时，构建出既稳固又灵活的软件结构。就像一座经过精心设计的大厦能够经受住风雨的考验一样，一个利用了恰当设计模式的软件系统也能在快速变化的技术世界中稳定运行。它们是从无数成功（和失败）的项目中提炼出来的知识精华，为软件开发者提供了一套通用的、可复用的解决方案框架。 这些模式不仅仅是静态的原则或者是一成不变的规则，它们更像是一种语言，让开发者之间能够有共同的理解和沟通基础。在这个基础上，设计模式允许团队成员更高效地协作，对现有问题提出经过验证的解决方案，同时也能够预见和规避潜在的设计陷阱。通过实施这些模式，开发者能够减少冗余，提升系统的模块化，从而使得代码更加清晰、扩展性更强，同时也更容易被后来者理解和维护。 在本文中，我们将探索设计模式的分类，它们在软件开发中的应用，并深入讨论在特定情境下选择和实施这些模式的最佳实践。通过具体的例子和场景分析，我们能够更好地理解设计模式在现代软件工程中的作用，以及如何运用这些模式来构建出既强大又优雅的代码结构。 设计模式的分类及应用 在软件工程的广阔舞台上，设计模式被分为三个主要类别，每个类别都解决一系列特定的问题，它们如同不同类型的工具，针对特定的工作选择合适的工具至关重要。 创建型模式，例如**单例和工厂方法**，主要关注对象的创建机制，以确保对于一个特定类而言，系统中只存在一个实例，或者将对象的创建和使用解耦，以增强系统的灵活性和可扩展性。在实际应用中，当我们需要控制客户如何创建一个对象，或者当我们知道对象的创建过程需要大量配置时，这些模式就显得尤为重要。例如，一个复杂的游戏中的资源管理器可能就会采用单例模式来确保所有的游戏组件都能够访问全局的、唯一的资源实例。 结构型模式，如**适配器和代理模式**，帮助设计系统中各个部件之间的组织方式，确保当系统的一部分发生变化时，不会影响到整个系统的功能。它们通过确保每个部分都能够独立地工作，来提高系统的整体灵活性。比如，在一个视频流服务中，适配器模式可以用来确保新的视频编码格式能够被现有的播放器支持，而不必对播放器进行大规模的重写。 行为型模式，例如**观察者和策略模式**，主要关注对象之间的交互和职责分配。这些模式不仅帮助定义对象间的通信模式，而且也使得系统更易于理解和扩展。观察者模式允许对象在无需知道其他对象具体实现的情况下，依旧能够相互通信，这在构建用户界面组件时尤其有用，其中一个动作可能需要更新多个界面元素。 通过深入分析这些模式，我们能够更好地理解它们在软件开发中的价值，以及如何将这些理论应用到实际开发的项目中。这不仅仅是一个理论上的练习；通过具体的代码示例和场景分析，我们将展示这些模式如何帮助开发团队构建更健壮、更可维护、更高效的软件系统。 设计模式的好处与挑战 设计模式的引入往往能够带来显著的好处。首先，它们提供了一种重用解决方案的方式，这可以节省时间和资源，并减少错误。例如，使用工厂模式可以创建一个集中的创建点，允许开发者轻松调整和维护创建逻辑，而无需遍布代码库的重复代码。同样，装饰器模式允许开发者扩展对象的行为，而无需修改现有类的代码，这是增强功能时尊重开闭原则的典范。 然而，设计模式的使用并非没有挑战。过度使用或不恰当使用设计模式可能会导致系统过于复杂，难以理解和维护。比如，一个简单的问题如果使用了一个复杂的模式来解决，可能会引入不必要的抽象层，从而导致代码的可读性和可维护性降低。因此，软件工程师必须具备判断何时使用设计模式的智慧，并且能够根据项目的具体需求和上下文来选择合适的模式。 此外，设计模式的实施需要团队成员有共同的理解，这意味着必须有一个良好的沟通和文档化过程。团队中的每个成员都需要理解这些模式的目的和实现方式，这样才能确保模式被正确地应用，并且整个团队能够有效地协作。 总结而言，设计模式在软件工程中的应用是一个平衡艺术。它们在提升代码质量、促进团队协作和增强软件的可持续发展方面发挥着关键作用。软件工程师需要不断地学习和实践，以便能够熟练地运用这些模式来解决日常开发中遇到的问题。通过理解设计模式的原理和适用场景，我们可以更加明智地选择何时以及如何使用它们，从而构建出更加健壮和可维护的软件系统。 设计模式的实际案例和代码示例 设计模式不仅在理论上具有吸引力，它们在实际应用中同样展现出巨大价值。例如，考虑一个电子商务平台，其中的购物车功能可以通过“单例模式”实现，以保证每个用户在浏览过程中都有一个且只有一个购物车实例。以下是一个简化的单例模式代码示例，用于创建一个购物车实例： public class ShoppingCart { private static ShoppingCart instance; private ShoppingCart() { // Private constructor to prevent instantiation. } public static ShoppingCart getInstance() { if (instance == null) { instance = new ShoppingCart(); } return instance; } } // Usage public class Main { public static void main(String[] args) { ShoppingCart cart1 = ShoppingCart.getInstance(); ShoppingCart cart2 = ShoppingCart.getInstance(); System.out.println(cart1 == cart2); // Output: true, cart1 and cart2 refer to the same instance. } } 在这个例子中，ShoppingCart 类确保了全局只有一个实例被创建。使用 getInstance() 方法保证了无论多少次调用构造函数，返回的都是同一个对象实例。 ...

“UGC 不存在了”——借鉴自《三体》 ChatGPT 的横空出世将一个全新的概念推上风口——AIGC（ AI Generated Content）。 GC 即创作内容（Generated Content），和传统的 UGC、PGC，OGC 不同的是，AIGC 的创作主体由人变成了人工智能。 xGC PGC：Professionally Generated Content，专业生产内容 UGC：User Generated Content，用户生产内容 OGC：Occupationally Generated Content，品牌生产内容。 AI 可以 Generate 哪些 Content？ 作为淘宝内容线的开发，我们每天都在和内容打交道，那么 AI 到底能生成什么内容？ 围绕着不同形式的内容生产，AIGC 大致分为以下几个领域： 文本生成 基于 NLP 的文本内容生成根据使用场景可分为非交互式文本生成与交互式文本生成。 非交互式文本生成包括摘要/标题生成、文本风格迁移、文章生成、图像生成文本等。 交互式文本生成主要包括聊天机器人、文本交互游戏等。 【代表性产品或模型】：JasperAI、copy.AI、ChatGPT、Bard、AI dungeon 等。 图像生成 图像生成根据使用场可分为图像编辑修改与图像自主生成。 图像编辑修改可应用于图像超分、图像修复、人脸替换、图像去水印、图像背景去除等。 图像自主生成包括端到端的生成，如真实图像生成卡通图像、参照图像生成绘画图像、真实图像生成素描图像、文本生成图像等。 【代表性产品或模型】：EditGAN，Deepfake，DALL-E、MidJourney、Stable Diffusion，文心一格等。 音频生成 音频生成技术较为成熟，在 C 端产品中也较为常见，如语音克隆，将人声 1 替换为人声 2。还可应用于文本生成特定场景语音，如数字人播报、语音客服等。此外，可基于文本描述、图片内容理解生成场景化音频、乐曲等。 【代表性产品或模型】：DeepMusic、WaveNet、Deep Voice、MusicAutoBot 等。 视频生成 视频生成与图像生成在原理上相似，主要分为视频编辑与视频自主生成。 视频编辑可应用于视频超分（视频画质增强）、视频修复（老电影上色、画质修复）、视频画面剪辑（识别画面内容，自动场景剪辑） 。 视频自主生成可应用于图像生成视频（给定参照图像，生成一段运动视频）、文本生成视频（给定一段描述性文字，生成内容相符视频） 。 【代表性产品或模型】：Deepfake，videoGPT，Gliacloud、Make-A-Video、Imagen video 等。 ...

前言 笔者最近在主导一个项目的架构迁移工作，由于迁移项目的历史包袱较重，人员合作较多，在迁移过程中免不了进行多分支、多次 commit 的情况，时间一长，git 的提交记录便混乱不堪，随便截一个图形化的 git 提交历史给大家感受一下。 各种分支疯狂打架宛如后宫争宠的妃子们，之所以会出现这种情况，主要还是因为滥用 git merge 命令并且不考虑后续的理解成本导致的。如今在大厂工作的程序员们，频繁接受变更的需求，一旦一开始考虑不周到，就一定会出现了大量无意义的 commit log，加上“敏捷”理念的推广，产品的快速迭代上线变成了核心指标，这些无意义的 commit log 便被“下次再处理”，久而久之就混乱不堪了。 而我们在看一些开源仓库时，会发现他们的 commit 记录十分整洁，其实这并不是社区的程序员能力更强，而是因为他们没有 KPI 大棒的鞭笞，在提交代码前会花时间整理自己的 commit log。而这就是本文的主角了——“Git Rebase”。 git rebase 和 git merge git rebase，中文翻译为“变基”，通常用于分支合并。既然提到了分支合并，那就一定离不开git merge这个命令。 相信每个新手程序员刚进入职场的时候，都会听到“xxx 你把这个分支 merge 一下”这样的话。那么问题来了，假如你有 6 个程序员一起工作， 你就会有 6 个程序员的分支， 如果你使用 merge, 你的代码历史树就会有六个 branch 跟这个主的 branch 交织在一起。 上图是 git merge 操作的流程示意图，Merge 命令会保留所有 commit 的历史时间。每个人对代码的提交是各式各样的。尽管这些时间对于程序本身并没有任何意义。但是 merge 的命令初衷就是为了保留这些时间不被修改。于是也就形成了以 merge 时间为基准的网状历史结构。每个分支上都会继续保留各自的代码记录，主分支上只保留 merge 的历史记录。子分支随时都有可能被删除。子分子删除以后，你能够看到的记录也就是，merge 某 branch 到某 branch 上了。这个历史记录描述基本上是没有意义的。 而 git rebase 中文翻译为“变基”，变得这个基指的是基准。如何理解这个基准呢？我们看一下下图。 ...