首页 › new-tools › Agent分叉、浏览器跑推理、六款海外新AI利器

Agent分叉、浏览器跑推理、六款海外新AI利器

导语:Agent跑着跑着要分叉探索?LLM热切换要等5分钟?AI工具互相打架写出三套代码?今天这六款工具,分别从推理层、Agent协作层、开发流程层三个维度,给出了你没想到的解法。它们全部开源,全部能直接上手。


一、Thaw:给运行中的LLM做"Git Branch"——0.88秒分叉一个Agent

这是什么: Thaw 是一个推理层原语库,核心能力是把一个正在运行的LLM推理会话(包括权重、KV Cache、调度器状态、前缀哈希表)完整快照,然后在分叉点生成N个独立的子会话并行运行。简单说就是 git branch,但作用对象是活着的LLM。

官网: github.com/thaw-ai/thaw
协议: Apache 2.0
HN热度: 2026年5月底上线,引发Agent开发者关注

为什么值得关注

当前所有主流Agent框架(LangGraph、CrewAI、AutoGen)在做并行探索时,每条分支都要从头做一次完整的Prefill(预填充),这意味着:

Thaw的做法是:只做一次Prefill建立共享KV Cache,后续分叉只做内存拷贝(memcpy),实测 0.88秒/次。

场景 无Thaw 有Thaw 提速比
8条并行Agent分支 ~45分钟 ~7秒 ~400×
16条RL Rollout ~90分钟 ~15秒 ~360×
70B模型热切换 ~53秒wake ~2.5秒 ~21×

适用场景

国内对比

目前国内没有同类工具。MiniMax、月之暗面等做RL后训练的团队,Rollout分叉仍依赖HuggingFace TRL等框架的串行实现。Thaw填补了"KV Cache级别分叉"这个空白。

快速上手

pip install thaw-vllm

兼容 vLLM 和 SGLang 两大推理引擎。


二、Async:Claude Code × Linear × GitHub PR 三合一工作流

这是什么: Async 是一个开源开发者工具,把 AI 编码、任务管理、代码审查三个流程焊死在一个流水线里。你提一个 GitHub Issue,Async 自动调研 → 拆分子任务 → 在云端隔离环境执行 → 提交Stacked PR → 等你Review合并。

官网: async.build | github.com/bkdevs/async-server
协议: 开源
HN热度: 107 pts,2025年8月

为什么值得关注

大多数AI编码工具(Cursor、Windsurf、Claude Code)的共同问题是:它们不懂你的项目管理流程。你在Linear里有个任务,它不知道;AI写的PR需要Review,你要手动在GitHub里操作。

Async的解法很硬核:

  1. 自动导入GitHub Issue → 转为Async内部任务
  2. Research Agent(GCR隔离Job)克隆你的仓库,分析代码库,生成澄清问题
  3. Execution Agent(Claude Code驱动)拆分子任务 → 逐个执行 → 创建Stacked PR
  4. 内置Review:在Async界面里逐个子任务Review,评论→修改→合并
完整流程:GitHub Issue → 调研 → 拆任务 → 执行 → Stacked PR → Review → Merge

国内对比

国内类似工具极少。飞书+自研Agent的团队(如字节、百度)有内部方案,但中小团队基本靠"Cursor + 手动PR"的原始流程。Async把整个链路串了起来,关键是云端隔离执行——不改你本地环境。

技术栈


三、Airweave(YC X25):让Agent搜遍你所有App的统一检索层

这是什么: Y Combinator X25批次项目,开源的AI Agent上下文检索基础设施。接入50+数据源(Slack、Notion、GitHub、Google Drive、Confluence、数据库等),持续同步数据,暴露统一的LLM友好搜索接口。Agent一次查询,跨多源检索。

官网: app.airweave.ai | github.com/airweave-ai/airweave
协议: 开源
HN热度: 164 pts,YC背书

为什么值得关注

