文章时间线

最近我花了不少时间和 AI 一起做视频。 一开始做的是「VibeCoding 技术栈」，介绍一些能直接用在项目里的东西。后来又做了 AI 产品讲解、应用宣传片，再到这两天尝试的手书 PV。一路做下来，我提得最多的要求大概是：这里太慢了、这句话说人话、画面和声音对不上，还有，回去看看之前那一期。 听起来像在反复挑毛病，但这些问题真的会决定一个视频能不能看下去。 先把一个东西讲明白 做技术栈视频时，我最在意的是，观众看完能知道它可以拿来做什么。 比如 Fuse.js，重点应该是搜索。演示可以放在一个资源库里，但如果花太多时间介绍资源库，观众就会忘记这期到底在讲什么。Ant Design 也是一样，

V17 这轮迭代，最让我印象深的事情不是某个参数终于调对了，而是我把一个公开策略拆开看了好几层，才发现它里面实际运行的核心比表面看起来旧。 刚开始看 Kaggle 上的分数时，心情也挺复杂。V17 在一个中午的存档里只有 2254.7，V16 是 2564.3；到了当天晚上，V17 的一张快照变成了 2561.8，V16 则是 2528.3。数字变化很快，看起来像是策略突然变强了，但这种在线评分会随着对手和对局变化，不能单凭这几张快照证明代码改动带来了多少提升。 所以我后来把注意力拉回到本地实验：V17 到底换了什么，结果又是在什么条件下测出来的。 V17 是什么 Kaggriculture

我一开始参加Kaggriculture，并不是因为我有多喜欢模拟经营。 我当时的想法其实挺俗的：找一个Agent方向的Kaggle比赛，最好不需要手工标数据，不需要训练特别大的模型，代码可以主要交给AI完成，然后看看能不能比较快地混到一块奖牌。 Kaggriculture看起来正好符合。 它是一场双人种田比赛。两个Agent在同一张地图上种地、养动物、雇工人、建牧场、买东西、卖东西，最后谁的钱多谁赢。 听起来有点像《星露谷物语》，实际写起来更像一个不会给你报错、只会默默把钱亏光的小型量化系统。 每局有720个状态，Agent每回合都要返回动作。市场还是双方共享的：你卖得早，可能吃到高价；你卖得

最近其实一直挺忙，但真让我说自己在忙什么，一时又有点说不清。 秋招、招聘和面试 前段时间主要还是在找实习、准备面试，然后顺手学了很多 Agent 相关的东西。之前我对 Agent 的理解其实很简单，差不多就是大模型会调用工具，然后拿到工具结果继续回答。真正开始面试之后才发现，很多东西我只是“用过”，并没有真的想明白。 比如面试官问我怎么设计一个简单的 Agent，Prompt 怎么组装，工具执行完之后结果怎么重新传给模型。如果再继续往下问，状态放在哪里、什么时候停止循环、任务失败之后怎么办，我其实没有办法很完整地回答。 这也是我最近最大的一个感受：现在靠 AI 写代码，把一个东西做出来并没有以

Self-Reflection 一般翻译成： 自我反思。 听起来有点抽象。 其实放在 Agent 里，它的意思很简单： Agent 做完一件事之后，再检查一下自己刚才做得对不对。 如果发现问题，就修改。 这就是 Self-Reflection。 为什么需要 Self-Reflection 大模型经常会犯一种错误： 它会很自信地给出一个错误结果。 比如让 Agent 写一段代码。 它写完以后直接回答： 已完成。 但实际上代码可能根本跑不起来。 如果加入 Self-Reflection，流程就不一样了。 这样最终结果通常会更可靠。 Self-Reflection 是怎么工作的 最简单的 Self-

