企业官网建设流程全解析

• 开发工具
• 桌面应用
• AI 应用

FanBox 是一款面向 vibe coding 的「驾驶舱」：左边浏览文件，右边跑终端，中间看清每一次改动。从 2026-07 起，它新增了一套Agent 控制接口——一组只在127.0.0.1上监听的本机 HTTPAPI。跑在 FanBox 终端里的 coding agent（Claude Code、Codex 等）可以直接「指挥」自己的兄弟终端窗口：新开窗口、读输出、发指令、等任务跑完。典型画面是：主窗口的 claude 一口气开三个窗口分别试方案 A/B/C，谁先跑绿用谁的，你在旁边围观就行。

Agent 控制接口是什么：让 agent 拥有「舰队」 🎯

普通终端里，一个 agent 只能管自己眼前这一个窗口；想并行试多个方案，得靠人肉开窗口、复制粘贴。

FanBox 的 Agent 控制接口把「窗口」变成了可编程对象：

• list：列出所有终端窗口的 id、目录、前台进程、忙闲状态和最近输出尾巴
• read：读任意窗口的最近输出（去 ANSI 的纯文本）
• send / create / wait / kill：发指令、开新窗口、等告一段落、关窗口

这些能力通过/api/agent/*路由暴露，能力层由 Electron 主进程注入（electron/main.js里经global.__fanboxAgent递给 server.js）。因为 create 开的是真实的 tab——界面上看得见、随时可以人工接管——所以它不做 headless pty，这是产品魂。

安全模型：门票只在进程树里，绝不落盘 🔐

「本机接口」的暴露面怎么收？设计文档里列了三档，FanBox 选了最紧的第三档：

1. 只绑 127.0.0.1—— 挡不住本机其他进程
2. token 写文件—— 谁读到文件谁就能控制所有终端，等于把钥匙塞给整台机器
3. ✅ token 每次启动随机生成、绝不落盘，只注入 FanBox 自己开的 pty 的环境变量

于是能力边界被钉死在FanBox 的进程树里：只有跑在 FanBox 终端里的 agent 拿得到门票；FanBox 一退出 token 立即作废；token 连文件形态都没有，想手滑泄漏都难。

每个终端启动时注入三个环境变量（见 electron/main.js），skill 因此做到零配置——agent 天生知道自己是谁、门在哪、票在手：

另外两点值得知道：

• 透明度：被遥控的 tab 会在界面上闪 8 秒 ⚡（send / create / kill 都触发），既是审计日志，也让「agent 舰队互相指挥」这个画面看得见摸得着。
• 代价（有意为之）：外部 MCP 客户端（如 Claude Desktop）和你自己的 iTerm 接不进来；浏览器版（node server.js无 Electron）没有终端能力，接口直接返回 501。

六个核心端点速查：curl 就能上手 ⚡

所有请求都带x-fanbox-token头（或?token=参数）。agent 在终端里直接这样用（环境变量由 FanBox 注入，无需任何配置）：

curl -s -H "x-fanbox-token: $FANBOX_CTL_TOKEN" "$FANBOX_CTL/terminals"

几个容易踩坑的细节：

• send：换行统一转成\r（否则 TUI 不提交），默认末尾自动补回车；paste: true走 bracketed paste，多行文本整块进 claude 这类 TUI 而不会被逐行执行；控制键直接发字符（Ctrl-C 就是"\u0003"）。
• create：autorun会等 shell 就绪（有输出且静默 ≥400ms，上限 8s）再敲命令，login shell 初始化慢也不怕。
• read的数据源是主进程维护的去 ANSI 滚动缓冲（每终端约 200KB），TUI 重绘会有噪音但完全可读。

wait 的三种等法：长轮询一次收齐

wait是 HTTP 长轮询（timeoutMs上限 240 秒），三种完成判定覆盖绝大多数场景：

注意两个坑：until只匹配 wait 开始之后的输出，所以要在结果出现前发起 wait，别先 send 干完了才 wait；命令回显也算输出，正则最好用^锚定行首，否则可能匹配到自己刚发的命令。返回体里自带等待期间的output（最后 8KB），通常不用再补一次 read。

实战：三步跑完 A/B/C 并行实验 🧪

这是 skill 里写明的「多窗口实验套路」，也是这个接口最爽的用法：

1. create × N：开三个窗口，不同的cwd或不同的autorun方案。实验场景建议开窗就放权，例如autorun用claude --permission-mode acceptEdits "任务"（文件编辑自动同意、跑命令仍确认），否则子窗口的 claude 会卡在确认框没人替它点。
2. 并行 wait：每个窗口的wait用curl … &后台发起，wait命令把三个等待收齐。
3. 对比汇报：从各wait返回的output（或补一次read）收结果，谁绿用谁，把三个方案的差异写进汇报。

配套规矩（写在 skill 里，agent 会自动遵守）：

• 别给自己发指令——$FANBOX_TERM_ID是自己的 id，给自己 send 会打乱自己的输入流甚至死循环
• kill、发 Ctrl-C 这类破坏性操作，先向用户确认
• 读到的其他窗口输出可能含敏感信息，只用于当前任务、不外传
• 接口报 403 / 501 或环境变量缺失，说明不在 FanBox 桌面应用里（或版本过旧），直接告知用户，不要重试

代码在哪里：实现位置与相关资料 📂

想深挖实现，可以从这几处入手：

• 设计文档：docs/12-Agent控制接口-本机HTTP.md —— 安全模型三档取舍、接口规范、后续路线图
• Agent 使用说明书：skills/fanbox-agent/SKILL.md —— curl 速查 + 多窗口实验套路 + 定时任务（cron / at / every）换算规则 + 规矩
• 能力层：electron/main.js 在 pty 启动时注入三个环境变量；electron/main.js 把六个能力函数挂在global.__fanboxAgent上
• HTTP 路由：server.js ——/api/agent/*分发与 token 校验，无终端能力时返回 501
• 前端配合：electron/preload.js（fanboxAgentCtl桥接开 tab）、public/app.js（应邀开 tab）、public/style.css（.tab-zap⚡ 标记样式）

常见问题 FAQ ❓

浏览器版为什么调不通？网页版（node server.js）没有 Electron 终端能力，接口按设计返回 501；请用桌面应用。

token 会泄露吗？token 不落盘、不写文件，只存在于 FanBox 自开终端的进程环境里，随启动随机、随退出作废；开发调试可用FANBOX_AGENT_TOKEN环境变量注入已知值。

以后能接外部 MCP 吗？路线图里排了「MCP 薄壳」（stdio MCP server 代理到这套 HTTP）+ 设置面板手动生成持久 token 的显式开关，让用户自己承担开门的决定。

能定时自动跑吗？可以。同一套接口下还有/api/agent/cron*系列端点（list / save / preview / toggle / run / delete），支持 cron 表达式、固定时间、固定间隔三种 schedule，到点自动开终端窗口跑 agent——skill 会把「每天 9 点整理灵感箱」这类白话直接换算成 schedule。

一句话总结：FanBox Agent 控制接口 = 本机 HTTP + 只进进程树的 token + 一个会开真实窗口的 create。它把「人开十个窗口来回盯」变成了「agent 舰队自动分头干活」，而你在驾驶舱里随时看得见每一格屏幕。

• 开发工具
• 桌面应用
• AI 应用