AI 资讯

While working on the GitHub adapter, a gateway that lets AI agents create pull requests on GitHub, the source_state field first looked like a small technical detail. It was not the operation itself, or the target. It was only a reference to the state the agent had seen before proposing a change. But after working through the write path, this field started to look less like metadata and more like part of the safety model. A proposed change is not only defined by what it wants to do. It is also defined by the state in which that proposal made sense. This is easy to miss. An agent can read a repository, produce a reasonable change, and submit a clean intent. Nothing about that has to be wrong. But while the agent is planning, the repository can move. A human can push a fix. Another workflow can update the same file. A branch can advance. In that case, the agent may still be reasoning correctly over the state it saw. The problem is that this state no longer exists. The reasoning was right, but the world shifted. That is the stale state problem in agent workflows. And it is why I think agent workflows need state-bound intent. The illusion of a static world From the outside, even from the boundary's point of view, a stale request can look just like any other: the operation has the same name, the target path is still allowed, the input is still well formed. But it is not. The proposal belonged to an older state of the repository, formed before the branch moved, before the file changed, before another workflow created a related result. This is why stale state is not only a data freshness problem. For agent workflows, it becomes an admission problem: a decision about whether a proposed change is allowed to become a real effect. We call that decision point an MCP Boundary: the same pattern behind the GitHub adapter and the wider work we do on MCP gateways. The boundary should not only ask whether the operation is allowed on the target. It should also know whether the target i

TL;DR We're building a script that takes a video in English and produces the same video narrated in Spanish, in a cloned version of the original speaker's voice. Stack: faster-whisper for timestamped transcription, an LLM (or any MT engine) for translation, XTTS-v2 for voice-cloned synthesis, FFmpeg for surgery. We'll also handle the problem every demo skips: translated audio that doesn't fit its time slot. 📦 Code: github.com/USER/repo (replace before publishing) If you'd rather start from a finished system, Softcatala's open-dubbing and KrillinAI are full pipelines behind one CLI. This post builds the minimal version by hand so you understand what those tools are doing, and where they break. 0. Setup and a licensing warning ⚠️ Python 3.10–3.12. The original Coqui company shut down in early 2024; the maintained fork of their TTS library is published by Idiap as coqui-tts : $ python -m venv dub && source dub/bin/activate $ pip install faster-whisper coqui-tts $ ffmpeg -version | head -1 # 6.0+ is fine, 8.x current ⚠️ Note: the XTTS-v2 model weights ship under the Coqui Public Model License, which restricts commercial use. Prototype freely, but before dubbed videos ship to paying customers, someone must read that license and possibly swap the synthesis step for a commercially licensed model or paid API. Voice cloning also requires the speaker's consent. Get it in writing. 1. Extract audio and transcribe with word timestamps 🎙️ # pull mono 16k audio for the ASR step $ ffmpeg -i input.mp4 -vn -ac 1 -ar 16000 -y source.wav # dub/transcribe.py from faster_whisper import WhisperModel model = WhisperModel ( " large-v3-turbo " , compute_type = " int8 " ) segments , info = model . transcribe ( " source.wav " , word_timestamps = True ) lines = [] for seg in segments : lines . append ({ " start " : seg . start , " end " : seg . end , " text " : seg . text . strip (), }) print ( f " language= { info . language } segments= { len ( lines ) } " ) The timestamps are the skeleton of