Map-Reduce 原本是一个很经典的数据处理思想。 在 Agent 和大模型应用里，它也经常被拿来处理一种问题： 内容太多，一个模型一次处理不完。 如果只用一句话解释： 先把大任务拆成很多小任务分别处理，再把结果合并起来。 这就是 Map-Reduce。 为什么需要 Map-Reduce 假设你现在有 100 篇新闻。 你想让大模型回答： 总结这 100 篇新闻里最重要的 AI 行业趋势。 最直接的方法是： 把 100 篇新闻全部扔进模型。 但这很容易遇到问题。 首先是 Context 可能放不下。 即使放得下，内容太多以后，模型也可能漏掉一些信息。 所以可以把 100 篇文章拆开处理。

Plan-and-Execute 是 Agent 里一种很常见的任务执行方式。 它的名字已经把核心说得很清楚了： 先规划，再执行。 如果只用一句话解释： 先把一个复杂任务拆成几步，再按照计划一步一步完成。 它和 ReAct 最大的区别就在这里。 ReAct 更像是边走边看。 Plan-and-Execute 更像是先想清楚路线，再开始走。 为什么需要 Plan-and-Execute 如果任务很简单，其实不需要专门规划。 比如： 帮我查一下今天北京的天气。 直接调用天气工具就可以。 但如果任务变成： 帮我分析三家 AI Agent 公司，比较它们的产品、价格和技术特点，最后给我一份报告。 这个

ReAct 是 Agent 里一个很经典的思路。 它的名字来自两个单词： Reasoning + Acting 也就是“思考”和“行动”。 如果只用一句话解释 ReAct： 让大模型一边做事，一边根据结果决定下一步做什么。 这和普通的大模型问答其实有很大的区别。 普通大模型是怎么工作的 平时我们问 ChatGPT 一个问题，大概是这样的： 模型只需要回答问题就行。 但 Agent 经常要处理一些模型自己并不知道答案的事情。 比如： 帮我查一下今天北京的天气，再告诉我该穿什么。 模型本身不知道今天的实时天气，所以它得先调用天气工具。 这已经有一点 Agent 的感觉了。 但 ReAct 真正重要

当我们向大语言模型发送一句话时，看起来只是： 输入问题 → 模型回答 但在模型内部，这个过程其实可以明显分成两个阶段： Prefill 和 Decode 这两个阶段的工作方式、计算特征、性能瓶颈都不一样。 如果继续往 LLM 推理、vLLM、推理加速、GPU 部署这些方向学习，Prefill 和 Decode 基本是绕不开的两个概念。 简单来说： Prefill 负责读懂输入。 Decode 负责一个 Token 一个 Token 地生成输出。 但真正理解它们以后，会发现很多常见问题都能顺着这两个概念解释清楚。 比如： 为什么 Prompt 越长，第一个 Token 出现得越慢？ 为什么模型开

这次一面整体问得比较偏 Agent 底层实现，不是那种一直问 LangChain、LangGraph 框架怎么用。 主要问了这些内容：怎么设计一个简单的 Agent、Agent 每一轮 Prompt 是怎么组装的、Tool Calling 里的参数是怎么定义的、MCP 和 Tool 有什么区别、RAG 的基本链路，以及 Agent Skills。另外也问了我平时怎么使用 Codex、Claude Code 这些 AI Coding 工具。 其中让我印象最深的是 Agent Prompt 怎么组装。这个问题当时确实把我问住了一些。我之前更熟的是 Runner、Workflow、Tool Call

如果你用过本地大模型，或者接触过 vLLM、TensorRT-LLM、llama.cpp 这类推理框架，基本都会看到一个词： KV Cache。 很多人第一次看到它，会把它理解成一种普通缓存： 把模型算过的结果存起来，下次直接用。 这个理解方向没错，但还不够准确。 KV Cache 缓存的并不是“模型回答”，也不是完整的中间结果，而是 Transformer Attention 中已经计算过的： Key 和 Value。 它之所以重要，是因为自回归语言模型每生成一个新 Token，都需要重新运行一轮 Transformer。 如果没有 KV Cache，大模型会不断重复计算过去已经算过的内容。

