v0.1.1-alpha.1

RiftX v0.1.1-alpha.1 — Shared Task Board & Multi-Agent Runtime

RiftX v0.1.1-alpha.1 正式发布。

本版本将主／子 Agent 协作从一次性任务派发升级为可恢复的共享任务板。新会话默认使用共享协作模式，多个 Agent 可以围绕同一调查状态领取工作、共享事实、发送消息，并在压缩、暂停和重启后继续推进。

把任务状态交给系统管理，把调查判断交给 Agent 完成。

核心更新

共享任务板

新会话现在默认启用持久化共享任务板：

• 使用嵌入式 SQLite 保存协作状态
• 支持任务提议、接纳、认领、阻塞、验收、重试和取消
• 支持任务依赖、优先级、执行者和结果引用
• 同一任务只能被一个 Agent 原子认领
• 使用任务版本、租约和执行代次隔离旧执行结果
• 任务状态可以在压缩、断线、暂停和重启后恢复
• 旧会话继续使用原有的子 Agent 流程，不强制迁移

任务生命周期包括：

proposed → ready → running → awaiting_review → done

同时支持：

blocked、failed、cancelled、rejected

主 Agent 与子 Agent 通信

主 Agent 负责规划、协调和验收，子 Agent 负责执行和提交结果：

• Main Agent 可以批准任务并分配给子 Agent
• 子 Agent 可以向 Main Agent 发送信息、问题和结果
• Main Agent 可以向指定子 Agent 发送任务更新
• 兄弟子 Agent 通过公共便笺、Finding、Artifact 和依赖变化共享信息
• 持久化收件箱保证消息不会因为断线或重启丢失
• 运行中的 Agent 在安全回合边界接收消息
• 空闲 Agent 只在有新工作或需要处理消息时唤醒模型
• 子 Agent 保留稳定身份和会话记录，空闲后可以释放临时资源并按需恢复

默认情况下，子 Agent 继承 Main Agent 的模型配置，也可以在设置中指定独立模型。

长任务与上下文连续性

本版本继续强化长时间任务的连续执行能力：

• 自动压缩后恢复任务板、当前工作项、消息和调查进度
• Investigation Capsule 从 Finding、Artifact、子任务和检查点中确定性重建调查状态
• 压缩失败时保留原始历史，不使用不完整摘要覆盖上下文
• 压缩失败自动进入退避，避免连续失败造成空转
• 压缩后的协作上下文和消息摘要有界注入，避免任务板耗尽模型上下文
• 支持中途压缩，不要求 Agent 结束当前调查回合
• 压缩后保留关键任务合同、调查胶囊和进度检查点

可靠的停止、暂停与恢复

协作运行时增加了明确的生命周期控制：

• 顶部停止会立即暂停任务板并中止当前执行
• 单项任务支持暂停、恢复、取消和重试
• 取消后的任务进入终态，不会被自动重新执行
• 重启后无法确认旧执行是否结束的任务会标记为待确认
• 未确认停止前不会重新分配同一任务
• 归档会话保留任务板和收件箱，恢复后不会自动运行
• 打开页面或 SSE 重连不会自动启动任务

Agent 调度与预算

调度器改为事件驱动：

• 复用空闲 Agent，避免重复创建会话
• 空闲 Agent 不进行模型轮询
• 每个 Agent 同时最多执行一个工作项
• 租约默认 120 秒，运行时自动续租
• 子 Agent 空闲一段时间后释放浏览器、MCP 和 SDK 临时资源
• 默认每轮最多接纳 32 个工作项
• 默认最多进行 60 次自主唤醒
• 每个工作项最多额外重试 2 次
• 每轮最多接受 256 条 Agent 消息和公共便笺
• 达到预算后保留当前进度，并等待主 Agent 或用户处理

这些预算限制用于防止任务空转，不代表 Token 费用上限。

WebUI 协作面板

右侧协作区域现在包含：

• 任务板
• Agent 列表
• 通信记录
• 任务状态、优先级、依赖和执行者
• 阻塞原因和待验收结果
• Agent 当前工作、运行状态和待处理消息
• 消息投递状态和回复关系
• 预算使用量及调整入口
• 暂停、恢复、取消、重试和发送消息操作

协作按钮、标签页、任务卡片和输入控件统一了交互反馈和视觉样式，鼠标悬停、点击、键盘聚焦和禁用状态都有明确反馈。

旧会话会显示旧协作流程，不会出现无法使用的新操作。

证据与调查状态

共享任务板继续使用现有 EvidenceStore 作为证据唯一来源：

