软件工厂平台压测问题汇总

100 并发下 Socket.IO 握手能力饱和，成功率仅 39%

正式压测前的预压测显示：50 并发正常，100 并发（50 用户×2 任务）成功率仅 39/100，失败全部是 Socket.IO 连接握手失败。压测期间 CPU 峰值仅 37%、内存 8.9/12.9G、8020 端口连接数峰值只到 68——不是硬件资源瓶颈，根因是 blade-agent 后端单进程单 asyncio 事件循环处理 Socket.IO 握手的能力上限（约 40–68 个活跃连接饱和）。当前单实例部署大约只能稳定支撑 40–50 个并发真实任务。

"这不是负载/资源问题，而是单个 asyncio 事件循环处理 Socket.IO 握手的能力上限"

报告随附的调优建议（原单列一条，按性价比排序）：① 改为多 worker（uvicorn --workers N）+ Redis 作为 Socket.IO 跨 worker 消息总线（socketio.AsyncRedisManager），是突破 100 并发的关键；② 水平扩展多个 blade-agent 实例 + Nginx 负载均衡，配合共享 session 存储线性扩展；③ 同一用户多个任务复用同一 socket 连接（按 session_id 路由），减少握手次数。

复测结果（2026-07-02，box 环境，blade-agent v1.0.1）：对纯 Socket.IO 握手做并发压测（Engine.IO websocket + namespace connect，带真实 JWT 鉴权，握手成功后保持连接 3 秒再断开），50 / 100 / 150 / 200 / 300 / 500 并发成功率均为 100%（原 100 并发仅 39%），问题不再复现。握手延迟 p50 随并发线性增长：50 并发 309ms → 100 并发 439ms → 200 并发 843ms → 500 并发 2267ms（max 3.4s），推测握手仍由单事件循环串行处理（吞吐约 145 次/秒），但只影响连接风暴时的等待时间，不再造成失败；500 并发瞬时 CPU 峰值约 76%（单核），内存稳定在 532MiB。注意：复测机器与 7-01 压测服务器硬件不同，且只覆盖握手环节，未覆盖"握手后跑真实 LLM 任务"的完整场景。

并发 Deploy 触发"reconcile 风暴"，CPU 打满 100%，应用发布大规模失败或长时间卡顿（两群同步出现，最多人反馈的问题）

9 点集体上线时，多人同时"发布挂了"，桌面图标已出现但发布未完成，智能体反复重试。作者贴出根因分析：日志中出现 221 次 "already installed" 409 错误 + 106 次 JWKS 鉴权超时；35 个浏览器轮询 GET /api/published-apps（60–90 次/分钟）无去重 → 每次触发 trigger_reconcile()（app_publish.py:522）→ 需获取全局 _sync_lock → reconcile 内部调用 Docker API + Blade OS API → asyncio 事件循环被阻塞调用塞满 → 单进程 CPU 100% → 所有 HTTP 请求变慢 → publish() 同样要等 _sync_lock 被排队挡住 → CLI 侧 30 秒超时（cli/internal/client/client.go:64）在请求到达服务端前就已超时。同期交付群用 htop 排查也确认服务器多核 CPU 100%、Load Average 2.3+。

"两个问题叠加导致了 deploy 失败：1. reconcile 风暴导致 CPU 100% ... 2. CLI deploy 超时太短"；"发布挂了~"；"软件工厂各页面、接口变得非常慢"；"我的图标也出现在桌面上了，但是还没发布成功"；"我的应用已经上线成功了，但是智能体还在努力尝试，很奇怪"

伴随表现（同一根因，原单列一条）：发布状态与后端实际状态不同步——桌面图标提前出现但实际未发布成功；反过来应用已上线成功，智能体却感知不到、仍在反复重试发布，浪费资源也误导用户判断（作者 / 戴振衡，20:47–20:49，PR #1094 缓解根因，待明晚压测复验）。

相关建议（原单列一条）：颜丙政在会议总结中提出，上线时临时扫端口是重行为，建议预先扫描分配好端口以优化上线速度（PR #1094 仅做了异步化，未实现预分配）。