如果继续往 GPT、Claude、Qwen、Llama 这些大语言模型的底层追，会反复碰到一个名字：Transformer。 Transformer 来自 Google 团队在 2017 年发表的论文《Attention Is All You Need》。它最初其实不是为了制造今天这种聊天机器人，而是为机器翻译设计的。但后来人们发现，这套架构非常适合扩大模型规模，于是 BERT、GPT 等模型相继出现，Transformer 也逐渐成为现代大语言模型最重要的基础架构之一。 Transformer 最值得理解的地方，不是它有多少层、多少参数，而是它解决了一个非常基础的问题： 一句话里的不同 To

做普通聊天机器人时，我们很容易产生一种错觉： 用户发一句话，系统把这句话交给大模型，然后大模型返回答案。 但到了 Agent 里，真正发送给模型的内容通常远远不止用户刚刚输入的那句话。 一个 Agent 在每一轮调用 LLM 之前，都要重新回答一个问题： 这一轮，模型到底需要看到什么？ 用户目标、系统规则、可用工具、前几轮工具执行结果、当前任务状态、RAG 检索出来的资料、Memory，甚至 Skill，都可能需要进入模型的上下文。 把这些东西挑出来、裁剪、排序，再组装成最终请求的过程，就是 Agent 里非常重要的一层： Context Assembly / Context Engineer

Tool Calling 解决了一个很直接的问题：模型可以决定“我要调用哪个工具”。 MCP 又把这个能力向前推了一步，它解决的是“Agent 怎么用统一方式连接外部工具和上下文”。 但当 Agent 真正进入复杂工作流之后，还会遇到另一个问题： 即使工具都接好了，Agent 也不一定知道“这件事应该怎么做”。 比如让一个 Agent 处理 PDF，不只是“会调用 PDF 工具”就够了。它还要知道什么时候应该提取文本，什么时候应该检查表格，什么时候应该保留版式，什么时候应该输出新的文件，以及完成之后要检查哪些内容。 这些“怎么做”的知识，就是 Skills 想解决的问题。 Skill 到底是什

大语言模型有一个很容易被忽略的问题： 它本身并没有真正意义上的长期记忆。 你和模型聊了很多轮，看起来它好像“记得”前面发生过什么，但很多时候，这并不是因为模型真的把这些事情存进了脑子里。 更准确地说，它只是因为： 前面的对话还在当前上下文里。 比如： 模型能回答“小明”，是因为前面的聊天记录还被一起发送给模型。 如果把前面的上下文删掉，只给它： 它通常就不知道了。 所以如果我们希望 Agent 可以跨任务、跨会话，甚至几天、几个月后还记得重要信息，就需要引入一个独立的系统： Memory。 什么是 Memory 在 Agent 中，Memory 可以理解成： 将过去的信息保存下来，并在未来需要

大语言模型很强，但它有一个非常明显的问题：它知道的东西，本质上受训练数据限制。 如果你问模型一个公开的、常见的问题，比如 TCP 为什么需要三次握手，它通常可以直接回答。 但如果你问： 我们公司最新的产品文档里，退款规则是什么？ 这份 300 页的 PDF 中，第 72 页提到了什么？ 今天刚刚更新的技术文档有什么变化？ 根据我自己的知识库，给客户回答售后问题 单纯依靠大模型本身就不够了。 这时候就需要 RAG。 什么是 RAG RAG 的全称是： Retrieval-Augmented Generation 中文一般叫： 检索增强生成。 它的核心思想非常简单： 不要求大模型记住所有知识，而是

当 AI Agent 从“回答问题”开始走向“真正执行任务”，一个很快就会遇到的问题是： 你敢不敢真的让它运行代码、修改文件、打开网页，甚至执行系统命令？ 如果没有任何限制，让模型直接操作宿主机，本质上相当于把一个能够自动生成命令、自动调用工具，并且可能连续执行几十步操作的程序直接接到了你的电脑上。 这显然不现实。 于是，Agent 系统里通常会引入一个非常重要的组件： Sandbox，也就是沙箱。 它为 Agent 提供一个受限制、可销毁、可控制的执行环境。 --- 为什么 Agent 需要沙箱 传统的大语言模型本身并没有真正的“执行能力”。 你问： 普通模型只能生成： 它并不会真的执行。

