Jumping Agent 跳一跳式 Agent 构建平台
用跳一跳游戏的方式在移动端搭建自己的 AI Agent，把抽象工作流变成可点、可跳的空间化步骤。
证据仅含 README、LICENSE 和三个测试文件。安全层面可见的只有：服务绑定 0.0.0.0、微信扫码绑定个人账号、API Key 写入 .env——均无代码证明有权限收敛、用户确认、数据流说明或回滚机制；不覆盖已有文件的测试（不覆盖 sentinel）算是生成安全的一个正面信号，故多数判 1，rollback 无任何证据判 0。source_attribution：作者明示个人独立开发并提供联系方式，给 2。
README 声称的功能（微信桥、编排器、workspace）没有任何被提供的源码佐证，只能算断言；依赖安装是散装的 pip install，无 requirements.txt/lock，版本漂移风险自担，判 1；失败路径与错误信息仅在测试字符串中偶尔出现（如 'build_plan. is not valid JSON'），整体证据薄弱，判 1。
受众与场景写得清楚（零基础用户、平板优先、微信渠道），判 2；作者坦承仅 7 种模板、构建流程不稳定，边界陈述诚实，判 2；environment_fit 有前置条件、多平台命令、局域网 iPad 说明，判 2；trigger_precision 在可见材料中完全没有涉及，判 0。
信息架构好：目录树加 mermaid 图，判 2；安装步骤完整可跟随，判 2；已知限制明确写出，判 2；LICENSE 为完整 Apache-2.0 全文，判 3。但命名不稳定（creat_project、run_time_templete、templete 等拼写错误出现在真实路径中），判 1；无 FAQ，示例仅一个视频，判 1；无 CHANGELOG/版本号，判 0；维护为个人承诺（'我会持续迭代'），无治理机制，判 1。
输出可用性：最终产物是可通过微信对话的 Agent，但工作区运行方式、输出格式在可见证据中描述有限，判 1；边际价值：游戏化空间化构建是差异化思路，判 2；成本收益：需自备 OpenAI Key、开三个终端、且自认构建流程不稳定，成本不低而稳定性折扣，判 1。
claim_traceability 弱：核心卖点（微信桥、编排）无法追溯到被提供的代码，判 1；交叉印证有限：测试仅佐证 agent_builder 的脚手架逻辑，与其余宣称基本不重叠，判 1；事实与推断分离较好：CLI 明确标注为'计划'，局限如实列出，判 2。
- 所有服务默认绑定 0.0.0.0，局域网内任何人可访问编排 API 与聊天端点，公网/不可信网络下务必改绑 127.0.0.1 或加鉴权。
- 微信扫码绑定将个人微信账号接入自动回复链路，账号凭据存储方式与数据流向在可见材料中无说明，使用前自行评估风险。
- 无依赖锁定文件，无法静态确认依赖版本是否存在已知漏洞。
- 无回滚/卸载说明；生成的 workspace 文件虽不会覆盖已有文件，但删除与恢复机制未提供。
- 作者自述构建流程尚不稳定，且无 CHANGELOG 与版本号，生产使用需谨慎。
- 本评估为静态审查，未执行任何代码，微信桥与编排器的实际行为未经验证。
这个 Agent 能做什么，适合哪些场景？
Jumping Agent 是一个开源（Apache-2.0）的 Agent 构建平台，把传统的平面 workflow 编排改成跳一跳游戏式的空间化交互，面向零基础用户，优先支持平板等移动端。用户在 Three.js 实现的跳台界面上按压跳跃完成流程搭建，平台通过 backend/orchestrator.py 编排服务调用 agent_builder 的模板和 back_agent 的 ReAct 代码补全能力，动态生成可运行的 Agent workspace。构建完成后可扫码绑定微信，直接在微信中与 Agent 对话，消息经 apps/weixin-main 的 iLink 连接器与 Weixin bridge（端口 8787）转发。整个系统自托管，需要本地运行 back_agent（8000 端口）、orchestrator（8001 端口）和前端（6301 端口）三个服务，并配置 OPENAI_API_KEY。项目由作者个人独立开发，作者自述当前版本工作流模板仅 7 种、编排与构建流程尚不够稳定。
用户在 Frontend/ 的 Three.js 跳一跳界面上选择流程模板（顺序、路由、并行等，见 agent_builder/flow_template/）并输入需求；orchestrator.py 接收请求，加载 agent_builder 的骨架与模板，通过本地 HTTP 调用 back_agent 的 ReAct Agent 对骨架代码进行补全与改写，在 backend/workspace/ 中生成包含 Agent/*.py 和 project_runtime.py 的项目工作区。微信链路上，apps/weixin-main 提供 iLink 扫码登录、账号存储、长轮询与文本/媒体消息，Weixin bridge 将消息经 /chat 接口转发至 orchestrator 运行对应 workspace 并回发微信。后端还带有 MCP 工具（网页、图像、会话等）、会话与长期记忆及 Agent ID 管理。
- 零编程基础的普通用户想在平板上直观理解并搭建一个多步骤 Agent 工作流
- 开发者想快速生成带顺序、路由或并行结构的 Agent 项目脚手架再自行修改代码
- 微信用户希望在微信里直接与自己构建的 Agent 对话，无需额外安装应用
- 教学或演示场景中，需要把抽象的 Agent 运行过程以游戏化跳台形式动态展示
- 想基于本地 MCP 工具（网页、图像、会话）扩展生成 Agent 能力的个人开发者
这个 Agent 有哪些优点和局限？
- 跳一跳游戏化交互显著降低 Agent 构建门槛，移动端（平板）优先设计，无需理解复杂连线图
- 从模板到可运行代码全自动：back_agent 的 ReAct Agent 直接补全并生成 workspace 项目
- 微信已作为正式渠道接入，支持扫码绑定后直接在微信对话，含文本/媒体消息与长轮询
- 架构模块清晰：前端、模板构建、ReAct 补全、编排、微信桥接各层职责明确，附 MCP 工具与记忆模块
- 作者自述当前版本仅提供 7 种工作流模板，跳台编排与最终构建流程尚不够稳定
- 强依赖 OpenAI 兼容 API（OPENAI_API_KEY），未见其他模型提供商的适配说明
- 需手动启动三个服务（8000/8001/6301 端口），CLI 尚在计划中未实现
- 微信接入依赖 iLink 连接器与 Weixin bridge，属于特定生态绑定，更换渠道需自行开发
如何安装或部署这个 Agent？
- 克隆仓库：git clone https://github.com/answeryt/Jumping-Agent-platform.git && cd Jumping-Agent-platform
- 安装前端依赖：cd Frontend && npm install && cd ..
- 创建 Python 虚拟环境：python -m venv .venv 并激活（Windows: .venv\Scripts\activate；macOS/Linux: source .venv/bin/activate）
- 安装后端依赖：python -m pip install "fastapi" "uvicorn[standard]" "pydantic" "openai"
- 安装微信连接器依赖：cd apps/weixin-main && npm install && cd ../..
- 配置密钥：设置 OPENAI_API_KEY 环境变量，或运行 python backend/set_agent_api_key.py 写入 .env
前置要求：Git、Python 3.11+、Node.js 18+、npm。
如何使用这个 Agent？
开三个终端，均在仓库根目录：
终端 A 启动 back_agent：cd back_agent && python -m uvicorn api:app --host 0.0.0.0 --port 8000
终端 B 启动 Orchestrator（会自动启动 Weixin bridge）：cd backend && python -m uvicorn orchestrator:app --host 0.0.0.0 --port 8001
终端 C 启动前端：cd Frontend && npm run server -- --host 0.0.0.0 --port 6301 --allowed-hosts all
浏览器访问 http://localhost:6301。在跳一跳界面构建 Agent 后，切到微信标签页获取二维码并扫码绑定，即可在微信中与 Agent 对话。iPad 访问需与电脑同一局域网，用电脑局域网 IP（如 http://192.168.x.x:6301）访问。