• 任务板只保存 Finding、请求、截图和 Artifact 引用
• 公共便笺不能直接创建 confirmed Finding
• confirmed Finding 仍必须绑定可解析的真实工具、请求或截图证据
• Finding 保存后自动同步到任务板
• 主 Agent 和子 Agent 可以引用同一份调查证据
• 长工具输出保存为本地 Artifact，模型只接收有界预览和文件路径

MCP 与外部工具稳定性

MCP 调用继续保持隔离：

• 每个 MCP Server 独立限制并发
• 单次调用具备明确超时
• 连续失败后自动启用 Circuit Breaker
• 冷却后通过探测调用恢复
• 超时但没有响应取消的调用继续占用原并发槽
• 取消可以从排队阶段传递到实际执行阶段
• 单个失控的 MCP Server 不会轻易拖垮整个 Agent Runtime

Node.js 与运行环境

本版本增加了 Node.js 运行时检查，避免 better-sqlite3 在 Node.js 24.19+ 的原生清理回归中导致进程崩溃。

推荐使用：

• Node.js 22 LTS
• Node.js 20.18.1 或更高版本
• Node.js 24.18.1

启动前会主动检查不兼容版本，并给出明确提示。

与上一版本的区别

上一版本主要解决了：

• 长任务消息连续性
• 上下文压缩后的调查状态恢复
• 图片与附件工作流
• 大型工具输出管理
• Finding 证据约束
• MCP Server 故障隔离
• 归档会话恢复

v0.1.1-alpha.1 进一步解决了多个 Agent 如何在同一调查中持续协作：

• 任务从临时派发变为持久化工作项
• 子 Agent 可以反复领取后续任务
• 主子 Agent 可以双向通信
• 兄弟 Agent 可以通过公共事实协作
• 任务和消息可以跨压缩、暂停和重启恢复
• 旧执行结果不会污染新的执行批次
• 用户可以直接查看和干预任务板状态

这是一次围绕多 Agent 协作、任务连续性和运行时可靠性的架构增强。

Benchmark

当前公开 Benchmark 成绩：

• Tsecbench v1：93.47 分，榜单第五名
• CyBench：40/40，完成率 100%，综合得分 100
• XBOW Validation Benchmarks：101/104，完成率 97.1%，综合得分 96.96

Benchmark 只能衡量部分能力。v0.1.1-alpha.1 的主要改进集中在多 Agent 协作、共享状态、长时间运行、上下文压缩、故障恢复和人机协作体验。

RiftX 仍处于 Alpha 阶段，欢迎试用、提交 Issue，并分享真实任务中的使用反馈。

v0.1.0-alpha.3

RiftX v0.1.0-alpha.3 — Context Continuity & Runtime Recovery

RiftX 的第三个公开 Alpha 版本正式发布。

alpha.2 改进了图片与附件、长会话消息同步、调查状态恢复和外部工具隔离。alpha.3 继续围绕长任务运行展开，重点处理上下文压缩、执行进度保存，以及工具超时后的恢复与退出。

任务运行得越久，越需要明确回答三个问题：已经做了什么，接下来做什么，以及某一步失败后系统该如何处理。

把确定性留给系统，把不确定性交给模型。

核心更新

上下文压缩与失败恢复

alpha.3 修复了长工具回合中的压缩预算计算错误，并完善了自动压缩的失败处理：

• 修复将待摘要内容误计为保留内容的问题，避免摘要输出额度被错误压低，极端情况下仅剩 1 token
• 根据 SDK 实际保留的历史计算预算，纳入固定上下文、连续性状态和文件引用的开销
• 同时检查摘要请求本身与压缩后上下文的容量，为后续模型回复预留空间
• 最近历史以模型上下文窗口的 10% 为保留目标，实际切分遵守工具调用边界
• 预算不足、摘要不完整或输出被截断时，保留原始历史
• 新消息发送前、回合中途、回合结束和上下文溢出恢复共享自动压缩失败退避
• 压缩失败时向界面提供诊断信息，避免仅出现压缩状态短暂闪烁
• 修正压缩结束后的运行状态展示，区分继续执行与任务空闲

这些改动针对可导致“压缩立即结束、任务停止、再次发送仍重复触发”的已复现路径，同时保留失败现场，便于继续诊断模型或服务端异常。

任务连续性与执行检查点

在 alpha.2 的 Investigation Capsule 基础上，alpha.3 增加了显式执行检查点工具 checkpoint_progress。

Agent 可以在阶段切换或完成一批子任务后记录：

• 当前任务目标
• 已完成的工作
• 已排除的方向
• 尚待验证的事项
• 下一步具体探测
• 关键证据与文件引用

检查点可以从持久化的会话记录中恢复，并在上下文压缩后重新注入。