我们研究的不是“AI Agent 会不会犯错”这样宽泛的问题，而是一个更具体、更危险的瞬间： Agent 刚刚执行了一个动作，工具返回成功，但受保护目标可能已经失效。仅凭这条成功回执，Agent 是否会继续批准一个不可逆操作？ 这就是 Do ≠ See 的核心命题： 执行成功，不等于目标仍然成立；看见成功，也不等于获得授权。 从一个直觉开始 在工具型 Agent 中，常见的工作流是： Agent 调用工具执行动作； 工具返回成功； Agent 根据成功回执判断任务已经完成； Agent 继续执行提交、发布、删除或其他不可逆操作。 这种流程在正常情况下非常自然。但问题在于，工具返回的成功通常只说

写这篇博客的原因是：现在各家的 Token Plan 老是在变化，我老是得给我的 OpenClaw 和其他 Agent 切换提供商。所以我想找一个一劳永逸的 API 来支持我的 OpenClaw。所以我就看到了 OpenRouter。 你可以把它理解成一个统一的大模型 API 网关 + 路由器。正常情况下，OpenAI、Claude、Gemini、DeepSeek、Qwen 等模型都有自己的 API、Key 和计费方式。 使用 OpenRouter 后，只需要一套 API： 再通过修改模型名称切换模型： 因此你的应用不需要针对每家模型重新开发一套接口。OpenRouter 目前接入了数百个模型

在 DeepSeek Harness 刚出的那几天，我就火速做了一个猫娘插件，准确说是「猫娘风味插件」 你看到的"喵"，实际上模型一个字都没生成，猫娘是本地代码补上的。 为什么这么做？ 一般的做法是，把一大段人设塞进每次请求，让模型每次回复前把这段读完。 这种方式可以达到让模型变成猫娘的效果，但上下文会变得越来越重。 所以，我换了个思路：模型只留一条短约束，猫娘交给本地渲染——「模型负责干活，界面负责卖萌」 实际上，日志里存的是依旧原文，没有任何关于猫娘的内容。只是界面上再把猫娘补回来。这样下来，模型的上下文并没有被改变，而你看到的还是猫娘。 实测数据 这是我用真实 DeepSeek API

用 AI 做视频时，最容易失控的地方往往不在剪辑本身，而在项目一开始就混用了渲染框架、画幅、内容类型和素材标准。 一条稳定的视频生产流程，应当先完成路由，再进入制作： 这正是 video-production 技能解决的问题。 一、先确定生产框架 所有新项目和重大修改，统一使用 HyperFrames。 HyperFrames 的 HTML composition 和 source builder 是生产源文件，负责： 画面布局 素材时序 字幕 动效 音频 生成的 index.html 只是产物，不能作为主要编辑对象。修改应当回到源 builder，再重新生成。 Remotion 只保留为历史

我最初做的，只是一个输入句子、输出荒诞结果的小工具。后来它逐渐变成了一件更完整的产品：有自己的生成规则、历史记录、排行榜、成就系统，也有一套针对生成质量和安全性的完整防线。 这次改造的核心，是让它真正适合运行在 Bilibili Toy 里。 从网页应用到 Toy 项目早期依赖 Cloudflare 页面和 Worker，模型调用集中在项目方服务端。这样开发方便，但模型额度和运行成本都会持续消耗项目方资源。 后来我们把页面独立封装成 Toy 静态包，保留了原有的视觉风格和 README 中的 Logo、Hero 设计，同时把生成规则、质量判断、安全逻辑拆分成共享模块。 Toy 目前包含： 主页

从 2023 年的 GPT-3.5-Turbo 中转站，到今天的 GPT Plus + OpenCode Go 双轨方案——一个大学生三年来用过的所有大模型 API 与订阅计划流水账。

