把多个编程智能体的审批集中到网页

同时用 Claude Code、Codex 和 Gemini CLI，麻烦往往不只是切换模型，而是审批散落在不同终端里：任务早就停了，人还以为它在继续跑。HackersHostel 的三位开发者做了 AgentWebUI，把聊天、任务进度、代码差异和审批按钮收进同一个浏览器页面。

它的思路很直接：用开放协议连接多个 Agent，用兼容 API 接入模型，再把部署和前端尽量做轻。对程序员有用的，是这套统一入口如何减少操作摩擦，以及「自托管、离线、免费」分别在哪些条件下成立。

一个 Allow 按钮，解决的是等待被遗漏

作者曾同时安装四个编程 Agent，每个工具都有自己的命令和权限提示。他离开一会儿再回来，才发现任务一直卡在某个被遗忘的窗口里，等着批准。

AgentWebUI 把这个过程搬进网页：先选 Agent，再选模型、推理投入程度（effort）和工作目录，随后查看流式输出的思考内容、计划、工具调用和文件差异。需要审批时，在同一处点击 Allow 或 Deny。

它统一的是人查看进度、审核改动和作出决定的入口。

这对远程运行任务尤其有用。作者描述，自己可以把任务交给家中服务器上的 Agent，关掉笔记本，之后换一台设备用浏览器检查；不必为了确认有没有卡住，专门 SSH 登录。

但标题里的「只按 Allow」不能照字面理解。正文明确写了要先读 diff，再决定是否允许。按钮集中之后，审核责任仍然在人身上；原文也没有详细说明不同 Agent 的每一种工具操作如何映射到审批机制。

为什么接更多 Agent，不必重写整套集成

AgentWebUI 实际提供了两条接入路径。

一条是模型聊天，连接任何 OpenAI-compatible API。原文列出的服务包括 OpenAI、OpenRouter、NVIDIA、Groq，以及可以部署在本机的 Ollama、LM Studio、vLLM。它们负责回答问题，不等于自动获得了修改项目文件的能力。

另一条是编程 Agent，通过标准输入输出（stdio）使用 Agent Client Protocol，简称 ACP。大白话解释：网页服务和 Agent 按共同约定交换消息，界面就不用为每个工具分别设计一套通信方式。

原文列出的 Agent 有 Claude Code、Codex、Gemini CLI、OpenCode、Hermes 和 Pi。其中 Claude Code、Codex 通过 ACP adapter 接入，因此不能把列表理解为它们都原生支持 ACP。

作者认为，开放协议让团队只需维护一个客户端，新增 Agent 通常主要是补配置。这是合理的架构收益，但协议统一不代表功能完全一致。各个适配器能暴露哪些模型选项、如何呈现工具调用，原文没有逐项说明。

作者的日常分工也值得借鉴：简单问题交给本地模型，复杂任务再使用付费服务。他们的配置中，Llama 3.2 3B 通过 Ollama 本地运行，旁边还有开放权重的 DeepSeek 模型。比如解释一段正则，不必每次都调用付费模型。

这里的「免费」指不再为这些本地请求支付云端 token 费用，不能据此推断运行没有硬件成本，也不能推断小模型能替代复杂编程任务。

轻量来自主动减掉功能，部署仍有前提

团队此前已有一个逐渐长成完整控制台的版本，现在叫 AgentWebUI Pro。这次为了 Hacktoberfest Open-Source AI Challenge Week 3，他们重新做了较小的 AgentWebUI，原则是新增重量必须有足够理由。

后端约 3,000 行 Python，只有 aiohttp 一个依赖，作者给出的内存占用约为 40 MB。前端使用 Preact 搭配 htm，没有构建步骤，不需要 bundler 或 node_modules，修改文件后刷新即可查看。

这组选择适合一个功能集中的自托管工具：维护者少一套构建链，使用者也少一些部署环节。不过，40 MB 描述的是服务端，不能算成本地大模型的运行内存；原文没有给出测量环境、并发量或压力测试结果。

配置统一放在 .env，没有账号和设置向导，包名与命令仍叫 agentwebui-lite。下面四条命令完成原文给出的 Docker 启动流程：

git clone https://github.com/HackersHostel/AgentWebUI.git
cd AgentWebUI
cp .env.example .env   # add your models and agents
docker compose up -d

要留意第三行：复制配置模板后，还要填写模型和 Agent 配置，四条命令并不代表这些依赖已经自动配好。若要在 VPS 或家庭服务器上作为服务运行，项目另有安装脚本，负责配置 systemd 和提供 HTTPS 的 Caddy。

页面默认使用 Geist 字体，作者称页面本身不加载外部资源，切换其他字体则可能例外。配合本地模型，即使外网中断，聊天部分仍可继续。这个需求来自作者在孟加拉国遇到的停电和网络不稳定问题。

离线成立的范围是本地模型聊天，Claude Code、Codex 等云端 Agent 仍然需要联网。

我的判断

这个项目选对了一个具体问题：当多个 Agent 都会停下来等人批准时，统一审批入口确实比记住各自的提示方式省心。与厂商客户端相比，它的优势是跨工具集中管理；与多个终端窗口相比，它还提供了浏览器访问入口。

但收益主要来自作者的日常使用反馈。原文没有给出节省时间、审批遗漏次数或任务完成率的对照数据，所以「更省事」目前是经验之谈，不能扩大成效率提升的量化结论。如果只使用一个 Agent，原有客户端可能已经足够。

自托管也需要拆开看。网页和任务目录由自己控制，不代表所选云模型不会接收代码上下文；页面不加载外部资源，也不代表 Agent 没有外部请求。原文没有展开这些数据流，更没有完整说明远程访问的鉴权方案。「没有账号」是配置简化，不能直接当作可以公开暴露服务的依据。

此外，它明确不做全面的 Agent 集群管理，那是 AgentWebUI Pro 的定位。更多 Agent 支持、测试、界面、无障碍和文档仍在待办列表里。是否适合长期使用，还要看你依赖的那条接入路径是否成熟。

能拿来做什么

• 如果你经常同时使用两个以上编程 Agent，可以挑一个小范围的前端或 Node 修改任务试用，重点观察审批能否及时出现、diff 是否足够清楚，以及失败后能否定位原因。
• 如果简单问答占了不少付费调用，可以尝试用 Ollama 运行原文提到的 Llama 3.2 3B，先处理正则解释等短问题，再根据实际回答质量决定分工。
• 如果任务常跑在家中服务器或 VPS 上，可以评估浏览器检查进度是否能减少 SSH 操作，同时先弄清部署入口如何限制访问，以及所用 ACP 适配器支持哪些能力。
• 如果你也在做内部 AI 工具，可以参考它用 OpenAI-compatible API 接模型、用 ACP 接 Agent 的分层方式；先验证必需功能，再判断是否需要额外的控制台和构建链。