同时，连续性状态采用统一的替换与排序逻辑，减少多次压缩后重复插入、旧状态残留或关键状态遗漏的问题。

这是一份有长度限制的执行记录。检查点中的结论仍需要通过关联证据验证。

浏览器状态连续性

调查胶囊现在可以携带轻量级浏览器状态，帮助 Agent 在压缩后重新定位正在进行的调查：

• 当前使用的身份
• 已打开页面及其 URL
• 各身份的活动页面
• 最近网络请求的引用、方法、URL 和状态码
• 已配置的主机映射
• 最近截图的引用

这让 Agent 在恢复任务时，可以沿着已有页面、请求和证据继续验证，减少重复导航和重新寻找线索。

工具超时与运行时恢复

alpha.3 将超时控制扩展到更多容易长时间等待的环节：

• 本地文件读取、搜索、列举、写入与编辑
• Web 搜索与页面抓取
• DNS 解析、响应正文读取和重定向检查
• Browser Tool 操作
• Finding 记录与部分长输出持久化流程

浏览器操作超时后，会尝试清理对应页面或浏览器上下文，并保留授权范围设置。

浏览器关闭过程本身也增加了时间限制。如果无法确认旧上下文已经销毁，系统会明确报告异常并限制继续使用，避免在可能仍存活的资源旁启动新的浏览器实例。

MCP 排队与连接回收

在 alpha.2 已有的并发限制、调用超时和熔断机制基础上，alpha.3 进一步处理了排队与清理阶段的等待问题：

• 排队时间纳入调用的总超时预算
• 并发槽被无响应调用占用时，后续请求也能按时返回失败
• 超时连接会被标记为不可复用，并尝试关闭
• 连接关闭与连接失败后的清理均有时间限制
• 后续重新打开会话时，可以重新建立连接

原有的并发槽保护继续保留：底层调用尚未结束时，不会仅因上层超时就立即释放槽位，避免不断累积仍在执行的调用。

上下文用量显示

上下文占用现在明确区分两类来源：

• 模型服务返回的 Token 用量
• RiftX 根据当前上下文计算的估算值

估算值在界面中使用 ≈ 标识，并在详情中说明来源。

估算会结合固定上下文、工具定义和历史消息，并参考模型服务返回的实际输入用量进行校准。压缩后的用量计算也会考虑保留历史和待恢复的连续性状态，减少显示数值与后续请求开销之间的偏差。

附件展示与模型配置

alpha.3 对已有交互流程进行了进一步整理：

• 用户消息中的文本附件以文件名标签展示，减少大段附件内容挤占聊天界面
• 展示调整保留发送给模型和持久化记录中的原始附件内容
• 模型配置新增 max、ultra 思考等级选项
• 完善新等级在会话初始化、模型切换与切换失败回滚时的映射

思考等级是否生效，仍取决于所选模型与服务接口的支持情况。

回归验证

本次新增与完善的回归用例覆盖了：

• 长工具回合中的摘要预算计算
• 多轮压缩后的历史重建
• 回合中途压缩后继续执行工具并完成回复
• 上下文溢出恢复后继续运行
• 压缩成功后接收下一条用户消息
• 压缩失败时保留原始历史
• 不同自动压缩入口共享失败退避
• 摘要截断、预算不足与主动取消
• 连续性状态的有序恢复与去重
• 压缩失败诊断在界面中的展示

其中，压缩恢复测试使用真实 SDK 与 Agent 循环，配合模拟模型响应验证执行过程。

与 alpha.2 的区别

alpha.2 主要补齐了长任务中的信息输入、状态恢复和证据管理：

• 图片与附件进入 Agent 工作流
• 会话重连后的消息同步
• Investigation Capsule
• 长工具输出 Artifact
• Finding 证据约束
• MCP 调用隔离与归档会话恢复

alpha.3 进一步处理这些能力在运行边界上的行为：

• 压缩预算是否足够生成完整摘要
• 压缩后是否能够继续执行
• 压缩失败是否会反复触发
• 当前进度和下一步操作是否能够恢复
• 工具排队、网络读取和资源清理是否能够及时结束
• 界面是否准确表达上下文用量和失败状态

这是一次围绕上下文连续性、故障处理和运行状态可见性的增量更新。

Benchmark

本次新增公开记录 Tsecbench v1 成绩，已有 CyBench 与 XBOW 成绩保持不变。

Benchmark 成绩 Tsecbench v1 | 93.47/100，榜单第 5 名；使用 deepseek-flash 模型配置