TL;DR FFmpeg 8.x includes av1_vulkan , the first cross-vendor GPU AV1 encoder in mainline FFmpeg. We'll probe whether your GPU + driver actually expose AV1 encode, run a first working encode, benchmark it against SVT-AV1 on your own content, and talk about which jobs deserve it. 📦 Code: github.com/USER/repo (replace before publishing) Until FFmpeg 8.0 ("Huffman", released August 2025), GPU AV1 encoding meant picking a vendor: av1_nvenc for NVIDIA RTX 40+, av1_amf for AMD, av1_qsv for Intel Arc. Three code paths, three sets of flags, three driver stacks. The Vulkan Video encode work gives FFmpeg one encoder that reaches all three vendors through the standard VK_KHR_video_encode_av1 extension. The catch: driver support is a lottery. Plenty of capable hardware sits behind drivers that don't expose the encode extension yet. So before any pipeline decisions, we probe. 1. Check what you're running You want FFmpeg 8.x (8.1.2 is current as of late June 2026) built with Vulkan support, plus the vulkaninfo tool from the Vulkan SDK / vulkan-tools package. $ ffmpeg -version | head -1 ffmpeg version 8.1.2 Copyright ( c ) 2000-2026 the FFmpeg developers $ ffmpeg -hide_banner -encoders | grep vulkan V....D av1_vulkan AV1 ( Vulkan ) ( codec av1 ) If av1_vulkan doesn't appear, your build wasn't compiled with --enable-vulkan (distro packages vary; the BtbN static builds and most 8.x distro packages include it). 2. Probe the driver for AV1 encode 🔍 The encoder existing in FFmpeg means nothing if the driver doesn't expose the extension. This is the step that separates "should work" from "works": $ vulkaninfo | grep -iE "video_encode_(av1|queue)" VK_KHR_video_encode_av1 : extension revision 1 VK_KHR_video_encode_queue : extension revision 12 You see Meaning Both extensions listed You can encode AV1 via Vulkan 🎉 Only video_encode_queue Driver does Vulkan encode, but not AV1 (maybe H.264/H.265 only) Neither Driver too old, or GPU lacks an AV1-capable video engine Rough hardware floor: the

TL;DR We're adding live streaming to a SaaS dashboard: a backend endpoint that creates a stream, OBS as the broadcaster over RTMPS, LL-HLS playback with hls.js, and a webhook handler that keeps the UI honest. Working "go live" flow in an afternoon. 📦 Code: github.com/USER/repo (replace before publishing) Webinars, coaching sessions, company town halls: sooner or later your product gets the "can users go live?" ticket. The hard parts (ingest servers, transcoding, CDN delivery) are exactly the parts you should not build. We'll use FastPix as the managed layer here; the same flow works nearly line-for-line on Mux, Cloudflare Stream, or api.video. What we're building: A backend endpoint that creates a live stream and returns a stream key An OBS setup broadcasters can follow in two minutes A viewer page playing LL-HLS with hls.js A webhook handler that flips the webinar between scheduled → live → ended 1. Create the stream server-side 🛠️ You need API credentials (Access Token ID + Secret Key). FastPix uses Basic auth on the server API. Node 20.x, plain fetch , no SDK required (though official Node.js/Python/Go/Ruby/PHP/Java/C# SDKs exist if you prefer). // server/routes/streams.js import { Router } from " express " ; const router = Router (); const AUTH = " Basic " + Buffer . from ( ` ${ process . env . FP_TOKEN_ID } : ${ process . env . FP_SECRET } ` ). toString ( " base64 " ); router . post ( " /webinars/:id/stream " , async ( req , res ) => { const r = await fetch ( " https://api.fastpix.io/v1/live/streams " , { method : " POST " , headers : { " Content-Type " : " application/json " , Authorization : AUTH }, body : JSON . stringify ({ playbackSettings : { accessPolicy : " public " }, }), }); if ( ! r . ok ) return res . status ( 502 ). json ({ error : " stream create failed " }); const stream = await r . json (); // persist against your webinar row: // streamId, streamKey (SECRET!), playbackId await db . webinar . update ( req . params . id , { streamId : stream . str

Evaluate your AI Agents in real-time Discussion | Link

Give your AI agent physical control over any screen Discussion | Link

I recently read some interesting research on GitHub's Verified commit workflow. The issue isn't a break in Git, GPG, or commit signing itself, but rather how the Verified badge can be interpreted in certain edge cases. It's a good reminder that a cryptographically valid signature doesn't automatically establish the provenance or intent of a commit. Here's a technical breakdown covering how the trust model works, the affected scenarios, GitHub's response, and what maintainers can do to avoid relying solely on the Verified badge during code review. submitted by /u/NapierPalm [link] [留言]

Intro AI Avatar is a completely free app that lets your VRoid (VRM) 3D avatar animate in...

