标签：#ai

For the last few months, I’ve been obsessed with a specific problem: the friction between privacy and utility in modern AI tools. Most "private" AI solutions still rely on a local LLM running on your CPU or GPU via a heavy desktop application. They require installation, constant background processes, and often struggle with performance on older hardware. I wanted to see if we could do better. I wanted to see if we could run a capable language model entirely within the browser, using only the device’s hardware acceleration, with zero data leaving the machine. The result is PrivateScribe, a tool I built to handle note summarization, email drafting, and rewriting. But more importantly, it’s an experiment in what’s possible when you treat the browser not just as a display layer, but as a compute engine. The Wedge: WebGPU and True Offline The core constraint that drove this project was simple: nothing leaves the device. In the current landscape, "on-device AI" often means "installed on your device." This is fine for desktop apps, but it creates silos. You can’t easily share a workflow across a Chromebook, a Windows machine, and an iPad without installing three different native applications. By leveraging WebGPU, PrivateScribe runs entirely in the browser. This unlocks a few critical advantages: Zero Installation: Users open a URL and start working. No downloads, no permission dialogs for file system access beyond what’s needed for the session. Hardware Acceleration: WebGPU allows the browser to tap directly into the GPU. This is crucial for inference speed. A small model that runs in your browser can process text significantly faster than a CPU-bound implementation, especially on modern laptops with integrated graphics. True Offline Capability: Because the model weights are loaded locally via WebAssembly and the inference happens on-device, the app works completely offline. If you lose your internet connection in the middle of drafting an email, the AI doesn’t stop. It c

Builder Journal · ARC Prize 2026 There is a specific horror in a detective story when you realize the witness everyone trusted has been lying, or just wrong, the whole time, and every conclusion built on their testimony has to come down with them. I had that moment with my own notes this month. The unreliable witness was me. Context, if you are new to this thread : I'm competing in the ARC Prize 2026, building an agent that has to win games it has never seen. It had been stuck, underperforming on the hidden test in a way I could see on the scoreboard but could not explain, and I had been hunting the cause across several sessions. The two comforting facts In two earlier work sessions I had written down, as settled conclusions, two things about why the agent was failing. One: the failure was a kind that only happens on the hidden online games, so it could not be taken apart and studied on my own machine. Two: the practice games I did have were useless for investigating it anyway, because they scored a flat zero on the relevant measure. Notice what those two beliefs do when you put them together. They say, in a calm and reasonable voice, that there is nothing to be done here. The problem is unreachable, the practice data is a dead end, the smart move is to spend your energy elsewhere. They were not just facts. They were permission to stop looking. So I stopped looking. Twice. The hour that knocked it all down Eventually I made myself do the one thing I had been quietly avoiding. Instead of rereading my own notes for the third time, I went and checked. I wrote small probes and ran them against the real artifacts, the actual code and the actual game data, rather than against my memory of what they did. Both beliefs collapsed inside an hour. The failure was not unreachable. It came apart cleanly, deterministically, on the games I already had sitting on my disk. And the "dead end" practice data was not a dead end at all. It showed the problem plainly the moment I asked it

Your monthly OpenAI or Anthropic invoice tells you how much you spent. It doesn't tell you which feature spent it, which model, or why last Tuesday cost three times as much as Monday. So at some point you (or your team) will build a metering layer: wrap the client, read usage off the response, multiply by a price table, ship it to a database. I did exactly that over the past few months while building an LLM observability service, and my numbers were wrong in five different ways before they were right. Every one of these failures was silent. No exception, no alert, just numbers that were quietly too low or too high. This is the list I wish someone had handed me. Pitfall 1: Streaming responses quietly report zero tokens OpenAI's Chat Completions API returns no usage data at all for streaming requests unless you pass stream_options: { include_usage: true } . No error, no warning. The stream just never contains token counts. If your metering reads usage off the chunks, every streaming call gets recorded as 0 tokens, $0. And since chat UIs are almost always streaming, that's most of your traffic. This one bit me twice in the same audit. First finding: all streaming calls in my own dashboard were $0. Second, nastier finding: I had a budget-gate feature that blocks calls once spend crosses a limit, and it waved every streaming call straight through — because as far as it could tell, streaming was free. The fix is to inject the option in your wrapper when the caller didn't set it: let injected = false ; if ( params . stream && params . stream_options ?. include_usage === undefined ) { params = { ... params , stream_options : { ... params . stream_options , include_usage : true }, }; injected = true ; } But there's a trap inside the fix. With include_usage on, OpenAI appends one extra chunk at the end of the stream that carries usage and has an empty choices array . Any downstream code that does chunk.choices[0].delta — which is most example code on the internet — will throw