今天是大扫除的日子。博客迁走之后，树莓派上下线了一批服务：旧的博客前后端、一个不再维护的项目、以及整套 frp 穿透。删东西比装东西更需要章法——记录一下我的下线 checklist。 下线前：确认与备份 确认没有隐性依赖。ss -ltnp 看端口，翻 nginx 配置和隧道路由，确认没有别的服务在引用它。我就发现过一个共享隧道，差点把还活着的服务一起带走。 代码推远端。工作目录里往往有未提交的改动，先 git status 检查，把最终状态推一个 pi-final-state 分支再删本地。删除是不可逆的，多推一个分支是免费的。 数据库要么导出要么明确放弃。这一步一定要显式决策，不要"先删了

把跑在树莓派上的博客整体迁移到 Cloudflare Workers：单 Worker 架构、Express 到 Hono、bcrypt 到 PBKDF2，以及一路踩过的坑。

insertId、ON DUPLICATE KEY、时区、反斜杠转义……一次数据库迁移中遇到的所有方言差异，一篇说完。

家里的树莓派要对外提供服务，内网穿透是绕不开的。这两年我先后用过 frp（以及 ChmlFrp 这类免费面板）和 Cloudflare Tunnel，最近做了一次彻底的梳理，把 frp 全面退役了。聊聊两者的取舍。 frp：灵活，但运维成本在自己身上 frp 的模型是自己（或第三方面板）提供一台有公网 IP 的服务器做中转： 优点： 协议自由，TCP/UDP 什么都能转发，打游戏开服也行 延迟取决于中转服务器位置，选得好可以很低 痛点： 免费面板的节点说没就没，配置漂移、隧道失效是常态 需要自己写 watchdog 脚本盯着进程，掉了自动拉起 HTTPS 证书、域名解析都要自己操心 我实际的使

树莓派上跑的服务越来越多，博客前后端、爬虫、搜索、隧道……不做点管理迟早乱成一锅粥。记录一下我现在的方案。 进程管理：pm2 所有 Node 服务统一用 pm2 托管，连 Python 服务也可以： 几个日常高频命令： pm2 save 一定要记得执行，不然重启树莓派之后进程列表是空的——别问我怎么知道的。 反向代理：nginx 每个服务一个 site 文件，放在 /etc/nginx/sites-available/，软链到 sites-enabled/。好处是下线某个服务时直接删软链，不影响其他站点。 对外暴露：cloudflared tunnel 以前用过 frp，现在主力是 Cloud

Roll Back 解决 99% 的问题。能跑就绝对别动它，除非新功能吊炸天。

从五月份的时候，我就准备开始一个新的课题——边缘开放语义感知系统。 由于我一直以来都是做的 YOLO 相关的工作，所以第一时间我就开源了YOLO-CLIPOpenVocDetection。 具体工作原理是： Image → YOLO26m (candidate boxes) → CLIP ViT-L/14@336px (zero-shot classification) 不过由于 YOLO 和 CLIP 模型是解耦的，在 VOC 数据集上只能达到 0.665 mAP@0.5（YOLO26m + ViT-L/14@336px)。比 YOLO26m fine-tuned (100 epochs)的

对博客 Nginx 配置进行全方面调优：Gzip压缩、缓存策略、HTTP/2、连接复用等，TTFB 从300ms降到30ms。

在树莓派5上运行 Stable Diffusion，记录从环境配置到实际生成的完整过程，以及踩过的各种坑。

Freakz3z 这个账号前前后后累计了快一百颗 star 吧，见证了我从一个彻头彻尾的小白，一路走过来成为一个有那么点用的人。 第一次提 PR，第一次收获 Star 和 Fork，第一次回答大家的 Issue，这些经历仿佛都在昨天。 可能的原因 至于被封禁的原因，大概是在 26 年春节那会，我用 nanobot 自动调用 GitHub API 并且定时推送到我的仓库。 这个行为持续了有两个星期，最后可能是被判定成机器人给软封禁了。 我做的尝试 我是偶然间发现仓库里的图片不显示，Star 趋势图也没有了，别人也看不到 Freakz3z 这个账号的 Profile 和任何仓库了才发现的。 发现这

