全部文章

我们研究的不是“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" 重启电脑 问题解决