Benchmark 衡量的是特定测试条件下的表现。alpha.3 的主要改进集中在压缩后的任务连续性、工具等待边界与失败诊断，这些能力还需要在更多真实长任务中持续验证。

RiftX 仍处于 Alpha 阶段，欢迎试用、提交 Issue，并分享真实任务中的使用反馈。

v0.1.0-alpha.2

RiftX v0.1.0-alpha.2 — Long-Running Reliability & Multimodal Workflow

RiftX 的第二个公开 Alpha 版本正式发布。

如果说 alpha.1 完成了多 Agent、Browser Tool、攻击面发现、证据记录和 MCP Client 的基础框架，那么 alpha.2 的重点，是让这套框架在持续数小时的真实任务中更加稳定、连续，也更方便人与 Agent 交换信息。

把确定性留给系统，把不确定性交给模型。

核心更新

图片与附件

用户现在可以向 Agent 提供更完整的上下文：

• 支持上传图片与常见文本、代码、配置文件
• 支持通过 Ctrl/Cmd + V 直接粘贴截图
• 图片在发送前提供缩略图预览
• 浏览器截图可直接显示在工具卡片中，并支持点击放大
• 非多模态模型会明确拒绝图片输入，避免模型“没有看到图片”却继续回答
• 发送失败时自动恢复附件，便于重新提交
• 附件按 Session 隔离，不会在不同会话间串联

图片在会话快照中使用内容哈希引用，避免长对话反复传输大体积 Base64 数据。

长任务与上下文连续性

alpha.2 重点改进了长时间运行任务中的状态一致性：

• 修复重连后回复已经生成、但页面没有及时显示的问题
• 终态事件到达时主动与持久化消息快照对账
• 为每次发送引入独立 requestId，避免连续 steer、跨会话事件或网络错误互相误判
• 改进上下文临界状态下的 mid-turn compaction
• 压缩后自动恢复关键调查状态，不要求 Agent 从零回忆
• 防止断线、刷新或快速响应造成重复用户消息和附件丢失

Investigation Capsule

新增轻量级调查胶囊，用于在上下文压缩后维持任务连续性。

胶囊会从 RiftX 已持久化的数据中重建：

• 已确认的安全发现
• 尚待验证的假设
• 已排除或关闭的方向
• 已知资产
• 正在运行或已经完成的子任务
• 长工具输出的本地 Artifact
• 下一步需要继续验证的事项

它不是第二套 Planner，也不依赖额外模型生成记忆，而是从现有证据、Finding 和 SubAgent 状态中确定性恢复上下文。

更严格的证据约束

Finding 系统进一步收紧了“确认漏洞”的条件：

• confirmed Finding 必须关联可解析的工具、请求或截图证据
• record_finding 和 spawn_subagent 的确认信息不能作为漏洞本身的证据
• 工具证据会从真实会话 Transcript 中解析并绑定
• 缺少有效证据的结论只能保留为 likely 或 suspected

这让“模型认为存在漏洞”和“系统已经验证漏洞”之间有了更清晰的边界。

长工具输出管理

大量输出不再被完整塞入模型上下文：

• 短输出继续直接返回
• 长输出保存为本地 Artifact
• 模型只接收有界的头尾预览及文件路径
• Agent 可通过 read、grep 按需检查完整结果
• 单文件和每个 Session 的 Artifact 数量均有上限
• 主 Agent 与子 Agent 的 Artifact 分目录保存

该能力已接入 Crawl、MCP 和 Web 工具输出，有助于避免大型扫描结果、接口清单和页面内容快速耗尽上下文。

MCP 调用稳定性

alpha.1 已经支持 MCP Client；alpha.2 进一步强化了实际运行时的隔离能力：

• 每个 MCP Server 独立限制并发调用
• 单次调用具备明确超时
• 连续失败后自动打开 Circuit Breaker
• 冷却后通过探测调用恢复
• 超时但不响应取消的调用继续占用原有并发槽，避免累积僵尸调用
• 调用取消可以从排队阶段一直传递到实际执行

一个失控或失联的外部 MCP Server 不再轻易拖垮整个 Agent Runtime。

Session 管理

• 已归档 Session 现在可以恢复
• 恢复操作不会删除原始会话数据
• 工作目录不匹配或数据缺失时会明确说明不可恢复原因
• 改进 WebUI 重启、SSE 断线和重新进入旧会话后的消息同步
• 系统提示词不再要求每次任务都默认生成渗透测试报告；完成时只提示可以继续生成报告

Skills 扩展

内置推荐安全 Skills 从 22 个扩展到 36 个，新增或加强：