欢迎来到Freak的小站！ 这是我第一次尝试用 React 制作独属于我自己的博客，也是我从2023年至今第三次部署博客。 希望这一次它可以陪伴我和大家更久的时间，也希望我能给大家带来更多的： 吐槽发癫 经验总结 技术分享 未来计划 --- 那么，很开心和大家再一次见面！

程序员的三大浪漫之一：拥有一个自己的个人主页。最近用 Vue 3 + Vite 写了 Lumen，一个现代化的个人主页模板，顺手开源了。 仓库：https://github.com/Freakz2z/Lumen 为什么不用现成模板 GitHub 上个人主页模板一抓一大把，但要么是几年前的 jQuery 风格，要么塞满了我用不上的功能。个人主页这种东西，本来就该是"我的审美的具象化"——自己写才有意思。 设计上的坚持 首屏即全部：个人主页不是简历，访客平均停留 10 秒，一屏内讲清楚你是谁、在做什么、去哪找你 动效克制：入场动画有，但不做视差滚动那种炫技——流畅感来自细节的缓动曲线，不是动画的数

Tool Calling 让模型能够选择工具，MCP 让工具和外部系统拥有统一的接入方式，但如果一个 Agent 只具备这两种能力，它依然很难直接进入生产环境。 原因很简单：会调用工具，不等于会稳定地完成任务。 一个真实任务通常不是： 而更像是： 这个过程本身就已经是一套流程系统。 Agent Workflow 解决的，就是如何把 LLM、Tool Calling、业务规则、状态管理和异常处理组织成一条可控的执行链路。 Agent Workflow 的核心不是让模型拥有更多自由，而是规定模型应该在哪些地方拥有自由。 为什么只靠 Tool Calling 不够 假设系统中给模型提供三个工具： 然

Harness 是让模型变成 Agent 的「操作系统」。拆解 agent 主循环、上下文管理、工具调度、记忆、权限与 MCP 六大组件，附最小实现思路与自建 vs 现成取舍。

零基础看懂 Harness：那个让 Agent 循环转起来的引擎。跑循环、管上下文、执行工具、设护栏，用类比讲清它为什么必不可少。

Agent 把判断交给模型、把执行交给工具。聊聊提示注入、权限失控、无声失败、token 成本，以及什么时候不该用 Agent。

记录 Qwen-JSON 的目标、底座、GRPO + LoRA 训练思路和结构化输出评估方法，并区分模型卡报告与独立复现实验。

Tool Calling 解决了一个很重要的问题：让大模型能够根据用户的目标，决定什么时候调用外部工具，以及应该传入什么参数。 但 Tool Calling 解决的只是模型这一侧的问题。 当一个 Agent 真正进入工程系统之后，很快就会遇到另一个问题：每接入一个新的外部系统，都需要重新定义工具、编写适配代码、处理通信方式、权限认证和返回格式。如果 Claude、ChatGPT、Cursor、VS Code、内部 Agent 平台都需要访问 GitHub、数据库、文件系统、浏览器和企业 API，那么如果没有统一协议，每一个“AI 应用 × 外部系统”的组合都可能需要单独适配。 MCP，也就是

在现有模型（如YOLO）的基础上进行改进以发表论文，是计算机视觉领域一个非常常见且可行的策略。关键在于找到那个小但有效的改进点，并进行充分的实验验证。 一、 核心思路：找准发力点 改进的核心在于发现YOLO在特定场景下的痛点，并针对性地解决。问自己几个问题： YOLO在什么情况下会失效？ （如小物体、密集物体、遮挡、特殊光照等） YOLO的哪个部分可能成为瓶颈？ （如特征提取网络、特征金字塔、预测头、损失函数等） 有没有新的技术可以嵌入到YOLO中？ （如注意力机制、新的卷积方式、标签分配策略等） --- 二、 具体的改进方向 轻量化与效率提升（非常适合工程应用类论文） 这个方向关注如何在保持

