别急着上生产OpenMAIC 课堂最容易翻车的四个点逐个排雷【免费下载链接】OpenMAICOpen Multi-Agent Interactive Classroom — Get an immersive, multi-agent learning experience in just one click项目地址: https://gitcode.com/GitHub_Trending/op/OpenMAICOpenMAICOpen Multi-Agent Interactive Classroom在过去一年里几乎成了教育类开源项目的顶流清华团队出品、多次登顶 GitHub 热榜、社区星数一度冲到 3.6 万一篇接一篇的教程在讲一句话生成一门 AI 互动课堂。但热度归热度真正把它从演示环境搬到公网服务器、让几十个学生同时用起来的时候问题才会浮出水面——社区里流传的部署踩坑帖、项目自己 CHANGELOG 里连续四个安全公告1.0.2 的 SSRF 与 DNS-rebinding 修复、1.0.3 的 access-code 过期与 Next.js RCE 补丁、1.1.1 的 MinerU 加固、1.1.2 的 provider 重定向拒绝都在提醒同一件事这个项目从能跑到能扛生产中间隔着好几个典型的坑。本文不重复如何部署的教程而是基于仓库源码与发布历史把最容易让课堂翻车的四个点逐个拆开它们什么情况下触发、源码里怎么定位、按什么顺序修。坑一把浏览器即后端的旧习惯带进 1.2.0现象与触发条件。如果你是从 1.1.x 或更早版本迁移上来的最容易踩的第一个坑是部署形态没跟着版本走。在 1.1.x 之前课程生成是浏览器一步步驱动的每个请求驱动一步课程、密钥、模型设置都存在浏览器里。关掉标签页课程就生成到一半停住了换一台浏览器一切要重新配置。1.2.0 把这一切搬到了服务端见 CHANGELOG.md 的 1.2.0-rc.1 发布说明生成在服务端进程内运行、关闭页面也继续、重启后从最后一个检查点续跑模型在openmaic.yml里配一次Web 应用与无头 API 共用同一条流水线。代价是部署形态彻底变了必须要有长驻 Node.js 进程 PostgreSQLDATABASE_URL是硬性要求。仓库在 README.md 里写得很直白没有DATABASE_URL时服务直接拒绝启动并退出退出码 1并在启动日志里给出修复指引Vercel 等 serverless 宿主从此不在支持名单上仓库连vercel.json都删了。这一坑的典型触发条件包括沿用 1.1.x 的 Vercel 部署步骤升级到 1.2.0得到一堆请求超时或 500本地pnpm dev正常、一上 Docker 就启动失败原因往往是漏了PERSISTENCE_POSTGRES_PASSWORD默认值openmaic-dev只在回环地址下可接受见 docker-compose.yml多实例部署时没有配置OPENMAIC_SECRET_KEY于是每个实例各自在data/instance-secret.key生成一份密钥——保存在数据库里的 provider 密钥用 A 实例的密钥加密后B 实例读不出来。.env.example里对此有明确警告密钥要与数据库一起备份多实例必须显式设置共享的OPENMAIC_SECRET_KEY设置了PERSISTENCE_SHARED_OWNER_ID却忘了同时设OWNER_SINGLE_USERfalse应用直接拒绝启动README.md 的升级章节专门强调了这一点。定位思路与修复顺序。定位这类问题最快的入口是启动日志里的[boot]前缀错误仓库在 CHANGELOG.md 中承诺无效配置在启动时以一行[boot]原因停服而不是让服务对每个请求都回 500。所以看到服务反复 500先回头查启动日志而不是去追业务代码。修复顺序是先确认 PostgreSQL 可达pnpm db:up或外部库、再配齐PERSISTENCE_POSTGRES_PASSWORD与OPENMAIC_SECRET_KEY、最后再谈模型配置见坑二。升级前务必备份数据库——首次启动会跑 schema 迁移回滚到 1.1.x 需要特定的 ownership copy-back SQL 或备份。坑二模型配置在没解析到模型上静默翻车现象与触发条件。1.2.0 之后模型统一由服务端的openmaic.yml管理providers声明可调用的账户slots把每一种 AI 用途大纲、幻灯片内容、语音、图像、视频、联网检索、文档解析、agent 等绑定到具体模型参考 openmaic.example.yml。这个设计的本意是配置一次、全员一致但它把翻车点从浏览器挪到了配置层slot 未解析 硬失败。llm是根其余聊天 slot 未单独指定时跟随它但如果某个 slot 最终解析不到模型没配置或 slot 被设为null提交生成任务会直接得到400 MISSING_MODEL。同类还有400 MISSING_API_KEYprovider 需要 key 但没配、400 INVALID_URL工作区不得使用的端点、400 MODEL_CONFIG_INVALID只有部署方才能设置的选项比如 Bedrock、代理。这些检查全部在 lib/server/model-config/llm.ts 的ModelConfigurationError里显式抛出在生成任务真正跑起来之前就拒绝提交而不是变成一个生成到一半才失败的 job。客户端自带的 baseUrl 永远走严格公网策略。用户在工作区填的 BYOK 端点按调用方提供处理一律按公网策略校验validateClientBaseUrlALLOW_LOCAL_NETWORKS对这条路径无效——想接内网 Ollama必须在openmaic.yml里由部署方声明lib/server/model-config/llm.ts 与 lib/server/ssrf-guard.ts 共同决定。MODEL_ROUTES兼容陷阱。1.2.0 起MODEL_ROUTES不再被读取设置了它而没有openmaic.yml的服务拒绝启动。跑过 Pro agent 的老部署必须先把路由迁移成 slotmaic-agent-driver→agentscene-content→course.content等。agent slot 不能设thinking.effort设了会被丢弃或拒绝fallback只对语言模型类 slot 生效openmaic.example.yml 的注释写得很清楚重试只在主模型遇到可重试错误且自身重试耗尽后才在 fallback 上再试一次。已知问题里还躺着一个玄学坑太短的需求可能跑题或无视你写的页数要求见 CHANGELOG.md Known issues。这不是配置错误但生产环境应把它当作输入校验的一部分处理。定位思路与修复顺序。这类坑的好处是会响未声明的 provider 引用、未知 preset、未设置的变量服务在启动时逐字段点名报错。所以流程是先用openmaic.yml把slots逐条写全缺能力就用null显式关掉不要留空、验证每个 slot 都能解析到带 key 的模型、再用lock把需要固定的 slot 锁死、用allowUserKeys: false禁止用户自带 provider。值得注意的是 README 推荐用快速长上下文模型如deepseek-v4.1-flash做默认而不是把最贵的旗舰模型挂在llm上——大纲、场景内容、配音都会继承这个默认模型选贵了成本会线性放大。坑三生成运行的超时、重试与并发配额现象与触发条件。课程生成现在是一条服务端流水线材料分析 → 联网研究 → 大纲 → 等待确认→ 角色配置 → 逐场景内容 → 动作 → 配音。这条流水线在 lib/server/generation/run/plan.ts 里是明确的状态机preparing → outlining → awaiting_outline_confirmation → generating → completed/paused。翻车往往发生在三个地方provider 挂起。1.1.x 时代每一步调用都有路由级预算1.2.0 把预算搬进了 lib/server/generation/run/deadline.ts材料分析/研究/大纲/单场景内容各 300 秒角色生成 120 秒场景动作 60 秒单条配音 30 秒。超时按 504 归类进入重试。所以某个场景卡了半小时不动在 1.2.0 里不应该出现——出现了先怀疑是不是跑在旧版本或者某个步骤压根没进 run 引擎。重试次数不对等。第一场景的内容生成只重试 2 次后续场景重试 5 次lib/server/generation/run/retry.ts 的FIRST_SCENE_MAX_RETRIES 2与SCENE_MAX_RETRIES 5动作和配音各有自己的重试语义配音的 400 类拒绝缺 voice、缺 key、客户端侧 provider不重试。这意味着同样的上游抖动第一场景更容易直接暂停在失败步上。并发配额与并行开关。每个 owner 同时在跑的 run 默认上限 2OPENMAIC_MAX_ACTIVE_RUNS_PER_OWNER超限提交直接429 ACTIVE_RUN_LIMIT等待大纲确认的 run 不占配额。另外.env.example里的PARALLEL_SCENE_CONCURRENCY是可选并行场景内容生成的开关注释明确警告API key 的每 key 并发配额低就别开——开了它一次提交会同时打多个场景内容请求很容易把上游的 429/限流打出来。定位思路与修复顺序。先看 run 的状态与事件1.2.0 的 run 会在失败步暂停Retry 只重跑那一步不是整个课程每个失败都带failureSeq以便定位事件流中的对应记录lib/generation-run-client/reducer.ts。修复顺序建议先修挂起确认 deadline 生效、provider 侧有没有超时配置、再修重试耗尽看日志里step_retry事件的原因是内容安全拒绝还是上游 5xx、最后调并发单 owner 并发上限、并行场景开关、媒体生成并发。媒体图像/视频失败不会暂停整个 run只会以 warning 形式记进结果——这一点在验收时容易被当成生成成功了务必检查result.warning。坑四公网暴露与凭据安全——默认配置是 fail-open 的现象与触发条件。这是最隐蔽也最严重的一类。几个事实必须摆在前面ACCESS_CODE未设置 默认放行。middleware.ts 的逻辑非常直白ACCESS_CODE为空时直接放行所有请求没有第二道强制关卡。Docker Compose 默认把服务发布在127.0.0.1且单用户模式这本身是安全的但一旦你执行了OPENMAIC_PUBLISH_ADDRESS0.0.0.0 docker compose up而没有先设ACCESS_CODE任何能触达这个端口的人都能读、改、删整个课程库——因为单用户模式下每个请求都是同一个 owner。本地网络豁免是双刃剑。ALLOW_LOCAL_NETWORKStrue会放开 RFC1918/回环/link-local/CGNAT 目标Ollama、Tailscale 等场景需要但 lib/server/ssrf-guard.ts 同时提醒云元数据端点169.254.169.254等一长串固定地址列表和 IANA 保留/组播/广播段永远不放行无论是否开启该开关。真正危险的是图省事把所有环境都设成 true 然后长期挂着——这会扩大 SSRF 攻击面。重定向劫持。一次 provider 请求的起点被校验过不代表终点安全公网可达的 host 可以回一个302 Location: http://内网地址/...把请求拽进内网。仓库为此写了 lib/server/fetch-with-redirect-validation.ts手动跟随重定向、每一跳重新跑 SSRF 校验、最多 5 跳、跨域跳转时剥离凭据头authorization、api-key、x-api-key、x-goog-api-key、xi-api-key等一整套清单流式请求体无法重放时明确失败而不是带空 body 转发。这就是 1.1.2 公告GHSA-g87c-cm4q-cw5x修掉的问题。render-service 的隔离依赖CAP_NET_ADMIN。MP4 导出的 render 容器通过 iptables 封锁出站但如果没有NET_ADMIN权限容器会照常启动、只打警告、不封锁 Chromium 出站见 docker-compose.yml 的注释。明文 HTTP 下的 cookie 陷阱。生产构建里匿名 owner cookie 和 access-code cookie 带Secure标志纯 HTTP无 TLS下浏览器不会存它们结果是每次请求都是新 owner、owner 作用域的写请求 403 连环报错Safari 对http://localhost尤其严格。.env.example给出了COOKIE_SECURE0的显式退出开关但注释同样警告只在可信网络使用否则 cookie 明文传输可被重放。定位思路与修复顺序。这类问题靠功能测试测不出来要靠配置审计。顺序是先把ACCESS_CODE设成至少 16 字符的随机值它是守卫部署的唯一秘密且验证有 7 天过期、HMAC 签名校验见 middleware.ts→ 再检查发布地址与ALLOW_LOCAL_NETWORKS的实际值 → 然后确认 render-service 拿到了CAP_NET_ADMIN→ 最后检查 TLS 与COOKIE_SECURE的组合。验证重定向防护是否生效可以直接用一个返回 302 到内网地址的假 provider 端点做回归测试——lib/server/fetch-with-redirect-validation.ts 的拒绝信息是防注入的安全审计时能据此确认每一跳都被校验。一套可复用的课堂稳定性检查清单把上面四个坑收敛成一张清单建议按这个顺序执行前一项不通过后一项没有意义部署前坑一DATABASE_URL已配置且可达服务启动无[boot]错误多实例共享同一个 PostgreSQL 时OPENMAIC_SECRET_KEY已显式设置PERSISTENCE_POSTGRES_PASSWORD已从默认值改掉PERSISTENCE_SHARED_OWNER_ID与OWNER_SINGLE_USER不冲突升级前已备份数据库MODEL_ROUTES已迁移为openmaic.ymlslots。模型配置坑二openmaic.yml里每个实际使用的 slot 都能解析到模型能力不需要就显式null无头 API 提交前先跑一遍GET /api/generate-classroom/capabilities确认哪些能力真正被配置需要一致性时启用lock与allowUserKeys: falseagentslot 未设置thinking.effort默认llm选快速长上下文模型而非旗舰模型。生成运行坑三确认运行在 1.2.0 的 run 引擎上超时预算lib/server/generation/run/deadline.ts生效低并发配额的 key 不开PARALLEL_SCENE_CONCURRENCY单 owner 并发按OPENMAIC_MAX_ACTIVE_RUNS_PER_OWNER规划验收时检查result.warning图像/视频失败的静默降级失败步 Retry 语义确认过重试只重跑失败的那一步不重跑整个课程。暴露公网前坑四ACCESS_CODE已设置≥16 字符随机值middleware.ts的 API 401 闸门已验证ALLOW_LOCAL_NETWORKS只在确有内网 provider 时开启且云元数据端点仍被拒绝render-service 容器具备CAP_NET_ADMIN或确认不需要出站封锁生产环境走 TLSCOOKIE_SECURE语义符合预期无纯 HTTP 部署。OpenMAIC 的工程化程度在同类开源项目里是相当高的显式的[boot]失败、类型化的错误码、每步 deadline、跨跳凭据剥离——这些设计都是冲着可生产去的。但正因为 1.2.0 把状态和配置全部集中到了服务端部署者的责任也同步变重了。把上面四个点当成上线前的必检项课堂才不会在第一个早高峰翻车。【免费下载链接】OpenMAICOpen Multi-Agent Interactive Classroom — Get an immersive, multi-agent learning experience in just one click项目地址: https://gitcode.com/GitHub_Trending/op/OpenMAIC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/9 20:21:43 · 阅读 1.2k 别急着上生产：OpenMAIC 课堂最容易翻车的四个点逐个排雷
别急着上生产OpenMAIC 课堂最容易翻车的四个点逐个排雷【免费下载链接】OpenMAICOpen Multi-Agent Interactive Classroom — Get an immersive, multi-agent learning experience in just one click项目地址: https://gitcode.com/GitHub_Trending/op/OpenMAICOpenMAICOpen Multi-Agent Interactive Classroom在过去一年里几乎成了教育类开源项目的顶流清华团队出品、多次登顶 GitHub 热榜、社区星数一度冲到 3.6 万一篇接一篇的教程在讲一句话生成一门 AI 互动课堂。但热度归热度真正把它从演示环境搬到公网服务器、让几十个学生同时用起来的时候问题才会浮出水面——社区里流传的部署踩坑帖、项目自己 CHANGELOG 里连续四个安全公告1.0.2 的 SSRF 与 DNS-rebinding 修复、1.0.3 的 access-code 过期与 Next.js RCE 补丁、1.1.1 的 MinerU 加固、1.1.2 的 provider 重定向拒绝都在提醒同一件事这个项目从能跑到能扛生产中间隔着好几个典型的坑。本文不重复如何部署的教程而是基于仓库源码与发布历史把最容易让课堂翻车的四个点逐个拆开它们什么情况下触发、源码里怎么定位、按什么顺序修。坑一把浏览器即后端的旧习惯带进 1.2.0现象与触发条件。如果你是从 1.1.x 或更早版本迁移上来的最容易踩的第一个坑是部署形态没跟着版本走。在 1.1.x 之前课程生成是浏览器一步步驱动的每个请求驱动一步课程、密钥、模型设置都存在浏览器里。关掉标签页课程就生成到一半停住了换一台浏览器一切要重新配置。1.2.0 把这一切搬到了服务端见 CHANGELOG.md 的 1.2.0-rc.1 发布说明生成在服务端进程内运行、关闭页面也继续、重启后从最后一个检查点续跑模型在openmaic.yml里配一次Web 应用与无头 API 共用同一条流水线。代价是部署形态彻底变了必须要有长驻 Node.js 进程 PostgreSQLDATABASE_URL是硬性要求。仓库在 README.md 里写得很直白没有DATABASE_URL时服务直接拒绝启动并退出退出码 1并在启动日志里给出修复指引Vercel 等 serverless 宿主从此不在支持名单上仓库连vercel.json都删了。这一坑的典型触发条件包括沿用 1.1.x 的 Vercel 部署步骤升级到 1.2.0得到一堆请求超时或 500本地pnpm dev正常、一上 Docker 就启动失败原因往往是漏了PERSISTENCE_POSTGRES_PASSWORD默认值openmaic-dev只在回环地址下可接受见 docker-compose.yml多实例部署时没有配置OPENMAIC_SECRET_KEY于是每个实例各自在data/instance-secret.key生成一份密钥——保存在数据库里的 provider 密钥用 A 实例的密钥加密后B 实例读不出来。.env.example里对此有明确警告密钥要与数据库一起备份多实例必须显式设置共享的OPENMAIC_SECRET_KEY设置了PERSISTENCE_SHARED_OWNER_ID却忘了同时设OWNER_SINGLE_USERfalse应用直接拒绝启动README.md 的升级章节专门强调了这一点。定位思路与修复顺序。定位这类问题最快的入口是启动日志里的[boot]前缀错误仓库在 CHANGELOG.md 中承诺无效配置在启动时以一行[boot]原因停服而不是让服务对每个请求都回 500。所以看到服务反复 500先回头查启动日志而不是去追业务代码。修复顺序是先确认 PostgreSQL 可达pnpm db:up或外部库、再配齐PERSISTENCE_POSTGRES_PASSWORD与OPENMAIC_SECRET_KEY、最后再谈模型配置见坑二。升级前务必备份数据库——首次启动会跑 schema 迁移回滚到 1.1.x 需要特定的 ownership copy-back SQL 或备份。坑二模型配置在没解析到模型上静默翻车现象与触发条件。1.2.0 之后模型统一由服务端的openmaic.yml管理providers声明可调用的账户slots把每一种 AI 用途大纲、幻灯片内容、语音、图像、视频、联网检索、文档解析、agent 等绑定到具体模型参考 openmaic.example.yml。这个设计的本意是配置一次、全员一致但它把翻车点从浏览器挪到了配置层slot 未解析 硬失败。llm是根其余聊天 slot 未单独指定时跟随它但如果某个 slot 最终解析不到模型没配置或 slot 被设为null提交生成任务会直接得到400 MISSING_MODEL。同类还有400 MISSING_API_KEYprovider 需要 key 但没配、400 INVALID_URL工作区不得使用的端点、400 MODEL_CONFIG_INVALID只有部署方才能设置的选项比如 Bedrock、代理。这些检查全部在 lib/server/model-config/llm.ts 的ModelConfigurationError里显式抛出在生成任务真正跑起来之前就拒绝提交而不是变成一个生成到一半才失败的 job。客户端自带的 baseUrl 永远走严格公网策略。用户在工作区填的 BYOK 端点按调用方提供处理一律按公网策略校验validateClientBaseUrlALLOW_LOCAL_NETWORKS对这条路径无效——想接内网 Ollama必须在openmaic.yml里由部署方声明lib/server/model-config/llm.ts 与 lib/server/ssrf-guard.ts 共同决定。MODEL_ROUTES兼容陷阱。1.2.0 起MODEL_ROUTES不再被读取设置了它而没有openmaic.yml的服务拒绝启动。跑过 Pro agent 的老部署必须先把路由迁移成 slotmaic-agent-driver→agentscene-content→course.content等。agent slot 不能设thinking.effort设了会被丢弃或拒绝fallback只对语言模型类 slot 生效openmaic.example.yml 的注释写得很清楚重试只在主模型遇到可重试错误且自身重试耗尽后才在 fallback 上再试一次。已知问题里还躺着一个玄学坑太短的需求可能跑题或无视你写的页数要求见 CHANGELOG.md Known issues。这不是配置错误但生产环境应把它当作输入校验的一部分处理。定位思路与修复顺序。这类坑的好处是会响未声明的 provider 引用、未知 preset、未设置的变量服务在启动时逐字段点名报错。所以流程是先用openmaic.yml把slots逐条写全缺能力就用null显式关掉不要留空、验证每个 slot 都能解析到带 key 的模型、再用lock把需要固定的 slot 锁死、用allowUserKeys: false禁止用户自带 provider。值得注意的是 README 推荐用快速长上下文模型如deepseek-v4.1-flash做默认而不是把最贵的旗舰模型挂在llm上——大纲、场景内容、配音都会继承这个默认模型选贵了成本会线性放大。坑三生成运行的超时、重试与并发配额现象与触发条件。课程生成现在是一条服务端流水线材料分析 → 联网研究 → 大纲 → 等待确认→ 角色配置 → 逐场景内容 → 动作 → 配音。这条流水线在 lib/server/generation/run/plan.ts 里是明确的状态机preparing → outlining → awaiting_outline_confirmation → generating → completed/paused。翻车往往发生在三个地方provider 挂起。1.1.x 时代每一步调用都有路由级预算1.2.0 把预算搬进了 lib/server/generation/run/deadline.ts材料分析/研究/大纲/单场景内容各 300 秒角色生成 120 秒场景动作 60 秒单条配音 30 秒。超时按 504 归类进入重试。所以某个场景卡了半小时不动在 1.2.0 里不应该出现——出现了先怀疑是不是跑在旧版本或者某个步骤压根没进 run 引擎。重试次数不对等。第一场景的内容生成只重试 2 次后续场景重试 5 次lib/server/generation/run/retry.ts 的FIRST_SCENE_MAX_RETRIES 2与SCENE_MAX_RETRIES 5动作和配音各有自己的重试语义配音的 400 类拒绝缺 voice、缺 key、客户端侧 provider不重试。这意味着同样的上游抖动第一场景更容易直接暂停在失败步上。并发配额与并行开关。每个 owner 同时在跑的 run 默认上限 2OPENMAIC_MAX_ACTIVE_RUNS_PER_OWNER超限提交直接429 ACTIVE_RUN_LIMIT等待大纲确认的 run 不占配额。另外.env.example里的PARALLEL_SCENE_CONCURRENCY是可选并行场景内容生成的开关注释明确警告API key 的每 key 并发配额低就别开——开了它一次提交会同时打多个场景内容请求很容易把上游的 429/限流打出来。定位思路与修复顺序。先看 run 的状态与事件1.2.0 的 run 会在失败步暂停Retry 只重跑那一步不是整个课程每个失败都带failureSeq以便定位事件流中的对应记录lib/generation-run-client/reducer.ts。修复顺序建议先修挂起确认 deadline 生效、provider 侧有没有超时配置、再修重试耗尽看日志里step_retry事件的原因是内容安全拒绝还是上游 5xx、最后调并发单 owner 并发上限、并行场景开关、媒体生成并发。媒体图像/视频失败不会暂停整个 run只会以 warning 形式记进结果——这一点在验收时容易被当成生成成功了务必检查result.warning。坑四公网暴露与凭据安全——默认配置是 fail-open 的现象与触发条件。这是最隐蔽也最严重的一类。几个事实必须摆在前面ACCESS_CODE未设置 默认放行。middleware.ts 的逻辑非常直白ACCESS_CODE为空时直接放行所有请求没有第二道强制关卡。Docker Compose 默认把服务发布在127.0.0.1且单用户模式这本身是安全的但一旦你执行了OPENMAIC_PUBLISH_ADDRESS0.0.0.0 docker compose up而没有先设ACCESS_CODE任何能触达这个端口的人都能读、改、删整个课程库——因为单用户模式下每个请求都是同一个 owner。本地网络豁免是双刃剑。ALLOW_LOCAL_NETWORKStrue会放开 RFC1918/回环/link-local/CGNAT 目标Ollama、Tailscale 等场景需要但 lib/server/ssrf-guard.ts 同时提醒云元数据端点169.254.169.254等一长串固定地址列表和 IANA 保留/组播/广播段永远不放行无论是否开启该开关。真正危险的是图省事把所有环境都设成 true 然后长期挂着——这会扩大 SSRF 攻击面。重定向劫持。一次 provider 请求的起点被校验过不代表终点安全公网可达的 host 可以回一个302 Location: http://内网地址/...把请求拽进内网。仓库为此写了 lib/server/fetch-with-redirect-validation.ts手动跟随重定向、每一跳重新跑 SSRF 校验、最多 5 跳、跨域跳转时剥离凭据头authorization、api-key、x-api-key、x-goog-api-key、xi-api-key等一整套清单流式请求体无法重放时明确失败而不是带空 body 转发。这就是 1.1.2 公告GHSA-g87c-cm4q-cw5x修掉的问题。render-service 的隔离依赖CAP_NET_ADMIN。MP4 导出的 render 容器通过 iptables 封锁出站但如果没有NET_ADMIN权限容器会照常启动、只打警告、不封锁 Chromium 出站见 docker-compose.yml 的注释。明文 HTTP 下的 cookie 陷阱。生产构建里匿名 owner cookie 和 access-code cookie 带Secure标志纯 HTTP无 TLS下浏览器不会存它们结果是每次请求都是新 owner、owner 作用域的写请求 403 连环报错Safari 对http://localhost尤其严格。.env.example给出了COOKIE_SECURE0的显式退出开关但注释同样警告只在可信网络使用否则 cookie 明文传输可被重放。定位思路与修复顺序。这类问题靠功能测试测不出来要靠配置审计。顺序是先把ACCESS_CODE设成至少 16 字符的随机值它是守卫部署的唯一秘密且验证有 7 天过期、HMAC 签名校验见 middleware.ts→ 再检查发布地址与ALLOW_LOCAL_NETWORKS的实际值 → 然后确认 render-service 拿到了CAP_NET_ADMIN→ 最后检查 TLS 与COOKIE_SECURE的组合。验证重定向防护是否生效可以直接用一个返回 302 到内网地址的假 provider 端点做回归测试——lib/server/fetch-with-redirect-validation.ts 的拒绝信息是防注入的安全审计时能据此确认每一跳都被校验。一套可复用的课堂稳定性检查清单把上面四个坑收敛成一张清单建议按这个顺序执行前一项不通过后一项没有意义部署前坑一DATABASE_URL已配置且可达服务启动无[boot]错误多实例共享同一个 PostgreSQL 时OPENMAIC_SECRET_KEY已显式设置PERSISTENCE_POSTGRES_PASSWORD已从默认值改掉PERSISTENCE_SHARED_OWNER_ID与OWNER_SINGLE_USER不冲突升级前已备份数据库MODEL_ROUTES已迁移为openmaic.ymlslots。模型配置坑二openmaic.yml里每个实际使用的 slot 都能解析到模型能力不需要就显式null无头 API 提交前先跑一遍GET /api/generate-classroom/capabilities确认哪些能力真正被配置需要一致性时启用lock与allowUserKeys: falseagentslot 未设置thinking.effort默认llm选快速长上下文模型而非旗舰模型。生成运行坑三确认运行在 1.2.0 的 run 引擎上超时预算lib/server/generation/run/deadline.ts生效低并发配额的 key 不开PARALLEL_SCENE_CONCURRENCY单 owner 并发按OPENMAIC_MAX_ACTIVE_RUNS_PER_OWNER规划验收时检查result.warning图像/视频失败的静默降级失败步 Retry 语义确认过重试只重跑失败的那一步不重跑整个课程。暴露公网前坑四ACCESS_CODE已设置≥16 字符随机值middleware.ts的 API 401 闸门已验证ALLOW_LOCAL_NETWORKS只在确有内网 provider 时开启且云元数据端点仍被拒绝render-service 容器具备CAP_NET_ADMIN或确认不需要出站封锁生产环境走 TLSCOOKIE_SECURE语义符合预期无纯 HTTP 部署。OpenMAIC 的工程化程度在同类开源项目里是相当高的显式的[boot]失败、类型化的错误码、每步 deadline、跨跳凭据剥离——这些设计都是冲着可生产去的。但正因为 1.2.0 把状态和配置全部集中到了服务端部署者的责任也同步变重了。把上面四个点当成上线前的必检项课堂才不会在第一个早高峰翻车。【免费下载链接】OpenMAICOpen Multi-Agent Interactive Classroom — Get an immersive, multi-agent learning experience in just one click项目地址: https://gitcode.com/GitHub_Trending/op/OpenMAIC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考