Flocks 文档

外观

工具清单 / MCP ​

工具清单是 Flocks 的"能做什么"页面。它集中管理平台可调用的执行能力——内置工具、API 工具、本地工具，以及通过 MCP（Model Context Protocol）接入的外部服务。在最新版 WebUI 里，MCP 已整合进工具清单页，不再作为独立一级菜单存在。

Flocks 工具体系的特点：支持"一句话接入"——给 Rex 一份 API 文档或 MCP 服务地址，平台会自动生成工具、自动验证、自动调试，直到可用为止。

功能定位 ​

工具回答的是"Agent 能执行什么动作"。Flocks 把它设计为平台级能力而不是零散脚本，核心体现在：

  • 统一注册 / 调度 / 管理：所有工具进同一运行时和统一管理面
  • 多来源合一：内置工具、Python 脚本工具、API 工具、MCP 适配工具都走同一套接口
  • 一句话生成：从自然语言描述接口用途、输入输出和调用目标开始，Flocks 编写代码生成完整的 API 调用工具
  • 自动验证 + 自动调试：生成不代表可用——Rex 会继续测试 Key、测试调用、失败自己修

四类工具 ​

类型适合典型例子
内置工具文件 / Shell / 代码搜索 / LSPbash、read、write、edit、grep
API 工具安全设备、情报源、内部业务接口ThreatBook、VirusTotal、GreyNoise、TDP、OneSec
本地工具 / Python 脚本业务特定处理、私有协议封装解析内部日志、查内网接口
MCP 服务已经提供 MCP 能力的外部系统各类 MCP Server

白皮书里也提到：项目中已经集成了 ThreatBook 等外部能力，并支持 MCP 统一接入。

适用场景 ​

进入工具清单通常有三类动机：

  1. 新接入一个安全设备或情报源（有 API 文档就行）
  2. 把成熟的网页后端调用沉淀为稳定工具（先浏览器突破，再 API 固化）
  3. 接入外部 MCP 服务（已经提供 MCP 能力的系统）

操作步骤（WebUI） ​

步骤 1：进入工具清单 ​

侧栏 Agent 工作室 → 工具清单 / MCP。页面显示：

  • 已接入的工具列表（按类型分组）
  • MCP 服务（同一页面下方或独立 Tab）
  • 每个工具的状态（启用 / 禁用 / 测试通过）
  • 可用的操作（测试连接、启用 / 禁用、删除）

步骤 2：用自然语言接入一个 API 服务 ​

最快的接入方式是在会话里对 Rex 说：

有 API 文档时：

text
帮我接入 VT 的 API 服务
Key 放在了 ~/vt_key.txt

文档：<贴上 API 文档链接 / 文本>

没有现成文档时：

text
帮我 web 搜索 VT 的 API 文档
然后帮我接入 VT 的 API 服务
Key 放在了 ~/vt_key.txt

来自 api_access.mp4 的原话：> > "如果设备有 API 文档，它的创建过程是完全一样的。你只要提供文档内容就好了。"

步骤 3：Rex 自动完成端到端接入 ​

Rex 在背后会做：

  1. 读取 API 文档（自己检索或用户提供）
  2. 生成工具代码（API 调用、参数构造、错误处理）
  3. 创建工具条目到工具清单
  4. 验证 Key：实际发一次请求试试这个 Key 能不能通
  5. 失败自动调试：验证失败就修工具、改参数、再试，一直到通为止
  6. 存储 → 回到工具清单，新工具出现

原话："它这里还要不断去验证这个 Key，这个过程是不是能够完全 OK。"

步骤 4：手动接入一个 MCP 服务 ​

在工具清单 MCP Tab 填写：

  • 服务地址（MCP Server URL）
  • 认证信息（Token / OAuth 或者该 MCP 服务自己定义的认证方式）

FAQ 提示：只配地址不代表已经完成认证。页面上有时只有服务地址输入，认证需要按 MCP 服务方的文档补齐。

步骤 5：在模型测试 / 工具测试里验证 ​

工具加进来但还不代表可用。尤其是 MCP 粘 JSON 测试时：

  • 先检查 JSON 语法
  • 再检查参数 schema 是否符合工具定义
  • 最后才怀疑工具本身是否适合在测试框里直接调用

