flyto-core

🛫 Flyto2 Core：AI Agent 工作流的模块化执行引擎

从"85 行脚本"到"12 步 Recipe"的工程哲学

想象这样一个场景：你的竞品分析爬虫已经跑了三个月，某天服务器 IP 被目标网站封禁，步骤 8 彻底失败。团队焦头烂额回顾代码——问题是，你根本不知道第 8 步具体做了什么，只能把整个脚本从头跑一遍。这是所有自动化工程师的共同噩梦，也是 Flyto2 Core 诞生的直接原因。

Flyto2 Core 是 Flyto2 的开源执行内核（Open-Source Execution Kernel），由 Flyto2 团队维护，遵循 Apache-2.0 许可。它用一套 registry 驱动的模块系统替代了传统的"手写 Python 脚本"模式：每个原子操作（浏览器启动、页面截图、API 调用、文件写入）都被封装为可注册、可复用、可追踪的独立模块。

flyto-core 的核心价值主张极为明确：让 AI Agent 的每一次工具调用都有迹可循、可断点重试。它不是另一个 LangChain 替代品，而是 AI Agent 落地时最容易被忽视的那个"执行可靠性"层面的完整解决方案。

上图为 flyto-core 执行竞品情报采集的完整流程：浏览器启动→导航→截图→性能采集→报告输出，每步均有时长记录和状态追踪

468 个模块 × 85 个分类：覆盖 AI 工作流的完整工具链

flyto-core 的模块注册表（ModuleRegistry）是整个框架的核心。从 GitHub 仓库的 README 可以看到，当前版本拥有 468 个注册模块，横跨 85 个分类前缀，包括但不限于：

这套模块系统的设计原则是确定性（Deterministic）：每个模块接受明确的输入参数，产出明确的输出结果，不依赖隐式状态。这与 LLM 的概率特性形成了鲜明对比——LLM 生成指令，flyto-core 执行指令，两者各司其职。

MCP 原生：AI 助手直接调用 468 个工具

MCP（Model Context Protocol）是 AI 行业新兴的工具调用协议，flyto-core 在 2.26.x 版本中已完整支持 MCP Streamable HTTP 传输。安装后，只需一行配置即可将 468 个模块暴露给支持 MCP 的 AI 助手：

{
  "mcpServers": {
    "flyto-core": {
      "command": "python",
      "args": ["-m", "core.mcp_server"]
    }
  }
}

这意味着 Claude Code、Cursor、Windsurf 等主流 AI 编程助手可以直接调用浏览器截图、API 请求、文件处理等 468 个经过代码审查的确定性工具，而不是让 LLM 生成可能出错的自定义代码。安全边界清晰可见：模块列表就是 AI 的能力边界。

断点重放：从"重新跑全部"到"只跑失败那一步"

flyto-core 最具差异化的特性是Execution Trace + Replay 机制。每一轮工作流执行都会生成完整的执行轨迹（Execution Trace），记录每个步骤的输入、输出、耗时和状态。如果步骤 8 失败，用户只需执行：

flyto replay --from-step 8

系统从步骤 8 开始重新执行，步骤 1–7 的状态完整保留，不浪费任何时间。这在爬虫工程、持续监控、自动化测试等长链路场景中价值尤为显著。

此外，flyto-core 还提供证据快照（Evidence Snapshots）：每个步骤执行前后的完整状态被记录保存，可用于审计、合规留存或事后复盘。

部署：pip 安装 + 一条 Dockerfile，多场景覆盖

flyto-core 提供多种接入方式：

• pip 安装：最轻量的核心引擎，包含 CLI 和 MCP Server

  pip install flyto-core[browser] && playwright install chromium
  

• HTTP API 部署：通过 flyto serve 启动本地 HTTP 服务（默认端口 8333），提供 /v1/workflow/run、/v1/workflow/{id}/replay/{step} 等 REST 端点
• Docker 部署：官方提供多阶段 Dockerfile（基于 python:3.12-slim），自动安装 Playwright Chromium，适合容器化生产环境
• Python API：直接在 Python 代码中调用 ModuleRegistry.execute()

快速部署时间：约 5 分钟（pip 安装 + playwright 浏览器下载）。无需 GPU，内存 2GB+ 即可运行。

局限与挑战

没有任何框架是银弹，flyto-core 的局限性需要客观认识：

1. 无独立 Web UI：框架本身只有 CLI 和 HTTP API，没有开箱即用的图形界面。相比 Browserbase、Autify 等商业平台，可视化程度较低。
2. 学习曲线：虽然 YAML Recipe 降低了使用门槛，但真正理解模块注册、上下文传递、证据快照等概念需要一定投入。
3. Playwright 依赖：浏览器自动化能力基于 Playwright，在某些反爬策略严格的网站（如 Cloudflare Bot Management）上仍然存在被检测的风险。
4. 生态成熟度：相比 Playwright 官方或 Selenium，flyto-core 的社区规模和第三方模块生态仍在成长阶段。

行业意义：AI Agent 从"能跑"到"敢上线"

flyto-core 的崛起折射出一个深层趋势：AI Agent 框架正在从"概念验证"走向"生产就绪"。

过去一年，LangChain、AutoGen、Semantic Kernel 等框架解决了"如何用 LLM 编排逻辑"的问题。但当这些 Agent 真正上线时，工程师们发现：LLM 生成的下游代码不可靠、无法回滚、难以审计——这些执行层的问题根本不在 LLM 框架的管辖范围内。

flyto-core 恰好填补了这个空白。它不依赖任何特定 LLM，不绑定特定云厂商，专注解决"LLM 决定做什么"之后的"怎么可靠地做"的问题。在 2025–2026 年 Agent 应用井喷的背景下，这种专注于执行可靠性的中间件价值正在被越来越多开发者认可。

项目当前 478 Stars（且在稳步增长），背后是 Flyto2 商业产品在真实客户场景中打磨多年的技术积累——Apache-2.0 许可确保了核心代码的开源透明，值得关注 AI 工作流工程化的团队持续跟进。