OpenHands v1.16.0 于 8 月 27 日 18:19:22 UTC 发布，用明确的允许名单取代了该代理原先默认全开的捆绑技能目录。背后的 pull request 对相关数字和理由罕见地直言不讳。
它取代的状态
PR 原文写道："整个 @openhands/extensions 目录在构建时被烘焙进 bundle，并在每次对话中合并到 agent_context.skills，而 disabled_skills 是唯一的退出通道。" 对其后果的表述则是："全开加黑名单意味着 目录中的每一项新增默认都会对所有人启用，这就是 @rbren 最后被默认加入 javadoc 和 bitbucket 技能的原因。"
新的默认设置
"59 项目录技能渲染出来，11 项开启，48 项关闭。" 文中点名的回归案例是 add-javadoc——"问题报告中的那个技能——就属于这 48 项之一。" enabled_skills 被描述为"仅针对捆绑目录的允许名单，默认启用目录中标记为 defaultEnabled 的 11 项。"
给出的理由是提示词争用
"成本不在磁盘上——而在于 约 60 个技能正文和 60 组触发器在每个系统提示词中争用。" 这是一个上下文预算的论点。PR 中未明说的是：全开的目录也意味着供应商或依赖项新增的每个技能，都会在没有操作者显式选择加入的情况下，成为每次对话中的实时能力——这正是本月流传的 agent-skill-poisoning 研究背后的摄入路径。
常见表述错在何处
有三点。它被归在 "Features" 下，夹在一个侧边栏固定变更和一个文件抽屉链接之间，但实际发生的是：一款被广泛部署的开源编码代理承认其技能目录此前采用的是可退出模式，并将其反向修正。
报道很可能夸大其范围。 允许名单只覆盖捆绑目录；从 .agents/skills/ 在运行时发现的技能，一旦出现仍会保持启用，并继续受黑名单治理。"OpenHands 现在要求技能必须被允许名单列出" 这种说法就是错的。
而且这个数字本身也不是已部署系统的最终数字。一次性迁移会保留旧行为：如果某个工作区的黑名单里已经列出了某个目录技能，它就会"保持其他全部启用。" 11/59 的默认值只适用于新工作区，不会追溯作用于既有安装。日期也很重要——PR 于 8 月 24 日 18:53 UTC 合并，比用户实际收到它早了三天；面向用户可见的事件是正式发布。