Nexus Core AI Agent 无限循环修复实录

AI Agent 无限循环比传统程序循环更难发现——它不卡死，而是持续产生看似合理的输出，同时默默消耗大量 token 和计算资源。Nexus Core AI OS 团队通过系统性复盘，解决了这一问题。

核心要点：

- 问题发现： 首次信号来自账务异常，某些任务 token 消耗达到 p95 基线的 8 倍，执行日志显示工具调用序列出现节奏性重复。
- 根因： Agent 在推理循环间缺乏结构化状态记忆，长上下文下自我循环检测能力退化；目标模糊和工具结果误读加剧了问题。
- 诊断手段： 通过给推理循环注入结构化检查点（checkpoint），构建执行图（执行图），直观识别循环形状（紧密两轮循环、慢漂移循环、单节点自循环）。
- 修复方案： 引入执行检查点强制 Agent 输出结构化进度报告；叠加状态哈希（局部敏感哈希）、重复追踪（相同工具+参数调用超 3 次自动拦截）、子任务深度限制（4 层）；将执行模型改为严格的两层结构（协调器→工作器），禁止递归。
- 效果： 循环发生率从 5.4% 降至 0.8%，p95 token 消耗降低约 34%，任务成功率从 91.2% 提升至 96.7%。非循环任务延迟增加 8–12%，通过异步写入检查点恢复了一半。

原文链接

#开发者 #工具

📢 频道：@DevToolboxHub

零拷贝原理：高性能数据传输秘籍

Kafka、Nginx、Netty 等工具能轻松打满 10Gbps 网络带宽且 CPU 占用极低，秘密在于零拷贝（Zero Copy）技术。传统 IO 需要 4 次上下文切换和数据在内核态与用户态之间来回复制，而零拷贝直接让数据在内核空间传输，绕过了用户缓冲区。

- 传统拷贝路径：磁盘 → 内核缓冲区 → 用户缓冲区 → 套接字缓冲区 → 网卡，经历 4 次上下文切换
- 零拷贝实现：通过 Java NIO 的 FileChannel.transferTo()，应用直接指示操作系统自文件描述符发送至套接字，数据全程在内核态
- 核心优势：数据零重复、上下文切换降为 2 次、DMA 硬件可直接从内核缓冲区拉取，CPU 完全解放处理其他请求

原文链接

#开发者 #工具

📢 频道：@DevToolboxHub

文档与 demo 是最便宜的设计审查

API 的设计缺陷，测试可能永远发现不了。文章以 turing-machine-js 引擎的 v4→v6 迭代为例，说明两种检查比测试更有效：

- 第一个真实消费者（demo）：暴露了钩子命名错误（onDebugBreak → onPause）和 halt 后事件丢失的交互问题。
- 文档（README）：当 dispatch 顺序无法用一句话说清时，揭示出形状本身有问题，最终将生命周期简化为 before(K)→step(K)→after(K)。

启发：发布 major 前先写 dispatch 段落；如果无法一句说明，设计就该改。

原文链接

#开发者 #工具

📢 频道：@DevToolboxHub

eBPF 取代用户态 Agent：内核级安全监控

eBPF 正成为安全可观测性的首选方案。传统用户态探针依赖被监控进程配合，若进程被攻破，日志可能被篡改或跳过。eBPF 直接挂载钩子到 Linux 内核系统调用接口，在容器级入侵时仍能保持可见性。关键优势包括：

- 内核层过滤数据，降低安全相关 CPU 消耗与数据传输量
- 不依赖被观察进程的协作，消除单点失效风险
- 适用于容器等动态环境，提供一致的观测基础

原文链接

#开发者 #工具

📢 频道：@DevToolboxHub

LLM评测基准存在法官偏见

Tessl 最新研究发现，使用单一 LLM 作为评分法官会带来系统性偏差。同一评测由 Sonnet、GPT-5.5、Opus-4-7 三个法官分别打分，结果排名大幅变动，某模型单项得分波动 47 个百分点。核心发现如下：

- 模型家族内部存在自评偏好：Opus 自评比另两个法官平均高出 4.6 分。
- 仅 opus-4-7 在所有法官下保持第一，其余模型排名均受法官选择影响。
- 建议：运行多个法官取平均，设计二元可验证的评分标准（如“文件是否删除”）以提升结果可靠性。

原文

#开发者 #工具

📢 频道：@DevToolboxHub