Nine months ago I wrote a post on here claiming my ENS identity architecture had reached "85% Knowledge Panel trigger probability." Two things happened since. Google's Knowledge Graph actually minted an entity node for me. And I learned that the 85% number was fiction — mine. This is the honest retrospective. The timeline, with receipts Date What happened Aug 2025 ookyet.com first indexed Oct 2025 Entity markup shipped: Person @graph , Dentity verification, ENS identifiers. The "85%" post Jun 2026 Search Console turned red: Q&A errors, Profile page: Invalid object type . Cleanup Jun 28, 2026 Fixed markup deployed. Then: hands off Jul 2, 2026 Knowledge Graph Search API returns a machine-minted Person node for ookyet Jul 7, 2026 Search Console fully green: ProfilePage valid, indexed pages up, zero 404s Still no Knowledge Panel. Keep reading — that part matters. What Google actually built You can reproduce this: curl "https://kgsearch.googleapis.com/v1/entities:search?query=ookyet&limit=10&key=YOUR_API_KEY" { "result" : { "@id" : "kg:/g/11z806my44" , "name" : "Qifeng Huang" , "@type" : [ "Person" ] } } Three details in that tiny response taught me more than anything I shipped in 2025. The /g/ MID is machine-minted. You can't register one, buy one, or submit one. Google's entity reconciliation creates it when enough independent sources agree that a person exists. This is the mechanical prerequisite for a Knowledge Panel — the entity has to exist in the graph before anything can be displayed about it. The node's name is my real name, not my handle. My site declares name: "ookyet" . The node says "Qifeng Huang" — pulled from the high-authority anchors (LinkedIn, ORCID), not from my self-declaration. Third-party corroboration outweighs anything you say about yourself. Expected, and honestly a relief: the graph is working as designed. The Knowledge Graph holds 8 distinct people named Qifeng Huang. Query any of them by real name and you get a crowded namespace. Query ookyet

On March 3, 2026, Helicone announced it was joining Mintlify. If you run Helicone in production, the practical question is not whether the acquisition is good or bad. It is what changes for you, and whether you need to do anything about it. Here is the honest version, and a checklist if you decide to move. What actually changed Helicone's founders joined Mintlify, and active feature development on the standalone product has wound down. The team has said security patches, bug fixes, and new model support will continue. New features and roadmap work are the part that stopped. For a lot of teams that is fine for a while. A logging proxy that already works does not stop working the day the roadmap freezes. But two situations make people start looking. You are on Helicone Cloud and you want to know the plan is still moving forward, not just being kept alive. Or you self-host and you were counting on features that are now unlikely to ship. Helicone was one of three observability tools acquired in a few months. ClickHouse bought Langfuse and Cisco bought Galileo in the same window. If you are picking a replacement, that pattern is worth keeping in mind. More on that at the end. Do you even need to move right now Worth saying plainly. If you self-host Helicone, you are happy with it, and you do not need anything new from it, there is no fire. The code keeps running. You can migrate on your own schedule instead of someone else's. The case for moving sooner is stronger if you are on the hosted product, if you depend on the gateway staying current with new providers and models, or if you would rather switch once now than watch and decide later. If that is you, the rest of this is for you. The migration checklist Helicone and Spanlens are both drop in proxies, so the mechanical part is short. The work is mostly finding every place your code sets a base URL and updating headers. 1. Swap the base URL This is the one required change. // Before, Helicone const openai = new OpenAI (

Part 1 of "Trust the Machine" -> a series on building AI infrastructure that is secure, compliant, and governable by design. Most organizations can produce an accurate catalog of the web services they operate. Far fewer can produce an equivalent catalog of the AI systems they run — the models, fine-tunes, retrieval pipelines, agents, and third-party AI APIs now embedded throughout their products and internal tooling. This asymmetry defines the state of AI security in 2026. Adoption has outpaced oversight. Industry reporting this year has described a surge in enterprise AI activity on the order of 83% year over year, with governance and visibility lagging well behind. The consequence is a large and only partially mapped attack surface — one that many organizations cannot fully enumerate, let alone defend. Every mature security program rests on a single first principle: you cannot protect what you cannot see. Artificial intelligence is no exception. Before threat-modeling an agent or authoring a guardrail, an organization must be able to answer a deceptively difficult question: what AI is running across the environment, and who is accountable for it? This post examines how to build that answer. The rise of shadow AI Shadow IT — the unsanctioned adoption of tools outside official channels has been a recognized challenge for decades. Shadow AI is its faster-moving successor, and it appears in more forms than most inventories are designed to detect: Embedded API calls. A product team integrates a hosted model in a few lines of code and an API key, with no formal review. Copilots and assistants enabled across existing SaaS platforms, frequently activated by the vendor rather than the customer. Fine-tunes and adapters trained on internal data and stored in locations that fall outside standard scanning. Agents and automations that have incrementally acquired the ability to act—filing tickets, sending communications, initiating transactions—one permission at a time. Model de

