NeCode 桌面端 v0.0.18 正式版发布：OMN 多智能体工作流 Beta

stanley

已经是necode 的19 版本

stanley

当上下文超出时候的压缩不完善？

feieuniu

stanley 发表于 2026-9-3 14:04
是否有关，用户的体验都是失败了
至少要自动切换到bing
又一次遇到问题

http://bbs.inoteexpress.com/foru ... id=82051&extra=

v0.0.20 已更新

feieuniu

stanley 发表于 2026-9-3 14:10
已经是necode 的19 版本

这个需要优化，模型的服务器跑满了，没有响应

stanley

feieuniu 发表于 2026-9-3 16:15
这个需要优化，模型的服务器跑满了，没有响应

跑满了是上下文，还是并发？ 表达清晰 便于交流

stanley

flash 挂了（无法继续，见图）的时候，没有 另外的模型接手继续工作，需要手工切换模型

stanley

自智能体都提示阻塞，只有一个成功

stanley

让codex 分析的情况：
从截图看，这不像五个子任务各自独立报错，更像同一批并行 Executor/Reviewer 同时失去进展：五项持续时间完全一致，统一被宿主标成“已阻塞”。我先核对 oh-my-necode 的会话状态、0.1.3 运行标记和 NeCode 最近日志，区分是权限等待、父子会话调度丢失、统一超时，还是循环熔断把所有子会话一起中止。只做只读取证，不修改安装。




运行了命令


第一处关键信号已经出现：磁盘安装确实是 0.1.3，但默认的 ~/.oh-my-necode/runtime 没有任何运行标记。这意味着至少存在两种可能：当前展示的这批 Orion/Raven 等任务并不是经 oh-my-necode 的 hook 创建，或者 NeCode 启动插件时使用了另一套状态目录/根本没有成功激活插件。继续查最新 sidecar 日志和数据库里的这五个任务。




已读取文件运行了命令


数据库已经找到截图对应的同一批任务，确认它们确实来自 oh-my-necode：同一 groupID=omn-c0d4…，五个子会话由同一父会话同时创建，模型都是 ne/deepseek-v4-flash，会话元数据仍保存 variant=max。接下来读取这五个子会话各自最后一条消息、结束事件和父会话状态，判断“已阻塞”究竟是实际失败，还是 NeCode UI 对长时间无事件的派生状态。




运行了命令


证据已经足够解释大部分现象：截图中的五个会话创建后从未收到任何消息，生命周期为 0 秒、输入/输出 token 都是 0；真正先执行的是它们共同依赖的侦察任务 Nova。Nova 每次恰好运行约 120 秒后被 abort，连续重试三次。也就是说，“已阻塞”不是这五个模型都卡住，而是上游依赖三次超时后，下游任务一直没有获得调度资格。再核对任务依赖图和 Nova 的最后动作，就能说明首个超时为什么发生。




已读取文件运行了命令


现在可以把“约原因”收敛为确定链条：该批 OMN 最终状态明确记录为 Tasks exhausted recovery attempts: recon-evidence，Nova 的错误是 task recon-evidence timed out after 120000ms。另外，Nova 每次在被终止前仍在正常读文件/跑 bash，并非等权限；它的侦察任务本身覆盖五大块，超过默认两分钟预算。还有一个值得核实的异常：数据库显示这些后台子任务用了大量 reasoning 且会话仍是 variant=max，而 0.1.3 原本想覆盖为 none；我再确认这个后台执行路径是否绕过了修订插件的参数 hook。

stanley

这次不是之前的“思考复读循环”，而是 OMN 任务依赖链被首个任务的硬超时阻断。

实际过程是：

```text
Nova：recon-evidence
  └─ 每次运行 120 秒后超时
     └─ 连续重试 3 次仍超时
        ├─ Orion：依赖 Nova → 阻塞
        ├─ Echo：依赖 Nova → 阻塞
        └─ Sage：依赖 Orion + Echo → 阻塞
           └─ Raven：依赖 Sage → 阻塞
              └─ Bolt：依赖 Raven → 阻塞
```

数据库记录的最终错误非常明确：

```text
task recon-evidence timed out after 120000ms
Tasks exhausted recovery attempts: recon-evidence
```

关键事实：

- Nova 三次分别运行约 120 秒，然后被 abort。
- Nova 并非等待权限，而是在持续读文件、执行 bash 和分析大量内容；任务范围太大，两分钟内无法完成。
- Orion、Echo、Sage、Raven、Bolt 创建后都没有收到消息，输入/输出 token 均为 0，实际上根本没有开始执行。
- 截图中的“23m 13s”是从任务卡创建开始累计的排队时间，不是五个任务各自运行了 23 分钟。
- 当时没有与之同步的网络断开证据。
- 安装目录中的 `oh-my-necode` 确实仍是 0.1.3，并非被降级。

还有一个架构层问题：这批任务通过 NeCode 0.0.19 的 `omn_run` 后台执行器启动，而我们修订的外部 0.1.3 插件只提供 `omn_dispatch`，并不包含 `omn_run`。因此这里实际生效的是 NeCode 新增的宿主后台调度层；0.1.3 的文本循环熔断无法解决该调度器的两分钟超时和依赖传播问题。

建议的修复优先级是：

1. 将后台子任务超时从 120 秒提高到至少 300–600 秒。
2. 把 Nova 的五大侦察内容拆成多个可并行的小任务。
3. 不让所有后续工作依赖一个“大一统 recon”单点。
4. 重试时恢复已有子会话，而不是每次从头重新读取。
5. 上游失败后将下游明确标为“因 recon 超时而跳过”，停止继续累计误导性的运行时间。
6. 确保 0.1.3 的参数限制和熔断 hook 同样进入 `omn_run` 创建的后台子会话。

所以一句话概括：**首个侦察任务工作量过大，被宿主固定的 120 秒超时连续杀掉三次；依赖图又是单点串联结构，导致其余五项全部被连带标为“已阻塞”。**

feieuniu

feieuniu 发表于 2026-9-3 16:15
这个需要优化，模型的服务器跑满了，没有响应

好的，已记录