让机器人能上生产：操作日志、双因子与插件签名

场景

一个机器人走出内网、真的对外服务之前，运维者通常要先回答三个问题。

第一，昨天是谁把供应商密钥改成了另一个值？谁删掉了那条流水线？第二，能登录这个实例的到底有几个人，除了一把密码还有没有第二道门？第三，装进来的插件包是谁签的，跑起来的到底是哪一份代码？

4.10 的部署里，这三个问题基本只能靠翻容器日志和单点口令来兜。4.11 补上的正是这一层问责能力：工作区级操作日志、双因子（2FA，界面里叫「两步验证」）与通行密钥、以及插件认证与签名。本文只讲这三件事------标题里的「能上生产」指的是为上线做准备的这三项准备，不是对整体上线能力的承诺。

4.11 里怎么做

操作日志（operation logs）。 4.11 新增了工作区级的操作日志表 workspace_operation_logs（源码 LangBot/src/langbot/pkg/persistence/alembic/versions/0033_operation_traceability.py）。每条记录带 workspace_uuid、actor_account_uuid、actor_role、auth_type、route、action、resource_type、resource_id、level、outcome、status_code、changes、record_hash、prev_hash、dedupe_key、client_ip、duration_ms 等字段（实体 LangBot/src/langbot/pkg/entity/persistence/operation_log.py:47）。changes 存的是「什么改成了什么」的紧凑前后差异，界面上显示成「N 项变更」。

等级分三档：off / mutation / read，默认是 off ，也就是追踪必须显式打开（LangBot/src/langbot/pkg/operation_trace/service.py:92）。每条记录的 record_hash 用 HMAC-SHA256 计算，并与前一条的 prev_hash 串成链（service.py:200），面板上因此有「校验通过 / 可能被篡改」标注，也能只筛「哈希不匹配 / 链路断裂」。

这是一个独立的审计面 ，和 Runner 的事件事实不是同一张表：Runner 侧另有 event_log（实体 LangBot/src/langbot/pkg/entity/persistence/event_log.py），而 operation_log.py 的注释明确说明两者刻意分开。别把 event_log 当成操作日志页的数据源。

双因子与通行密钥。 账户面板支持 TOTP 双因子与 WebAuthn 通行密钥（Passkey）。TOTP 密钥不以明文落库：它以 Fernet 令牌形式保存，包装密钥由实例 JWT secret 经 HKDF-SHA256 派生（LangBot/src/langbot/pkg/api/http/service/totp.py，salt langbot.totp.secret.v1）；恢复码只存 PBKDF2-HMAC-SHA256 摘要，迭代 600000 次。登录挑战有效期 5 分钟、最多尝试 5 次，登录接口用 totp_required / totp_invalid_code 区分「需要第二因子」与「验证失败」（LangBot/src/langbot/pkg/api/http/controller/groups/user.py:118-141）。通行密钥走 WebAuthn 注册与认证，凭据存 passkey_credentials（迁移 0024_passkey_credentials.py）。这些能力背后是固定的工作区角色 owner / admin / developer / operator / viewer，按能力拆分（LangBot/src/langbot/pkg/api/http/authz.py:42-63）：audit.view 只给 owner 和 admin，且最后一个 owner 不能被删除或降级（文档 docs/multi-tenant/workspace-multi-user-architecture.md §5.5）。

插件签名与认证。 安装插件包时，Core 在写入产物、调用 Runtime 之前，先调用 SDK 的 langbot_plugin.certification.verify_archive()，从 ZIP 注释里读取严格证书信封并校验被签名的归一化 ZIP 摘要，且不先解压载荷（文档 docs/architecture/certified-plugins.md）。结论落进插件记录 install_info._certification，字段含 artifact_digest、normalized_digest、verification、certificate_runtime_profile、certificate_component_model、certificate_id、runtime_profile、admission_code（源码 LangBot/src/langbot/pkg/plugin/connector.py:1896-1910）。只有 verification: valid 且同时声明 shared-runtime-v1 与 stateless-v1 的插件，才可能进入共享运行配置；OSS 默认的受信任公钥环为空，此时无法解析的声明一律落到 dedicated 独立运行配置。administrator_force 只在显式为布尔 true 时生效，而且它不会把无效签名「认证」成有效。

本次实测（2026-10-16）的升级路径可以印证这几项都属于 4.11：4.10.11 的库停在 alembic_version = 0023_bot_scoped_sessions，4.11 启动时自动迁移到 0037_metadata_text，跨 14 个 revision、共 50 张表；而通行密钥（0024）、TOTP（0025）、认证摘要回填（0032）、操作日志（0033）都落在这段区间内。

动手：步骤

先起一个本地演示实例（命令来自本期实测环境）：

bash 复制代码

# 4.11.0（全新实例）
docker network create lang7-411
docker run -d --name lang7-411-core --network lang7-411 --restart on-failure -e TZ=Asia/Shanghai \
  -e BOX__ENABLED=false -e SPACE__DISABLE_TELEMETRY=true -p 15400:5300 -p 15480-15485:2280-2285 \
  -v "$PWD/deploy/411/data:/app/data" rockchin/langbot:v4.11.0
docker run -d --name lang7-411-runtime --network lang7-411 --network-alias langbot_plugin_runtime --restart on-failure \
  -e TZ=Asia/Shanghai -e SPACE__DISABLE_TELEMETRY=true -v "$PWD/deploy/411/data/plugins:/app/data/plugins" \
  rockchin/langbot:v4.11.0 uv run --no-sync -m langbot_plugin.cli.__init__ rt