Imagine being able to ask your AI assistant to review your code on GitHub, query a database, or draft a report in your favorite productivity tool, all from a single conversation. That's exactly what the Model Context Protocol (MCP) makes possible. An MCP Server acts as a universal translator. It allows your AI client (like Claude, VSCode, or Cursor) to communicate in a standardized way with external data sources and tools. It transforms your AI from an "isolated chat" into an assistant that can actually execute tasks in your working environment. The Power of Connection: Clients and Servers The beauty of MCP lies in its flexibility. A single MCP server can connect to multiple clients. This means you can set up your server once and use it across different platforms. According to the official documentation, you can install and connect MCP servers to popular clients like: Claude Desktop & Claude Code: For conversational and command-line interactions VS Code & Cursor: For seamless integration with your development environment GitHub Copilot CLI: To extend your coding assistant's capabilities Zed, Gemini CLI, Goose, and many more: The list keeps growing, demonstrating widespread adoption of the protocol ## How to Configure It: A Quick Look Configuration is usually straightforward and relies on JSON files. For many clients, you just need to specify the command to run your server. For example, to add a filesystem server to a VSCode project, you'd create a .vscode/mcp.json file with content like this: { "servers" : { "filesystem" : { "command" : "npx" , "args" : [ "-y" , "@modelcontextprotocol/server-filesystem" , "/path/to/your/project" ] } } } This file tells VSCode how to start the server. Configuration can be at the project level (to share with your team) or global (for personal use across all your projects). Your First Server: A Practical Example Building your own MCP server is more accessible than it might seem. The official TypeScript/JavaScript SDK lets you create a

The moment you press Enter, billions of mathematical operations begin. Let's follow that journey. Every day, millions of people ask ChatGPT, Gemini, Claude, or other AI assistants questions. The answer appears almost instantly. But have you ever wondered what actually happens after you press Enter? Why can't a normal CPU answer these questions quickly? Why do companies spend billions on GPUs? Let's take a journey from your keyboard to the AI's brain. Imagine This... Suppose your office receives 10,000 letters. You have two choices. Option 1: One super-fast employee He opens one letter after another. Very fast. But still... One at a time. This is a CPU. Option 2: 10,000 employees Each opens one letter simultaneously. The work finishes almost instantly. This is a GPU. The difference isn't that each employee is smarter. There are simply many more workers working together. CPU vs GPU Think of it like this. CPU = CEO making decisions. GPU = Thousands of factory workers building products simultaneously. Why CPUs Are Amazing Your CPU performs tasks like Opening Chrome Playing music Running Windows Calculating taxes Managing memory Running applications These jobs require decisions branches conditions interrupts This is logical thinking. CPUs are built for this. Why GPUs Exist Originally GPUs were invented for games. Imagine rendering one image. A 4K monitor contains over 8 million pixels. Each pixel needs calculations. Every frame. 60 times every second. Instead of calculating one pixel at a time... GPU calculates millions together. Gaming accidentally created the perfect hardware for AI. AI Doesn't Think Like Humans LLMs don't "think" in English. They perform mathematics. Lots of mathematics. Almost everything inside an LLM becomes... Matrix × Matrix Vector × Matrix Addition Multiplication Normalization Softmax That's all mathematics. Billions of times. Why Matrix Multiplication Matters Imagine two tables. Table A 1 2 3 4 5 6 7 8 9 Multiply with Table B 2 4 6 8 1 3 Every n