• Authentication Bypass
• IDOR
• OAuth / JWT
• Race Conditions
• Request Smuggling
• Cache Poisoning
• WebSocket
• CSRF
• Host Header
• Prototype Pollution
• WAF Bypass
• Business Logic
• Information Disclosure
• Development Surface Exposure
• Java Deserialization、JNDI、XXE 与 EL Injection
• API Gateway、GraphQL 与 JavaScript Reverse Analysis

这些 Skills 仍然是按任务需要动态加载，而不是一次性全部占用上下文。

与 alpha.1 的区别

alpha.1 解决的是“RiftX 能否作为一个完整的安全 Agent 工作台运行”：

• 多 Agent 协作
• Browser Tool
• Crawl
• Finding 与证据记录
• MCP Client
• 本机会话与审批机制

alpha.2 解决的是“这套工作台能否更稳定地完成几个小时的真实任务”：

• 长会话消息不丢失
• 上下文压缩后调查状态可恢复
• 图片与附件能够进入 Agent 工作流
• 大型工具输出不会淹没上下文
• 已确认漏洞必须绑定真实证据
• 外部 MCP Server 故障不会拖垮整个 Runtime
• 归档会话可以重新恢复使用

这是一次以稳定性、上下文效率和证据可信度为核心的增量版本，而不是对 alpha.1 架构的重新设计。

Benchmark

当前公开的 Benchmark 成绩保持不变：

• CyBench：40/40，完成率 100%，综合得分 100
• XBOW Validation Benchmarks：101/104，完成率 97.1%，综合得分 96.96

Benchmark 只能衡量部分能力。alpha.2 的主要改进集中在长时间运行、上下文压缩、故障恢复、证据约束和人机协作体验，这些能力更接近 RiftX 在真实安全测试任务中的运行条件。

RiftX 仍处于 Alpha 阶段，欢迎试用、提交 Issue，并分享真实任务中的使用反馈。

v0.1.0-alpha.1

RiftX v0.1.0-alpha.1 — First Public Release

RiftX 的第一个公开版本正式发布。

RiftX 是一个面向授权 Web 安全测试的本机多 Agent 工作台。它尝试为当前模型提供一个适合渗透测试任务的运行环境：保留模型原生的探索与推理能力，同时由系统负责工具执行、并发调度、浏览器控制、权限审批、上下文管理和证据留存。

把确定性留给系统，把不确定性交给模型。

核心能力

多 Agent 协作

• 主 Agent 可以并行派出多个后台子 Agent
• 子 Agent 拥有独立线程、BrowserContext 和审批流程
• 支持并发限制、任务排队、增量日志、取消、重试和结果恢复
• 主 Agent 可在子任务运行期间继续推进主线，并及时接收完成结果

为渗透测试设计的 Browser Tool

• 基于 Playwright 和真实 Chromium
• 使用适合非多模态模型读取的页面快照与稳定元素引用
• 支持页面交互、JavaScript 执行、Console、截图和多标签页
• 支持请求详情、响应正文、Cookie、Storage 和身份隔离
• 支持 Host Mapping、Host Header、TLS SNI、自签名证书及内网场景
• 能够通过 DOM、网络请求和浏览器状态完成大量不依赖视觉理解的验证任务

攻击面发现

内置 crawl 工具，可从已知入口继续提取：

• 页面链接与表单
• 隐藏字段
• JavaScript Bundle 中的 API 路由
• SPA 接口线索
• 登录墙与认证边界
• 跨主机线索

证据驱动的发现记录

安全发现可以关联：

• 工具调用
• HTTP 请求与响应
• 页面截图
• 原始文本摘录
• 影响、置信度与复现步骤

结论不再只是 Agent 的一段描述，而能够回到产生它的原始证据。

MCP Client

RiftX 可以连接外部 MCP Server，并将其工具提供给主 Agent 和子 Agent：

• 支持 stdio 与 Streamable HTTP
• 支持直接粘贴常见 Claude/Cursor MCP 配置
• MCP 工具接入统一审批流程
• 支持连接测试、连接复用、生命周期管理与死连接重连

本机优先

• 不需要数据库
• 不需要 RiftX 云账户
• 会话、配置、Skill 和证据保存在 ~/.riftx/
• 支持 OpenAI、Anthropic、Google 及兼容 API 端点
• 默认只监听 127.0.0.1

Benchmark

RiftX v0.1.0 在两个安全验证 Benchmark 上取得了以下结果：

• CyBench：40/40，完成率 100%，综合得分 100
• XBOW Validation Benchmarks：101/104，完成率 97.1%，综合得分 96.96

Benchmark 只能衡量部分能力，但这些结果至少证明：RiftX 已经能够支撑持续、多步骤、需要浏览器与工具协同的安全验证任务。