全部 · 2026-07-20

这篇预印本点出了一个很容易被忽略的时间差：我们以为 Agent 还在配环境，其实 pip install 或 npm install 那一步就已经在跑代码了。Python 的 setup.py、npm 的 postinstall、Cargo 的 build.rs 都能在安装时执行，而最终 diff 只记录仓库文件变更，不会告诉你安装脚本刚才干了什么。 作者构造了 12 个场景、5 类攻击，测了 9 种模型和客户端的组合。明显拼错的包名基本都被拦住了，但换成更接近真名的变体、加一个攻击者控制的额外 registry，或者指定一个已知有漏洞的旧版本，很多配置就放行了。这里有个关键限制：实验是构造场景，不是对真实攻击的统计，也没有独立复现。 文章给出的建议很具体：安装前先解析出包名、来源和版本，对不上预期就暂停，等开发者确认；通过检查的安装也要跑在受限环境里。但正文没披露这套规则在真实项目里的误报率，也没测不同客户端实现这些检查的工程成本。如果团队用了内部 registry 或 Git 依赖，规则怎么配、谁来维护，这些落地细节都还是空白。

这条新闻值得点开看，因为它讲清楚了一个很实际的坑：文件格式统一不等于行为统一。截至 2026 年 7 月 17 日，Codex、Cursor、OpenCode、Gemini CLI 和 Antigravity 全家桶都会扫描项目里的 `.agents/skills/` 共享目录，唯独 Claude Code 只认自己的 `.claude/skills/`，需要额外建 symlink 桥接。更麻烦的是，就算 Claude Code 找到了同一个 Skill，它那 14 个私有 frontmatter 字段——比如 model、effort、hooks、disallowed-tools——在其他客户端里会被直接忽略。这意味着你写的 Skill 在 Claude Code 里能控制模型行为、限制工具调用，换到 Gemini CLI 或 OpenCode 里就只剩 name 和 description 还管用，安全策略得重新配。 执行层的差异更大。Gemini CLI 加载 Skill 前会弹确认框，OpenCode 要求模型先调 skill 工具，Antigravity CLI 直接用文件工具读。脚本从哪个目录启动、工具名叫什么、权限怎么管，全看各家 Harness 自己的规矩。正文没披露这些差异在实际项目里导致过什么事故，但如果你打算让一个 Skill 跨客户端跑，光靠格式兼容远远不够。 自建 Harness 的开发者更得注意：OpenAI 和微软的 SDK 都只解决了 Skill 怎么进模型，扫描目录、准备依赖、沙箱、授权这些活还得自己写。文章建议维护一份克制的核心 Skill，适配层按客户端单独加，这个思路务实，但没给出具体适配成本的数据。

这篇文章把“为什么需要沙箱”拆得很清楚，核心逻辑是：审批只能看命令开头，管不了命令启动后实际执行的代码。作者沿着一次修 bug 任务走了一遍，从 npm install 的生命周期脚本，到测试框架加载的第三方插件，再到推送代码时的凭证风险，每一步都解释了为什么黑名单、逐条审批和专用工具都不够用。 文章引用了 Anthropic 和 Cursor 的工程实践，提到 macOS 用 Seatbelt、Linux 用 bubblewrap 做操作系统隔离，Docker Sandboxes 把凭证留在宿主机侧代理，这些都有出处。但全文没给任何性能数字——沙箱会增加多少延迟、快照恢复要多久、资源开销多大，这些都没提。对实际选型来说，这些缺失挺关键的。 另外，文章把“虚拟机守不住合法权限”这点讲得很实在：即使进程关在沙箱里，只要带着有效 Token 推代码，远端仓库照样会被改。它把网络策略、凭证代理和外部权限策略分成三道闸门，这个分层思路对做 Agent 安全设计的人有参考价值。整体判断都挂在具体机制上，没有画饼，值得一读，但别指望拿到可以直接对比的指标。