Flyto2 Core：把 AI 代理的每一步都变成可回放的证据
Flyto2 Core 是用于自动化和 AI 代理工作流程的开源执行内核：452 个注册表支持的模块、MCP 原生传输、YAML 配方、证据捕获、重播、触发器、队列、版本控制和计量。
秒懂
- 它是什么？
- Flyto2 Core 是一个开源的 Python 执行内核，用 480 个注册模块和 YAML 配方把 AI 代理的工作变成可验证、可回放的过程。本文拆解它的机制、上手方式、局限，以及适合谁用。
- 适合谁用？
- 适合需要把 AI 代理产出变成可审计证据的团队，尤其是做浏览器自动化、竞品调研、Web Vitals 检查这类重复性任务，并且希望失败后只重跑单个步骤的人。不适合想要完整 AI 治理（意图管理、模型路由、过程学习）的用户，因为那些功能在 flyto-ai 和 flyto-blueprint 里，flyto-core 只管执行和证据。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 8 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
一个把 AI 工作变成可验证流程的执行内核
Flyto2 Core 解决的问题很具体：AI 代理说它完成了任务，但你怎么知道它真的做了？shell 脚本能跑，但失败一次就得全部重来。flyto-core 把工作拆成 YAML 配方里的步骤，每个步骤调用一个注册表里的模块，执行时记录完整 trace，失败后可以用 flyto replay --from-step 8 只重跑第 8 步。它面向的是那些想要 AI 代理框架但不想让代理乱写代码的人，尤其是做浏览器自动化、API 集成、网页抓取和 MCP 服务器自动化的工程师。它不负责意图治理、模型路由或过程学习，那些在 flyto-ai 和 flyto-blueprint 里。这个边界在 flyto-product.toml 里用 flyto.product-contract.v1 记录下来了。
注册表模块、MCP 传输和证据捕获的三角结构
flyto-core 的架构核心是 ModuleRegistry，一个注册表驱动的模块清单，当前有 480 个模块，分布在 88 个目录类别里。docs/TOOL_CATALOG.md 是从这个注册表生成的，不是手数的。模块通过 schema 暴露给 MCP 兼容的客户端，这意味着 AI 代理只能调用经过审核的模块，不能临时生成未审查的代码。执行时每个步骤都会产生证据：截图、Web Vitals 指标、JSON 报告，README 里的示例输出显示每一步都有耗时和状态。这种设计把 AI 代理的不可预测性关进了一个可审计的笼子里。但注意，README 只展示了 browser 模块的示例，其他模块（比如 crypto、verification）的具体行为没有详细说明，你需要查 docs 目录才能确认。
30 秒上手：安装、配方和回放命令
安装命令在 README 里写得很清楚：pip install flyto-core 装核心引擎、CLI 和 MCP 服务器，pip install flyto-core[browser] 加 Playwright 支持，然后 playwright install chromium 做一次性浏览器设置。跑一个配方只要一行：flyto recipe competitor-intel --url https://github.com/pricing。这个命令会执行 12 步，从 browser.launch 到 browser.evaluate，输出带每步耗时和保存的文件名。最关键的命令是失败后的回放：flyto replay --from-step 8，前 7 步瞬间完成，只有第 8 步重新执行，上下文完全保留。README 还给了三个内置配方示例：competitor-intel、full-audit 和 scrape-to-csv，后者接受 --selector 参数。总共 41 个内置配方，清单在 docs/RECIPES.md。
YAML 配方 vs 85 行 Python：可读性换来了什么
README 里做了一个对比：同样的竞品定价分析，Python 写 85 行，flyto-core 用 12 步 YAML。Python 版本没有 trace、没有 replay、没有每步计时，第 5 步失败就得重跑全部。YAML 版本把每个步骤拆成 id、module、params，比如 browser.goto 带 url 参数，browser.screenshot 带 path 和 full_page。这个对比很诚实，但也要看到代价：YAML 配方是声明式的，复杂逻辑（比如条件分支、循环、异常处理）在 12 步里怎么表达？README 没有给出例子。如果你需要高度自定义的控制流，纯 Python 可能更灵活。flyto-core 的卖点是确定性，但确定性往往意味着表达能力受限。
版本更新暴露的安全与边界关注
最近的三个版本透露了项目的优先级。v2.28.0 做了 IPv6 SSRF 加固和扩展管理，v2.27.0 引入了边界覆盖强制。这说明项目在认真处理安全边界，尤其是 SSRF 这类浏览器自动化常见的漏洞。但这也暗示一个风险：这类工具容易成为攻击面，因为浏览器自动化模块可能访问内网地址。如果你在一个多租户环境里跑 flyto-core，需要仔细配置网络策略。另一个值得注意的点是 metering（计量）模块的存在，它可能用于记录执行次数，但 README 没有说明计量数据存到哪里、是否会上传到云端。自托管用户需要自己检查这些模块的行为。
替代方案：Playwright 脚本与 n8n 的差异
最直接的替代是直接用 Playwright 写 Python 脚本，就像 README 里那个 85 行的例子。区别在于：Playwright 只提供浏览器自动化原语，没有 trace、replay、证据捕获和模块注册表。你得自己实现失败重试和日志。另一个替代是 n8n 这类可视化工作流工具，它也有节点和重试机制，但它的核心是事件驱动和 UI 配置，不是 YAML 配方，也不强调 MCP 原生集成。flyto-core 的独特之处是把 MCP 作为传输层，让 AI 代理能通过 schema 调用模块，而 n8n 的 AI 集成通常是 HTTP 节点或自写代码。如果你已经深度使用 MCP 生态，flyto-core 会更契合；如果你只需要一个简单的定时抓取，n8n 或纯 Playwright 可能更轻。
维护成本与许可证的现实考量
flyto-core 采用 Apache-2.0 许可证，这对商业使用友好，没有 copyleft 义务，但要注意它不提供任何担保，这是 Apache 许可证的标准条款。维护成本方面，项目更新频繁，最近一次发布是 2026-08-14，版本号到了 v2.28.1，说明迭代速度快。但这也意味着你需要跟上版本变化，尤其是安全修复（比如 v2.28.0 的 SSRF 加固）。升级时要注意模块 schema 可能变化，因为注册表是版本化的，但 README 没有明确说明向后兼容策略。另外，flyto-core 是三个包之一，另外两个是 flyto-ai 和 flyto-blueprint，它们不是开源的？README 没有明确说，但提到 flyto-core 独立运行，不依赖它们。如果你需要完整的产品功能，可能需要购买云服务，但本地执行是免费的。
编辑结论
适合需要把 AI 代理产出变成可审计证据的团队，尤其是做浏览器自动化、竞品调研、Web Vitals 检查这类重复性任务，并且希望失败后只重跑单个步骤的人。不适合想要完整 AI 治理（意图管理、模型路由、过程学习）的用户，因为那些功能在 flyto-ai 和 flyto-blueprint 里，flyto-core 只管执行和证据。采用前先验证三件事：你的 Python 版本是否满足要求，Playwright 的 chromium 是否已安装，以及你需要的模块是否真的在 480 个清单里，因为模块是注册表驱动的，不是任意代码都能跑。最终判断：flyto-core 的价值不在模块数量，而在 replay --from-step 这个命令，它把调试成本从整个流程降到了单个步骤。
社区笔记