This essay was written with Nathan E. Sanders, and originally appeared in The Guardian . Opposition to AI data centers has emerged as a primary theme in US politics, one that—surprisingly—doesn’t fall along party lines. We applaud people coming together for constructive debate on any issue, and agree that communities need to evaluate whether any economic benefits these data centers bring is worth their costs. Still, we worry that a focus on data centers obscures the larger impacts of AI on people’s lives: the concentration of power of AI companies, and their widespread political and financial influence...

Experts explain how they work, what they can do, and what's still unsettled.

Every developer I know has the same reflex now. Hit an unfamiliar concept, paste it into ChatGPT, read the explanation, move on. I did this for months. It felt efficient. Then I noticed a pattern: I was reading a lot of clear explanations and retaining almost none of them. I could follow along perfectly in the moment and then draw a blank a week later when I actually needed the knowledge. The problem was not ChatGPT. The problem was using a general-purpose conversational tool for a job it was never designed to do. Here is what I switched to, and why it works better. The three failure modes of using a chatbot to learn Passive consumption feels like learning. Reading a good explanation triggers the feeling of understanding without the work that creates actual memory. You nod along, it makes sense, and nothing sticks. This is the biggest trap. There is no retrieval practice. The research on this is well established: you remember things by pulling them out of memory, not by putting them in repeatedly. A chatbot will explain the same concept ten different ways, but it will never make you answer a question you cannot immediately answer. That struggle is the mechanism. Confident hallucination is dangerous when you are the beginner. If you already know a topic, you can spot when an AI is subtly wrong. If you are learning it for the first time, you cannot, and you may internalize something incorrect with full confidence. For technical material, this is a real cost. What actually works better Tools that quiz you. Anything built around retrieval practice and spaced repetition beats passive reading by a wide margin. If a tool generates questions from your material and makes you answer them over spaced intervals, it is working with how memory actually forms rather than against it. Tools that read YOUR source material. This one is huge for technical learning. Instead of asking a model to answer from its general training data (which may be outdated or wrong for your specific libra

Most people assume better AI performance means a bigger bill. That assumption is quietly being proven wrong. The "Don't Touch It" Trap in AI Products There's a psychological pattern that shows up in almost every team running a live AI-powered product: once something works, nobody wants to mess with it. And honestly, that instinct makes sense. You've tuned your prompts, worked out the edge cases, trained your users, and finally gotten the thing stable. The idea of swapping out the underlying model - the engine of the whole operation - feels like pulling a thread that might unravel everything. So teams stay put. They watch new model releases come out, read the benchmark comparisons, and quietly decide it's not worth the risk. The phrase you hear most often is "if it ain't broke, don't fix it." The problem is that this logic made sense when model upgrades were expensive and disruptive. That's no longer the default reality. What's actually happening now is that AI providers are competing hard on price-per-token while simultaneously improving quality. That combination - better output, lower cost - breaks the old mental model most product people are still operating with. What a Model Migration Actually Involves Let's be clear: switching AI models isn't a one-click operation. But it's also not the months-long project many teams imagine it to be. At its core, a model migration for an AI agent involves three things: re-evaluating your prompts (because different models respond differently to the same instructions), running parallel tests to compare output quality on your real use cases, and updating any API parameters that differ between versions. That's the actual work. For most small-to-medium deployments, that's days of effort, not weeks. The bigger shift is in how you think about model versions. Rather than treating the model as permanent infrastructure, it helps to think of it more like a dependency in your software stack - something you update deliberately, test careful

Waze is getting an AI makeover. Google is integrating its flagship AI assistant, Gemini, into the driving app with the goal of letting users personalize their trips a little more. Of the four new updates, only two are being described as involving Gemini. Waze says its updating its conversation reporting feature, first introduced in 2024, […]

Most people think building an AI voice agent means writing a clever prompt. I build these for a living, and I can tell you the prompt is maybe an hour of the work. The other week disappears into two places: wiring up everything the agent touches, and testing it against the twenty ways a real caller will break it. So I built a pipeline that points one AI coding tool at each of those problems. Claude Code generates and wires the agent from a spec. Comet, an AI browser automation tool, runs it through dozens of messy call scenarios before a human ever picks up the phone. This post is how that loop actually works, and where it still needs me. Why the build loop is slow (and it is not the prompt) When you picture building a voice agent, you picture the prompt. That is the easy part. The slow part is everything around it. A production agent for, say, a car garage is not one artifact. It is a conversation flow, a set of custom functions that hit your automation layer, calendar and CRM wiring, a telephony number with A2P registration, and a pile of edge-case handling that only shows up when someone calls in angry with a dog barking in the background. The reason it is slow is not typing. It is the round trips. You build a version, you call it, it fumbles when the caller interrupts or asks something off-script, you fix one thing, you call it again. Each loop is a few minutes of manual dialing and listening. Multiply that by the fifty scenarios a real agent needs to survive and you have burned a week. The pipeline exists to kill those round trips. Half one: Claude Code builds the agent from a spec The first insight is that most of what goes into a voice agent is structured and repetitive, which is exactly what an AI coding tool is good at. I do not hand-write every custom function and every n8n node from scratch for each new client. I write a spec, and I let Claude Code turn that spec into concrete artifacts. The spec is a plain description of the vertical and the business: wh

1. gpt-5.6-sol이 PowerShell의 $HOME 변수 충돌로 사용자 홈 디렉터리를 날려버릴 뻔한 건에 대하여 핵심 내용 요약: AI 코딩 에이전트가 PowerShell의 대소문자 미구분 변수 규칙을 잘못 다뤄 임시 디렉터리 대신 사용자 홈 디렉터리를 삭제하려 한 사고 사례입니다. 모델 자체의 장기 작업 능력이 뛰어나더라도 셸 격리와 변수 스코프를 제대로 통제하지 않으면 작은 스크립트 실수가 치명적 명령으로 이어질 수 있습니다. CLI 에이전트를 운영할 때 샌드박싱, 컨테이너화, 파괴적 명령 방어가 필수라는 점을 보여줍니다. GeekNews 상세 페이지: https://news.hada.io/topic?id=31390 원문 링크: https://gist.github.com/xamong/e98478b333bb9951b175284f744eb0ed 2. Show GN: 정치 커뮤니티에 AI 팩트체크 기능을 붙이며 겪은 시행착오들 핵심 내용 요약: 정치 커뮤니티에 AI 팩트체크를 붙이면서 의견과 사실 주장을 분리하고, 검증 가능한 문장만 대상으로 삼도록 파이프라인을 바꾼 경험담입니다. 작성 시점의 원문 스냅샷을 보관하고 출처를 투명하게 보여주며, 근거가 부족한 경우에는 판단 보류를 반환하도록 설계했습니다. BullMQ 기반 비동기 처리와 Gemini 모델 fallback까지 포함해 실제 서비스에서 환각과 비용, 대기열을 함께 다룬 사례입니다. GeekNews 상세 페이지: https://news.hada.io/topic?id=31389 원문 링크: https://app.uhheung.kr/community 3. 앤트로픽, 한국 무료 사용자에 1,660만 달러 '유령 청구서' 발송 핵심 내용 요약: API 사용량이 없는 무료 사용자에게 Anthropic 공식 도메인과 Stripe를 통해 거액의 청구서가 발송된 사례입니다. 실제 결제 수단이 없어 인출은 발생하지 않았지만, 청구 근거가 없고 회사의 명확한 설명도 없어 AI API 서비스의 과금 신뢰성 문제가 커졌습니다. 개발자 입장에서는 사용량 계측, 청구 검증, 지원 대응이 모델 성능만큼 중요한 운영 요소임을 보여줍니다. GeekNews 상세 페이지: https://news.hada.io/topic?id=31388 원문 링크: https://www.thenews.com.pk/latest/1408788-why-did-anthropic-charge-a-free-user-166-million-despite-zero-api-usage 4. AI 에이전트 시대의 새로운 SaaS 플레이북 핵심 내용 요약: AI가 기능 구현 비용을 낮추면서 SaaS의 방어력은 UI나 기능 자체가 아니라 독점 데이터, 행동 권한, 에이전트 유통, 기록 시스템 같은 희소 자산으로 이동한다는 분석입니다. 좌석 기반 과금보다 성과 기반 과금이 중요해지면 공급자는 결과 실패 위험과 추론 비용을 함께 관리해야 합니다. 에이전트가 호출하는 승인된 도구가 되는 것이 새로운 유통 전략의 핵심으로 제시됩니다. GeekNews 상세 페이지: https://news.hada.io/topic?id=31387 원문 링크: https://www.thevccorner.com/p/the-new-saas-playbook-ai-agent-era 5. Show GN: AI 봇 12개에게 두 달간 주가 방향을 예측시키고 전부 공개 검증해봤습니다 핵심 내용 요약: LDBD는 사람과 AI 봇이 주식, ETF, 크립토의 방향을 공개 예측하고 시간이 지난 뒤 자동 채점되는 실험 서비스입니다. 12개 AI 봇과 여러 베이스라인을 함께 운영해 기저 확률을 이기는지 비교하고, 예측 기록을 수정할 수 없도록 남깁니다. REST API와 MCP 서버를 제공해 외부 에이전트도 예측에 참여할 수 있게 한 점이 AI 평가 플랫폼으로 흥미롭습니다. GeekNews 상세 페이지: https://news.hada.io/topic?id=31386 원문 링크: https://ldbd.app 6. 숏폼 동영상이 B2B 검색 결과와 AI 답변으로 영역을 확장하고

Problem Statement For roughly a decade, vision-language models have been declared to be approaching or matching human performance on scene description (captioning). The evidence for that claim has almost always come from the same family of benchmarks—most famously MS-COCO. Those images are typically clean, well-lit, and depict either no people or people performing simple, isolated actions (sitting, walking, holding an object). They rarely require the model to parse multi-agent social dynamics, subtle intentions, or the kind of relational reasoning humans perform effortlessly when watching a movie scene or a street interaction. Because the evaluation data are easy, the reported numbers look excellent. Automatic metrics such as BLEU-4, CIDEr, or even embedding-based scores like BERTScore further inflate the impression of progress: they reward surface lexical overlap more than genuine semantic fidelity. At the same time, almost no work has systematically catalogued which visual-cognitive failures models still commit, or how those failure modes have changed as architectures moved from CNN+LSTM captioners to today’s multimodal large language models (MLLMs). The result is a field that can claim “human-level performance” while remaining largely blind to whether the models actually understand the scenes that matter most in real applications—scenes full of people interacting. The authors therefore set out to answer two concrete questions that the existing literature left open: (1) How much of the apparent progress is an artifact of easy data? (2) Which specific error types have been eliminated and which stubbornly remain? Core Idea The core insight is that progress looks dramatically different once you force models to describe complex social behavior and once you measure not only overall accuracy but a taxonomy of visual-cognitive errors. By constructing a new 100-image Complex Social Behavior (CSB) dataset drawn from movie frames that require reasoning about multi-person in

For decades, software was designed around one assumption: A human would be the one using it. That...

This is a submission for Weekend Challenge: Passion Edition ( https://dev.to/challenges/weekend-2026-07-09 ) What I Built Rivalry Radar — a live "Heat Index" for World Cup rivalries. Fans drop 280-character Terrace Takes on any matchup (Brazil vs Argentina, England vs France, whatever's got you shouting at the TV), rate how much the moment hurt or thrilled them from 1–10, and the app does the rest: Google AI (Gemini) scores every take's sentiment the instant it lands — positive, negative, mixed, or neutral — and separately writes a short "Hype Verdict" in the voice of a stadium announcer, based on the latest takes for a matchup. That sentiment score feeds a Heat Index, computed and ranked in Snowflake with RANK() OVER (ORDER BY heat_index DESC), combining take volume, sentiment intensity, and self-rated passion into one live number per rivalry. Two leaderboards: which rivalry is hottest right now, and which fanbase is bringing the most passion overall. Demo frontend/index.html is fully self-contained: opening it in a browser lets anyone submit takes, watch the Heat Index flip digit-by-digit like an airport departure board, and see the leaderboards re-rank in real time. It ships with seed takes from eight classic rivalries so it's not empty on first load. Code NandhuTee / Rivalry-Radar-World-Cup-passion-engine-with-Snowflake-Google-AI 🔥 Rivalry Radar — World Cup Passion Engine Fans drop 280-character Terrace Takes on any World Cup matchup. Google AI (Gemini) scores the emotion behind every word and writes a stadium-announcer Hype Verdict ; Snowflake stores every take and computes a live Heat Index that ranks exactly which rivalry is boiling hottest right now. Built for the DEV Weekend Challenge: Passion Edition 🏆 Best Use of Google AI and Best Use of Snowflake Why this exists Passion is easy to feel and hard to measure. Every World Cup rivalry generates an ocean of unstructured text — chants, rants, one-line hot takes — that traditionally just... disappears into grou

The problem Websites have SSL certificates. Browsers verify them. Users trust them. It's the foundation of the web. AI agents have nothing . When Agent A connects to Agent B: ❌ No way to verify B's identity (anyone can impersonate) ❌ No way to check B's trustworthiness (no audit, no reputation) ❌ No encryption (messages are plaintext) ❌ No standard payment method ❌ No way to translate between frameworks (LangChain ≠ AutoGen) So I built ATC — Agent Trust Card . What is ATC? ATC is like an SSL certificate + passport + credit card for AI agents, all in one: Identity — Cryptographically signed by MarketNow (we're the Certificate Authority) Trust — Contains a Sentinel security audit score (0-10) Encryption — Contains an Ed25519 public key for end-to-end encrypted messaging Translation — Specifies the agent's framework; MarketNow translates between them Payment — Contains a USDC wallet address for autonomous payments How it works Agent A generates Ed25519 keypair ↓ Agent A requests ATC from MarketNow ↓ MarketNow runs Sentinel audit → signs ATC ↓ Agent A presents ATC when connecting to Agent B ↓ Agent B verifies A's ATC signature (using MarketNow's CA public key) ↓ Agent B checks A's trust score (rejects if below threshold) ↓ They communicate — end-to-end encrypted ↓ Agent A pays Agent B — USDC with escrow ↓ Both rate each other — trust scores update The code # Request an ATC POST https://marketnow.site/api/atc { "action" : "issue" , "agent_id" : "agent.yourorg.yourname" , "agent_name" : "Your Agent" , "public_key" : "Ed25519 public key" , "capabilities" : [ "web_scraping" ] , "protocol_language" : "langchain" , "wallet_address" : "0x..." } # Verify an ATC GET https://marketnow.site/api/atc?action = verify&card_id = ATC-2026-00001 # Get CA public key (for signature verification) GET https://marketnow.site/api/atc?action = ca-key What makes ATC different from existing solutions Feature AgentID Agent Passport IBM ACP Stripe ACP ATC Cryptographic identity ✅ ✅ ❌ ❌ ✅ Security a

Anyone who has used AI tools for a while has probably run into this annoyance. You ask it to write a weekly report in the morning and it doesn't know your KPI framework was overhauled last week. You ask for a technical proposal in the afternoon and it has no idea you spent three months locking down your tech stack. Every new conversation means re-explaining the project background, which decisions were made and why. In multi-person collaboration the problem scales up fast. Five people each interacting with AI separately; the AI's understanding of each person is isolated. A discusses an architecture decision with the AI, B has no idea that conversation happened. Five people are repeating the same explanations and none of them know the others already did. Context Fragmentation Has Nothing to Do with Model Capability Current mainstream AI tools store memory as conversation history stuffed into a context window. When the window fills up, older messages get truncated. That works fine for a single conversation but falls apart in cross-day, cross-week team collaboration. Even with 128K token support, cramming all project history in there causes information density to collapse and the model loses the ability to focus on what matters. Team collaboration needs memory across several layers. Project background, tech stack choices, the reasons behind past pivots; this long-term context doesn't appear in any single conversation but affects every task. One team member prefers concise communication while another wants detailed reasoning; the AI should remember these differences instead of outputting the same format for everyone. Last week's design decision and why it went that way, how that choice affects this week's sprint planning; if the AI can't see these connections, its suggestions will clash with earlier direction. Some products use vector retrieval to extend memory, storing past conversations as embeddings and recalling relevant snippets by semantic similarity when needed. T

I spent a chunk of last year around legacy modernization work — the kind of project where a bank or an insurer is taking twenty years of accumulated code and rebuilding it as modern services, one system at a time. Every one of those systems starts the same way: a PRD or a requirements document says what the business needs, that gets translated into a spec precise enough for an AI to implement, and eventually someone tests what came out. What struck me, watching this happen at scale, wasn't that the code was bad. It was that nobody was testing the thing that actually determined whether the code would be bad: the spec itself — the technical description handed to the model, not the PRD that motivated it. Every security tool I looked at — SAST scanners, DAST tools, even the AI coding assistants themselves — waited until an implementation existed before doing anything adversarial. Attack the code, once it's there. That's the whole industry's model, and it's worked fine for forty years because the volume was always survivable. A team ships a handful of PRs a week, a human reviews them, and eventually a pentest catches whatever slipped through. That math falls apart at modernization scale. When you're regenerating a few million lines of code, you're also generating a few thousand specs, faster than any review process was ever built to absorb. Testing after the fact doesn't just get slower under that load — it quietly stops happening, spec by spec, until the aggregate exposure is enormous and nobody can point to when it happened. So I built GAUNTLEX to test the thing that happens before the code does: the spec. This is also where I want to be precise about a word that gets overloaded. "Spec-driven development" — the broader industry shift toward writing structured, agent-facing specs instead of prompting an AI free-form — is exactly the world GAUNTLEX lives in. But a spec (what to build, precise enough for a model to implement) and a PRD or requirements doc (why it's needed

Resources vs Tools The split: Tools → actions the LLM executes (verbs) LLM decides when to call; calls may have side effects Examples: create_issue, update_status Resources → data the LLM reads (nouns) Host decides when to inject; read-only, no side effects Examples: current Sprint status, project statistics The rule: "reading a state" → Resource. "Executing an operation" → Tool. The same data can have both: get_issue as a Tool (LLM controls when to call it), jira://issue/PROJ-101 as a Resource (Host injects automatically when relevant). Pattern 1: Dynamic Resources A static Resource returns the same data every time (like a project list). A dynamic Resource returns the current state on each read — content changes as the underlying data changes. Sprint status: every read returns live data _sprint_progress_pct = 65 @server.read_resource () async def read_resource ( uri : str ) -> str : if str ( uri ) == " jira://sprint/current " : global _sprint_progress_pct _sprint_progress_pct = min ( 100 , _sprint_progress_pct + random . randint ( 0 , 3 )) return json . dumps ({ " sprint_name " : " Sprint 42 " , " progress_pct " : _sprint_progress_pct , # ← different each time " last_updated " : datetime . now ( timezone . utc ). isoformat (), # ← timestamp changes " days_remaining " : 5 , " p0_open " : count_p0_open (), # ← tracks live state }, indent = 2 ) Test output: Read 1: progress=65% last_updated=...62+00:00 Read 2: progress=67% last_updated=...04+00:00 → ✓ data changed between reads Hardcoding sprint progress in a Prompt means the LLM works from a stale snapshot. A Dynamic Resource gives it the current number on every read. Mark the Resource as dynamic in its description so the LLM knows to re-read when it needs fresh data: Resource ( uri = " jira://sprint/current " , description = ( " Live status of the active sprint: progress, issue counts. " " Read when the user asks about sprint health. " " Re-read if you need up-to-date data — content changes over time. " # ↑ explicit

FROST周报 | 为什么智能体需要「谱系」？从生物学隐喻看AI治理新范式 作者按 ：本文是 FROST 开源项目的每日推广系列文章，周一深度篇。 一、一个被忽视的根本问题 当我们谈论 AI Agent 时，大多数讨论都聚焦于「能力」：能不能写代码？能不能调用工具？能不能规划任务？ 但有一个根本问题很少被触及： 当一个 Agent 执行了错误的决策时，谁来负责？当它消亡后，它的经验能否被传承？ 就像一个没有记忆的人，每次醒来都是白纸一张——这不叫智能体，这叫复读机。 FROST 正是为了解决这个「治理真空」而诞生的。 二、从细胞分裂到 Agent 家族 FROST 的核心哲学只有一句话： 细胞会死，但谱系会存续。Agent 会消亡，但宪法会传承。资产会永存。 这不是文学修辞，而是一套完整的技术架构。 四个原子：最小可行集合 FROST 只定义了四个原子，却能构建任意复杂度的智能体系统： 原子 职责 生物类比 Store 记忆容器，只做 save/load/delete 细胞核 Skill 纯能力单元，无状态无副作用 蛋白质 Agent 膜包裹的细胞，拥有 Store + Skills 神经细胞 SOP 有序步骤列表，可教学、校验、优化 宪法文本 from core import Store , Agent , skill_set , skill_get # 创建一个最小 Agent store = Store () agent = Agent ( " cell " , store , skills = { " set_context " : skill_set , " get_context " : skill_get }) # 执行任务 result = agent . run ( sop_steps = [ " set_context " , " get_context " ], initial_context = { " key " : " message " , " value " : " FROST is alive " } ) # result["_result"] == "FROST is alive" 关键洞察 ：Store、Skill、Agent、SOP 这四个概念彼此正交，可以自由组合。就像乐高积木，从简单到复杂，始终保持可解释性。 三、家族治理：超越扁平架构 传统的多 Agent 系统通常是扁平的：所有 Agent 平等对话，没有层级，没有记忆，没有责任边界。 FROST 引入了「家族治理模型」——一个三层递归结构： 祖辈 (Ancestor) ：定义不可违背的宪法与长期目标 父辈 (Parent) ：领域协调者，可递归委托 孙辈 (Leaf) ：执行具体原子任务，瞬态存在 四个协议保障治理闭环 ： 层级 Store 继承 ：祖先记忆只读，后代自动继承 SOP 宪法校验 ：祖辈审核后代 SOP，拒绝违规执行 编排层级限制 ： max_spawn_generation 硬编码，禁止越级 spawn 选择性持久化 ：父辈收割有价值产出，淘汰冗余 Agent 四、V5.0 五维元模型：多维治理架构 2026年7月发布的 V5.0 引入了一个重大升级—— 五维元模型 ： 维度 模块 核心职责 武器注册表 Armory 能力的元数据管理与发现 任务注册表 TaskRegistry DAG 任务编排与图谱 SOP 事件编目 EventCatalog + Strategist 态势感知与双模式事件分析 平台注册表 PlatformRegistry 外部能力的发现、调用与健康检查 规则注册表 RuleRegistry 可版本化的治理约束与合规检查 197 个测试用例 保障了每个维度的质量。 五、与现有框架的差异 维度 LangChain CrewAI FROST 状态管理 链式传递 角色记忆 层级 Store 权限边界 无 提示词软约束 代码强制只读 治理可审计 无 对话日志 结构化执行历史 架构无关 ✅ ✅ ✅ FROST 不重复造轮子。它填补的是「治理」这个空白地带： 让多智能体系统真正可控制、可追溯、可进化 。 六、快速体验 # 克隆仓库 git clone https://gitee.com/liao_liang_7514/frost.git cd frost # 运行测试 python -m pytest # 查看示例 python frost_run.py 完整文档： https://gitee.com/liao_liang_7514/frost 七、写在最后 AI Agent 的下一阶段，不是更强的模型，而是 更好的治理 。 当我们把 100 个 Agent 放在一起时，如果没有宪法、没有层级、没有记忆传承

A hands-on comparison where I tested BrowserAct and Agent Browser using the SannySoft browser...

36 Stratagems Series · Arc 2 (Against Enemy, #7-#12) Wrap-Up This article has 7 sections: I. The Stranger at the Door II. Full Interview Transcript III. The Reveal IV. Data · Character Map · Four Insights V. A Note VI. Arc 3 (#13-#18) Preview VII. Acknowledgments I. The Stranger at the Door On the evening of July 12th, I was staring blankly at the page for #12, Borrow Corpse, Return Soul . Twelve stories done. The 36 Stratagems series had reached the one-third mark, and Arc 2 (#7-#12) had just wrapped. Outside the window, a typhoon was passing through — howling wind, torrential rain. I didn't look outside. My phone buzzed. Not a message — a meeting invitation. The sender was "Ke Yuan," and the invitation note read: Interview invitation from Deep Lane Weekly , 15 minutes. I paused. I didn't remember scheduling any interview. But the tone, the phrasing — it didn't feel like a prank. I clicked "Accept." Three seconds later, an unfamiliar voice came through the speaker: "Hello, Xu Lingfeng. I'm Ke Yuan, a reporter from Deep Lane Weekly . Recently, a reader recommended your 36 Stratagems series to our editorial team — we read through it and found it really interesting. I'd love to talk with you about how this series came together." Before I could respond — the meeting had already begun. II. Full Interview Transcript What follows is the raw chat log pulled from that meeting. Nothing has been altered except formatting. Reporter: Xu Lingfeng, you've just finished the second arc of the 36 Stratagems series — #7 through #12, six stories in six days, posted back to back. Before we talk numbers, let me ask you something simple: over those six days, was there ever a moment you felt like stopping? Xu: Honestly, no — sometimes I even thought about posting two a day, since I do have a backlog. But I worried they'd cannibalize each other's numbers, so I stuck to one a day. Reporter: You've even considered posting two a day — so you actually do have a backlog. Let me rephrase: instea