Integuru v0 评测：用 HAR 文件反向工程平台内部 API，生成可运行集成代码
The first AI agent that builds permissionless integrations through reverse engineering platforms' internal APIs.
秒懂
- 它是什么？
- Integuru v0 是一个 Python 编写的 AI 代理，通过分析浏览器网络请求（HAR 文件）来生成针对无官方 API 平台的集成代码。本文基于仓库文档，解析其工作机制、运行方式与适用边界。
- 适合谁用？
- Integuru v0 适合需要快速为无官方 API 的平台生成一次性或低频集成脚本的开发者，尤其是那些熟悉浏览器开发者工具、能手动导出 HAR 文件并处理 Cookie 的人。它不适合需要长期稳定运行、涉及复杂认证（如频繁 2FA）或对代码质量有严格要求的场景，因为生成的代码依赖脆弱的内部端点，且需要 OpenAI 付费模型。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库最近一次提交在 83 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
一个解决无 API 平台集成问题的早期尝试
很多平台没有公开 API，或者 API 权限申请流程漫长。Integuru v0 的定位是：让 AI 代理通过分析浏览器网络请求，自动生成能调用平台内部端点的 Python 代码。这个仓库是 Integuru 团队公开的最早版本，README 明确说明它展示了原始方法，而最新版本已经移至 integuru.com。因此，这里评测的对象是 v0 代码，它更像一个概念验证，而非持续维护的产品。目标用户是那些愿意手动录制浏览器操作、并希望跳过手工分析请求依赖过程的开发者。
从 HAR 到依赖图：核心机制拆解
工作流程分三步。首先，用 create_har.py 启动浏览器，用户登录平台并执行目标操作（如下载账单），该脚本会记录所有网络请求到 network_requests.har，同时保存 Cookie 到 cookies.json。其次，运行 integuru 命令，传入描述操作的 prompt。代理会分析 HAR 文件，定位触发目标操作的请求，例如一个包含 accountId 和 userId 参数的下载 URL。接着，代理识别这些动态参数，并在 HAR 中寻找能提供这些参数的请求，将它们建立依赖关系。这个过程递归进行，直到请求只依赖认证 Cookie。最后，代理从依赖图的末端节点开始向上遍历，把每个请求转换为可运行的 Python 函数，最终生成完整代码。README 中强调，图生成阶段推荐使用支持函数调用的 gpt-4o，而代码生成阶段会自动切换到 o1-preview（如果账户可用）。这意味着实际运行需要两个不同能力的模型协作。
安装与运行：Poetry、Jupyter 和 OpenAI 密钥
安装依赖使用 Poetry，命令序列为：poetry install、poetry shell、poetry run ipython kernel install --user --name=integuru。之后运行 poetry run python create_har.py 启动浏览器，手动完成登录和目标操作。随后执行 poetry run integuru --prompt "download utility bills" --model gpt-4o。命令行参数包括 --har-path（默认 ./network_requests.har）、--cookie-path（默认 ./cookies.json）、--max_steps（默认 20）、--input_variables（支持键值对格式，但仅用于图生成，代码生成尚未支持）以及 --generate-code 开关。另外，也可以通过 Jupyter Notebook main.ipynb 运行。整个过程依赖 OpenAI API 密钥，README 建议使用至少 o1-mini 能力的模型，o1-preview 更佳。
Cookie 与 2FA：一个实际的脆弱点
认证处理完全依赖 Cookie 文件。README 明确说明，当目标站点使用双因素认证（2FA）时，用户需先完成 2FA 流程，然后获取认证后的 Cookie 或会话令牌，再将这些令牌用于工作流。这意味着生成的代码不会自动处理动态的 2FA 挑战，而是假定 Cookie 在有限时间内有效。对于短期任务（如一次性下载文件）这或许可行，但若目标平台频繁刷新令牌或强制重新认证，生成的代码就会失效。此外，Cookie 文件是明文存储，虽然 README 声明数据仅保存在本地，但任何能访问该文件的人都能复用会话，这要求用户妥善保管文件。
输入变量支持不完整：一个明显的功能缺口
README 的 Features 部分承认，输入变量（例如选择下载哪一年的账单）仅在图生成阶段支持，代码生成尚未实现。也就是说，即使你通过 --input_variables 指定了动态输入，生成的 Python 代码可能仍会将参数硬编码为录制时的值。这意味着，如果你需要针对不同年份重复运行集成，当前版本无法直接生成可参数化的代码，必须手动修改生成的代码。这个限制对于真实场景影响很大，因为大多数集成都需要处理可变输入。
与替代方案的对比：RPA 与传统 API 封装
Integuru v0 的替代方案有两类。一类是传统 RPA 工具（如 Selenium 或 Playwright），它们通过模拟浏览器 UI 操作来实现自动化，不依赖内部 API，因此对 UI 变更的容忍度更高，但运行速度慢且脆弱。另一类是手动封装：开发者用浏览器的开发者工具自己分析请求，然后用 requests 库写脚本。这种方式需要手工构建依赖图，但能完全控制代码质量。Integuru v0 的核心差异在于用 LLM 自动完成依赖分析，省去了人工追踪请求参数来源的耗时步骤。但代价是依赖 OpenAI 模型，且生成代码的质量受模型能力限制。另外，像 Apify 或 n8n 这类平台提供现成的集成模板，但通常需要平台支持目标服务。
维护成本与许可证考量
仓库没有发布任何 release，最近的推送日期是 2026 年 6 月，但这是 v0 版本，README 明确表示新版本已移至商业站点。因此，维护升级需自行承担：没有版本发布记录，也没有社区讨论的可见渠道。许可证为 AGPL-3.0，这意味着如果你将生成的代码或修改后的代理集成到通过网络提供的服务中，可能需要开源你的修改。但注意，生成的集成代码本身可能被视为独立作品，具体需咨询法律意见。此外，CI 工作流仅运行 pytest，测试覆盖范围有限，未提供针对真实平台的集成测试。
编辑结论
Integuru v0 适合需要快速为无官方 API 的平台生成一次性或低频集成脚本的开发者，尤其是那些熟悉浏览器开发者工具、能手动导出 HAR 文件并处理 Cookie 的人。它不适合需要长期稳定运行、涉及复杂认证（如频繁 2FA）或对代码质量有严格要求的场景，因为生成的代码依赖脆弱的内部端点，且需要 OpenAI 付费模型。在采用前，应先确认目标平台的使用条款是否允许自动化请求，并检查生成的代码是否包含硬编码的 Cookie 或动态参数。该仓库仅代表 2024 年的早期思路，最新版本已移至 Integuru.com，若需要持续维护的功能，应评估商业版本而非此 v0 代码。
社区笔记