Agent

在上一篇文章中，我把 OpenWebUI 的数据库迁移到了 Azure 托管 PostgreSQL。在日常使用 OpenWebUI 的过程中，我经常遇到两个问题： 问不到最新的信息：模型有知识截止时间，问到最近的版本发布、新闻或价格，要么答不上来，要么答错。 贴进去的链接不会被打开：把文章、文档或 GitHub 页面的 URL 贴进对话框，想让模型总结、翻译或对比，模型却不会去读这个链接，有时甚至会根据 URL 猜出一段“看起来很像”的内容。 这两个问题都可以靠 OpenWebUI 的联网能力解决。本文使用微软新推出的 Microsoft Web IQ 作为联网搜索引擎，并让模型自动识别消息中的 URL、读取网页后再回答。整个过程只需要在 Azure 门户中创建一个 Web IQ 资源，再到 OpenWebUI 的管理界面中完成配置，不需要写代码，也不需要部署额外的服务。 本文基于 Open WebUI v0.11.4（2026 年 9 月发布），界面名称以英文界面为准。文中的 API Key 均为占位符。 最终效果 配置完成后： 提问涉及最新信息时，模型会自己调用 search_web，由 Web IQ 返回搜索结果，回答附带参考链接； 消息中出现 http:// 或 https:// 链接时，模型会自己调用 fetch_url，通过 Web IQ 读取页面正文后再回答，读取过的页面会出现在引用来源中； 两者可以在同一次回答中组合使用，例如先读取你给出的文档，再搜索最新的变更说明做对比。 为什么选择 Microsoft Web IQ 打开 OpenWebUI 的 Settings → Admin → Web Search，在 Web Search Engine 中可以找到 bing。选中后需要填写 Bing Search V7 Endpoint 和 Bing Search V7 Subscription Key，看起来只要填上 Azure 上 Bing 资源的密钥就能用，但这条路已经走不通了：...

引言 2026 年 9 月，AI 圈突然流行起一类“不会说话”的模型。 9 月 15 日，由前 OpenAI 研究员 Diogo Almeida 创办的 TypeSafe AI 发布了 Jev：它不聊天、不写文章、也不生成代码，只接收一段状态（state）和一组预先定义好的问题，然后直接返回带有校准概率的结构化决策。 仅仅三天后，9 月 18 日，独立研究者 Nandakishor M（Convai Innovations）开源了 Laya。它同样是一个非自回归的 System 1 决策模型，采用 Apache 2.0 协议，权重可以直接从 Hugging Face 下载，三天内 GitHub 星标就超过了 6000，被社区称为“开源版 Jev”。 一边是背靠 4000 万美元种子轮、开箱即用的闭源 API，一边是 4.2 亿参数、一张 T4 甚至一台 MacBook 就能跑起来的开源模型。社交媒体上“Laya 反超 Jev”“Jev 的护城河只维持了两天”之类的说法很多，但如果把双方公开的资料仔细读一遍，就会发现结论远没有这么简单。 本文将从以下几个方面展开： 什么是决策模型，它要解决什么问题 Jev 与 Laya 各自的技术路线 核心差异与基准数据解读 两者各自的优势与劣势 适用场景与选型建议 什么是决策模型（System One Model） 1. 名字的由来 “System One”来自丹尼尔·卡尼曼的《思考，快与慢》：System 1 是快速、直觉式的判断，System 2 是缓慢、审慎的推理。在这个比喻下，生成式大模型（尤其是推理模型）更像 System 2，而决策模型负责的是毫秒级的“直觉反应”。...

在过去一年里，AI 编程的主流交互方式经历了一个明显演进： Prompt → Prompt Engineering → Context Engineering → Skill（能力封装） 如果说 Prompt 是一次性调用模型能力，那么 Skill 本质上是在构建“可复用的智能能力模块”，它让 AI 从“会回答问题”，进化为“能执行任务”。 这篇文章将系统讲清： 什么是 AI 编程中的 Skill Skill 与 Prompt 的本质区别 如何在 VS Code + GitHub Copilot Chat 中使用 Skill 思维 实战案例（工程级） 什么是 Skill？ 在 AI 编程语境下，Skill = 结构化提示 + 上下文 + 执行约束 + 输出格式 可以用一个更工程化的定义： Skill = f(Instruction, Context, Constraints, Output Schema) 它不是一句 prompt，而是一个“可复用的能力接口”。 对比理解 方式 特点 问题 Prompt 临时输入 不可复用、不稳定 Prompt Engineering 优化表达 仍然是一次性 Skill 能力封装 可复用、可组合、可治理 为什么 Skill 很重要？ 在实际开发中，AI 使用很快会遇到几个瓶颈：...