Deploy API 参数格式与预期不符：需要 JSON body 而非 multipart 文件上传

blade deploy 命令持续超时，智能体尝试直接 curl 调用发布 API 绕过超时限制，结果返回 500；进一步排查发现发布 API 实际需要 JSON body（含 session_id、app_dir），而不是最初尝试的 multipart 文件上传方式，标准部署路径完全走不通，需人工绕过。

"原来发布API需要的是JSON body，包含session_id和app_dir，而不是上传文件！"

上下文压缩（compact）失败导致对话彻底中断（"No active chat"）——三个群均反馈，出现频率最高的严重 bug

产品研发群：朱昭、肖小智的项目对话压缩后均出现红色错误横幅 "No active chat"，看板任务面板归零；作者总结为"1. 上下文压缩失败；2. 压缩失败后无法对话"。西安创新特区：朱昭、郑宇独立复现同一故障，说明是普遍性问题而非个例。交付产品支持群：王博截图显示具体失败原因 "#4ed188 节省0%（104k→0 token）归档0个工具结果，失败原因：LLM summary generation failed after 3 attempts"；张江勃、肖小智的对话也各自独立出现过"No active chat"（重新发一条消息可临时恢复）。

"刚才的上下文压缩失败是怎么回事"；"压缩失败这个我也出现了，而且有的智能体还在执行被设置为已完成了"；"LLM summary generation failed after 3 attempts"；"@郑宇 访问下 debug/{sessionid}"

伴随表现（原单列一条）：压缩失败的同时，智能体真实进度与界面显示不一致——任务仍在执行却被错误标记为"已完成"，用户需访问 debug/{session_id} 页面才能看到真实状态，说明前端任务状态展示不可靠（郑宇 / 汪从武 / 张通，西安创新特区 21:03–21:09，PR #1095 待复验）。

〔安全/计费缺陷〕上下文压缩调用模型时走的是环境变量里的全局 SK，而非发起请求用户自己的 PAT

该操作的计费归属、用量统计、权限边界都可能记错账户，属于安全与计费层面的设计缺陷，被肖小智评价为"这才是值钱的bug"。

"惊天大 bug 呀，压缩上下文走的是环境变量里面的 sk，不是走的用户的 PAT"

应用发布上线后完全无法运行，前端接口全部 Connection Refused

发布的 GJB438C 军标文档模板应用停在"加载中"，浏览器控制台报 7 个错误：1 个 404（favicon）+ 6 条 net::ERR_CONNECTION_REFUSED，均指向 127.0.0.1:22311/api/srs/... 等接口，说明应用发布后对应的后端服务根本没有正确启动/监听。

"上线后一堆错误，没有跑起来"

Gitea 服务不可用 + GITEA_URL 默认配置错误，导致代码无法推送 / 项目仓库初始化持续 500

项目仓库初始化命令 blade kanban project bootstrap 持续返回 500，curl 探测 http://gitea:3000 连接失败；默认环境变量 GITEA_URL 在当前沙盒下不可用，需手动改成 http://localhost:30030 才能绕过。作者后来 @all 群发广播了修复方法，说明该问题影响面广、默认配置本身有缺陷，普通用户很难自行发现。

"gitea是不是挂了"；"@_all 推送到gitea之前，得先改一下gitea的url...GITEA_URL，改成http://localhost:30030"

后端多类服务异常日志（三种独立报错）

① box-ba：blade_auth_client.errors.JwksUnavailableError: PAT verification service timed out（鉴权服务超时）；② box-nexus-index：代理 pypi 包 skyfield 时报 500，FileNotFoundError: /app/data/simple（Nexus 索引目录缺失）；③ plan_progress._process_safely 流程中出现 openai.AuthenticationError: 401（模型调用鉴权失败）。

"日志抓到两个报错"（另加一条 openai 401 trace）

大项目上传无预警限制：超过 1000 个文件即卡死，无清晰提示

