假设你对一个代码 Agent 说： 帮我克隆并运行某个最近很火的项目。 你只记得项目名，不记得 GitHub 所有者。Agent 根据自己的知识生成了一个看起来合理的地址： https://github.com/project-name/project-name 这个地址原本并不存在。 但当 Ag

当 Coding Agent 准备修改文件、执行命令或者访问工作区外资源时，产品通常会弹出一个确认框： 是否允许修改 project_settings.json？ 用户查看路径和 diff，点击“批准”。从交互流程看，人类仍然掌握最终决定权。 但这里存在一个被长期忽略的问题：用户批准的究竟是界面中显

过去谈软件供应链安全，我们通常会画出这样一条链路：源代码、第三方依赖、构建系统、软件包、部署产物。相应的防御手段也围绕这条链展开：用 SCA 检查依赖版本和已知漏洞，用 SBOM 建立组件清单，用静态分析寻找代码缺陷，再对构建和发布环节进行签名与审计。 但 Agent 正在改变这条链路。 一个现代

前段时间，我分别用 std::chrono 和 __rdtsc() 测量同一类计算，得到了两组看起来完全不在一个世界里的结果： chrono delta = 29224041600 rdtsc delta = 70798114701 第一反应很容易是：CPU 执行了七百多亿个周期，而 chrono

假设有一千万个整数，我们只累加其中大于 128 的元素：  std::uint64_t sum = 0;  ​  for (int value : data) {      if (value >= 128) {          sum += value;     }  } 现在准备两份内容完全

最近我在准备一套能够长时间运行的漏洞挖掘系统。它需要读取目标项目、调用分析工具、理解结果、提出新的检查方向，并在尽量少依赖人工干预的情况下持续工作。由于运行环境后续可能断网，模型、工具、知识库和执行脚本还必须提前部署完整。 这个过程让我重新思考了一个看起来很简单的问题：一个大模型能够调用工具，再给它

最近一段时间，AI Agent 在安全领域的讨论明显变多了。代码审计、漏洞挖掘、渗透测试、应急响应、二进制分析，几乎每一个安全方向都开始尝试把大模型接入原有工作流。 但很多讨论容易走向两个极端。 一种极端是把 Agent 理解成“会调用工具的大模型”。给它一个任务，让它自己想、自己查、自己调用命令，

很多人第一次听到 Fuzzing，容易把它理解成“随机生成一堆输入，然后看程序会不会崩”。这个理解不能说完全错，但只停留在了最表层。真正有效的 Fuzzing，核心并不是“随机”，而是“反馈驱动的搜索”。 换句话说，Fuzzing 并不是单纯地往程序里乱塞数据，而是在一个巨大的输入空间里，不断尝试找

从 Intent 到 XPC：不同操作系统如何让进程互相说话 很久以前我学操作系统的时候，对“进程间通信”的理解很朴素：管道、消息队列、共享内存、信号量、Socket，大概就是进程之间传数据的几种办法。这个理解当然没错，但它只覆盖了 IPC 最底层的一面。 如果把视角从内核 API 拉到真实的用户体