Firecrawl
官方资料已核实
把网页转成 Markdown 或结构化 JSON 的托管抓取 API。
自动化与工作流
把重复动作连成流程，以及为流程提供数据抓取与网页解析能力。
这个类别解决什么问题
同一件事重复到第三次，就该交给机器。这一层解决两件事：把散在多个服务之间的动作串成一条流程；以及把网页上的信息变成结构化数据，供流程使用。
什么时候需要
当你有明确重复动作的时候。如果一件事每周只做一次，手工做更省事；判断标准是「不做会漏，做起来又都一样」。
选择时看哪些指标
这些是评估这类服务时通用的判断维度，不针对任何具体厂商。
- 托管还是自托管：数据要不要留在自己服务器上
- 计费口径：按执行次数、按任务数，还是按数据量
- 触发方式的丰富程度：定时、Webhook、邮件、数据库变更
- 失败处理：出错会不会重试、有没有执行日志
- 抓取类工具还要看：是否遵守目标站点的 robots、有没有速率限制
中国开发者特别需要考虑什么
流程类工具本身多为托管服务，触发与回调依赖公网可达性，实际可用性请以官方说明与你自己的实测为准。自托管方案把数据放在自己的服务器上，但运维成本也落在自己身上。
这一层的成本结构
成本取决于计费口径。按任务数计费的工具，在验证期很便宜，但任务量一上来账单会陡增——这也是为什么很多团队在跑起来之后迁到自托管方案。按执行次数计费的，要注意「一次流程里调用了多少个步骤」也算钱。抓取类工具通常按页面数或计算单元计费，复杂页面（需要渲染 JS 的）比静态页面贵得多。
常见误区
- 一上来就搭一条几十步的大流程，出错时不知道断在哪。先把最小的两三步跑通，再往外扩。
- 在验证期就选自托管方案，把运维成本提前背上。想法没验证之前，托管服务更省事。
- 抓取时不看目标站点的 robots 与条款。技术上抓得到，不等于允许抓。
从零开始的上手顺序
- 先写下你要自动化的那件事的完整手工流程，包括每一步的输入输出。写不出来的流程，自动化只会把混乱放大。
- 只自动化其中最容易出错或最耗时的一两步，其余保持手工。
- 加上失败通知：流程断了要有人知道，而不是等三天后发现数据没同步。
- 跑满两周再评估：如果这两步从来没手工做过，说明流程设计有问题。
- 等任务量确实上来、账单开始显眼时，再考虑迁到自托管方案。
在不同业务模式中的作用
saas
把注册、开通、账单通知串起来，减少人工介入
ai-saas
用量统计与额度提醒的自动化
app
崩溃告警与版本发布的联动
api
调用异常的自动告警与限流响应
digital-product
购买后自动发货与授权
ecommerce
订单、库存与物流状态的同步
常见问题
我应该自托管还是用托管服务？
验证期用托管服务，跑稳了再考虑自托管。自托管的吸引力是省钱和控制权，代价是服务器、升级、备份都归你管。判断标准是：这条流程断了会不会影响收入。
按任务数计费和按执行次数计费，差在哪？
按任务数通常指一次触发算一次，按执行次数可能把流程内的每一步都算上。同一个流程在两种口径下费用可能差好几倍，选之前先算一遍你自己的实际调用量。
抓取别人的网站合法吗？
这取决于目标站点的条款、robots 协议以及你所在地区的法律，本站不给判断。技术上抓得到不等于允许抓，正式使用前请自行确认，必要时咨询专业人士。
流程跑起来之后还需要维护吗？
需要。上游服务改接口、改登录方式，流程就会断。建议给每条流程写一句「它依赖什么」，断了能快速定位。