内容
# NodeBench AI
实体智能，适用于任何公司、市场或问题。
**在线访问：** [nodebenchai.com](https://www.nodebenchai.com)
**npm 安装：** `npx nodebench-mcp` / `npx nodebench-mcp-power` / `npx nodebench-mcp-admin`
**GitHub 地址：** [HomenShum/nodebench-ai](https://github.com/HomenShum/nodebench-ai)
## 产品概述
NodeBench 是一个围绕五个用户界面构建的研究和报告产品：
- `首页` = 快速开始
- `报告` = 可重复使用的记忆
- `聊天` = 执行任务
- `收件箱` = 捕获、提醒、自动化和未分配的审查
- `我` = 操作员上下文和控制
深入研究在单独的 `nodebench.workspace` 界面中打开；它不是第六个选项卡。
核心思想很简单：
用户不仅需要一个只能回答一次的聊天机器人。
他们需要一个可以：
- 接纳问题、文件、URL 或之前的线程
- 搜索和综合来源
- 将运行结果变成可重复使用的产物
- 监测有意义的变化
- 从学习中改进下一次运行
## 已实现功能
- 跨 `首页`、`报告`、`聊天`、`收件箱` 和 `我` 的五界面网页应用
- 在 `nodebench.workspace` 的独立深工作空间
- 类型搜索和报告管道
- 外部应用和代理的托管公共研究 MCP：`https://nodebench-mcp-unified.onrender.com?profile=public-research`
- `报告` 上的 Pi-AI 管道，带有代码生成、设计生成、研究、复合运行、计划、流媒体预览、评估记分卡和 MCP HTTP 桥
- 实时 SSE 流与保存的运行时状态
- Convex 支持的会话、报告、实体、提醒、文件和相关对象的产品状态
- 共享上下文交接和委托管道
- 搜索、流媒体、语音和共享上下文路由的本地和部署服务器运行时
- `nodebench-mcp`、`nodebench-mcp-power` 和 `nodebench-mcp-admin` 分发通道
- 面向构建者的 Oracle、试用、评估、重放和控制平面基础设施
## 托管公共研究 MCP
NodeBench 可以作为公共研究记忆和工具服务器，供任何代理或应用使用，无需在获得有用的结果之前进行注册。
使用托管的 MCP 端点：
```txt
https://nodebench-mcp-unified.onrender.com?profile=public-research
```
对于 Gmail/job-match 风格的集成，请使用较小的配置文件：
```txt
https://nodebench-mcp-unified.onrender.com?profile=gmail-research
```
公共配置文件默认情况下是匿名的，但仍然有计量。响应包括：
```txt
x-nodebench-request-id
x-nodebench-profile
x-nodebench-auth-mode
x-nodebench-account-key
```
应用应发送稳定的、非敏感的客户端标头：
```http
x-nodebench-client: your-app-name
x-nodebench-client-version: 1.0.0
x-nodebench-client-id: stable-install-or-workspace-id
```
`x-nodebench-client-id` 允许 NodeBench 在不要求 NodeBench 代币的情况下归因匿名使用和估计成本。不要在该标头中放置私人电子邮件文本、简历文本、API 密钥或用户机密。
### 渐进式登录和链接
预期的用户流程是：
```text
第一个公共档案在无需注册的情况下生效
-> 显示来源、新鲜度和置信度
-> 在可见值后提供“链接 NodeBench”
-> 链接用户获取稳定的历史记录、更高的预算、团队使用、Webhook、令牌管理和计费控制，以及可重复使用的私有工作区上下文
```
不要在登录之前阻止公共来源研究。在用户需要持久性、共享团队内存、预算控制、私有工作区链接或 API/MCP 代币时，促进登录。
参见 [MCP_TOOL_PROFILES.md](./docs/guides/MCP_TOOL_PROFILES.md)，了解完整的配置文件列表、工具目录、帐户归因和成本跟踪合同。
## 产品概览
```text
用户界面
-------------
首页 -> 快速开始
报告 -> 可重复使用的报告内存
聊天 -> 回答、来源、跟踪、后续跟进
收件箱 -> 捕获、提醒、自动化、警报、未分配的项目
我 -> 操作员上下文、权限、控制
后端
-------
Convex 表格和产品状态，用于会话、报告、实体、提醒、文件、共享上下文和评估产物
运行时
-------
搜索管道
-> 回答数据包
-> 保存的报告
-> 跟踪的实体 / 跟踪的主题 / 后续任务
-> 提醒或准备简报
-> 继续聊天或重新打开报告
复合循环
----------------
问题
-> 答案
-> 保存的报告
-> 监视项目
-> 有用的提醒
-> 更好的下一次运行
分发
------------
nodebenchai.com
nodebench.workspace
nodebench-mcp
nodebench-mcp-power
nodebench-mcp-admin
```
## 事件智能服务模型
事件服务扩展了主应用和 MCP 运行时使用的相同预算搜索路由。 NodeBench 将搜索视为构建内存的操作，并带有预算。对于事件，NodeBench 在进行实时搜索之前检查事件语料库和工作区内存，然后将有用的结果保存为实体、主张、来源和工作区上下文。
ScratchNode 是适用于此模型的轻量级实时事件侧车：一个可丢弃的房间，它将公共聊天和来源的 `/ask` 答案转换为公共 Wiki，同时保持与会者笔记的私密性。它补充了 Luma、Slack、Eventbrite 等其他事件表面，而不是取代它们；显式交接到 NodeBench 打开 `https://nodebenchai.com/events/:eventSlug/private`，并带有私人笔记继续上下文和没有 URL 带来的 `ownerKey`。
事件流程是：
```text
活动前
-> 构建事件语料库
活动期间
-> 即时捕获杂乱的笔记
活动后
-> 将捕获的内容转化为报告、卡片、后续跟进和可重复使用的记忆
```
产品模型是：
```text
ScratchNode 侧车房间 + 公共事件语料库 + 私有 NodeBench 继续
```
事件语料库和捕获数据保持分离：
- `共享事件语料库` = 公共事件信息、演讲者、赞助商、公司页面、会话和公共来源缓存。
- `私有捕获` = 用户个人听到的、写下的、录制的或拍摄的内容； ScratchNode 私有笔记从不进入公共动态、公共 Wiki 或公共 `/ask` 缓存。
- `团队/组织内存` = 仅在基金、公司或工作区内共享。
- `事件聚合洞察` = 选择加入或匿名。
在活动期间，大多数捕获应该首先进入事件语料库，避免付费搜索：
```text
语音备忘录 / 文本 / 截图
-> 捕获路由器
-> 活动事件语料库
-> 实体和主张提取
-> 活动会话附件
-> 预算政策
-> 确认 + 下一步
```
示例移动确认：
```text
保存到 Ship Demo Day 会话
检测到 1 人 | 1 家公司 | 2 个主张 | 1 个后续跟进
使用事件语料库 | 0 次付费调用
```
活动结束后，报告在 `nodebench.workspace` 中打开：
```text
简报 -> 活动后备忘录
卡片 -> 人、公司、产品、主题
笔记本 -> 原始笔记、转录、截图 OCR、清理笔记
来源 -> 实地笔记、公共证据、验证状态
聊天 -> 后续问题和更深入的刷新
地图 -> 图形视图
```
规范文档位于 [EVENT_INTELLIGENCE_SERVING_MODEL.md](./docs/architecture/EVENT_INTELLIGENCE_SERVING_MODEL.md)。 ScratchNode/NodeBench 隐私边界位于 [SCRATCHNODE_NODEBENCH_BOUNDARY.md](./docs/architecture/SCRATCHNODE_NODEBENCH_BOUNDARY.md)。
## 为什么采用这种设计
NodeBench 的设计围绕几个产品现实情况：
1. 有用的答案不应该在一次聊天后消失。
2. 保存的工作应该成为可重复使用的记忆，而不是死亡的存档行。
3. 产品应该在有意义的事情发生变化时，只需将用户带回。
4. 系统应该在不强制进行大量注册流程的情况下，逐渐了解用户的工作方式。
5. 操作员上下文应该在不将系统变成公司口语或虚假同意泥浆的情况下，改善未来的运行。
这推动了当前的设计：
- 答案优先的执行
- 通过动态路由设计顾问模式：
- 常规工作的快速执行通道
- 用于模糊性、规划和更复杂的推理的更深入的顾问通道
- 与 Claude Code 的官方 `opusplan` 分裂类似：更强的规划通道，更便宜的执行通道
- 保存的产物作为一等公民对象
- 可见的来源和可追溯性
- 五页循环而不是五个无关的选项卡
- 未来的 `Harness v2` 工作重点关注规范、操作员上下文和复合行为
用大白话来说：
```text
NodeBench 不应该在每个请求上花费最昂贵的推理路径。
它应该默认快速移动，然后在任务、证据或用户请求需要时深入研究。
```
详细实施、验证和评估计划的文档位于：
- [HARNESS_V2_PROPOSAL.md](./docs/architecture/HARNESS_V2_PROPOSAL.md)
- [HARNESS_V2_BUILD_PLAN.md](./docs/architecture/HARNESS_V2_BUILD_PLAN.md)
## 五个页面如何复合
NodeBench 不应该感觉像五个独立的目的地。
预期的产品行为是：
```text
首页
-> 快速开始
报告
-> 将该产物变成可重复使用的记忆
聊天
-> 执行任务
-> 创建第一个有用的产物
收件箱
-> 分类捕获、提醒、自动化、警报和未分配的项目
我
-> 改进下一个运行的处理方式
工作区
-> 打开深入的简报 / 卡片 / 笔记本 / 来源 / 聊天 / 地图工作
-> 位于 nodebench.workspace，不在操作选项卡栏中
下一个首页或聊天运行
-> 从比以前更多的上下文开始
```
最短的复合循环版本是：
```text
问题
-> 答案
-> 保存的报告
-> 监视项目
-> 有用的提醒
-> 更好的下一次运行
```
用白话解释产物流程：
```text
输入
-> 答案数据包
-> 保存的报告
-> 跟踪的实体 / 跟踪的主题 / 后续任务
-> 提醒或准备简报
-> 继续报告或继续聊天
-> 用户纠正或确认
-> 更新的操作员上下文
-> 更好的下一次运行
```
每个页面贡献的内容：
- `首页` 以尽可能少的摩擦启动运行
- `报告` 将这些转化为用户可以重新打开、刷新和重用的持久报告
- `聊天` 创建答案、来源、跟踪、实体和后续行动
- `收件箱` 收集提醒、捕获、自动化、警报和未分配的项目
- `我` 存储操作员上下文，改进下一个答案
- `工作区` 拥有递归卡片、笔记本编辑、来源验证和长期智能记忆
## 当前的遗留基础设施
NodeBench 不是从零开始的。存储库中已经包含一个相当可观的遗留堆栈，今天就可以运行。
当前的遗留基础：
- 五界面网页产品
- Convex 支持的规范数据层
- 本地和部署的服务器运行时
- v1 计划和执行路径
- 共享上下文交接和委托支持
- MCP 分发通道
- 面向构建者的评估和控制平面系统
这意味着：
- 问题不是缺少架构
- 问题是产品行为、工作流压缩和更清晰的跨表面复合
## 路线图
近期的目标是:
```text
保持有效的遗留基础
消除不必要的复杂性
添加规范感知操作员上下文
发布一个清晰的复合工作流
```
仍需完成的任务：
- [ ] 使 `首页 -> 报告 -> 聊天 -> 收件箱 -> 我` 表现得像一个连续的工作流，而不是五个相邻的界面
- [ ] 将 v1 升级为更清晰的 v2 形状，详见 [HARNESS_V2_PROPOSAL](docs/architecture/HARNESS_V2_PROPOSAL.md)
- [ ] 发布 `层 0` 操作员上下文，以便系统可以在不强制进行大量注册流程的情况下学习有用的工作流模式
- [ ] 支持来自 NodeBench 聊天的有权限的转录导入，首先是可选的外部日志，如 Claude Code JSONL 转录，用于 `nodebench-mcp`
- [ ] 添加风格漂移防护措施，以便系统在不拟合公司语音、填充物或谄媚的情况下学习判断和工作流
- [ ] 添加预测准备行为，以便系统可以在重要的交互发生之前准备用户，而不是仅仅在事后回答
- [ ] 使保存的报告表现得像可重复使用的内存，而不是存储
- [ ] 保留 `提醒` 作为收件箱部分，至少有一个日常触发器生效
- [ ] 使 `我` 清晰地通过显示正在使用的上下文及其原因来改进未来的运行
- [ ] 完成 `nodebench-mcp` v3 切割和分割计划，以便默认运行时、强力运行时和管理员运行时清晰分离
- [ ] 测量实时延迟、实际成本、实际产物完成度和跨网页和 MCP 流的实际重用
- [ ] 保持 README、运行时行为和公开的工具数量同步，以便公共故事与实际系统保持一致
- [ ] 保持试用、评估和构建者控制基础设施作为内部杠杆，而不是让它泄漏到主要的面向用户的产品中
## 快速入门
### 网页应用
打开 [nodebenchai.com](https://www.nodebenchai.com) 并在 `首页` 开始。
### MCP
```bash
# Claude Code
claude mcp add nodebench -- npx -y nodebench-mcp
# Claude Code 强力通道
claude mcp add nodebench-power -- npx -y nodebench-mcp-power
# Claude Code 管理通道
claude mcp add nodebench-admin -- npx -y nodebench-mcp-admin
# Cursor
npx nodebench-mcp --preset cursor
# 通用 MCP 客户端
npx nodebench-mcp
```
### 本地开发
```bash
git clone https://github.com/HomenShum/nodebench-ai.git
cd nodebench-ai
npm install
cp .env.example .env.local
# 前端 + Convex + 语音服务器
npm run dev
# 生产构建
npm run build
```
## 架构
```text
nodebenchai.com (React + Vite + Tailwind)
|
Convex 云（会话、报告、实体、提醒、文件、产品状态）
|
服务器运行时 + 搜索管道 + SSE
|
答案数据包
|
保存的报告
|
跟踪的实体 / 监视条件 / 提醒
|
未来的运行，更好的操作员上下文
```
## 学生学习课程
存储库中的笔记本和勤勉堆栈是常见的产品工程权衡的示例：
- 最好的用户体验是一个连续的笔记本，让人感觉连续
- 当前最安全的运行时仍然是分层且可寻址的底层
对于 NodeBench，这意味着：
- `创始人` 是一个特征和勤勉块，而不是永久的第六个选项卡
- 勤勉应该使用一个通用管道，而不是许多狭窄的 `*Identify.ts` 功能
- 运行时应保持 `scratchpad-first -> structuring pass -> deterministic merge`
- 用户拥有的散文应该感觉本地优先和冷静的打字体验
- 实时代理输出应首先作为叠加层或装饰出现，而不是直接文档突变
- 接受的代理输出应该成为冻结的、用户拥有的笔记本内容
- 凭证应该保持可用，但次于阅读和写作流程
为什么笔记本 **不** 使用一个巨大的实时编辑器模型：
- 协作在系统可以寻址有限部分时更可靠
- 溯源、证据和贡献日志需要稳定的附件点
- 背景代理更新不应与用户按键竞争
- 确定性分段级合并比整个页面突变变化更容易推理
存储库中的实用规则是：
```text
UX 应该感觉是整体的。
运行时应保持分层。
打字应该本地优先。
代理输出应该优先作为叠加层。
接受的输出应该成为所有者的散文。
```
当前的笔记本重构课程：
- 在阅读路径中隐藏块机械
- 保持 Chrome 安静并将元数据移至悬停或焦点
- 将笔记本表面与页面级重新渲染变化隔离
- 优先使用一个 memoized 笔记本边界而不是许多内联对象道具
- 将实时勤勉作为只读参考叠加，直到用户接受它
- 当接受时，物化冻结的笔记本快照，具有明确的溯源
- 将实时叠加层锚定在笔记本表面，而不是在第一个可编辑行中
- 让 Convex 投影行携带真正的源元数据，以便 UI 不被迫从散文本身重建信任状态
- 使用一个通用的叠加层生产者：报告写入相同的结构化行，页面加载回填和手动刷新重新运行
- 移动到报告支持的叠加层时，仅在二级轨道流原始草稿，并发出结构化投影行而不是将草稿文本转入笔记本主体
- 如果结构来自 LLM，保持块范围和模式绑定：`草稿检查点 -> JSON -> 验证/修复 -> 确定性回退 -> 投影行`
- 让模型结构中间 JSON，但保持合并、持久性和笔记本所有权确定性
- 发布通用勤勉原语，然后块特定渲染器
对于学生阅读代码，最相关的文档是：
- [`AGENT_PIPELINE`](docs/architecture/AGENT_PIPELINE.md)
- [`DILIGENCE_BLOCKS`](docs/architecture/DILIGENCE_BLOCKS.md)
- [`SCRATCHPAD_PATTERN`](docs/architecture/SCRATCHPAD_PATTERN.md)
- [`PROSEMIRROR_DECORATIONS`](docs/architecture/PROSEMIRROR_DECORATIONS.md)
- [`SESSION_ARTIFACTS`](docs/architecture/SESSION_ARTIFACTS.md)
### 关键技术
- 前端：React，Vite，TypeScript，Tailwind CSS
- 后端：Convex
- 搜索：Linkup + Gemini 提取 + 接地管道
- MCP 服务器：Node.js + TypeScript
- 实时运行时：SSE + Convex 支持的持久性
API 密钥
在 `.env.local` 中设置本地开发环境变量，或在 Convex / Vercel 中设置部署环境变量。
| 密钥 | 是否必需 | 用途 |
| --- | --- | --- |
| `GEMINI_API_KEY` | 是 | 分类、提取、合成 |
| `LINKUP_API_KEY` | 推荐 | 网络搜索和来源答案 |
| `VITE_CONVEX_URL` | 是 | Convex 部署 URL |
## 代码库映射
前 3 级，带注释。有关管道图，请参阅 [`ARCHITECTURE.md`](ARCHITECTURE.md)，有关 13 个规范文档，请参阅 [`docs/architecture/README.md`](docs/architecture/README.md)。
```text
nodebench-ai/
├── README.md ← 你在这里
├── ARCHITECTURE.md ← 顶级管道图
├── CONTRIBUTING.md ← 贡献栏
├── CLAUDE.md ← 本仓库的克劳德代码约定
├── AGENTS.md ← 代理方法 + 评估基准
├── LICENSE ← MIT
│
├── src/ ← React 前端（Vite）
│ ├── features/ ← 功能优先，30 个文件夹（首页 · 报告 · 聊天 · 收件箱 · 我 · 工作区 · 实体 · 代理 · …）
│ │ └── <feature>/ ← 视图 · 组件 · 钩子 · 库 · __tests__（共存）
│ ├── shared/ ← 共享 UI 原语、钩子、实用程序
│ ├── lib/ ← 注册表、分析、错误报告
│ └── layouts/ ← 外壳 + 驾驶舱 + 公共
│
├── server/ ← 节点运行时（Express + MCP 网关）
│ ├── pipeline/ ← 代理运行 勤勉块
│ ├── routes/ ← HTTP 路由（搜索、运行、创始人剧集）
│ mcpGateway.ts ← WebSocket MCP 网关
│ └── services/ ← 共享服务
│
├── convex/ ← Convex 后端
│ ├── domains/ ← 19 个领域文件夹（代理 · 产品 · 研究 · 创始人 · 搜索 · …）
│ ├── schema.ts ← 数据库模式（包括 agentScratchpads）
│ └── crons.ts ← 调度作业
│
├── packages/
│ ├── mcp-local/ ← 已发布的 nodebench-mcp npm 包（MIT）
│ ├── mcp-client/ ← 类型客户端 SDK
│ └── convex-mcp-nodebench/ ← Convex 端 MCP 审计器
│
├── .claude/
│ ├── README.md ← .claude/ 布局映射
│ ├── rules/ ← 31 个模块化规则，相关引用
│ ├── skills/ ← 可重用的操作规程
│ ├── agents/ ← 子代理配置
│ └── commands/ ← 自定义斜杠命令
│
├── docs/
│ ├── README.md ← 文档树映射
│ ├── ONBOARDING.md ← 30 分钟新贡献者路径
│ ├── architecture/ ← 13 个规范 + 计划/ + README 索引
│ ├── agents/ ← 代理文档 + 引导配置
│ ├── guides/ ← 构建者操作指南
│ ├── decisions/ ← ADRs
│ ├── changelog/ ← 发布说明
│ ├── product/ ← 产品决策
│ ├── qa/ ← QA 协议
│ └── archive/ ← 废弃内容，仅保留出处
│
├── tests/
│ ├── e2e/ ← Playwright 端到端
│ └── fixtures/ ←固定装置
│
├── scripts/ ← 自用、评估运行、一次性脚本
├── public/ ← Vite + Vercel 提供静态资产
└── vendor/ ← 第三方引用
```
## 相关文档
**从这里开始：** [`docs/ONBOARDING.md`](docs/ONBOARDING.md) · [`ARCHITECTURE.md`](ARCHITECTURE.md) · [`docs/architecture/README.md`](docs/architecture/README.md)
13 个规范文档分为 4 层。有关索引地图，请参阅 [`docs/architecture/README.md`](docs/architecture/README.md)：
- **第 1 层（核心管道）：** [`AGENT_PIPELINE`](docs/architecture/AGENT_PIPELINE.md) · [`DILIGENCE_BLOCKS`](docs/architecture/DILIGENCE_BLOCKS.md) · [`USER_FEEDBACK_SECURITY`](docs/architecture/USER_FEEDBACK_SECURITY.md)
- **第 2 层（子模式）：** [`SCRATCHPAD_PATTERN`](docs/architecture/SCRATCHPAD_PATTERN.md) · [`PROSEMIRROR_DECORATIONS`](docs/architecture/PROSEMIRROR_DECORATIONS.md) · [`AGENT_OBSERVABILITY`](docs/architecture/AGENT_OBSERVABILITY.md) · [`SESSION_ARTIFACTS`](docs/architecture/SESSION_ARTIFACTS.md)
- **第 3 层（功能）：** [`FOUNDER_FEATURE`](docs/architecture/FOUNDER_FEATURE.md) · [`REPORTS_AND_ENTITIES`](docs/architecture/REPORTS_AND_ENTITIES.md) · [`AUTH_AND_SHARING`](docs/architecture/AUTH_AND_SHARING.md)
- **第 4 层（跨切割）：** [`MCP_INTEGRATION`](docs/architecture/MCP_INTEGRATION.md) · [`EVAL_AND_FLYWHEEL`](docs/architecture/EVAL_AND_FLYWHEEL.md) · [`DESIGN_SYSTEM`](docs/architecture/DESIGN_SYSTEM.md)
活动架构补充：
[`GRAPH_SEARCH_AGENT_CONTEXT`](docs/architecture/GRAPH_SEARCH_AGENT_CONTEXT.md)
捕获图/搜索/代理上下文策略、精确产品问题、规模预测、节点注意力模型和人机检索分割。
历史规格保存在 [`docs/archive/2026-q1/`](docs/archive/2026-q1/INDEX.md)。
## 生产就绪性和评估
NodeBench 配备了全面的评估运行程序，证明了在 32+ 个场景、9 个用户角色和 9 个功能类别中的正确性。这不是一种模糊的“有效”——它是经过测量、版本控制和可复制的。
### 最新发布的运行结果
**Pi-AI级联：** 于 2026-04-30 合并到 `main`，版本号为 `2a541037874c0f8c675ab393d5c08f50123cf6d2`。
| 通道 | 结果 |
|------|--------|
| PR 链 | #211 -> #212 -> #213 -> #214 -> #215 -> #216 全部合并 |
| 生产表面 | `https://www.nodebenchai.com/?surface=packets` |
| MCP 网桥 | `https://agile-caribou-964.convex.site/mcp/pipeline/*`，在 `MCP_SECRET` 后 |
| 代码生成运行 | `pipeline_mokobe4y_6n23be` 成功，`verified`，6 个文件，32.9s，约 `$0.001` |
| 研究流媒体 | `pipeline_mokpvi1b_yoj8ot` 完成，4,317 个字符流媒体 |
| Linkup 研究 | `pipeline_mol2wj2j_2lgx2u` 成功，5 个子问题中 18 个片段 |
| 复合管道 | `research_then_code` 完成第 1 阶段研究和第 2 阶段代码生成 |
| 调度工作流 | 一次调度被 cron/manual 清除并在运行后自动禁用 |
| 设计输出 | 设计生成了一个存储在 Convex 存储中的 PNG |
| UI 启动器 | DOM 提交的复合运行更新了反应运行列表 |
| 管道记分卡 | 41.7% 验证，12 次运行中 Brier 0.135 |
实现位于报告界面：
- `PipelineLauncher`
- `PipelineSchedulesPanel`
- `PipelineEvalScorecard`
- `PipelineRunsPanel`
- `EntityFindingsPanel`
详细移交在
[`docs/handoff/PI_AI_PIPELINES_HANDOFF.md`](docs/handoff/PI_AI_PIPELINES_HANDOFF.md)。
**工作流循环评估库：** 于 2026-04-30 添加，用于测试完整产品循环，而不仅仅是答案文本。
```text
查询/捕获
-> 内存搜索
-> 实体解析
-> 报告更新
-> 笔记本更新
-> 图形边缘
-> 源/声明
-> 跟进/导出
```
| 评估库 | 结果 |
|-----------|--------|
| 总工作流案例 | 124 |
| 最小 P0 套件 | 30 个案例 |
| 覆盖类别 | 11 |
| 评分维度 | 12 |
| 验证器 | `src/features/evaluation/data/nodebenchWorkflowEvalBank.test.ts` |
| 最新本地检查 | `npx vitest run src/features/evaluation/data/nodebenchWorkflowEvalBank.test.ts` -> 4/4 通过 |
评估库位于
[`src/features/evaluation/data/nodebenchWorkflowEvalBank.ts`](src/features/evaluation/data/nodebenchWorkflowEvalBank.ts)。
### 两层法官架构
每次生产运行都由两个独立系统评估：
**第 1 层：确定性布尔门** (`server/pipeline/diligenceJudge.ts`)
- 10 个严格的通过/失败检查：层有效性、延迟预算、令牌捕获、
- 裁决：` | `provisionally_verified`needs_review`failed`
- 零 LLM 参与 — 纯确定性验证
**第 2 层：LLM 语义评分** (`server/pipeline/diligenceLlmJudge.ts`)
- 5 个维度评分 [0,1]文质量、性、源可信度、层、整体语义
- 跟踪 (`llge-v1`)分离
-限：30 秒超时，512KB ，诚实
这种双意味着幻觉和质量回归被 **两个独立系统** 捕获，然后再由用户访问。
### 当前生产状态
**最新全栈评估：** `2026-04-23T06:53Z`
```text
总体通过率： 100%
LLM 法官平均值： 9.6/10（目标：≥7 用于生产）
自用分数： 100/100（0 个实际问题）
实体解析 100%
事实准确性： 90.6%
无幻觉： 90.6%
可操作输出： 100%
答案控制： 100% （所有 8 个维度）
功能广度： % （31 个场景）
保留/连续性： 4/4 通过
```
所有生产门 **通过**：
- 通过扩展功能覆盖生产门
- 通过答案控制生产- 通过自用生产门
- 通过笔记本容量生产门
- 通过历史浸泡生产门
**注意：** 唯一未完成项是 p95 延迟优化（174s 与 90s 目标相比）— 性能增强，而不是正确性阻塞。系统 **已准备好生产就绪，适用于所有质量场景**。
### 评估覆盖
**能力评估 — 32 个角色场景**
| 角色 | 示例 状态 |
|---------|---------------|--------|
| JPM 初创银行家 | "DISCO — 是否值得联系？最快的汇报" | 100| 初创风险投资 | "OpenAutoGLM — 什么是契机？" | 100% |
| CTO 技术负责人 | "QuickJS — 我有暴露风险吗？" | 100% |
| 企业高管 | "Gemini 3 — 下一步采购？" |100% |
| 生态系统合作伙伴 | "SoundCloud VPN — 谁受益？" | 100% |
| 创始人战略 | "Salesforce Agentforce — 反向定位？" | 100% |
| 学术研发 | "RyR2/阿尔茨海默症 — 文学锚点？" | 100% |
| 量化分析师 | "DISCO — 提取资金信号" | 100% |
| 产品设计师 | "DISCO — 模式密集 UI 卡 JSON" | 100% |
| 销售工程师 | "DISCO — 随时可分享的总结" | 100% |
**扩展功能广度 — 31 个场景**
| 类别 | 数量 | 通过率 |
|----------|-------| 日历 | 3 | 100%
| 披露 | 100%
| 文档 | 3 | 100%
| 混合 | 4 | 100%
| 媒体 | 3 | 100%
| 技能 | 4 | 100%
| 电子表格 | 3 | 100%
| 工具 | 4 | 100%
| 网络 | 3 | 100%
**答案控制 — 8 个维度**
- 实体解析：100%
- 检索相关性：100%
- 声明支持：100%
- 最终响应质量：100%
- 轨迹质量：100%
行性：
- 工件决策质量：100%
- 模糊恢复：100%
### 如何验证
运行完整生产评估套件：
```bash
# 完整的 8 阶段评估（类型 构建 → 能力 → 扩展 → → 自用 → 笔记本 → 历史）
npm run eval
#验证（3 个场景）
npm run eval:quick-slice
# 单个通道
npm run eval:capability # 32 个角色场景
npm run eval:feature-breadth # 31 个功能场景
npm run eval:retention # 维基连续性套件
```
所有工件都存储在 `docs/architecture/benchmarks/` 中：
- `full-stack-eval-latest.md` — 总体摘要
- `comprehensive-eval-*.md` — 能力结果
- `expanded-eval-*.md` — 功能广度结果
- `product-answer-control-eval-*.md` — 答案控制结果
### 生产就绪的含义
1. **确定性门通过** — 核心正确性
2. **LLM 司法评分 ≥7** — 独立 LLM 验证的语义质量
3. **自用分数 ≥85** — 内部使用显示无实际问题
4. **所有 32 个角色场景通过** — 正确处理不同用户类型
5. **所有 31 个功能** — 覆盖广泛的表面积
6. **保留/连续性通过** — 长期内存有效
7. **答案控制 100%** — 工件决策、模糊恢复可靠
系统满足所有这些条件。剩余的工作只有延迟优化 — 使快速答案更快，而不是使损坏的答案起作用。
### 模型策略
- **主要：** `moonshotai/kimi-k2.6` （OpenRouter）— 100% 能力通过
- **备用：** `gpt-5.4` — 空/缺失汇报的自动重试
- **裁判：** `kimi-k2.6` — 9.6/10 所有场景平均值
Kimi 是主要通道。GPT-5.4 仍然是安全备用，直到 Kimi 的首次稳定性提高，但两个路径都经过生产测试。
## 产品套件
```text
NodeBench AI = 旗舰用户界面
nodebench-mcp = 工作流通道
Attrition.sh = 测量的重放 + 优化通道
```
Attrition 不是第三个旗舰产品。它是同一 NodeBench 工作流的可衡量优化通道。
## 许可证
MIT
MCP 配置
以下是此 MCP Server 的配置信息，可直接复制到 Cursor 或其他 MCP 客户端中使用。
mcp.json
连接信息
猜你喜欢
暂无推荐服务器