夜雨聆风别从零造轮子：CrewAI Tools 八赛道选型导览
自定义 Tool 解决「你们公司独有的 API」；公开能力优先看 crewai-tools 与文档 Tools 分区。本篇是生态地图：按场景选赛道与代表工具，不展开每个构造参数。文档版本对齐 v1.15.9。
选型比背参数重要。Agent 绑定的工具列表越长，越容易出现「该用 A 却调用了 B」或在近似工具间空转。推荐做法是：按角色裁剪——研究员只拿搜索+爬虫，库管员只拿数据库只读工具，运营写回员只拿 Composio/Zapier——再在赛道内留一到两个备选，而不是把八个货架全塞进一个 Agent。
uv add crewai-tools挂载方式统一：
from crewai import Agentfrom crewai_tools import SerperDevTool, ScrapeWebsiteTool, FileReadToolagent = Agent( role="Researcher", goal="Find and summarize sources", backstory="Careful with citations.", tools=[SerperDevTool(), ScrapeWebsiteTool(), FileReadTool()],)需要限流时关注工具的 max_usage_count，避免 Agent 在循环里刷爆外部 API。
总览：八个货架
文档首页的「快捷入口」常推：RAG Tool、Serper Dev、File Read、Scrape Website、Code Interpreter、S3 Reader——可当作默认短名单。
1. Search & Research：先搜，再深挖
| Serper Dev / SerpApi Google | |
| Brave | |
| Exa | |
| Tavily 全家桶 | |
| LinkUp | |
| GitHub / Code Docs / Website Search | |
| YouTube Channel/Video Search | |
| Arxiv Paper |
选型口诀： 要「广搜」→ Serper/Brave/Tavily；要「语义找页」→ Exa；要「写成带引用的研究」→ Tavily Research；要「只在自家文档站」→ Website/Code Docs Search。
成本与配额也要算进选型：SERP 类按次计费，Tavily Research 一类多步任务更贵但省去你自建「搜索-阅读-再搜索」循环。学术场景先 Arxiv，再决定是否把 PDF 丢给文件检索或 Knowledge。GitHub Search 适合「代码里有没有现成实现」，不要拿它当通用网页搜索。
2. Web Scraping & Browsing：页面进模型的方式
ScrapeWebsiteToolScrapeElementFromWebsiteTool | ||
实践建议： 能搜到摘要就先搜；必须正文再刮。尊重 robots/ToS，控制并发；动态站优先云浏览器类，而不是裸 HTTP。选型上：静态正文 → Scrape/Firecrawl；登录后 SPA → BrowserBase/Stagehand；大规模合规采集 → Oxylabs/Bright Data。
3. File & Document：仓库即知识
读写：FileReadTool / FileWriteTool、DirectoryReadTool / DirectorySearchTool。检索向（偏 RAG）：PDF / DOCX / CSV / JSON / XML / MDX / TXT Search。进阶：OCRTool（视觉模型抽图中文字）、PDFTextWritingTool（按坐标写回 PDF）。
场景： 合同比对、CSV 运营分析、文档库问答、把 Agent 产出落盘。大库更宜配合 Knowledge（下篇）做切块嵌入；单次「打开这个文件」用 File 工具更直接。
OCR 适合票据、截图里的字；扫描件 PDF 往往「看起来是 PDF、其实是图」，这时 PDF Search 可能挖不到文本，应先 OCR 或换视觉模型路径。Directory 工具则适合「先找文件再读内容」的两步策略，避免把整仓文件列表塞进 prompt。
4. Database & Data：结构化真相源
关系库 / 数仓： MySQL Tool、PostgreSQL Search、Snowflake Search、SingleStore（安全 SELECT/SHOW + 连接池） 自然语言查库： NL2SQL 向量： Qdrant、Weaviate、MongoDB Atlas Vector
Agent 直连生产库务必：只读账号、表白名单、max_usage_count、审计。分析型问题可「NL2SQL 生成 → 人类或校验层审查 → 再执行」。
5. AI & Machine Learning：模型当工具
DALL-E / Vision：生图与读图 Code Interpreter：沙箱跑 Python、做表算 RAG Tool：通用检索增强 LlamaIndex / LangChain Tool：复用既有索引与链 AI Mind：偏推理/决策类能力封装
适合「Crew 里已有专家 Agent，但某步需要专用模型能力」——例如分析师 Agent 调 Code Interpreter，设计师 Agent 调 DALL-E。
RAG Tool 与下一篇的 Knowledge 有重叠：前者偏「工具调用式检索」，后者偏「挂在 Agent/Crew 上的知识源」。已有 LlamaIndex 索引时，用对应 Tool 接入比推倒重来更合理；绿场项目则直接 Knowledge + 默认向量库往往更短。
6. Cloud & Storage + 7. Automation + 8. Integrations
云存储： S3 Reader/Writer；Bedrock Invoke Agent、Bedrock KB Retriever——已在 AWS 体系的团队可把 Bedrock 资产直接编进 Crew。
自动化：
集成： Merge Agent Handler（Linear/GitHub/Slack 等统一 API）、CrewAI Run Automation（调用平台上已部署的自动化并轮询）、Bedrock Invoke Agent（带护栏与流式回灌）。
Wait Tool 看起来不起眼，却是长流程里的节拍器：等待外部审批、等待爬虫任务完成、避免紧挨着打爆下游限流。Automation 赛道的共性是「副作用在系统外」，务必配合上一篇的失败语义与限流，并在 Task 里写清成功标准，否则 Agent 会把「已触发 Zap」误当成「业务已办结」。
一张「任务 → 货架」速查
组合原则：搜索定位 URL → 爬虫取正文 → 文件/库工具落证据 → 自动化工具写回业务系统。工具别一次挂二十个；按 Agent 职责裁剪列表，description 冲突时模型会「工具幻觉」。
落地检查清单可以很短：每个外部工具是否配置了密钥与 max_usage_count？写操作是否隔离在单独 Agent？失败是字符串还是 ToolFailure？同一赛道是否只保留一个默认实现？把这四问答完，再去翻具体工具的参数页，会少走很多弯路。
本篇小结
官方工具不是参数字典，而是八条可组合的能力总线。先定数据从哪来、结果写回哪，再在赛道内挑 1～3 个代表工具验证；细节参数以各工具文档为准。下一篇讲 Knowledge、统一 Memory、Files——让 Agent 拥有长期参考库、可回忆上下文，以及多模态文件入口。
由于微信公众号更改规则，请点击上面“智子 AI 社区”关注本号，再点击右上角”..."，选择“设为星标”，以免错过文章更新。