上传 922MB / 3146 个文件的已有项目，点击"交给智能体创建"后转圈又恢复原状，未进入后续流程。后经排查确认平台隐藏限制为"Too many files. Maximum number of files is 1000."，且单文件需 ≤25MB，但上传前完全没有提示，用户体验是"卡死无反馈"。整个过程界面只有"转圈后恢复原状""一直卡着"的中间状态，没有任何报错反馈，用户不清楚是否失败、是否需要重试（原"上传/创建过程无明确反馈"一条并入此处）。

"现在上传一个922MB的项目，点击交给智能体创建 后开始转圈，然后又恢复了。没进入后续。。"；"转完圈，又变成这样了"；"我还在卡着呢。。"

直接上传 CLAUDE.md 文件到项目触发异常

具体报错文案未截图留存，但发言明确指出上传该文件会导致异常，需要后续复现确认。

"直接上传CLAUDE.md有异常"

智能体自己生成的代码存在 bug，导致后端接口持续 500 / 反复无法启动

"启动后端服务"任务日志出现 FastAPI 异常，曹京京临时重启解决过一次但很快复现；上传的 error.txt 定位根因：design_constellation 接口调用 get_terrain_masking(req.terrain) 报 TypeError: get_terrain_masking() takes 0 positional arguments but 1 was given，导致 /api/v1/design-constellation 持续 500。反映出智能体自主编写代码的质量把关不足。

"这个算问题不？后端无法启动"；error.txt: "TypeError: get_terrain_masking() takes 0 positional arguments but 1 was given"

预览页面按钮无法点击

应用预览页面内的按钮完全无响应，具体页面/元素未进一步说明。

"预览的页面，按钮无法点击"

提交的 PR 链接点击后无法访问

项目提交 PR 后生成的链接跳转失效，无法查看 PR 内容。

"我提交的pr，我点击链接之后，无法访问"

间歇性 401 invalid token：轻则命令偶发报错，重则应用更新代码后无法下线（两群反馈，原两条合并）

朱里、汪从武执行 blade kanban list 等命令时偶发 401 invalid token（不阻塞主流程）；于静洋更新代码后持续尝试下线应用但始终失败，会议纪要印证与 invalid token 报错相关联，截图已发群里待官方排查。根因分析：v3 PAT 走中心化 Casdoor/blade-oauth 校验，网络抖动或 OAuth 服务负载高时 verify() 抛异常直接返回 401（与上文"后端多类服务异常日志"中的 JWKS 鉴权超时同源）；另有 JWT 时钟偏差、legacy key 在 SQLite 并发锁冲突两种次要成因。

"更新代码问题之后，一直尝试下线，但是无法下线"；"有时会遇到401，invalid token。不过不阻塞使用。"

对话空闲时智能体提问的选项被后续看板通知覆盖，无法点选，且长时间不会自动恢复

用户在对话空闲时被智能体询问"权限设计怎么处理？"，正准备选择答复时，之前创建的看板任务完成通知突然插入/覆盖界面，导致原提问的选项按钮点不了，等了很久也没有自动刷新恢复。

"等我选择答复的时候之前创建的智能体看板又冒出来了，导致我选择不了1图的选项，等了半天也一直没用刷新出来"

软件工厂平台未实现共享文件读写功能，阻塞跨团队协作测试

中电云团队产出的文件写入共享目录后，其他团队无法读取/测试，肖小智确认平台目前没有实现读写共享文件的功能，导致该环节测试无法进行。

"@颜丙政 好像软件工厂里面没有实现读写共享文件的功能"

GIS 类项目依赖 PostgreSQL/Redis/OpenLayers，沙盒环境不支持且无法通过内网源安装

GIS 后端需要 PostgreSQL + Redis，沙盒环境中这两个服务都不可用，也无法通过 apt/pip 安装；内网 npm 仓库也缺少 OpenLayers（ol）等前端依赖包，智能体只能被迫降级为"前端独立启动、不依赖后端"的方案。会议纪要中也提出希望软件工厂支持环境自定义配置。

"GIS 后端需要 PostgreSQL + Redis，而沙盒环境中这两个服务都不可用，且无法通过apt/pip安装"

看板任务创建耗时过长，一刻钟仍未完成

创建看板任务持续阻塞 15 分钟以上未完成，用户长时间无法继续后续操作。

"看板任务建了一刻钟了还没建好"