Experts.js
用 OpenAI Assistants API 组装可协作的多智能体工具链。
- Star 数
- ★ 1.1k
- 最近更新
- 2 年前
- License
- MIT
- 主语言
- JavaScript
- FA 评分
- 55/100 · 缺口较多
30 秒速览
- 可在哪里用
- 平台专用OpenAI API
- 开始前需要
- 典型场景
- Node.js 团队要在客服或内部应用中调用 OpenAI Assistant，并希望只通过 ask() 获取回答而不处理 Run 对象。
- 主要局限
- 核心设计依赖 OpenAI Assistants API，没有记录其他模型提供商或兼容 API 的适配路径。
这个 Agent 能做什么，适合哪些场景？
Experts.js 是一个 JavaScript 库，以 Assistant、Tool 和 Thread 三个对象封装 OpenAI Assistants API。应用通过 Assistant.create() 创建或加载助手，再以 ask() 向指定 Thread 发送消息并取得输出，无需直接管理 Run 或 Run Step。Tool 是 Assistant 的子类，可由父 Assistant 调用；工具既可以由模型驱动，也可以通过 llm: false 实现自定义 ask()。库默认使用流式事件，并允许监听文本增量、工具调用、运行步骤及异步完成事件。生产部署可为 Assistant 或 Tool 提供 asst_ 格式的 id，以复用远程助手并用本地配置覆盖其配置。
开发者从 experts 导入 Assistant、Tool 和 Thread，先调用 Thread.create() 获得 thread id，再调用 Assistant.create() 创建助手，并执行 assistant.ask(message, threadID)。ask() 接受字符串或原生 OpenAI message 对象，并在内部管理 Run；调用期间可通过 on("textDelta") 等事件接收文本、图像文件和工具调用输出。父 Assistant 通过 addAssistantTool(ToolClass) 注册 Tool；LLM 驱动的 Tool 会把自身响应作为父级工具输出，非 LLM Tool 则必须自行实现 ask(message)。线程关系会写入 OpenAI thread metadata，以便在父子助手之间为 Tool 查找或创建独立线程。
- Node.js 团队要在客服或内部应用中调用 OpenAI Assistant，并希望只通过 ask() 获取回答而不处理 Run 对象。
- 需要把商品目录检索、OpenSearch 查询生成等职责拆分为可由主助手调用的 Tool 的应用开发者。
- Express 服务需要通过 textDelta 事件将助手回复以分块文本流式返回给浏览器。
- 知识库应用需要在 Assistant 配置中使用 file_search 和 vector_store_ids 检索 OpenAI Vector Store 中的文件。
- 需要为不同子工具维持独立上下文、避免父线程等待工具输出时发生线程锁定的多助手系统。
如何安装或部署这个 Agent？
安装：npm install experts。代码中使用 import { Assistant, Tool, Thread } from "experts";。开发环境文档要求创建 .env.development.local，其中包含 OPENAI_API_KEY=sk-... 和 POST_IMAGES_API_KEY=...，然后可运行 ./bin/setup 与 ./bin/test。最小调用为：const thread = await Thread.create(); const assistant = await Assistant.create(); const output = await assistant.ask("Say hello.", thread.id);。
如何使用这个 Agent？
定义 Assistant 子类时向 super() 传入 name、instructions、model、tools 或 tool_resources；默认模型为 gpt-4o-mini。使用 this.addAssistantTool(EchoTool) 把 Tool 加入父助手，且应在 super() 之后调用。要流式处理回复，创建助手后注册 assistant.on("textDelta", (delta) => process.stdout.write(delta.value))，再执行 ask()。部署时把已有的 asst_... id 传入构造选项；如不希望用本地配置更新远程助手，可设定 skipUpdate: true。
这个 Agent 有哪些优点和局限？
- 将 Assistant、Tool 与 Thread 提炼为三个主要对象，并把 Run 管理隐藏在 ask() 接口之后。
- Assistant 可直接作为父助手的函数工具，支持多层工具编排和父子线程关联。
- 提供 textDelta、toolCallDelta、runStepDone、end 及对应异步完成事件，适合流式 UI 和运行指标采集。
- 支持 OpenAI 原生工具配置，包括 file_search、code_interpreter、函数调用和 Vector Store 资源。
- 核心设计依赖 OpenAI Assistants API，没有记录其他模型提供商或兼容 API 的适配路径。
- 每个问题都需要 thread ID；应用仍需负责保存聊天场景中的线程标识。
- LLM Tool 的函数名必须在父助手全部工具名中唯一，命名冲突会影响调用。
- 流式 SSE 事件不适合直接 async/await；异步工作需要改用 textDoneAsync、endAsync 等扩展事件。
这个 Agent 与同类方案有什么区别？
与直接使用 OpenAI Chat Completions API 相比，Experts.js 面向 Assistants、Threads、Runs 和工具编排；与 Custom GPTs 相比，README 所述的基础是可由应用代码调用的 OpenAI Assistants API。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|
| Experts.js 当前 | 55 · 缺口较多 | ★ 1.1k | 2 年前 | JavaScript | OpenAI API |
| Hello-Agents 智能体教程 | 54 · 缺口较多 | ★ 81k | 1 天前 | Python | OpenAI API |
| Dynamiq 智能体编排框架 | 61 · 存在缺口 | ★ 1.1k | 1 天前 | Python | OpenAI API |
| LangGraph Multi-Agent Swarm | 51 · 缺口较多 | ★ 1.6k | 4 天前 | Python | OpenAI API |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
证据显示：项目使用MIT许可证，作者为Ken Collins，但发布者未经验证。代码中未发现恶意行为，但存在外部API调用（OpenAI、postimages），且测试需要API密钥。未发现用户确认机制，数据流透明度有限，敏感数据处理未明确。依赖项包括openai和eventemitter2，但未提供安全审计。外部效果包括创建和删除OpenAI资源，但未提供回滚机制。来源归属明确，但发布者身份未知。扣分原因：缺少用户确认、数据流透明度不足、敏感数据处理不明确、依赖安全未审计、外部效果无回滚。
证据显示：README和代码示例一致，测试套件存在，但测试依赖外部API，可能不稳定。依赖项在package.json中明确，但未提供版本锁定。失败消息未详细说明。扣分原因：测试依赖外部服务，失败消息不充分。
证据显示：README提供了多种使用场景，包括产品目录、流式传输、图像消息、向量存储等。能力边界在文档中有所说明，但未明确限制。触发精度通过工具名称和描述实现，但未详细说明。环境适配支持ES6和CommonJS，但未提供浏览器支持。扣分原因：能力边界不明确，触发精度依赖模型。
证据显示：README结构清晰，安装说明简单，命名稳定，示例丰富，但已知限制未明确。许可证为MIT，版本号存在，但变更日志未提供。维护责任由作者承担，但未明确。扣分原因：已知限制未列出，变更日志缺失。
证据显示：输出可用性高，提供了多种输出方式。边际价值高，简化了Assistants API的使用。成本效益合理，但未提供性能数据。扣分原因：成本效益未量化。
证据显示：README中的声明与代码一致，测试套件提供了部分验证。但未提供独立验证。事实与推断分离良好。扣分原因：跨来源验证不足。
- 源码中未见：执行前用户确认开启或自行加上执行前确认；先在沙箱或测试环境跑通，确认行为后再接入真实数据。
- 发布者身份未经验证，使用前应自行评估风险。
- 测试依赖外部API和密钥，可能不稳定且存在安全风险。
- 未提供用户确认机制，工具调用可能自动执行。
- 依赖项未进行安全审计，建议检查依赖漏洞。