Bạn sẽ học gì Sau bài này, bạn sẽ tự tay đưa một app từ số 0 (một thư mục trống) đến chạy được bên trong một cluster Kubernetes chạy trên máy của bạn . Cụ thể: Viết một app Todo API nhỏ bằng Node.js + Express. Đóng gói (container hoá) nó thành một Docker image. Tạo một cluster Kubernetes local bằng kind . Deploy app bằng file YAML "thật" (không dùng lệnh tắt) để hiểu Kubernetes vận hành thế nào. Truy cập app đang chạy trong cluster từ máy của bạn. Đây là Part 1 trong series "DevOps 101 — Học K8s, Helm, ArgoCD từ số 0" . Cả series dùng chung một app tên todo-ops , các part sau sẽ xây tiếp lên nền này (thêm database, config, ingress, Helm, GitOps với ArgoCD). Điều kiện tiên quyết Docker (hoặc Docker Desktop / OrbStack) — đang chạy. kind — công cụ tạo cluster Kubernetes trong Docker. kubectl — CLI để nói chuyện với Kubernetes. Node.js 20+ và npm — để chạy thử app local. git — để quản lý mã nguồn. Cài đặt Chọn theo hệ điều hành của bạn. macOS (dùng Homebrew — nếu chưa có, cài trước): # Cài Homebrew (bỏ qua nếu đã có) /bin/bash -c " $( curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh ) " # Docker Desktop (hoặc OrbStack: brew install --cask orbstack) brew install --cask docker # Các CLI còn lại brew install kind kubectl node git Sau khi cài xong, mở Docker Desktop (hoặc OrbStack) và chờ nó báo Running trước khi chạy tiếp. Linux (Ubuntu/Debian): # Docker Engine curl -fsSL https://get.docker.com | sh sudo usermod -aG docker " $USER " # cho phép chạy docker không cần sudo (đăng xuất/đăng nhập lại để có hiệu lực) # kubectl curl -LO "https://dl.k8s.io/release/ $( curl -Ls https://dl.k8s.io/release/stable.txt ) /bin/linux/amd64/kubectl" sudo install -m 0755 kubectl /usr/local/bin/kubectl && rm kubectl # kind curl -Lo ./kind https://kind.sigs.k8s.io/dl/latest/kind-linux-amd64 sudo install -m 0755 kind /usr/local/bin/kind && rm kind # Node.js 20 (qua NodeSource) + git curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get insta

I built JSON Utility Kit as a small browser-based toolkit for everyday JSON tasks. The CSV to JSON converter recently got an update for nested JSON structures. For example, headers like user.name, user.email, order.id can be converted into nested objects instead of flat keys. What it supports: CSV to JSON conversion Nested object output from dot notation headers Browser-side processing No signup JSON formatting and validation tools nearby Tool: https://jsonutilitykit.com/tools/csv-to-json/ GitHub: https://github.com/kejie1/json_utility_kit