核心概念 ​

语言生成工具 ​

Flocks 工具系统的核心价值点之一。从一句话需求开始，自动：

  • 理解接口用途、参数、输出
  • 生成调用代码
  • 创建工具注册条目
  • 发起验证请求
  • 失败自我调试

这让"新接入一个设备"的成本从若干小时降到几分钟。

先浏览器突破、再 API 固化 ​

很多真实安全环境下接口能力不足。白皮书里描述的核心能力是：

  1. Rex 先用浏览器工具登录控制台、取数、完成分析任务（参见 场景 · 浏览器自动化）
  2. 把浏览器过程中发现的后端接口，沉淀成稳定的 API 工具
  3. 从此长期运行、定时调度都可靠

这是 Flocks 工具体系中最有企业落地价值的设计，也是区别于纯 Web 爬虫方案的核心点。

MCP 与工具的关系 ​

MCP 不是"另一个工具类型"，而是统一接入外部系统的标准协议。对没有原生工具但已提供 MCP 能力的系统，MCP 比自己写 API 适配器更省事。使用上两者无缝——Agent 调用时不区分。

工具的可见范围 ​

和 Agent / Skill 一样，工具也分：

  • 内置工具 — 平台自带
  • 用户级工具 — 当前用户所有 Workspace 可见
  • 项目级工具 — 只在某个 Workspace 内可见

真实案例走读 ​

背景 ​

用"语言生成"方式重建 VT 服务。

用户输入 ​

一句话需求（无文档）：

「帮我 web 搜索 VT 的 API 文档，然后帮我接入 VT 的 API 服务，Key 在文件里」

生成过程 ​

Rex 一步步做：

  1. 先做一次 Web 搜索找到 VT API 文档
  2. 读取文档，理解接口结构
  3. 生成 VT 工具代码
  4. 用提供的 Key 真实调一次接口
  5. 验证通过，工具存入工具清单

整个过程演示里约 1~2 分钟。用户评论：

"输入一句话，它会去做各种的……首先创建这个工具，然后去做各种验证；如果验证失败的话，它会自己继续调试，一直到这个调试成功为止。"

结果 ​

  • 删掉的 VT 服务"又创建回来了"
  • 工具可用、Key 可用、验证通过

常见问题 ​

接入后自动加载还是要手动启用？ ​

通常会自动出现在工具清单，并且 Rex 会在后续会话里可以直接调用。如果没出现，先刷新页面、确认在哪个 Workspace。

MCP 测试里粘贴 JSON 报错，是格式问题还是调用方式不对？ ​

分层排查：

  1. 先校验 JSON 语法
  2. 再看参数结构是否符合工具 schema
  3. 最后才考虑"这个工具是不是本来就不适合直接在测试框里这样调"

参见 FAQ MCP 与工具调用。

为什么测试通过但真实任务调不通？ ​

测试只验证最基础的连通性。真实任务会叠加更长的上下文、更大的输出、工具组合。参考 模型报错排查 的思路——先区分"所有工具都失败"还是"只这个工具失败"。

Docker 场景下工具能正常用吗？ ​

取决于工具类型：

  • API 工具：网络通、Key 对就行，Docker 下同样可用
  • 浏览器工具：Docker 下 agent-browser headed 模式不可用，交互式登录要本机安装
  • Bash / 本地文件工具：要注意挂载目录是否正确

参见 远程部署 和 FAQ 浏览器自动化与网页登录。

工具调用成功但结果没自动保存 ​

不少工具默认只返回结果、不落盘。要看到文件产出，需要：

  • 在任务 Prompt 里明确要求"结果写入文件"
  • 或者在工具定义里加输出路径
  • 或者让后续 Workflow 节点把结果显式写到 Workspace 的 artifacts/

API 工具能不能加到特定 Agent 而不是全局可见？ ​

工具本身注册在平台级，但每个 Agent 可以配置自己的工具白名单——决定这个 Agent 能调用哪些工具。这样可以避免一个 Agent 乱用不相关工具。

相关模块 ​

基于 VitePress 构建

Copyright © Flocks