理解 GRPO 如何通过同一 prompt 的多条回答计算组内相对优势，减少 critic 依赖，并分析它在可验证任务中的优势与奖励设计陷阱。

如果说大语言模型解决的是“理解和生成”，那么 Tool Calling 解决的，就是如何让模型真正进入软件系统。 没有 Tool Calling，大模型本质上仍然只是一个文本生成器。它可以解释天气、分析订单、讨论数据库，也可以根据已有上下文给出建议，但它无法真正查询实时天气接口、读取订单状态、修改日历，也无法调用企业内部系统完成实际操作。 Tool Calling 改变的正是这一点。它让大模型不再只负责“回答问题”，而是开始参与任务执行过程： 这也是现代 AI Agent 最基础的一层能力。 它到底是什么 Tool Calling 可以理解为：将一组程序能力暴露给大模型，让模型根据当前任务决定

在使用树莓派进行 pip 操作时，可能会出现一下类似报错： 这时候我们就需要使用国内源或者为树莓派启动网络代理。不过如果你不想在树莓派中下载 Clash 等软件，而你又正好有一台同WIFI下的其他主机，那么你就可以像本文中提到的一样，对树莓派进行网络设置。 查看代理： 临时设置代理： 将后面的信息改为你电脑的 临时关闭代理： 永久修改代理： （推荐）修改 /etc/environment 树莓派的网络代理文件通常是 /etc/environment，我们可以通过 进入此文件，若你没有修改过网络代理文件，你会看到： 你可以将其修改为： 修改 /etc/apt/apt.conf.d/99proxy

零基础看懂 AI Agent：模型会想、工具会做、循环会坚持、记忆记得住。用生活化的例子讲清 Agent 与聊天机器人、自动脚本的区别。

从监督微调的训练目标、对话数据格式和 assistant-only loss 入手，理解 SFT 如何把通用语言模型调整成更符合任务要求的模型。

从策略梯度、概率比值和裁剪目标入手，理解 PPO 如何在语言模型对齐中限制策略漂移，以及它为什么需要 reward、critic 和 reference policy。

LabelMe是图形图像注释工具，它是用Python编写的，并将Qt用于其图形界面。 它的功能很多，包括： 对图像进行多边形，矩形，圆形，多段线，线段，点形式的标注（可用于目标检测，图像分割等任务）。 对图像进行进行 flag 形式的标注（可用于图像分类和清理任务） 视频标注 生成 VOC 格式的数据集 生成 COCO 格式的数据集 windows安装 在安装前请保证你的计算机中有conda环境，详细看此文 https://blog.csdn.net/qq44000789/article/details/142214660 创建一个名为 labelme 的python3.9虚拟环境 启动虚拟环

在阅读本文章时，请保证电脑中已经安装了Git，或前往安装Git。 一、创建GitHub仓库 在GitHub DashBoard左侧找到绿色的 NEW 按钮创建仓库： 输入 Repository name 输入 Description 选择可见性 Public 或 Private 加入 README.md 文件 > README.md为项目的描述文件 加入 .gitignore 文件 > .gitignore文件中可以自定义git推送时自动忽略的文件 选择开源协议 > 此处不多赘述 二、使用Git > 此处以命令行为例 三、注意事项 > 请注意此处是使用代理的情况

在使用本方法前请先保证 nvidia-smi 指令有相应输出，并且显示器依旧黑屏 问题背景 在PVE中安装了Ubuntu22.04，远程连接时有图像输出。在做了以下尝试： 开启显卡直连 使用NVIDIA驱动 屏蔽Nouveau驱动 后显示器依旧保持黑屏。 解决方法 打开 10-nvidia.conf 文件 在 10-nvidia.conf 文件中添加:Option "PrimaryGPU" "Yes" 打开 10-amdgpu.conf 文件 在 10-amdgpu.conf 文件中将 Driver "amdgpu" 改为 Driver "modesetting" 重启电脑 问题解决