内网安全产品接入
"把一套设备接进来"是 Flocks 进入大多数企业的第一步。TDP / NDR / XDR / HIDS / EDR / 蜜罐 / SIP / 情报源……每家企业手里都有一堆这些系统，接入方式也五花八门。
这一页回答两件事：
- 面对一个设备，该走哪条路接进来（选型：API / 日志推送 / 浏览器）
- API 接入在 Flocks 里到底怎么做（给一份 API 文档 → Rex 自动生成工具）
场景简介
Flocks 已经内置了一批主流安全设备 / 情报源的接入样例：
- 情报类：ThreatBook TIP、VirusTotal、GreyNoise、FOFA
- 流量 / 告警：微步 TDP、OneSEC、奇安信天眼
- 端点：青藤云 HIDS
但企业真实环境永远有 Flocks 没见过的系统。所以这个场景的关键能力不是"内置多少家"，而是任何有 API 文档的设备，都能在几分钟内接入——这是 Flocks 从"建议型助手"走向"执行型平台"的基础。
接入方式优先级
遇到一个新设备时按下面的顺序选，别反过来：
| 优先级 | 方式 | 适合场景 | 不适合场景 |
|---|---|---|---|
| ★★★ | 官方 / 私有 API | 长期稳定运行、定时任务、批量调用 | 确实没开放 API |
| ★★☆ | 日志推送 / 消息队列 / 中转脚本 | 设备本身是事件源、追求标准化 | 需要实时查询响应 |
| ★☆☆ | 浏览器登录后读页面 | 没有 API、只能从 Web 控制台拿数据 | 作为主路径长期运行 |
核心结论：浏览器方案是兜底，不是主路径。API 更稳定、更便宜、更适合定时跑。具体浏览器用法见 浏览器自动化与网页登录。
内网环境是否必须联网
Flocks 本身不硬性要求公网联网。需要网络的是你选的模型：
| 模型选择 | 是否要公网 |
|---|---|
| 私有化 / 本地部署模型 | 不需要 |
| 内网模型服务 | 不需要（能到模型就行） |
| 外部云端模型（OpenAI、Claude 等） | 需要 |
所以"能不能内网部署"这个问题，本质是模型问题，不是 Flocks 本身的问题。
API 接入主路径（推荐方式）
这是 Flocks 里最值得重点展示的能力：你只要把 API 文档给 Rex，剩下的它自己搞定。
操作步骤（WebUI）
进入 会话管理 → + 新建会话
一句话描述目标，比如：
「帮我 web 搜索 VT 的 API 文档，然后帮我接入 VT 的 API 服务，Key 在我刚才发的文件里」
Rex 会：
- Web Search 拉到 API 文档（如果你直接贴文档，跳过这步）
- 根据文档生成一个 Python / API 工具
- 把 Key 填进去
- 自动发起一轮调用验证
- 验证失败 → 自己调试 → 直到成功
工具写到 Tools 里，Rex 此后就能直接调用它
可选：在 Skill 里记下"调用这类设备的约定 / 限频 / 字段映射"，长期沉淀
真实案例走读（VT API 从零接入）
节选自demo演示视频（2 分钟）：
| 时间 | Rex 动作 | 说明 |
|---|---|---|
| 0:02 | 假设你手上有一份设备 API 文档 | 演示为了干净，先删掉现有 VT 工具 |
| 0:38 | 用户一句话：「web 搜索 VT 的 API 文档，然后帮我接入」 | 不需要教 Rex 怎么写代码 |
| 1:05 | Rex 开始 Web Search | 大约一两分钟 |
| 1:33 | 工具已创建 | 但"有工具"不代表"能跑" |
| 1:48 | Rex 继续验证 Key 是否能正常调用 | 关键一步 |
| 2:03 | 验证通过，工具存储完成 | VT 工具重新回到 Tools 列表 |
| 2:26 | 总结 | 整个过程就是"一句话输入 → 自动创建 → 自动验证 → 自动调试" |
这条路径的价值
- 接入速度：历史上需要开发介入 2-3 天的工作，现在是 2-3 分钟
- 可沉淀：生成的工具直接进入 Tools 目录，后续所有会话都能用
- 可纠错：失败能自动调试，不是一次就放弃
- 可迭代：需要改字段、加参数，直接在对话里继续改
MCP 接入（同样一句话）
除了 API 工具，Flocks 还支持 MCP（Model Context Protocol） 统一接入：
- 第三方已经写好的 MCP server → 配一下就能用
- 企业自己写的 MCP server → 同样"一句话接入"
- MCP 的好处：协议一致，跨 AI 平台复用
选 API 工具还是 MCP？一个简单的判断：
- 这个能力只给 Flocks 用 → API 工具就够了
- 这个能力可能跨多个 AI 平台复用 → 走 MCP
日志 / 消息队列接入（第二优先级）
有些设备天然是事件源（syslog、kafka、消息总线），这类场景适合这么组织：
- 设备按原有方式推日志 / 事件到企业的汇聚层（syslog server、kafka 集群、ES……）
- 写一个小的 API 工具或 MCP server，从汇聚层捞数（不是直连设备）
- Rex 调用这个工具拿到结构化事件，再做后续分析
好处是：
- 设备侧不需要动
- 汇聚层天然做了标准化
- 更新 / 扩容时 Flocks 这边零改动
浏览器方案（兜底，不推荐做主路径）
只有当 API 和日志都不可得，才考虑让 Rex 调浏览器工具登录 Web 控制台取数。这种方案的具体用法和边界见 浏览器自动化与网页登录。
值得强调的一点：通过浏览器发现的后端接口，可以反过来固化成稳定 API 工具。Rex 在 Web 操作过程中会观察浏览器实际发出的 XHR / Fetch 请求，必要时可以把这些请求模式沉淀成 Python / CLI 工具。这是 Flocks "浏览器突破 → 工具沉淀"的闭环思路。
前置条件
| 依赖项 | 要求 |
|---|---|
| 模型 | 推理能力越强，API 自动调试成功率越高 |
| 网络 | Flocks 运行节点能达到目标设备的 API / Web / 日志汇聚层 |
| 凭证 | 设备 API Key / Token / 账号密码（建议通过 Workspace secrets 管理） |
| Web Search 工具 | 如果依赖 Rex 自动搜索 API 文档；自己贴文档可以不用 |
持续运行建议
- 接入完成后，务必让 Rex 自己跑一轮验证调用，不要光看有没有工具
- 把"调用这家设备时的约束"（限频、必填头、字段映射）以 Skill 形式沉淀
- 需要长期运行的数据拉取，挂到任务中心做定时调度
- 失败告警接通道（钉钉 / 企微），便于运营层监控接入稳定性
边界与常见问题
| 问题 | 处理 |
|---|---|
| 设备 API 文档是 Word / PPT / 扫描件 | 先转成文本（pdftotext / OCR），再丢给 Rex |
| 文档里有多个 API，只想接几个 | 对 Rex 说"只接入 /v1/ioc 和 /v1/sample 两个接口"即可 |
| 接完跑一段时间后报 401 | 多半是 Token 过期，去 Tools 里刷新 Key |
| 想让接入的工具被特定专家 Agent 专用 | 在 Agent 定义里 tools: 字段显式声明，而不是全局开放 |
| 接入后发现字段对不上业务需求 | 让 Rex "加一层转换"，生成 wrapper 工具 |
| API 被限频 | 在 Skill 里写明限频规则，Rex 调用时会照顾；或者走日志层绕开直连 |
相关：场景总览 · 浏览器自动化与网页登录 · 告警研判 · 威胁情报与 IOC 研判 · 工具清单 / MCP · MCP 接入