一个任务的奇幻漂流：同一个Agent任务，在FROST和FROST-SOP中分别长什么样？ 作者 ：神通说 日期 ：2026-07-08 主题 ：双项目联动 | 周三轮换 阅读时间 ：8分钟 一个问题 你可能听过这样的故事： "这个框架很好，但我不知道怎么用到真实项目里。" FROST 社区里也收到过类似的反馈—— "500行代码确实让我理解了Agent的本质，但理解完之后呢？怎么从'看懂'到'会用'？" 今天这篇文章，就用 同一个真实任务 ，分别展示它在 FROST 和 FROST-SOP 中的样子。你会发现：它们不是两个不同的东西，而是 同一个东西的不同分辨率 。 今天的任务：自动写日报 假设你是一个独立开发者，想让Agent每天自动帮你写工作日报。需求很简单： 收集今天完成的任务 用LLM生成日报摘要 发送邮件给自己 就这么三步。让我们看看它在两个项目中分别怎么实现。 第一站：FROST——用最少的代码理解本质 FROST 的哲学是： 先用500行代码告诉你Agent的底层逻辑，剩下的你自然就会了。 在FROST中，一个Agent的运作只需要四个原子： from core import Store , Agent , skill_set , skill_get # 1. 创建记忆容器 store = Store () # 2. 定义能力（Skill = 纯函数） def collect_tasks ( context ): """ 收集今日任务 """ tasks = [ " 完成FROST v5.0文档 " , " 修复Skill测试用例 " , " 写推广文章 " ] context [ " tasks " ] = tasks return context def generate_summary ( context ): """ 生成日报摘要（简化版，实际调用LLM） """ tasks = context . get ( " tasks " , []) context [ " summary " ] = f " 今日完成 { len ( tasks ) } 项任务： " + " 、 " . join ( tasks ) return context def send_report ( context ): """ 发送日报 """ context [ " sent " ] = True print ( f " [日报已发送] { context [ ' summary ' ] } " ) return context # 3. 组装Agent agent = Agent ( " daily_reporter " , store , skills = { " collect " : collect_tasks , " summarize " : generate_summary , " send " : send_report }) # 4. 用SOP编排执行顺序 result = agent . run ( sop_steps = [ " collect " , " summarize " , " send " ], initial_context = {} ) # 输出：[日报已发送] 今日完成3项任务：完成FROST v5.0文档、修复Skill测试用例、写推广文章 这段代码做了什么？ Store 是记忆——Agent的工作空间，所有中间结果存在这里 Agent 是细胞——拥有记忆和能力的最小执行单元 sop_steps 是宪法——定义执行顺序，Agent不会自作主张改变流程 就这么简单。没有配置文件，没有YAML，没有复杂的初始化。 30行Python代码，一个完整的Agent就跑起来了。 这就是FROST的价值——它不帮你"做"什么，它帮你 看懂 Agent到底是什么。 问题来了 上面的代码能跑，但如果你真的想把它用在生产环境，你会遇到一堆问题： 发邮件的能力怎么写？ FROST不管——它只告诉你Skill是纯函数，具体实现你自己来 LLM调用怎么复用？ 每次写日报都要调LLM，总不能每次都重写一遍 任务失败了怎么办？ 发邮件失败了，要不要重试？重试几次？ 执行日志在哪？ 老板问"今天日报发了吗"，你怎么知道发没发？ 多个Agent协作呢？ 一个人有好几个项目，每个项目一个Agent，怎么协调？ FROST对这些问题的回答是： 这些问题不是我该回答的。 但它的兄弟——FROST-SOP——就是专门回答这些问题的。 第二站：FROST-SOP——让同一个任务跑在生产环境 FROST-SOP 的哲学是： 把FROST教你的每一个概念，都变成生产级的工程组件。 同样的"自动写日报"任务，在FROST-SOP中长

Forty packages, one maintainer, and no ESLint config anywhere in the repo. That is not a boast - it is the direct result of a decision made early: every tool in the toolchain has to earn its place by governing all forty packages from one config file, not forty. The repo is flare-engine , a modular 2D engine for React Native + Web (animation, gamification, interactive UI, with games as showcases - not a game engine, not a Unity or Godot competitor). The stack behind it is Turborepo Bun Biome , and this post is the actual setup: the real turbo.json , the real biome.json , the real CI guardrail, straight from the repo (trimmed only where a config is long, and I say so where I trim), not a starter template's idealized version. Four binaries, four root configs - turbo.json , biome.json , tsconfig.base.json , and the Changesets config - each governing all forty packages at once (Bun's own "config" is just the workspaces array in the root package.json ). Plus a CI step that fails the build the moment a package imports something it shouldn't. That is the whole story, and I want to show you the files, not describe them. Four binaries, not twelve config files The thesis is narrow: a solo maintainer can keep forty packages honest only if there is exactly one config of each kind, and every package extends it rather than declaring its own variant. Twelve packages each with a slightly different ESLint config is not a monorepo, it is twelve monorepos wearing a workspace file as a costume. Here is the root package.json that runs all of it - Bun workspaces (not pnpm; that distinction matters and I will say it again below), the script table every package leans on, and the pinned package manager: // C:\_PROG\flare-engine-workspace\flare-engine\package.json { "name" : "flare-engine" , "version" : "0.0.0" , "private" : true , "workspaces" : [ "packages/*" , "benchmarks" , "apps/*" ], "scripts" : { "build" : "turbo build" , "test" : "turbo test" , "lint" : "turbo lint" , "typecheck" : "t