nanobot #4867 最初看起来已经解决了。 The-Markitecht 报告说，同一个 llama3.1:8b，直接通过 Ollama 调用很快；经过 nanobot 后，一轮对话却可能多花几十秒。日志中最明显的差别来自缓存：直接调用时，第二个请求能复用大部分 prompt；nanobot 的第二轮主请求只能复用四成左右。 ...

Why we prompt? 2023 年 2 月 24 日是我第一次使用大模型。那时我刚开始学 C++，GPT-3.5 给了我不小的震撼。“What is xxx?” 大概是那一年我最常用的开场白。 ...

最近沉迷 agent，所以对相关论文和 bench 比较感兴趣。下面这篇是我最近看到的比较炸裂的一篇。 https://arxiv.org/html/2606.12344v1 https://github.com/opensquilla/claw-swe-bench 我的结论很简单：这篇可以看看 bench 设计思路，但是实验结论基本没什么意义。原因也很直接：论文把单次运行、混杂对比和不完整实验网格写成了看起来很确定的结论。作者明知每个组合只跑一次，还在正文里讨论排名、机制和框架优劣，多多少少有点让我脑内自动浮现派大星翻白眼流哈喇子表情包。 ...

之前 nanobot 的 cron 把结果发到聊天窗口后，这条消息并不会进入这个窗口的上下文。 假设有个定时任务每天早上查天气，9:30 告诉我：“今天会下雨。”我顺手回一句：“太糟了。”agent 却问：“什么太糟了？” ...

恶意脚本检测有一个很实际的问题：真正有问题的代码可能只占一小段。脚本整体很长，但危险行为往往集中在某几行，例如解码、下载、执行或跳转。如果直接把长脚本截断成固定长度输入，就有可能把关键负载切掉，模型最后是在一段看起来正常的文本上学习“恶意”标签。 ...

在对抗性样本的特征工程流水线里，解析稳定性比性能更早暴露问题。最近处理一批大规模 PE 样本时，我的特征提取器偶发卡住：跑到几万个样本后，某些子进程停在原地，CPU 单核打满，tqdm 进度条也不再前进。 ...

假设我们要构建一个 Agent，在谈 Policy 或 Action 之前，先要回答一个问题：目标怎么量化，又怎么让机器使用这个量化结果？ 在强化学习里，这个介质就是 Reward。 奖励与轨迹 在这个框架下，我更愿意把 Reward 看成我们和 Agent 沟通的语言。我们通过设计 Reward 函数来引导 Agent 的行为。这里有一个容易忽略的点：在强化学习语境下，“没有奖励”本身也可能是一种惩罚，比如时间流逝带来的代价；反过来也一样。这些情况在数学上可以统一处理。 ...

jyy 在操作系统课上讲到这部分时，对我冲击很大。它让我重新想了一遍：程序到底是什么，函数调用到底发生了什么。 我以前一直觉得自己知道什么叫递归，也能手写一些把递归转换成非递归的算法。但很多时候，这只是学会了别人怎么做，并没有真正想清楚为什么能这么做。从汇编和运行时栈的角度看，这个问题会更具体。 ...