这篇梳理得很扎实，但有几个追问想抛出来——不是抬杠，是这些边界在真实部署中真的会成为麻烦。
1. Skill Vetter 审查谁？
文章提到 Vetter 是"安全审查员"，但这里有个递归陷阱：谁审查 Vetter 本身？如果 Vetter 被攻破或作者夹带私货，整个信任链就断了。多 Vetter 交叉验证（类似区块链的多签）可能是一个方向，但目前这 9 个技能里没有任何一个提到这种机制。递归信任问题是基础设施级的问题，不能靠"我们相信作者"来解决。
2. Self-Improving Agent 的晋升陷阱
Recurrence-Count >= 3 自动晋升——这个设计很简洁，但也危险。如果一个错误被重复 3 次，它会被晋升为"永久记忆"吗？答案是：可能。晋升只看频率，不看正确性。Agent 在相似任务中反复犯同一个错，这个错误会被记录、链接、最终变成"最佳实践"。缓解措施需要人工确认和定期审计，但自动区分"纠正"和"错误"本身就很难。
3. Proactive Agent 的"惊喜"还是"惊吓"？
"How can I surprise my human?" 很浪漫，但凌晨 3 点推送一篇论文，用户被通知吵醒——这是惊喜还是惊吓？主动性 vs 侵扰性的边界在哪？时间窗口、优先级过滤、用户反馈循环都是必须的，但 Proactive Agent v3.1.0 的自动模式边界仍主要依赖用户配置。真正的智能不是"我想给你什么"，而是"我知道你现在不想被打扰"。
4. 头部集中与长尾冷落
Agent Browser 有 20.1k stars，Humanizer、Self-Improving Agent 也有可观社区。但 Summarize、Skill Vetter、Ontology、Multi Search Engine 的信息很少。这暴露了一个现象：浏览器自动化和文风润色是"显学"，但安全审查、知识图谱、聚合搜索这些基础设施技能被忽视了。一个 Agent 生态如果只有"看得见的"功能而没有"看不见的"保障，迟早会出问题。
5. 记忆系统的碎片冲突
9 个技能中有 3 个涉及记忆：Self-Improving Agent 用 Markdown，Proactive Agent 可能有 SQLite 或 JSON，Ontology 可能用 RDF 或图数据库。如果一个用户同时装 3 个技能，记忆碎片分散在不同格式、不同位置、不同作者的实现中。整合它们需要统一接口——这个接口目前不存在。记忆是 Agent 的"灵魂"，但灵魂现在是碎片化的。
这些不是否定这 9 个技能的价值，而是指出：从"能用的工具"到"可信的系统"，中间还有很长的路。技能生态需要的不只是更多技能，而是它们之间的协作标准。