RAG(检索增强生成)的痛点不是算法,是数据管道。每个Agent要对接不同的App,每个App的API不同、认证不同、数据格式不同。自己搭一套能用的多源RAG管道,至少2-3周。

Airweave的做法:

层 Airweave做什么 你需要做什么
连接 50+预制集成(Slack/GitHub/Notion等) 选数据源,填API Key
同步 持续增量同步 + 自动索引 无
检索 统一语义搜索接口 Agent调SDK查
输出 LLM友好的结构化上下文 直接用

快速上手

git clone https://github.com/airweave-ai/airweave.git
cd airweave && ./start.sh
# 访问 http://localhost:8080

也支持Cloud版本,零部署直接用。支持MCP协议、REST API、Python SDK。

国内对比

国内Dify、FastGPT提供类似的知识库RAG能力,但多App实时同步这个层面做得不够深。Airweave的50+预制集成是实打实的,不是PPT。对于做AI Agent的团队来说,这是"不想重复造轮子"的基础设施。


四、TheFoundry:企业级多Agent系统的"一键脚手架"

这是什么: 一个Multi-Agent System(MAS)的启动引导框架。不是一个Agent框架,而是一套治理体系:定义Agent角色、权限、通信协议、任务队列、共享看板,让多个AI Agent协作开发软件项目时不打架。

官网: github.com/aavilagallego/TheFoundry
协议: 开源
HN热度: 2026年5月底上线

为什么值得关注

多Agent协作的三个致命问题: 1. 上下文腐烂:把巨大的spec.md喂给Agent改一个CSS bug,Token浪费且容易幻觉 2. 无限循环:Agent修Bug陷入死循环,烧Token永无止境 3. 互相覆盖:两个Agent同时改同一个文件

TheFoundry的解法非常工程化:

graph TD
    A[Bootstrap命令] --> B[@bootstrapper Agent]
    B --> C[生成项目结构+配置]
    C --> D[自毁:删除自己源码]
    D --> E[永久Agent团队启动]

    E --> F[@architect 架构师]
    E --> G[@backend 后端]
    E --> H[@frontend 前端]
    E --> I[@devops 运维]
    E --> J[@qa 测试]

    F --> K[任务队列 .agent/tasks/]
    G --> K
    H --> K

    K --> L[Pull模式:Agent自己领任务]
    L --> M[更新 team_status.md 看板]

    style B fill:#ff9900,stroke:#333,color:#000
    style F fill:#4CAF50,stroke:#333,color:#fff
    style G fill:#2196F3,stroke:#333,color:#fff
    style H fill:#9C27B0,stroke:#333,color:#fff

核心设计亮点:

国内对比

国内多Agent框架(MetaGPT等)侧重"编排逻辑",TheFoundry侧重"治理和护栏"。两个互补。


五、Open Envelope:定义AI Agent团队的开放Schema

这是什么: 一个开放的JSON Schema标准,用来定义AI Agent团队的组成、角色、技能和交互方式。不是一个产品,是一个协议。

官网: openenvelope.org
协议: 开放标准
HN热度: 52 pts

为什么值得关注

现在的Agent框架各自为战:LangGraph用图、CrewAI用角色、AutoGen用对话。一个Agent的"简历"(能做什么、需要什么工具、权限边界)没有统一格式。

Open Envelope想做的事情类似于Kubernetes里的Pod定义——用一个标准Schema描述一个Agent团队:

{
  "team": {
    "name": "code-review-squad",
    "agents": [
      {
        "role": "security-reviewer",
        "skills": ["static-analysis", "dependency-audit"],
        "tools": ["semgrep", "snyk"],
        "permissions": ["read:code", "write:comments"]
      }
    ]
  }
}

这意味着你可以: - 把一个团队定义导出到不同Agent框架运行 - 用一个可视化工具编辑所有Agent的配置 - 做Agent供应链管理——审计每个Agent的权限和依赖

国内启示