管理员初始账号 admin@langbot.local，初始密码 LangBot411!demo（本地演示值，请自行替换）。三个界面入口：

操作日志：设置 → 操作日志。先展开「收集设置」，把「操作等级」从默认的关闭改成「修改」或「读」，按需调整「保留天数 / 最大记录数 / 去重窗口（秒）」，保存。再回到「操作记录」列表，用「操作类型 / 资源类型 / 操作者」筛选，展开每条的「详情」看变更。
双因子 ：设置 → 账户 → 「两步验证」。点「启用」→「生成密钥」，用验证器扫「两步验证二维码」，填入 6 位「验证码」后「验证并启用」；恢复代码只在确认那一步显示一次（界面文案：两步验证已启用 · 剩余 {{count}} 个恢复代码）。同一面板可「添加通行密钥」。owner / admin 还能查看并重置本工作区账户的双因子。
插件认证 ：扩展市场里带「认证插件」标记的版本（徽章按市场侧的 certificate_status: "issued" 渲染），tooltip 说明是「此版本已通过数据隔离与共享运行环境兼容性审核，插件包已签名。」注意：admission_code / verification / certificate_id / runtime_profile 这几个本实例准入字段在 WebUI 没有任何展示面 （对 web/src 全量检索 0 命中，全站只有市场侧徽章这一处渲染），只能从 GET /api/v1/plugins 的 install_info._certification 读------不要去找页面。

验证

操作日志 ：把等级调到「修改」后再做一次配置修改，GET /api/v1/settings/operation-logs 应返回该条记录；该路由（以及 .../filters、.../export）都要求 audit.view，即只有 owner / admin 能读（源码 LangBot/src/langbot/pkg/operation_trace/routes.py:15）。列表分页上限 200 条、导出上限 10000 行（service.py:109、service.py:2293）。列表为空时，先确认等级不是 off------这是最常见的原因。
双因子 ：绑定后用同一账号重新登录，会出现「两步验证」挑战页；输错返回 totp_invalid_code，恢复码也走同一条验证路径。本次实测没有走完绑定 ，所以这一段是依据界面文案与源码给出的预期行为，不是本实例的实测结果：该实例 GET /api/v1/user/totp/status 全程为 {"enabled": false, "pending": false, "confirmed_at": null, "recovery_codes_remaining": 0}。
插件认证 ：本次实测装的是一个来自插件市场的 Runner 插件，同一个版本在两侧记录并不一样，如实记录如下（实例侧取自 GET /api/v1/plugins 的 install_info._certification，市场侧取自 space.langbot.app 的市场接口，两侧都没有页面可看）------
- 实例侧 install_info._certification（逐字）：{"admission_code": "CERTIFIED_PLUGIN_OSS_UNTRUSTED_DEDICATED", "artifact_digest": "2d2ce17055d70dd7736e6902595be3262992fd1598a00bd9d79d19fef1c16329", "certificate_component_model": "stateless-v1", "certificate_id": null, "certificate_runtime_profile": "shared-runtime-v1", "normalized_digest": "fc70e08968d8358a33e2cb3032bd1846b8acf38b40b4a7b5f66032c2e12e8205", "runtime_profile": "dedicated", "verification": "invalid"}
- 市场侧同一版本：插件记录（GET https://space.langbot.app/api/v1/marketplace/plugins/langbot-team/LocalAgent）给 certification_status: "issued"、certificate_id: cert:86f25832a3f5df65b6e2f938155f3a855ed69ead87d835ddf54c49b4607b629f；版本记录（同一路径下的 /versions）另外给 certificate_key_id: ed25519:86e697952a6c3bc4。
- 字段怎么读：verification 是这台实例上的核验结论 ，runtime_profile 是最终选中的运行配置 ，admission_code 是做出这个选择的固定原因码，normalized_digest 是证书绑定的摘要，certificate_id 为 null 表示这次落库没有可关联的证书 ID。两侧记录分属不同侧，交叉核对需要你自己做；不要把市场侧的 issued 标记当成云端准入已通过。

边界与注意

操作日志默认关闭（DEFAULT_OPERATION_LEVEL = 0），不打开就没有记录；它是追加写的，没有删除路由，保留策略是唯一的删除路径。
操作日志只覆盖 LangBot 实例内的管理动作，不覆盖外部平台侧的操作：微信 / 飞书 / 钉钉等平台后台改的东西不在这里。举例涉及平台能力时请注意，具体支持取决于适配器/平台，请先核对支持矩阵。
权限是固定的 RBAC，developer / operator / viewer 都拿不到 audit.view；OSS 是「单工作区 + 多账号 + 固定 RBAC」，不支持自定义角色。该架构文档自身仍标注为基线阶段，不宜当作可直接上线的多租户方案（文档 §6）。
认证只是准入判定，不等于执行隔离：Runner 插件被定位为「由运维方拥有的执行」，LangBot 对模型、知识库、工具、事件、状态等自己持有的资源 做运行级授权与作用域化的 MCP 网关（短期 run_token），执行环境由用户或部署平台负责，不提供托管沙箱 （文档 docs/agent-runner-pluginization/SECURITY_HARDENING.md）。
以上三项是上线前的准备工作，不等于整体上线能力的全部内容。

小结与下一步

如果你的目标是把 4.10 的实例迁过来，再补上这些治理能力，先看置顶迁移文档 docs/pipeline-migration-config-map.zh-CN.md，版本变动见 v4.11.0 release。托管部署只在你确有需要时作为备选了解一下 space.langbot.app，本文不对其作任何承诺。