内网安全产品接入
将安全设备和外部系统接入 Flocks，通常是企业落地的第一步。TDP / NDR / XDR / HIDS / EDR / 蜜罐 / SIP / 情报源等系统在不同企业中的部署形态各不相同，接入方式也存在差异。
这一页回答两件事：
- 面对一个设备时，如何选择 API、日志推送或浏览器等接入路径。
- 在 API 接入路径下，如何通过 API 文档生成并验证可复用工具。
场景简介
Flocks 已经内置了一批主流安全设备 / 情报源的接入样例：
- 情报类：ThreatBook TIP、VirusTotal、GreyNoise、FOFA
- 流量 / 告警：微步 TDP、OneSEC、奇安信天眼
- 端点：青藤云 HIDS
企业真实环境中常常存在未预置的系统。因此，该场景的关键并不是内置设备数量，而是能否基于 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 接入）
以下为 VT API 接入演示中的关键节点：
| 时间 | Rex 动作 | 说明 |
|---|---|---|
| 0:02 | 假设已有一份设备 API 文档 | 演示中先删除已有 VT 工具，以展示重新接入过程 |
| 0:38 | 用户提出接入 VT API 的自然语言需求 | Rex 根据目标自行规划接入步骤 |
| 1:05 | Rex 开始 Web Search | 大约一两分钟 |
| 1:33 | 工具已创建 | 但创建完成并不代表调用链路已经可用 |
| 1:48 | Rex 继续验证 Key 是否能正常调用 | 关键一步 |
| 2:03 | 验证通过，工具存储完成 | VT 工具重新回到 Tools 列表 |
| 2:26 | 总结 | 完成从需求输入、工具创建到验证调试的闭环 |
这条路径的价值
- 接入速度：原本需要开发介入的接口封装工作，可显著缩短接入周期
- 可沉淀：生成的工具直接进入 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 接入