国内做Agent平台的团队(Coze、Dify等)应该关注这个方向。Agent的标准化定义是"Agent市场"和"Agent供应链"的前提。


六、AG2B:Agent跑在浏览器里,通过WebMCP暴露工具

这是什么: 一个客户端侧的Agent运行时(Runtime)。Agent不在服务器跑,在你的浏览器里跑。服务器只做LLM代理(Proxy),Agent的逻辑、工具调用、状态管理全部在前端完成。

官网: ag2b.ai
协议: 开源
HN热度: 2026年5月底上线

为什么值得关注

传统Agent架构:

用户 → 服务器(运行Agent + 调LLM + 执行工具) → 返回结果

AG2B架构:

用户 → 浏览器(运行Agent + 执行工具) → LLM API(只做推理)→ 浏览器

这个架构的三个杀手级优势:

优势 说明
零服务端成本 Agent逻辑和工具执行全在客户端,服务器只转发LLM请求
天然安全 用户数据不离开浏览器,敏感操作本地执行
实时交互 Agent直接操作DOM,没有WebSocket延迟

支持 React 框架绑定,Vue.js 即将支持。通过 WebMCP Bridge 可以在浏览器里直接调用MCP工具。

国内对比

国内做Agent应用的团队大多还在"全后端"架构。AG2B的"前端Agent"思路对于C端产品(AI助手、智能表单、自动化工具)非常有参考价值——省服务器成本、数据不出端。


信息差总结

维度 你可能知道的 你可能不知道的
Agent分叉 开N个进程并行探索 KV Cache级别快照分叉,0.88秒/次
AI编码流程 Cursor写代码 + 手动PR Async全自动:Issue→调研→执行→PR→Review
RAG数据管道 自己写对接脚本 Airweave 50+集成开箱即用,YC背书
多Agent治理 用LangGraph画图 TheFoundry的Pull模式+步数预算+TOML协议
Agent标准化 每个框架格式不同 Open Envelope统一Schema,跨框架可移植
Agent部署 全跑在服务器 AG2B跑在浏览器,零服务端成本
graph LR
    subgraph 推理层
        T[Thaw<br/>KV Cache分叉]
    end

    subgraph Agent协作层
        A2[TheFoundry<br/>多Agent治理]
        A3[Open Envelope<br/>Agent标准化]
        A4[AG2B<br/>浏览器Agent]
    end

    subgraph 开发流程层
        A1[Async<br/>编码全流程]
        A5[Airweave<br/>统一检索层]
    end

    T -->|加速| A2
    A2 -->|定义| A3
    A3 -->|兼容| A4
    A1 -->|检索用| A5

    style T fill:#ff6b6b,stroke:#333,color:#fff
    style A2 fill:#4ecdc4,stroke:#333,color:#fff
    style A3 fill:#45b7d1,stroke:#333,color:#fff
    style A4 fill:#96ceb4,stroke:#333,color:#fff
    style A1 fill:#ffeaa7,stroke:#333,color:#000
    style A5 fill:#dda0dd,stroke:#333,color:#fff

行动指南

立刻可做(0成本):

  1. Thaw:pip install thaw-vllm,跑一下 demos/fork_pool_rl.py 感受0.88秒分叉
  2. Open Envelope:去 openenvelope.org 读一遍Schema,思考你的Agent团队怎么标准化定义
  3. AG2B:npm i @ag2b/core zod,写一个浏览器里的最小Agent

周末可做(需要Docker):

  1. Airweave:git clone + ./start.sh,接入你的Slack和Notion,体验多源检索
  2. Async:安装GitHub App,提一个Issue,看它全自动执行

团队级别(需要规划):

  1. TheFoundry:研究它的Pull模式和TOML协议,对照你的多Agent架构找优化点
  2. Thaw + 你的RL Pipeline:如果做RL后训练,把Rollout分叉换成Thaw,省下的GPU时间直接算钱

参考来源


本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生(微信ID: gprshome201101)维护。 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入