你是不是也遇到过这种场景Agent 任务在服务器上跑得好好的突然卡住了。你看一眼手机里的日志推送原来是 Agent 在执行一个高风险操作需要人工确认。它等你授权而你不在电脑旁边。你能想象这个画面吗代码写完了、环境也配好了Agent 到了“临门一脚”却被一个权限点卡住直到你赶回工位点一下回车或点击“允许”。更让人难受的是这种打断不是一次两次。跑一个大的 Agent 任务可能在午休时弹一次在通勤路上弹一次在晚上下班后又弹一次。你反复被拉回电脑面前只为点一个“确认继续”。如果只看表面很容易误以为这是“安全设计太啰嗦”。但深一层看真正的瓶颈其实是Agent 的执行流和人的审批流被绑在了同一个物理位置。明明已经可以用手机办公了审批却还得回到电脑。这就是 botmux 这一类工具存在的意义把 Agent 的权限交互从电脑屏幕搬到飞书消息里。这篇文章会讲清楚 botmux 是什么、它的核心架构、为什么选择飞书作为控制平面然后直接给出一个可以跑通的示例创建飞书应用、配置事件订阅、部署 botmux 服务、接入 Agent、用手机在飞书上点击“允许”或“拒绝”。1. 被“回电脑点授权”打断的 Agent 工作流先说一个真实的工作流困境。很多 Agent 框架为了安全会在执行敏感指令前要求用户确认。比如删除文件或清空目录执行一条可能影响线上服务的命令调用第三方的付费 API修改生产环境的配置发布代码。当 Agent 遇到这些操作时它会暂停执行等待用户确认。这个设计的初衷没问题避免机器在无人监督的情况下做出破坏性动作。真正的问题出在交互方式上。大多数本地运行的 Agent 框架确认交互是在终端里完成的。终端在电脑上所以你必须在电脑前。一旦人不在电脑旁整个 Agent 流程就被“卡死”。等待期间Agent 不干活、不推进、不自己判断因为设计上不允许它跳过授权。这种模式有几类明显问题第一响应及时性差。一个需要五分钟就能完成的审批可能因为人不在电脑前拖了半小时甚至更久。Agent 本来能帮你节省时间结果反而因为等待审批变得更慢。第二中断率高。如果 Agent 任务涉及多个工具调用每个工具调用都可能触发一次授权。次数一多你很难一直守在电脑旁。第三多 Agent 场景更难管理。如果你同时跑五个 Agent每个都可能在不同时间点请求授权。你需要在多个终端窗口之间来回切换容易漏掉、误点。第四缺乏审计记录。终端里弹出的确认窗口没有统一留痕。事后复盘某个 Agent 到底执行了什么你只能翻历史日志而且不一定找得到完整的授权链路。我个人的判断是Agent 发展的下一个关键不再只是模型有多聪明而是“人在环上”的交互设计有多顺滑。如果人的审批链路是顺畅的Agent 就能长时间自主运行只在真正需要的时候打断人。如果审批链路是笨重的Agent 就会被“硬件设备”绑架跑不远。botmux 解决的正是这个问题。它不是一个 Agent 框架也不是一个模型而是一个连接层把 Agent 的权限请求路由到飞书把人通过飞书反馈的结果带回给 Agent。2. botmux 是什么一条连接飞书与 Agent 的消息总线“botmux”这个名字可以拆成两部分理解。“bot”指机器人或 Agent 进程“mux”是多路复用multiplex的缩写。所以 botmux 本质上是一个机器人多路复用网关它负责管理多个 Agent 与用户之间的通信、权限确认和指令路由。你可以把它理解成 Agent 世界的“前台接线员”。Agent 不直接面对用户它把请求发给 botmuxbotmux 决定这条请求应该发给谁、用什么格式、需要什么审批级别。用户通过飞书做出的回应也由 botmux 负责接收并转回给对应的 Agent。从技术定位来看botmux 属于控制平面Control Plane和执行平面Execution Plane之间的中间层。Agent 的运行环境是执行平面负责真正干活飞书上的消息和卡片是控制平面负责人的决策。没有 botmux 时控制平面和执行平面耦合在一起有 botmux 后两者通过 API 解耦。那么botmux 到底做了什么从功能上看它至少包含四个核心模块。第一个是消息路由模块。多个 Agent 可以注册到 botmux 上每个 Agent 有一个自己的 ID。当 Agent 发起请求时botmux 会根据 agent_id 找到对应的回调地址、审批人列表和审批渠道。第二个是审批流模块。botmux 内部维护一个“待审批请求表”。Agent 的每个权限请求会生成一个唯一的 request_id绑上 action、detail、callback 和超时时间。用户审批后botmux 会根据 request_id 触发回调把结果返回给 Agent。第三个是渠道适配模块。botmux 不限定只能接飞书理论上可以接钉钉、企业微信、Slack 等。微信公众号、钉钉、飞书的机器人接口各有差异botmux 通过适配器屏蔽了这些差异。对于开发者来说只需要关心业务层面的配置不需要关心各个平台的 API 细节。第四个是审计与日志模块。每一次审批请求、审批结果、超时情况都应该被记录。这样当 Agent 执行出现问题时可以回溯到具体的授权环节判断是谁批准了什么操作。用一句话概括botmux 把“人确认 Agent 操作”这个动作从靠位置的交互变成了靠消息的交互。它与远程桌面不同。远程桌面是把整个电脑画面搬到手机里你看到的还是终端窗口还是要去找那一个待确认的按钮。botmux 则把“是否允许执行”这个信息单独提炼出来用结构化的卡片消息推送到飞书把审批成本降到最低。它与自动跳过审批也完全不同。自动跳过等于放弃安全边界风险很高。botmux 不是让你取消审批而是让审批更快、更便捷、更可控。人仍然是决策的主体。3. 为什么控制平面选飞书可能有人会问为什么控制平面选飞书而不是自己做一个 Web 管理后台也不是不行但飞书有几个实际优势。第一飞书本身就是高频办公工具。审批动作通常发生在工作间隙而不是专门打开一个后台页面。如果审批入口在飞书里你随时都能看到不需要额外下载和登录一个独立系统。消息推送会主动通知你比自己去刷后台高效得多。第二飞书机器人支持交互式卡片。这是非常关键的一点。一个授权确认不只包含“同意”和“拒绝”两个按钮你可能还需要看到Agent 要执行什么命令涉及哪个文件目标环境是什么在飞书卡片上这些信息可以结构化展示按钮的动作值也可以携带 request_id、decision 等参数。用户点一下按钮卡片回调就带着上下文回到 botmux省略了一大堆解析工作。第三飞书开放平台的事件订阅机制比较成熟。机器人可以接收用户消息、卡片交互、加群事件等。botmux 通过飞书事件订阅可以实时感知用户的操作并做出响应。相比轮询这种机制更及时也更省资源。第四飞书在团队协作中的渗透率比较高。如果你的 Agent 服务需要团队共用飞书群本身就是一个天然的审批中心。你可以把某个 Agent 的审批人配置成群成员或指定某个群为审批群。审批记录也能在群消息里留存方便追溯。有人会担心如果团队不用飞书怎么办这个顾虑很正常。botmux 的设计思路并不绑定某个特定平台。只要渠道适配器实现对应的接口把飞书换成钉钉、企业微信或者自研的消息系统改动成本是可控的。你真正需要理解的是“审批消息化”这个模式而不只是某一个平台的配置。当然飞书也有一些值得注意的边界。比如机器人应用需要企业管理员审批开通权限范围需要合理配置。另外飞书开放平台的部分能力需要企业认证后才能使用。这些问题不是 botmux 能替你解决的属于使用飞书本身的成本。4. 整体架构与消息流转模型在动手写代码之前先把架构讲清楚。下面这组组件是 botmux 模式的核心组件作用代表实现Agent 执行进程运行实际任务遇到敏感操作时发起审批请求本地 Python 进程、OpenClaw、自研 Agentbotmux 核心管理 Agent 注册、审批请求路由、超时和回调botmux 服务渠道适配器对接具体消息平台负责发送卡片、接收回调飞书适配器消息平台把审批内容呈现给用户收集用户决策飞书审计存储记录审批请求、审批结果、超时事件MySQL、SQLite、飞书多维表格一个典型的审批流转过程如下Agent 执行到某一步判断需要人工授权。Agent 调用 botmux API传入请求内容例如“执行 rm -rf /tmp/cache”。botmux 生成 request_id并写入 pending_requests将请求标记为“等待审批”。botmux 调用飞书适配器向指定的用户或群发送一张审批卡片卡片包含操作说明和两个按钮“允许”和“拒绝”。用户在飞书上点击“允许”。飞书平台把卡片回调事件推送到 botmux。botmux 校验事件签名解析出 request_id 和 decision。botmux 在 pending_requests 中找到对应的 Future 或等待对象把决策结果写回。botmux 向 Agent 返回 HTTP 响应内容包含 decisionallow。Agent 收到结果继续执行后续逻辑。从时序上看Agent 侧发起的请求是同步等待的。也就是说Agent 发送审批请求后就保持连接挂起直到 botmux 返回结果。如果用户在飞书上一直不点那么这个请求会在超时时间之后返回“超时”状态Agent 根据业务决定退出还是跳过。这里真正容易踩坑的地方是一个 Agent 任务可能在短时间内发起多个审批请求如果只用 request_id 做标识但要保证全局唯一。设计上不能用 agent_id action 作为主键因为同一个 action 可能被执行两次。更稳妥的做法是每次审批都生成一个 UUID。另一个容易踩坑的地方是飞书的回调事件可能由于网络抖动重复推送。botmux 在解析回调时必须做幂等处理。同一个 request_id 的回调如果已经处理过一次后续重复到达时需要直接忽略不能重复触发 Agent 的同一段逻辑。5. 环境准备与前置条件下面进入实操阶段。为了让示例跑通需要准备以下环境。操作系统Linux 或 macOS建议 Linux 云服务器毕竟你的 Agent 很可能跑在服务器上。运行环境Python 3.9 以上用于跑 botmux 服务端和 Agent 示例。依赖管理pip 或 Poetry按你的习惯选择。消息平台飞书开放平台账号具备创建企业自建应用的权限。Agent 框架本文不限定具体框架用简单 Python 脚本演示接入逻辑。如果你想接 OpenClaw需要用类似的方式调用 botmux API。关于版本这里说明一下不同项目的安装方式和依赖版本会有差异。下面演示的代码重点在于讲解实现思路具体的版本号请以实际项目文档为准不建议直接照搬。建议先在一个隔离的测试环境中操作避免影响已有的 Agent 服务。如果你打算在生产环境接入最好先用一台独立的测试机器完成验证。6. 飞书开放平台应用配置botmux 要和飞书通信第一步是创建飞书应用。在飞书开放平台后台选择“创建企业自建应用”填写应用名称和描述。创建完成后进入应用详情页依次完成以下配置。6.1 添加机器人能力在“应用能力”中找到“机器人”启用机器人能力。之后应用才具备在群聊或单聊中收发消息的权限。启用后你会看到一个机器人它可以被添加到群聊中。6.2 配置事件订阅这一步比较关键。botmux 需要接收两类事件用户发送给机器人的消息事件用户在卡片上点击按钮产生的交互回调。在“事件订阅”页面有两种接入模式长连接模式和 Webhook 模式。长连接模式的优势是不需要暴露公网 IPbotmux 通过 WebSocket 和飞书保持长连接。适合部署在私网环境、没有公网入口的服务器。Webhook 模式则需要一个公网可访问的 HTTPS 地址飞书平台会把事件 POST 到这个地址。从工程实践看个人部署推荐长连接模式省去公网和域名配置。企业级部署如果已经有网关Webhook 模式会更灵活。本文示例用的是事件接收框架你可以按自己的场景选择代码逻辑差异不大。6.3 配置权限范围要让机器人发送消息需要申请以下权限im:message读取用户发给机器人的消息im:message:send_as_bot以机器人身份发送消息如果需要读取用户信息可以追加contact:user.base:readonly。权限申请后需要发布版本并等待管理员审核。在测试阶段也可以先使用企业内自建应用提供的测试权限但要注意权限生效时间和范围。6.4 获取密钥信息完成以上配置后在“凭证与基础信息”页面可以拿到App ID格式类似cli_xxxxApp Secret事件订阅中的 Encrypt Key 和 Verification Token。这些信息需要在 botmux 配置文件中填写。实际操作中App Secret 和 Encrypt Key 应该存在环境变量或密钥管理服务里不要直接写死在代码仓库。7. botmux 服务端搭建与授权流转实现下面开始搭建 botmux 服务端。我用 FastAPI 作为示例框架因为它写异步接口比较简洁。在项目目录下创建虚拟环境并安装依赖python -m venv venv source venv/bin/activate pip install fastapi uvicorn httpx python-dotenv然后创建 botmux 的配置文件。这里用 YAML 保存 Agent 注册信息和飞书配置。如果项目提供了配置模板以项目模板为准。# config/botmux.yaml server: host: 0.0.0.0 port: 7080 feishu: app_id: cli_xxxx app_secret: your_app_secret encrypt_key: your_encrypt_key verification_token: your_verification_token # long_connection 表示长连接模式webhook 表示接收飞书回调 mode: long_connection agents: - id: code-agent name: 代码 Agent # 审批结果将发送到这个飞书用户 approver: ou_xxxx timeout_seconds: 300 - id: data-agent name: 数据 Agent approver: ou_yyyy timeout_seconds: 600这里解释一下配置项的含义。server.host和server.port是 botmux 服务的监听地址。feishu部分存放飞书开放平台的应用凭证。agents列表声明了允许接入的 Agent每个 Agent 都有独立的审批人。timeout_seconds表示用户如果长时间不操作审批请求超过该时间后自动超时。接下来是服务端主代码。我把 pending approval 的存储放在内存里用 asyncio.Future 配合超时控制。# app/main.py import asyncio import uuid from typing import Dict from fastapi import FastAPI, Request from pydantic import BaseModel app FastAPI() # 存储待审批请求。key: request_id, value: asyncio.Future pending_requests: Dict[str, asyncio.Future] {} class ApprovalRequest(BaseModel): agent_id: str action: str detail: str timeout: int 300 callback_url: str class ApprovalResponse(BaseModel): request_id: str decision: str reason: str async def push_to_feishu(msg_dict: dict): 向飞书发送审批卡片。 这里需要改成你的飞书适配器实现 调用飞书开放平台接口发送含审批按钮的卡片。 # 实际项目中这里用飞书 SDK 或自己实现的 HTTP 调用 print([feishu] send message:, msg_dict) app.post(/botmux/v1/approval-request) async def create_approval_request(req: ApprovalRequest): request_id uuid.uuid4().hex loop asyncio.get_running_loop() future loop.create_future() pending_requests[request_id] future # 把审批请求推送到飞书 await push_to_feishu({ request_id: request_id, agent_id: req.agent_id, action: req.action, detail: req.detail, }) try: decision await asyncio.wait_for(future, timeoutreq.timeout) return { request_id: request_id, decision: decision, } except asyncio.TimeoutError: pending_requests.pop(request_id, None) return { request_id: request_id, decision: timeout, } app.post(/botmux/v1/callback) async def feishu_callback(request: Request): 接收飞书卡片交互回调。 飞书会 POST 一个 JSON 到这个地址里面包含按钮动作。 在生产环境必须校验飞书回调签名防止伪造请求。 payload await request.json() # 1. 校验签名防止伪造回调查看下一节 # 2. 解析 action.value从中取出 request_id 和 decision action_value payload.get(action, {}).get(value, {}) request_id action_value.get(request_id) decision action_value.get(decision) if not request_id or not decision: return {code: 400, msg: invalid payload} # 3. 幂等处理如果该请求已经被处理过直接忽略 if request_id not in pending_requests: return {code: 0, msg: already processed} # 4. 把决策写入 Future唤醒正在等待的 Agent 请求 future pending_requests.pop(request_id) future.set_result(decision) return {code: 0, msg: ok}这段代码的逻辑很清晰Agent 调用审批接口后请求会被挂起等待飞书回调。当用户在飞书上点击“允许”或“拒绝”回调接口会解析出 request_id 和 decision唤醒对应的 Future返回给 Agent。有一个细节值得注意飞书回调里按钮的 value 字段需要你在发送卡片时定义好。下面是一个简化的卡片构造示例展示如何绑定动作值{ msg_type: interactive, card: { header: { title: {tag: plain_text, content: Agent 审批请求} }, elements: [ { tag: div, text: { tag: lark_md, content: Agent code-agent 请求执行\nrm -rf /tmp/cache } }, { tag: action, actions: [ { tag: button, text: {tag: plain_text, content: 允许}, type: primary, value: { request_id: REPLACE_WITH_REQUEST_ID, decision: allow } }, { tag: button, text: {tag: plain_text, content: 拒绝}, type: danger, value: { request_id: REPLACE_WITH_REQUEST_ID, decision: deny } } ] } ] } }这个卡片的 JSON 结构就是飞书交互卡片的标准格式。你在 botmux 的飞书适配器里需要把REPLACE_WITH_REQUEST_ID替换成真实的 request_id。8. Agent 侧接入与完整示例Agent 侧要做的事情很简单在需要人工确认的地方调用 botmux 的审批 API等待结果。假设你有一个函数delete_cache()正常情况下它会直接执行删除。现在需要包一层授权逻辑。# agent_example.py import requests BOTMUX_URL http://127.0.0.1:7080 def request_approval(agent_id: str, action: str, detail: str, timeout: int 60): 向 botmux 发起审批请求等待用户决策。 返回 True 表示允许False 表示拒绝或超时。 resp requests.post( f{BOTMUX_URL}/botmux/v1/approval-request, json{ agent_id: agent_id, action: action, detail: detail, timeout: timeout, }, timeouttimeout 10, ) resp.raise_for_status() result resp.json() return result.get(decision) allow def delete_cache_with_approval(): approved request_approval( agent_idcode-agent, actionexecute_command, detailrm -rf /tmp/cache, timeout120, ) if not approved: print(未获得授权跳过删除操作) return False # 这里是真正执行删除的代码 import shutil shutil.rmtree(/tmp/cache, ignore_errorsTrue) print(缓存已删除) return True if __name__ __main__: delete_cache_with_approval()在这个示例里Agent 在真正执行危险操作之前会先通过 botmux 发起一次审批。审批通过后才执行否则直接跳过。在更复杂的 Agent 框架中你可以把request_approval封装成一个工具函数挂载到 Agent 的 Tool 调用链里。每次 Agent 准备调用高权限工具时先在工具层触发一次审批。这样不用修改 Agent 的核心逻辑侵入性会小很多。最典型的封装方式是写一个装饰器给需要审批的函数自动加一层授权检查。这样代码会更整洁也更适合在团队内复用。9. 运行验证与效果检查现在把整个链路跑起来验证。9.1 启动 botmux 服务uvicorn app.main:app --host 0.0.0.0 --port 7080看到类似Uvicorn running on http://0.0.0.0:7080的日志说明服务启动成功。9.2 模拟 Agent 发起审批请求打开另一个终端执行curl -X POST http://127.0.0.1:7080/botmux/v1/approval-request \ -H Content-Type: application/json \ -d { agent_id: code-agent, action: execute_command, detail: rm -rf /tmp/cache, timeout: 60 }执行后curl 会保持等待状态因为 botmux 正在等待飞书回调。9.3 在飞书上完成审批打开飞书你应该能收到 botmux 发送的审批卡片。点击“允许”后观察 botmux 服务端日志。日志会打印出飞书回调的处理过程。如果你在飞书上点击了“允许”再回到终端会发现 curl 返回了类似下面的 JSON{request_id:a1b2c3d4...,decision:allow}如果你一直没有点击超过 timeout 时间后curl 会返回{request_id:a1b2c3d4...,decision:timeout}9.4 判断链路是否走通判断标准有三个飞书收到了卡片并能看到操作详情点击按钮后curl 能收到对应的决策结果重复点击同一个按钮不会产生重复处理。如果第 1 步失败优先排查飞书应用的权限和事件订阅配置。如果第 2 步失败优先检查回调地址是否可达、签名校验是否通过。如果第 3 步失败说明幂等处理有 bug需要检查pending_requests里的 request_id 是否在第一次处理时被正确移除。10. 常见问题与排查思路下面整理了一些常见问题按“现象、可能原因、排查方式、解决方案”的顺序列出。问题现象可能原因排查方式解决方案飞书没有收到审批卡片飞书应用权限不足或机器人未启用检查应用权限列表在飞书中确认应用是否已添加机器人添加im:message:send_as_bot权限重新发布应用版本卡片收到了但点击按钮后 Agent 没反应回调地址无法访问或签名校验失败查看 botmux 日志用 curl 手动模拟回调确认回调 URL 能被飞书访问检查签名算法和 token点击按钮后收到 “invalid payload”action.value 里没有 request_id 或 decision打印飞书回调原始 JSON检查卡片 action.value 是否包含正确字段重复点击按钮导致 Agent 执行两次幂等处理有缺陷观察 pending_requests 日志在第一次处理时立即 pop request_id后续请求直接忽略审批超时时间太短用户来不及操作timeout 配置不合理查看请求参数设置更长的 timeout或在配置层给定默认值Agent 并发请求多个审批时结果互相串request_id 生成冲突检查 request_id 是否唯一使用 uuid4 或雪花 ID 生成唯一标识部署在私网环境飞书 Webhook 推不进来没有公网入口检查网络拓扑改用飞书长连接模式避免对外开放公网端口排查的顺序建议是先看飞书是否收到消息再看按钮点击后是否触发回调最后看 botmux 是否把结果返回给了 Agent。一层一层往后走定位效率最高。11. 最佳实践与工程建议11.1 审批请求必须幂等消息平台存在重试机制飞书的回调可能重复推送。如果你在回调里直接执行 Agent 的任务而不是只解除等待很可能造成重复执行。正确做法是回调只负责把 request_id 对应的 Future 设置为终态真正的 Agent 任务由等待方执行。11.2 回调必须验签飞书的回调接口暴露在公网或内网中如果不验签任何人都可以伪造一个“允许”的请求绕过人工审批。后果很严重攻击者让 Agent 执行任意命令。所以验签不是可选项而是必须项。验签逻辑建议放在依赖边界上。botmux 的飞书适配器收到回调后第一步就是验证签名验证不通过直接拒绝。如果需要二次校验可以再用 verification_token 做一次轻量校验。11.3 最小权限原则Agent 不是什么东西都能执行的。在 botmux 配置里可以为不同 Agent 设置不同的审批等级。比如只读操作可以自动执行不需要审批低风险写操作记录日志即可高风险操作必须飞书审批极端风险操作必须到达指定审批人且可能需要两个以上审批人。审批等级不应该写死在 Agent 代码里而应该由 botmux 统一管理。这样调整权限时不需要改动 Agent。11.4 超时和降级策略审批请求不能无限等待。应该为每个请求设置合理超时并在超时后触发降级策略。降级策略可以是“跳过该操作”“回滚到上一个状态”“直接终止任务”。具体选哪种取决于这个操作对任务的影响。另一个建议是不要在 Agent 的核心执行线程里等待审批过久否则会阻塞其他任务。可以考虑把审批挂起的时间计入任务执行时间超过一定阈值后切换到其它可独立运行的任务。11.5 审计记录建议接入飞书多维表格botmux 每次审批请求处理完成后可以写一条审计记录字段包括request_id、agent_id、action、detail、决策人、决策时间、决策结果。这个记录除了写入本地日志也可以写入飞书多维表格。多维表格天然适合做筛选和统计团队复盘时可以直接看到审批链路。把审计数据和飞书消息放在同一平台减少了取数成本。11.6 环境区分与配置管理开发环境、测试环境、生产环境应该使用不同的飞书应用。不要把生产环境的 App Secret 放在开发机里。配置信息用环境变量或专门的配置中心管理不要在代码仓库里提交明文密钥。12. 总结与后续学习方向写到这里本文的核心内容已经讲完了。我们围绕“Agent 授权卡在电脑上”这个痛点拆解了 botmux 的架构它作为消息总线把 Agent 的权限请求路由到飞书再把人在飞书上的决策返回给 Agent。文中给出了一个基于 FastAPI 的最小实现包含审批请求接口、飞书回调接口、Agent 侧工具函数和飞书交互卡片的 JSON 示例。这个最小实现能帮你理解整个链路也能作为你自己项目的起点。如果你正在做 Agent 开发下一步可以沿着这几个方向继续深入把审批请求从内存存储升级为 Redis 或数据库存储解决多实例部署时的状态不一致问题加入多级审批流支持不同操作需要不同审批人的场景把 Agent 的授权链路接到自己的日志系统或审计平台研究飞书长连接模式的断线重连机制提升长稳运行的可靠性如果 Agent 框架支持 Tool Call 拦截把 botmux 审批封装成通用的 Tool Wrapper做到对上层无感。最后提醒一句任何安全设计都不能完全依赖某一个中间件。botmux 为人提供了更便捷的审批入口但 Agent 本身的权限控制、文件系统隔离、网络访问策略仍然需要你配置好。审批只是最后一道防线而不是唯一防线。建议保存这份流程清单实际操作时对照检查至少能帮你少踩一半的坑。
用botmux把Agent审批搬到飞书，告别电脑前等待
你是不是也遇到过这种场景Agent 任务在服务器上跑得好好的突然卡住了。你看一眼手机里的日志推送原来是 Agent 在执行一个高风险操作需要人工确认。它等你授权而你不在电脑旁边。你能想象这个画面吗代码写完了、环境也配好了Agent 到了“临门一脚”却被一个权限点卡住直到你赶回工位点一下回车或点击“允许”。更让人难受的是这种打断不是一次两次。跑一个大的 Agent 任务可能在午休时弹一次在通勤路上弹一次在晚上下班后又弹一次。你反复被拉回电脑面前只为点一个“确认继续”。如果只看表面很容易误以为这是“安全设计太啰嗦”。但深一层看真正的瓶颈其实是Agent 的执行流和人的审批流被绑在了同一个物理位置。明明已经可以用手机办公了审批却还得回到电脑。这就是 botmux 这一类工具存在的意义把 Agent 的权限交互从电脑屏幕搬到飞书消息里。这篇文章会讲清楚 botmux 是什么、它的核心架构、为什么选择飞书作为控制平面然后直接给出一个可以跑通的示例创建飞书应用、配置事件订阅、部署 botmux 服务、接入 Agent、用手机在飞书上点击“允许”或“拒绝”。1. 被“回电脑点授权”打断的 Agent 工作流先说一个真实的工作流困境。很多 Agent 框架为了安全会在执行敏感指令前要求用户确认。比如删除文件或清空目录执行一条可能影响线上服务的命令调用第三方的付费 API修改生产环境的配置发布代码。当 Agent 遇到这些操作时它会暂停执行等待用户确认。这个设计的初衷没问题避免机器在无人监督的情况下做出破坏性动作。真正的问题出在交互方式上。大多数本地运行的 Agent 框架确认交互是在终端里完成的。终端在电脑上所以你必须在电脑前。一旦人不在电脑旁整个 Agent 流程就被“卡死”。等待期间Agent 不干活、不推进、不自己判断因为设计上不允许它跳过授权。这种模式有几类明显问题第一响应及时性差。一个需要五分钟就能完成的审批可能因为人不在电脑前拖了半小时甚至更久。Agent 本来能帮你节省时间结果反而因为等待审批变得更慢。第二中断率高。如果 Agent 任务涉及多个工具调用每个工具调用都可能触发一次授权。次数一多你很难一直守在电脑旁。第三多 Agent 场景更难管理。如果你同时跑五个 Agent每个都可能在不同时间点请求授权。你需要在多个终端窗口之间来回切换容易漏掉、误点。第四缺乏审计记录。终端里弹出的确认窗口没有统一留痕。事后复盘某个 Agent 到底执行了什么你只能翻历史日志而且不一定找得到完整的授权链路。我个人的判断是Agent 发展的下一个关键不再只是模型有多聪明而是“人在环上”的交互设计有多顺滑。如果人的审批链路是顺畅的Agent 就能长时间自主运行只在真正需要的时候打断人。如果审批链路是笨重的Agent 就会被“硬件设备”绑架跑不远。botmux 解决的正是这个问题。它不是一个 Agent 框架也不是一个模型而是一个连接层把 Agent 的权限请求路由到飞书把人通过飞书反馈的结果带回给 Agent。2. botmux 是什么一条连接飞书与 Agent 的消息总线“botmux”这个名字可以拆成两部分理解。“bot”指机器人或 Agent 进程“mux”是多路复用multiplex的缩写。所以 botmux 本质上是一个机器人多路复用网关它负责管理多个 Agent 与用户之间的通信、权限确认和指令路由。你可以把它理解成 Agent 世界的“前台接线员”。Agent 不直接面对用户它把请求发给 botmuxbotmux 决定这条请求应该发给谁、用什么格式、需要什么审批级别。用户通过飞书做出的回应也由 botmux 负责接收并转回给对应的 Agent。从技术定位来看botmux 属于控制平面Control Plane和执行平面Execution Plane之间的中间层。Agent 的运行环境是执行平面负责真正干活飞书上的消息和卡片是控制平面负责人的决策。没有 botmux 时控制平面和执行平面耦合在一起有 botmux 后两者通过 API 解耦。那么botmux 到底做了什么从功能上看它至少包含四个核心模块。第一个是消息路由模块。多个 Agent 可以注册到 botmux 上每个 Agent 有一个自己的 ID。当 Agent 发起请求时botmux 会根据 agent_id 找到对应的回调地址、审批人列表和审批渠道。第二个是审批流模块。botmux 内部维护一个“待审批请求表”。Agent 的每个权限请求会生成一个唯一的 request_id绑上 action、detail、callback 和超时时间。用户审批后botmux 会根据 request_id 触发回调把结果返回给 Agent。第三个是渠道适配模块。botmux 不限定只能接飞书理论上可以接钉钉、企业微信、Slack 等。微信公众号、钉钉、飞书的机器人接口各有差异botmux 通过适配器屏蔽了这些差异。对于开发者来说只需要关心业务层面的配置不需要关心各个平台的 API 细节。第四个是审计与日志模块。每一次审批请求、审批结果、超时情况都应该被记录。这样当 Agent 执行出现问题时可以回溯到具体的授权环节判断是谁批准了什么操作。用一句话概括botmux 把“人确认 Agent 操作”这个动作从靠位置的交互变成了靠消息的交互。它与远程桌面不同。远程桌面是把整个电脑画面搬到手机里你看到的还是终端窗口还是要去找那一个待确认的按钮。botmux 则把“是否允许执行”这个信息单独提炼出来用结构化的卡片消息推送到飞书把审批成本降到最低。它与自动跳过审批也完全不同。自动跳过等于放弃安全边界风险很高。botmux 不是让你取消审批而是让审批更快、更便捷、更可控。人仍然是决策的主体。3. 为什么控制平面选飞书可能有人会问为什么控制平面选飞书而不是自己做一个 Web 管理后台也不是不行但飞书有几个实际优势。第一飞书本身就是高频办公工具。审批动作通常发生在工作间隙而不是专门打开一个后台页面。如果审批入口在飞书里你随时都能看到不需要额外下载和登录一个独立系统。消息推送会主动通知你比自己去刷后台高效得多。第二飞书机器人支持交互式卡片。这是非常关键的一点。一个授权确认不只包含“同意”和“拒绝”两个按钮你可能还需要看到Agent 要执行什么命令涉及哪个文件目标环境是什么在飞书卡片上这些信息可以结构化展示按钮的动作值也可以携带 request_id、decision 等参数。用户点一下按钮卡片回调就带着上下文回到 botmux省略了一大堆解析工作。第三飞书开放平台的事件订阅机制比较成熟。机器人可以接收用户消息、卡片交互、加群事件等。botmux 通过飞书事件订阅可以实时感知用户的操作并做出响应。相比轮询这种机制更及时也更省资源。第四飞书在团队协作中的渗透率比较高。如果你的 Agent 服务需要团队共用飞书群本身就是一个天然的审批中心。你可以把某个 Agent 的审批人配置成群成员或指定某个群为审批群。审批记录也能在群消息里留存方便追溯。有人会担心如果团队不用飞书怎么办这个顾虑很正常。botmux 的设计思路并不绑定某个特定平台。只要渠道适配器实现对应的接口把飞书换成钉钉、企业微信或者自研的消息系统改动成本是可控的。你真正需要理解的是“审批消息化”这个模式而不只是某一个平台的配置。当然飞书也有一些值得注意的边界。比如机器人应用需要企业管理员审批开通权限范围需要合理配置。另外飞书开放平台的部分能力需要企业认证后才能使用。这些问题不是 botmux 能替你解决的属于使用飞书本身的成本。4. 整体架构与消息流转模型在动手写代码之前先把架构讲清楚。下面这组组件是 botmux 模式的核心组件作用代表实现Agent 执行进程运行实际任务遇到敏感操作时发起审批请求本地 Python 进程、OpenClaw、自研 Agentbotmux 核心管理 Agent 注册、审批请求路由、超时和回调botmux 服务渠道适配器对接具体消息平台负责发送卡片、接收回调飞书适配器消息平台把审批内容呈现给用户收集用户决策飞书审计存储记录审批请求、审批结果、超时事件MySQL、SQLite、飞书多维表格一个典型的审批流转过程如下Agent 执行到某一步判断需要人工授权。Agent 调用 botmux API传入请求内容例如“执行 rm -rf /tmp/cache”。botmux 生成 request_id并写入 pending_requests将请求标记为“等待审批”。botmux 调用飞书适配器向指定的用户或群发送一张审批卡片卡片包含操作说明和两个按钮“允许”和“拒绝”。用户在飞书上点击“允许”。飞书平台把卡片回调事件推送到 botmux。botmux 校验事件签名解析出 request_id 和 decision。botmux 在 pending_requests 中找到对应的 Future 或等待对象把决策结果写回。botmux 向 Agent 返回 HTTP 响应内容包含 decisionallow。Agent 收到结果继续执行后续逻辑。从时序上看Agent 侧发起的请求是同步等待的。也就是说Agent 发送审批请求后就保持连接挂起直到 botmux 返回结果。如果用户在飞书上一直不点那么这个请求会在超时时间之后返回“超时”状态Agent 根据业务决定退出还是跳过。这里真正容易踩坑的地方是一个 Agent 任务可能在短时间内发起多个审批请求如果只用 request_id 做标识但要保证全局唯一。设计上不能用 agent_id action 作为主键因为同一个 action 可能被执行两次。更稳妥的做法是每次审批都生成一个 UUID。另一个容易踩坑的地方是飞书的回调事件可能由于网络抖动重复推送。botmux 在解析回调时必须做幂等处理。同一个 request_id 的回调如果已经处理过一次后续重复到达时需要直接忽略不能重复触发 Agent 的同一段逻辑。5. 环境准备与前置条件下面进入实操阶段。为了让示例跑通需要准备以下环境。操作系统Linux 或 macOS建议 Linux 云服务器毕竟你的 Agent 很可能跑在服务器上。运行环境Python 3.9 以上用于跑 botmux 服务端和 Agent 示例。依赖管理pip 或 Poetry按你的习惯选择。消息平台飞书开放平台账号具备创建企业自建应用的权限。Agent 框架本文不限定具体框架用简单 Python 脚本演示接入逻辑。如果你想接 OpenClaw需要用类似的方式调用 botmux API。关于版本这里说明一下不同项目的安装方式和依赖版本会有差异。下面演示的代码重点在于讲解实现思路具体的版本号请以实际项目文档为准不建议直接照搬。建议先在一个隔离的测试环境中操作避免影响已有的 Agent 服务。如果你打算在生产环境接入最好先用一台独立的测试机器完成验证。6. 飞书开放平台应用配置botmux 要和飞书通信第一步是创建飞书应用。在飞书开放平台后台选择“创建企业自建应用”填写应用名称和描述。创建完成后进入应用详情页依次完成以下配置。6.1 添加机器人能力在“应用能力”中找到“机器人”启用机器人能力。之后应用才具备在群聊或单聊中收发消息的权限。启用后你会看到一个机器人它可以被添加到群聊中。6.2 配置事件订阅这一步比较关键。botmux 需要接收两类事件用户发送给机器人的消息事件用户在卡片上点击按钮产生的交互回调。在“事件订阅”页面有两种接入模式长连接模式和 Webhook 模式。长连接模式的优势是不需要暴露公网 IPbotmux 通过 WebSocket 和飞书保持长连接。适合部署在私网环境、没有公网入口的服务器。Webhook 模式则需要一个公网可访问的 HTTPS 地址飞书平台会把事件 POST 到这个地址。从工程实践看个人部署推荐长连接模式省去公网和域名配置。企业级部署如果已经有网关Webhook 模式会更灵活。本文示例用的是事件接收框架你可以按自己的场景选择代码逻辑差异不大。6.3 配置权限范围要让机器人发送消息需要申请以下权限im:message读取用户发给机器人的消息im:message:send_as_bot以机器人身份发送消息如果需要读取用户信息可以追加contact:user.base:readonly。权限申请后需要发布版本并等待管理员审核。在测试阶段也可以先使用企业内自建应用提供的测试权限但要注意权限生效时间和范围。6.4 获取密钥信息完成以上配置后在“凭证与基础信息”页面可以拿到App ID格式类似cli_xxxxApp Secret事件订阅中的 Encrypt Key 和 Verification Token。这些信息需要在 botmux 配置文件中填写。实际操作中App Secret 和 Encrypt Key 应该存在环境变量或密钥管理服务里不要直接写死在代码仓库。7. botmux 服务端搭建与授权流转实现下面开始搭建 botmux 服务端。我用 FastAPI 作为示例框架因为它写异步接口比较简洁。在项目目录下创建虚拟环境并安装依赖python -m venv venv source venv/bin/activate pip install fastapi uvicorn httpx python-dotenv然后创建 botmux 的配置文件。这里用 YAML 保存 Agent 注册信息和飞书配置。如果项目提供了配置模板以项目模板为准。# config/botmux.yaml server: host: 0.0.0.0 port: 7080 feishu: app_id: cli_xxxx app_secret: your_app_secret encrypt_key: your_encrypt_key verification_token: your_verification_token # long_connection 表示长连接模式webhook 表示接收飞书回调 mode: long_connection agents: - id: code-agent name: 代码 Agent # 审批结果将发送到这个飞书用户 approver: ou_xxxx timeout_seconds: 300 - id: data-agent name: 数据 Agent approver: ou_yyyy timeout_seconds: 600这里解释一下配置项的含义。server.host和server.port是 botmux 服务的监听地址。feishu部分存放飞书开放平台的应用凭证。agents列表声明了允许接入的 Agent每个 Agent 都有独立的审批人。timeout_seconds表示用户如果长时间不操作审批请求超过该时间后自动超时。接下来是服务端主代码。我把 pending approval 的存储放在内存里用 asyncio.Future 配合超时控制。# app/main.py import asyncio import uuid from typing import Dict from fastapi import FastAPI, Request from pydantic import BaseModel app FastAPI() # 存储待审批请求。key: request_id, value: asyncio.Future pending_requests: Dict[str, asyncio.Future] {} class ApprovalRequest(BaseModel): agent_id: str action: str detail: str timeout: int 300 callback_url: str class ApprovalResponse(BaseModel): request_id: str decision: str reason: str async def push_to_feishu(msg_dict: dict): 向飞书发送审批卡片。 这里需要改成你的飞书适配器实现 调用飞书开放平台接口发送含审批按钮的卡片。 # 实际项目中这里用飞书 SDK 或自己实现的 HTTP 调用 print([feishu] send message:, msg_dict) app.post(/botmux/v1/approval-request) async def create_approval_request(req: ApprovalRequest): request_id uuid.uuid4().hex loop asyncio.get_running_loop() future loop.create_future() pending_requests[request_id] future # 把审批请求推送到飞书 await push_to_feishu({ request_id: request_id, agent_id: req.agent_id, action: req.action, detail: req.detail, }) try: decision await asyncio.wait_for(future, timeoutreq.timeout) return { request_id: request_id, decision: decision, } except asyncio.TimeoutError: pending_requests.pop(request_id, None) return { request_id: request_id, decision: timeout, } app.post(/botmux/v1/callback) async def feishu_callback(request: Request): 接收飞书卡片交互回调。 飞书会 POST 一个 JSON 到这个地址里面包含按钮动作。 在生产环境必须校验飞书回调签名防止伪造请求。 payload await request.json() # 1. 校验签名防止伪造回调查看下一节 # 2. 解析 action.value从中取出 request_id 和 decision action_value payload.get(action, {}).get(value, {}) request_id action_value.get(request_id) decision action_value.get(decision) if not request_id or not decision: return {code: 400, msg: invalid payload} # 3. 幂等处理如果该请求已经被处理过直接忽略 if request_id not in pending_requests: return {code: 0, msg: already processed} # 4. 把决策写入 Future唤醒正在等待的 Agent 请求 future pending_requests.pop(request_id) future.set_result(decision) return {code: 0, msg: ok}这段代码的逻辑很清晰Agent 调用审批接口后请求会被挂起等待飞书回调。当用户在飞书上点击“允许”或“拒绝”回调接口会解析出 request_id 和 decision唤醒对应的 Future返回给 Agent。有一个细节值得注意飞书回调里按钮的 value 字段需要你在发送卡片时定义好。下面是一个简化的卡片构造示例展示如何绑定动作值{ msg_type: interactive, card: { header: { title: {tag: plain_text, content: Agent 审批请求} }, elements: [ { tag: div, text: { tag: lark_md, content: Agent code-agent 请求执行\nrm -rf /tmp/cache } }, { tag: action, actions: [ { tag: button, text: {tag: plain_text, content: 允许}, type: primary, value: { request_id: REPLACE_WITH_REQUEST_ID, decision: allow } }, { tag: button, text: {tag: plain_text, content: 拒绝}, type: danger, value: { request_id: REPLACE_WITH_REQUEST_ID, decision: deny } } ] } ] } }这个卡片的 JSON 结构就是飞书交互卡片的标准格式。你在 botmux 的飞书适配器里需要把REPLACE_WITH_REQUEST_ID替换成真实的 request_id。8. Agent 侧接入与完整示例Agent 侧要做的事情很简单在需要人工确认的地方调用 botmux 的审批 API等待结果。假设你有一个函数delete_cache()正常情况下它会直接执行删除。现在需要包一层授权逻辑。# agent_example.py import requests BOTMUX_URL http://127.0.0.1:7080 def request_approval(agent_id: str, action: str, detail: str, timeout: int 60): 向 botmux 发起审批请求等待用户决策。 返回 True 表示允许False 表示拒绝或超时。 resp requests.post( f{BOTMUX_URL}/botmux/v1/approval-request, json{ agent_id: agent_id, action: action, detail: detail, timeout: timeout, }, timeouttimeout 10, ) resp.raise_for_status() result resp.json() return result.get(decision) allow def delete_cache_with_approval(): approved request_approval( agent_idcode-agent, actionexecute_command, detailrm -rf /tmp/cache, timeout120, ) if not approved: print(未获得授权跳过删除操作) return False # 这里是真正执行删除的代码 import shutil shutil.rmtree(/tmp/cache, ignore_errorsTrue) print(缓存已删除) return True if __name__ __main__: delete_cache_with_approval()在这个示例里Agent 在真正执行危险操作之前会先通过 botmux 发起一次审批。审批通过后才执行否则直接跳过。在更复杂的 Agent 框架中你可以把request_approval封装成一个工具函数挂载到 Agent 的 Tool 调用链里。每次 Agent 准备调用高权限工具时先在工具层触发一次审批。这样不用修改 Agent 的核心逻辑侵入性会小很多。最典型的封装方式是写一个装饰器给需要审批的函数自动加一层授权检查。这样代码会更整洁也更适合在团队内复用。9. 运行验证与效果检查现在把整个链路跑起来验证。9.1 启动 botmux 服务uvicorn app.main:app --host 0.0.0.0 --port 7080看到类似Uvicorn running on http://0.0.0.0:7080的日志说明服务启动成功。9.2 模拟 Agent 发起审批请求打开另一个终端执行curl -X POST http://127.0.0.1:7080/botmux/v1/approval-request \ -H Content-Type: application/json \ -d { agent_id: code-agent, action: execute_command, detail: rm -rf /tmp/cache, timeout: 60 }执行后curl 会保持等待状态因为 botmux 正在等待飞书回调。9.3 在飞书上完成审批打开飞书你应该能收到 botmux 发送的审批卡片。点击“允许”后观察 botmux 服务端日志。日志会打印出飞书回调的处理过程。如果你在飞书上点击了“允许”再回到终端会发现 curl 返回了类似下面的 JSON{request_id:a1b2c3d4...,decision:allow}如果你一直没有点击超过 timeout 时间后curl 会返回{request_id:a1b2c3d4...,decision:timeout}9.4 判断链路是否走通判断标准有三个飞书收到了卡片并能看到操作详情点击按钮后curl 能收到对应的决策结果重复点击同一个按钮不会产生重复处理。如果第 1 步失败优先排查飞书应用的权限和事件订阅配置。如果第 2 步失败优先检查回调地址是否可达、签名校验是否通过。如果第 3 步失败说明幂等处理有 bug需要检查pending_requests里的 request_id 是否在第一次处理时被正确移除。10. 常见问题与排查思路下面整理了一些常见问题按“现象、可能原因、排查方式、解决方案”的顺序列出。问题现象可能原因排查方式解决方案飞书没有收到审批卡片飞书应用权限不足或机器人未启用检查应用权限列表在飞书中确认应用是否已添加机器人添加im:message:send_as_bot权限重新发布应用版本卡片收到了但点击按钮后 Agent 没反应回调地址无法访问或签名校验失败查看 botmux 日志用 curl 手动模拟回调确认回调 URL 能被飞书访问检查签名算法和 token点击按钮后收到 “invalid payload”action.value 里没有 request_id 或 decision打印飞书回调原始 JSON检查卡片 action.value 是否包含正确字段重复点击按钮导致 Agent 执行两次幂等处理有缺陷观察 pending_requests 日志在第一次处理时立即 pop request_id后续请求直接忽略审批超时时间太短用户来不及操作timeout 配置不合理查看请求参数设置更长的 timeout或在配置层给定默认值Agent 并发请求多个审批时结果互相串request_id 生成冲突检查 request_id 是否唯一使用 uuid4 或雪花 ID 生成唯一标识部署在私网环境飞书 Webhook 推不进来没有公网入口检查网络拓扑改用飞书长连接模式避免对外开放公网端口排查的顺序建议是先看飞书是否收到消息再看按钮点击后是否触发回调最后看 botmux 是否把结果返回给了 Agent。一层一层往后走定位效率最高。11. 最佳实践与工程建议11.1 审批请求必须幂等消息平台存在重试机制飞书的回调可能重复推送。如果你在回调里直接执行 Agent 的任务而不是只解除等待很可能造成重复执行。正确做法是回调只负责把 request_id 对应的 Future 设置为终态真正的 Agent 任务由等待方执行。11.2 回调必须验签飞书的回调接口暴露在公网或内网中如果不验签任何人都可以伪造一个“允许”的请求绕过人工审批。后果很严重攻击者让 Agent 执行任意命令。所以验签不是可选项而是必须项。验签逻辑建议放在依赖边界上。botmux 的飞书适配器收到回调后第一步就是验证签名验证不通过直接拒绝。如果需要二次校验可以再用 verification_token 做一次轻量校验。11.3 最小权限原则Agent 不是什么东西都能执行的。在 botmux 配置里可以为不同 Agent 设置不同的审批等级。比如只读操作可以自动执行不需要审批低风险写操作记录日志即可高风险操作必须飞书审批极端风险操作必须到达指定审批人且可能需要两个以上审批人。审批等级不应该写死在 Agent 代码里而应该由 botmux 统一管理。这样调整权限时不需要改动 Agent。11.4 超时和降级策略审批请求不能无限等待。应该为每个请求设置合理超时并在超时后触发降级策略。降级策略可以是“跳过该操作”“回滚到上一个状态”“直接终止任务”。具体选哪种取决于这个操作对任务的影响。另一个建议是不要在 Agent 的核心执行线程里等待审批过久否则会阻塞其他任务。可以考虑把审批挂起的时间计入任务执行时间超过一定阈值后切换到其它可独立运行的任务。11.5 审计记录建议接入飞书多维表格botmux 每次审批请求处理完成后可以写一条审计记录字段包括request_id、agent_id、action、detail、决策人、决策时间、决策结果。这个记录除了写入本地日志也可以写入飞书多维表格。多维表格天然适合做筛选和统计团队复盘时可以直接看到审批链路。把审计数据和飞书消息放在同一平台减少了取数成本。11.6 环境区分与配置管理开发环境、测试环境、生产环境应该使用不同的飞书应用。不要把生产环境的 App Secret 放在开发机里。配置信息用环境变量或专门的配置中心管理不要在代码仓库里提交明文密钥。12. 总结与后续学习方向写到这里本文的核心内容已经讲完了。我们围绕“Agent 授权卡在电脑上”这个痛点拆解了 botmux 的架构它作为消息总线把 Agent 的权限请求路由到飞书再把人在飞书上的决策返回给 Agent。文中给出了一个基于 FastAPI 的最小实现包含审批请求接口、飞书回调接口、Agent 侧工具函数和飞书交互卡片的 JSON 示例。这个最小实现能帮你理解整个链路也能作为你自己项目的起点。如果你正在做 Agent 开发下一步可以沿着这几个方向继续深入把审批请求从内存存储升级为 Redis 或数据库存储解决多实例部署时的状态不一致问题加入多级审批流支持不同操作需要不同审批人的场景把 Agent 的授权链路接到自己的日志系统或审计平台研究飞书长连接模式的断线重连机制提升长稳运行的可靠性如果 Agent 框架支持 Tool Call 拦截把 botmux 审批封装成通用的 Tool Wrapper做到对上层无感。最后提醒一句任何安全设计都不能完全依赖某一个中间件。botmux 为人提供了更便捷的审批入口但 Agent 本身的权限控制、文件系统隔离、网络访问策略仍然需要你配置好。审批只是最后一道防线而不是唯一防线。建议保存这份流程清单实际操作时对照检查至少能帮你少踩一半的坑。