随着生成式 AI 与智能代理的快速发展，自托管的智能系统正变得越来越受开发者和技术团队关注。Clawdbot 就是这样一款开源、可自托管的个人 AI 助手，它不仅能与用户进行对话，还能执行任务、集成消息平台、提供自动化能力，并可部署在云平台上如 Azure。本文将逐步介绍 Clawdbot 的能力、架构以及如何在 Microsoft Azure 上部署并开始使用它。 什么是 Clawdbot Clawdbot 是一个开源的个人 AI 助手项目，本质上是一个智能代理框架，它可以： 与多种消息平台进行交互，包括 WhatsApp、Telegram、Discord、Slack、Microsoft Teams 等。 承担智能对话、任务执行、自动化工作流的角色，而非单纯聊天机器人。 支持在本地或自托管服务器上运行，数据默认保存在本地，增强隐私保护。 通过插件/技能扩展，实现日程提醒、文件管理、邮件处理、代码生成等功能。 Clawdbot 的核心由 **Gateway、Providers（平台接入）、Agents/Skills（智能任务执行单元）**构成。Gateway 负责消息总线、Providers 负责与各消息平台对接，Agents/Skills 则实际执行用户请求。 Clawdbot 的主要特性 多平台消息接入 Clawdbot 支持通过连接聊天平台 API，接收来自 WhatsApp、Telegram、Discord、Signal、Slack、Microsoft Teams 等消息，并将这些消息传递给 AI 模型进行处理。 隐私和数据控制 与云端托管的聊天 AI 不同，Clawdbot 可以运行在你自己的服务器或 VPS 上，所有对话历史、配置、凭据都可以按需存储和访问。 自动化执行能力 除了对话，Clawdbot 还能执行具体任务，包括浏览器控制、文件操作、数据处理、发送提醒等，这使其成为一个更为复杂的个人助手平台。 可扩展的模型支持 Clawdbot 支持多种 AI 模型提供者（如 OpenAI GPT、Anthropic Claude，甚至本地 LLM 服务如 Ollama）。 在 Azure VM 部署 Clawdbot 虽然 Clawdbot 支持本地运行或容器平台，但在以下场景中，Azure VM 是非常合适的部署形态：...

微软研究院最近发布了 Fara-7B，这是一款专为电脑操作（Computer Use）设计的代理小语言模型（Agentic SLM）。与传统的聊天模型不同，Fara-7B 旨在通过像人类一样使用鼠标和键盘来完成任务。 什么是 Fara-7B？ Fara-7B 是一个拥有 70 亿参数的模型，基于 Qwen2.5-VL-7B 构建。它的主要特点包括： 视觉感知：它通过视觉感知网页（截图）来操作，不需要依赖辅助功能树（Accessibility Trees）或额外的解析模型。 高效紧凑：尽管只有 7B 参数，但在同类模型中实现了最先进的性能，甚至在某些基准测试中可以与更大的模型竞争。 端侧运行：由于体积小，它可以在设备上本地运行，从而降低延迟并提高隐私安全性。 核心技术 Fara-7B 的训练利用了微软开发的合成数据生成管道，该管道基于 Magentic-One 框架。它通过“观察-思考-行动”（observe-think-act）的循环来执行任务。 在每个步骤中，模型会接收： 用户指令 完整的操作历史 最近的三张屏幕截图 然后，它会输出一个推理信息（“思考”下一步行动），随后调用工具（如 click(x,y)、type() 等）来执行操作。 性能表现 在 WebVoyager、Online-Mind2Web 等基准测试中，Fara-7B 展现了强大的性能。例如在 WebVoyager 上，它的任务成功率达到了 73.5%，超过了 UI-TARS-1.5-7B (66.4%) 和 GPT-4o (SoM Agent, 65.1%)。 如何通过 vLLM 使用 Fara-7B Fara-7B 已经发布在 Hugging Face 上。由于它是基于 Qwen2.5-VL 的，我们可以使用 vLLM 来高效地部署和推理。 安装 vLLM 首先确保你安装了最新版本的 vllm： pip install vllm Python 代码示例 以下是一个使用 vLLM 加载 Fara-7B 并进行推理的 Python 脚本示例：...