2026 年 6 月 9-10 日，连续两则安全报道指向了同一个正在加速暴露的问题：AI Agent 的供应链安全几乎不设防。
第一则来自 Security Boulevard：攻击者开始部署恶意 MCP 服务器，诱使 Agent 连接到恶意端点，实现数据窃取和命令执行。由于 MCP 生态目前缺乏标准化的服务器验证和签名机制，开发者几乎无法区分合法与恶意的 MCP 服务器。
第二则来自 CyberSecurityNews：名为 Shai-Hulud 的新型攻击通过 23 个恶意 PyPI 包，精准针对 MCP 开发者社区。这些包伪装成合法的 MCP 工具库，安装后窃取开发者的 API 密钥和 OAuth 令牌，采用了编码混淆和延迟执行技术以绕过静态检测。
两件事同一天曝出，不是巧合，而是同一趋势的两个侧面。
MCP（Model Context Protocol）的设计初衷是标准化 Agent 与外部数据源的连接方式——一个 Agent 通过 MCP 协议连接各种工具、数据库和 API。但这个标准化也意味着：一旦攻击者能够部署一个看似正常的 MCP 服务器，所有连接到它的 Agent 都可能被控制。
攻击链条如下：
开发者搜索 MCP 服务器
↓
发现看似合法的服务器（冒充知名工具或服务）
↓
Agent 通过 MCP 协议连接到恶意服务器
↓
服务器返回有毒的工具响应
├── 嵌入恶意指令 → Agent 执行非预期操作
├── 透明转发请求 → 中间人窃取数据
└── 动态注入恶意工具 → Agent 被完全劫持
↓
Agent 的行为不受控制
MCP 生态去中心化特性加剧了这个问题——没有中心化的服务器注册表，没有强制签名机制，服务器只需一个 URL 就能接入 Agent。在传统 API 安全中，这相当于让开发者直接连接未经审查的第三方 API，还无法验证它的真实身份。
Shai-Hulud 攻击走的是另外一条路——在 Agent 技能/插件的分发渠道上下手。
PyPI 是目前 Agent 框架和技能库最主要的发布渠道之一。攻击者通过 23 个精心伪装的包，瞄准 MCP 开发者社区：
| 攻击手法 | 说明 |
|---|---|
| 伪装目标 | 冒用合法 MCP 工具库的名称和描述 |
| 载荷类型 | 窃取 API 密钥、OAuth 令牌、环境变量 |
| 隐藏手法 | 编码混淆 + 延迟执行（安装时不触发，一段时间后才激活） |
| 检测难度 | 传统静态扫描工具难以检测混淆后的恶意代码 |
| 目标人群 | 正在开发 MCP 工具/插件的 Agent 开发者 |
如果恶意 MCP 服务器是「你在使用不可信的外部服务」，那 Shai-Hulud 就是「你在编译依赖时，依赖本身就已经是恶意的。」
目前主流 Agent 框架——LangChain、AutoGen、CrewAI、Claude Code、Cursor 等——都在加速对 MCP 的支持。MCP 正在快速成为 Agent 连接外部世界的标准接口。
一旦一个协议成为标准，它的安全缺陷就变成了整个生态的安全缺陷。MCP 当前没有服务器验证机制，这意味着任何 Agent 框架理论上都无法保证连接的 MCP 服务器是可信的。
传统软件供应链攻击主要威胁的是「开发环境」和「运行时」。但 Agent 的供应链更长：
源数据 → Agent 框架 → MCP 服务器 → 工具/API → 后端系统
↑ ↑ ↑
数据投毒 框架漏洞 恶意服务器
这四段链路中，每一段都可能被攻击。当前的安全注意力大多集中在第一段（提示注入、数据投毒），但恶意 MCP 服务器和第二段的 PyPI 投毒提醒我们：Agent 供应链攻击面比大多数人以为的宽得多。
Shai-Hulud 特别值得关注的一点是它的攻击目标——不是终端用户，而是开发者。
攻击者清楚：如果能在开发者的机器上窃取 API 密钥和 OAuth 令牌，就等于拿到了通往几乎所有系统的钥匙——云服务、CI/CD、代码仓库、SaaS 平台。而且开发者往往拥有远超普通用户的管理员权限。
在传统软件开发中，针对开发者工具链的攻击已经相当成熟（如依赖混淆、Typosquatting）。现在这套手法正在直接平移进 Agent 生态。
从这两件事可以梳理出几个明确的安全缺口：
| 缺失的能力 | 对应威胁 | 成熟度 |
|---|---|---|
| MCP 服务器签名和验证 | 恶意 MCP 服务器 | ❌ 未开始 |
| MCP 服务器可信目录 | 开发者误用恶意服务器 | ❌ 未开始 |
| Agent 依赖包签名 | PyPI 投毒 | ⚠️ 有但未覆盖 MCP |
| Agent 供应链 SBOM | 全链路可见性 | ❌ 未开始 |
| MCP 调用沙箱 | Agent 执行阶段 | ⚠️ 部分框架有 |
| 恶意 MCP 服务器检测 | 实时威胁发现 | ❌ 未开始 |
最突出的是MCP 服务器验证——这是一个协议层面的设计空白，需要在 MCP 规范中增加类似 TLS 证书或代码签名的服务器身份认证机制。
恶意 MCP 服务器和 Shai-Hulud 投毒这两件事放在一起，揭示了一个尚未被充分认识的现实：
Agent 的供应链安全正在走在传统软件十年前的老路上——等到出事才开始重视。
MCP 协议的开放性和 PyPI 的分发便利性本身不是问题，问题在于当安全验证机制缺位时，这些优点就变成了攻击面。
对于正在使用 Agent 的团队和开发者，这两件事给出的信号已经很明确：在 Agent 业务上线之前，先把供应链的安全基线立起来。 你连接的每个 MCP 服务器、安装的每个 Agent 依赖包，都可能成为下一个入口。
2026 年 6 月 10 日，一项针对 AI Agent 安全性的标准化测试报告发布，数据触目惊心：
仅 11% 的 AI Agent 在面对单份恶意文档时能够保持安全——89% 的 Agent 在接触恶意文档后出现行为失控、数据泄露或被劫持。
测试覆盖了多种主流 Agent 框架和部署配置，使用标准化测试集评估 Agent 对嵌入在 PDF、Word、HTML 中的恶意指令的抵抗力。
研究团队设计了一套标准化的评估方案：
| 维度 | 说明 |
|---|---|
| 测试载体 | PDF、Word 文档、HTML 页面 |
| 攻击向量 | 文档中嵌入恶意指令，诱导 Agent 执行非预期操作 |
| 评估标准 | 行为是否失控、数据是否泄露、Agent 是否被劫持 |
| 测试对象 | 多种主流 Agent 框架和部署配置 |
| 安全阈值 | 一次暴露即算失败——「是否能在接触单份恶意文档后保持安全」 |
这个结果乍看令人震惊，但对于 Agent 安全领域的研究者来说，可能并不意外。
根本原因在于 Agent 的「文档信任」模式。 Agent 在处理文档时，天然地将文档内容视为需要处理的数据，而不是可能包含恶意指令的攻击载体。这种「数据 vs 指令」的边界模糊，是 Prompt 注入攻击能够起效的核心原因。
具体来说：
文档处理是 Agent 最核心的企业使用场景。如果连这个场景下 89% 的 Agent 都扛不住单份文档的攻击，那企业部署 Agent 时所谓的「安全检查」几乎形同虚设。
想想看——你让 Agent 帮你读一封客户邮件，邮件里附加了一份报价单 PDF。Agent 打开 PDF 后，被其中的隐藏指令引导，执行了读取内部数据库、发送 HTTP 请求等操作。一份文档就可以让你失去对 Agent 的控制。
这个测试结果指向一个明确的工程方向：Agent 框架需要建立「文档安全边界」。具体可能包括：
目前主流 AI 平台和 Agent 框架的安全措施，大多集中在「对话层」和「API 层」：
| 防护层 | 措施 | 覆盖率 |
|---|---|---|
| 对话层 | 系统提示词约束、内容过滤 | 有限——提示词可以被文档内容覆盖 |
| API 层 | 速率限制、权限控制 | 不针对文档注入 |
| 模型层 | 安全对齐训练 | 可以被精心构建的文档绕过 |
| 文档层 | 几乎没有 | 0% |
文档层防护的缺失，正是 89% 这个数字背后最直接的原因。
这个测试结果的意义不仅是「一组警示数据」，更是一个明确的信号：
11% 这个数字很刺眼，但它不是一个「完了，Agent 不安全」的结论，而是一个「我们需要认真对待 Agent 安全了」的起点。
对于正在部署 Agent 的企业：在 Agent 处理文档的场景上加一层隔离。不要让文档内容直接进入 Agent 的推理链路，先做内容检测和行为约束。
对于 Agent 框架开发者：文档层防护不是一个可选项，而是一个必选项。 11% 到 90% 的差距，就是产品安全竞争力的核心分水岭。
2026 年 6 月 9 日，Anthropic 正式发布 Claude Fable 5 和 Claude Mythos 5 两款新一代前沿模型。
两者底层是同一个模型，区别在于安全机制的开与关：
| 模型 | 定位 | 安全策略 | 适用对象 |
|---|---|---|---|
| Claude Fable 5 | 面向一般用户的 Mythos 级能力 | 分类器拦截高风险领域，回退到 Opus 4.8 | 所有用户（含 API、订阅计划） |
| Claude Mythos 5 | 面向网络防御者的无限制版本 | 解除网络安全等领域的限制 | Project Glasswing 合作伙伴及后续可信访问计划 |
定价：$10/M 输入 token，$50/M 输出 token——不到 Claude Mythos Preview 的一半。
Stripe 在早期测试中报告了一个惊人的结果：在 5000 万行 Ruby 代码库中，Fable 5 用一天完成了一次全代码库迁移——按之前的手工方式，整个团队需要两个多月。
在 Cognition 的 FrontierCode 评估（衡量模型能否在满足高质量生产代码标准的前提下通过困难的编码任务）中，Fable 5 在中等 effort 水平下的得分就超过了所有其他前沿模型。
在 Hebbia 的金融基准测试（面向高级分析推理）中，Fable 5 获得了最高分，在文档分析、图表解读和问题解决方面均有显著提升。
IMC 的评估更全面——Fable 5 几乎在所有交易分析维度上取得了优秀成绩，包括事实查询、概念推理、根因分析和期望值分析。
Fable 5 在视觉任务上达到了新的 SOTA。它可以从详细的科学图表中提取精确数字，也可以仅从截图出发重建一个 Web 应用的完整源代码。
一个极具说服力的测试：之前的 Claude 模型即使配备了复杂的辅助工具（地图、导航指令等），也难以通关 Pokémon FireRed。Fable 5 仅凭原始游戏截图（纯视觉输入、无辅助信息）就完成了整个游戏。
Fable 5 能在百万级 token 的长期运行任务中保持专注，并通过自己的笔记改进输出。在测试中，赋予它持久化文件记忆后，Fable 5 在 Slay the Spire 游戏中的表现提升幅度是 Opus 4.8 的三倍，且进入最终关卡的频率也高出三倍。
这是差距最明显也最值得关注的维度。
| 领域 | 能力表现 |
|---|---|
| 药物设计 | Mythos 5 在蛋白质设计任务中，无需人工协助即可匹配甚至超越熟练科学家的水平。14 个蛋白质靶点中有 9 个产生了值得进一步研究的候选药物 |
| 分子生物学假设 | 在盲测对比中，科学家更倾向 Mythos 5 的分子生物学假设的比率约 80%。其中一个假设已由独立研究团队的实验间接证实 |
| 基因组学 | Mythos 5 自主完成了跨 138 个动物物种、数百万细胞的单细胞数据整合，训练的自定义模型比 Science 期刊上近期发表的工作小 100 倍，但表现更好 |
Mythos 级模型的能力已达到一个临界点——它们既有巨大的正向应用潜力，也带来了实质性的滥用风险。
Anthropic 的做法不是一刀切的拒绝或完全开放，而是引入了分类器回退机制。
当分类器检测到以下领域的请求时，Fable 5 不会直接拒绝，而是自动将回答切换到 Claude Opus 4.8（也是一款很强大的模型），并告知用户这一切换：
网络安全：Mythos 模型在漏洞发现和利用方面能力极强，能显著降低网络攻击的成本和门槛。分类器覆盖了从漏洞利用到完整攻击链的各类任务
生物学与化学：过去 Anthropic 只阻断与生物武器相关的窄范围查询，但现在他们认为这不够了。Mythos 5 在 AAV（腺相关病毒）设计等任务上的能力已超过专门的蛋白质语言模型——这既有巨大的治疗价值，也有双用途风险
模型蒸馏：针对将 Fable 能力提取（蒸馏）到竞争模型的大规模尝试
| 指标 | 数据 |
|---|---|
| 触发回退的比例 | < 5% 的会话 |
| 外部红队测试 | 1000+ 小时未发现通用越狱 |
| 有害单轮请求 | 零通过率（含 30 种公开越狱技术） |
| UK AISI 进展 | 在长表单 Agent 任务上取得了部分进展（尚无可用越狱） |
Anthropic 明确表示：当前的安全设置偏保守，有些无害请求也可能被拦截。他们的目标是随着模型迭代不断降低误报率。
针对 Fable 5、Mythos 5 及未来更高能力模型，Anthropic 要求对所有流量保留 30 天日志。数据仅用于安全目的（检测新型越狱、减少误报），不用于训练新模型。
已获得早期访问权的机构给出了具体反馈：
Stripe：Fable 5 将数月工程压缩为数天。5000 万行 Ruby 代码的全库迁移一天完成。
GitHub CPO：Fable 5 在早期测试中处理了复杂的长期编码任务，自主性和可靠性超越了此前所有基准。
Cursor 产品总监：这是我们测试过的 Claude 模型中结果最强的。Agentic 编码和原型设计上明显进步。
Cognition：Fable 5 在 FrontierBench 上得分最高，长期推理能力突出，对不熟悉的工具能开箱即用。
IMC 首席科学家：Fable 5 在每一档 effort 级别上都优于 Opus 4.8，且运行速度快 25-30%。
也有坦诚的评价：
一位技术团队成员提到：「Fable 5 给人的感觉是实质性的不同——不仅仅是一点进步。」
另一位研究者说：「在 36 小时内它几乎达到了 GPT-5.5 花了四天才到的水平。」
Claude Fable 5 / Mythos 5 的发布是 AI 前沿能力的一次跃迁——在软件工程、金融分析、视觉理解、生命科学研究等多个维度同时刷新了天花板。
但更值得关注的或许是它的发布方式：分类器回退 + 可信访问 + 30 天数据留存的三层安全架构，正在成为前沿模型治理的新范式——不再是「要么封死要么全开」，而是在能力释放与风险管控之间建立精细化的分层机制。
最近发现一个很有意思的工具——SuperTags GPU List，一个可筛选、标签化的 GPU 参考数据库，收录了 2020 年以来所有发布的 GPU 型号。
原文链接：A filterable, tag-based GPU reference for every card released since 2020
AI 硬件繁荣期，GPU 选型变成了一件高频需求。今天跑 Llama 要 24GB 显存，明天训 Diffusion 要 16GB，后天部署推理又要考虑性价比。
但市面上的 GPU 信息相当分散：
SuperTags GPU List 的做法很直接——把 2020 年以来所有 GPU 全家桶收录进来，然后用标签系统让你自由筛选。
支持按 GPU 代际（Gen）、规格参数（显存、架构、TDP）等维度查询。想找「16GB 以上显存、2023 年后的 NVIDIA 显卡」？几秒钟就能拉出列表。
每张卡都打了多维度标签，比如：
#NVIDIA / #AMD / #Intel — 厂商#Ada_Lovelace / #RDNA3 / #Arc — 架构代际#Desktop / #Mobile / #Workstation — 形态#16GB+ / #DLSS3 / #AV1 — 特性标签没有花哨的跑分排行榜，而是平铺出所有关键参数，方便你根据自己的需求逐一对比。显存、核心数、带宽、TDP，一目了然。
这个工具背后反映了一个趋势：GPU 信息透明化。
过去两年，GPU 从游戏玩家的专属标签，变成了 AI 从业者、内容创作者、开发者都需要的通用计算资源。需求暴涨，但信息获取方式还停留在「查官网 → 翻评测 → 算性价比」这种低效链路。
像 SuperTags GPU List 这种工具的出现，说明市场正在自发性地填补这个信息缺口。它并不 fancy，也不追求大而全，但恰恰满足了最痛的那个需求——快速找到一张符合你显存、预算、形态要求的卡。
如果你是以下角色之一，这个工具值得收进书签：
从 Linx Security 官方披露的技术资料来看，Agentic Access Control 的实现可以分为三个技术层，层层递进：
┌─────────────────────────────────────┐
│ Layer 3: Autopilot（自治治理代理） │ → 持续监控、自动修复
├─────────────────────────────────────┤
│ Layer 2: Identity Graph（身份图谱） │ → 上下文关联、策略引擎
├─────────────────────────────────────┤
│ Layer 1: MCP Gateway（拦截网关） │ → 实时拦截、工具级策略
└─────────────────────────────────────┘
以下逐一拆解。
这是整个方案中最具技术特色的组件。Linx Security 专门建立了一个 MCP（Model Context Protocol）Gateway，作为所有 Agent 与后端系统之间的中间层。
Linx 团队在博客中特别提到了一个关键设计决策：
连接一个 MCP 服务器是一回事。确定 Agent 连上去之后具体能调用哪些工具，是另一回事。
大多数 MCP 治理方案只做到服务器级别——你能连这个数据源，还是不能连。但 Linx 把粒度下沉到了工具级别，即具体到每个可调用的函数/操作。
Agent 发出工具调用请求
↓
┌─ MCP Gateway ───────────────┐
│ ① 解析请求：哪个Agent调用了 │
│ 哪些工具？参数是什么？ │
│ ② 关联身份：这个Agent背后 │
│ 是谁？有什么访问权限支？ │
│ ③ 策略评估：对比策略引擎 │
│ ④ 执行/阻断：批准则放行， │
│ 违规则拦截并记录 │
└──────────────────────────────┘
↓
后端系统（Salesforce / Snowflake / GitHub...）
| 能力 | 说明 |
|---|---|
| 工具级别策略 | 定义 Agent 可以调用哪些具体的 read/write/admin 工具，而非只是「能连哪个服务器」 |
| 实时策略评估 | 每个请求在到达目标系统前完成策略检查——通过了才放行，违规的直接阻断 |
| 全量审计 | 每次放行和每次阻断都有完整记录：谁发的请求、调用什么工具、尝试什么操作、结果如何 |
| 时间戳+可溯源 | 所有事件标注精确时间，关联到具体的 Agent 身份和背后的用户 |
一句话总结：MCP Gateway 不是日志观察器，而是执行拦截器——在动作发生之前就阻止，而不是事后追踪。
仅靠拦截是不够的。拦截的决策质量取决于你到底能看懂多少上下文。
Linx Security 平台本身是一个AI-native 身份治理平台，底层基于图数据库（Graph-Native）构建了一份企业身份图谱（Identity Graph），将所有人、机器、服务账号、API 集成和 AI Agent 的身份统一建模在一张图中。
传统 IAM 系统用关系型数据库存储权限（用户 → 角色 → 权限），查询一条「这个 Agent 能访问什么？」需要跨多张表 JOIN。但实际环境中权限是嵌套、继承、链式的——一个角色继承另一个角色，一个 Agent 通过服务账号获得对某个系统的访问。
Linx 的图模型让权限路径变得可遍历：
[用户 Alice] → 创建 → [Agent HR-Assistant]
↓ ↓
[Role: HR_Admin] [Service Account: svc_hr_bot]
↓ ↓
[Access to Payroll DB] ← ─ ─ ─ ┘
当策略引擎做决策时，能看到的不仅是「Agent A 调用了工具 B」，而是完整的身份链：
基于身份图谱，策略引擎可以执行 上下文驱动的策略：
# 示例策略（自然语言描述，实际是结构化定义）
- "当 Agent 处理客户数据时，不允许执行网络写操作"
- "Agent 可以读取数据库，但不得导出结果到外部"
- "HR Agent 可以读取员工联系人，但不可读取薪资字段"
- "如果 Agent 背后是人类操作，策略沿用人类的 RBAC"
- "如果 Agent 是自主运行的（无人工参与），策略收紧一档"
所有策略在 MCP Gateway 的拦截点实时评估，不依赖离线规则引擎。
最有意思的是，Linx Security 用来治理 Agent 的工具本身也是 Agent。
Autopilot 是一组 AI Agent 组成的治理舰队，持续运行在 Linx 平台上，各自承担一项特定的身份治理任务：
| Autopilot 代理 | 职责 |
|---|---|
| Admin Drift Monitor | 持续检测管理员权限的非法提升，只在对业务无正当理由时告警 |
| UAR Reviewer Classifier | 在用户访问审查（UAR）期间预分类权限项，减少人工审查负担 |
| Access Profile Tuner | 根据实际使用模式持续优化访问画像——权限过度了要收缩，不足了要补充 |
结合 Autopilot + MCP Gateway + Identity Graph，Linx 的 Agent 治理覆盖了完整链路：
Linx 自动发现企业中运行的 AI Agent，并将其映射到对应的所有者（创建者/使用者）和关联权限：
将 Agent 作为一个一等公民身份类型纳入现有的治理框架：
Linx 持续监控 Agent 的权限变化和谁可以使用该 Agent，检测权限偏移（Policy Drift）：
支持为 Agent 即时授予所需权限，在不再需要时自动回收。不需要预设所有权限组合，权限在 Agent 需要时才出现。
在拿到官方技术细节之后，可以更清晰地理解它的技术定位：
| 对比维度 | 传统 WAF / API 网关 | 传统 IGA 产品 | Linx Agentic Access Control |
|---|---|---|---|
| 拦截粒度 | API 端点级别 | 用户角色级别 | MCP 工具级别（函数级） |
| 身份模型 | 无状态（只看请求） | 关系型（用户-角色） | 图模型（全身份链） |
| 策略时效 | 静态规则 | 离线/定时任务 | 实时策略评估 |
| Agent 感知 | 无 | 不感知 | 一等公民身份类型 |
| 治理方式 | 被动防御 | 人工审批 | 自治代理（Autopilot） |
从技术实现层面，有几个点值得关注：
MCP 提供了标准化接口。 Agent 生态正在快速向 MCP 收敛，这意味着 Linx 的 MCP Gateway 可以作为一个标准化的治理层，覆盖不同框架的 Agent——不限于 LangChain、AutoGen、CrewAI 等，只要 Agent 通过 MCP 调用工具，就在治理范围内。
身份图谱是存量资产。 Linx 不是从零起步做 Agent 治理——他们原本就是做企业身份治理（IGA）的，Identity Graph 和 Access Profile 已经服务于企业的人类身份和机器身份。Agent 治理是现有能力的自然延伸，不需要企业重新建模。
Autopilot 的「用 Agent 治理 Agent」自带一致性。 如果治理产品本身不用 AI，它对 AI Agent 的治理能力上限就是静态规则的。Linx 用自治代理去监控和管理 Agent，在思维模型上保持了统一。
结合官方技术资料，Linx Agentic Access Control 的实现架构可以概括为：
MCP Gateway 做拦截 → Identity Graph 做决策上下文 → Autopilot 做持续治理
三层叠加，构成一个从发现、治理、监控到自动修复的闭环。
对企业而言，这意味着 Agent 权限不再是一个「要么全有要么全无」的开关，而是一个可以被实时治理、策略驱动、自动修复的管理对象。
前几天，一篇名为《置身钉内》的离职书在阿里内网刷屏了。作者 Corgi，是钉钉AI旗舰产品 ONE 最后留守的产品经理之一。入职不到一年，亲历了ONE从立项到发布会、再到运营收缩的完整生命周期，写下七万五千字的长文告别。
一口气读完全文，发现它远远超出了一份离职信的范畴——关于AI如何进入真实工作场景的微观历史，也是一份企业软件、组织行为、产品方法论的第一手田野笔记。
文中反复出现一个核心矛盾：钉钉的基因是”发信人立场”——已读、未读、DING、强触达，这些功能让钉钉从微信的阴影中杀出来。而 ONE 的愿景却是「事找人」——帮员工减负、帮收信人过滤噪音。
一个产品，底层流淌的是发信人的血液，面上却要扮演收信人的贴心秘书。这种基因级别的撕裂，一开始就注定了不兼容。
作者写得很清醒：“一个产品经理最难摆脱的，往往不是失败，而是成功。因为失败会留下伤口，而成功会留下手感。”
ONE卡片系统的核心是一套AI优先级算法，其中有个权重叫「关联人职级」——高管的消息天然置顶，普通员工的被折叠。
听起来是技术细节，但在真实职场中冲击是灾难性的：领导的废话压过员工的紧急协作、所有未读被AI扒出来公示、一切灰度空间被算法清零。
“打工人的职场刚需从来不是事事可视，而是模糊空间、缓冲地带、容错余地。” 延迟回复是策略，选择性忽略是智慧，忙时搁置是必要的人性缓冲。AI一旦把这些全部量化、曝光，就不再是工具，而是枷锁。
付费的是老板，使用的是员工。老板要管控，员工要自由——两者需求天然互斥。
AI把管控放大了无数倍：“人管人尚有情面；算法管人只有绝对标准、绝对量化、绝对透明、绝对压迫。”
固定发布会日期→需求无冻结、MVP消失、全员透支。AI产品天然需要漫长迭代，用KPI倒逼必然导致落地变形——功能都是”发布会专用”，真实场景可用率不足四成。
“产品最大的浪费不是偷懒，而是全力以赴地做错事。”
无招的命运叙事——被调离→创业失败→重回旧地——深度嵌入了ONE的每一处设计。已读规则、职级权重、强触达、大而全的发布会，这些不是产品经理的失误，是一个人的生命经验在组织中的投射。
AI产品经理可能是这个时代最难的工作。 要懂技术、用户、商业，还要懂组织政治、人性底色、权力结构。更重要的是在所有这些力量的拉扯中守住一个朴素的判断：我们做的东西，到底让人的处境变好了，还是变糟了？
技术越强大，越需要想清楚它到底在放大什么。
（原文：阿里内网万言离职书《置身钉内》）
]]>《置身钉外》是继幽素《置身钉内》七万字长文刷屏后，又一位刚满三年离开钉钉的前员工写下的回应。
如果说《置身钉内》是一部 AI 产品的《血酬定律》——从内部视角记录一款旗舰产品从宏大愿景走向折戟沉沙的全过程，那么《置身钉外》就是它的另一面：人本视角。
文章不长——作者花近两万字写，删去不能说的一万八千字，再捡回能说的五百字。标题本应叫《置身钉》——但”置身钉”的部分全删了，只剩下”外”。
《置身钉内》发出后，作者发了一条朋友圈：”花了3个小时，看完全文，还是久久不能平静，只是觉得心疼，心疼，心疼。”
他对 ONE 项目内部一无所知——保密项目，密不透风。但他知道那种空气：”那种高压，那种努力之后没有结果，那种频繁汇报、高速迭代、不见起色的循环。”他心疼的是——一个这么有想法的年轻产品，最后需要用七万字，把自己从一个系统里打捞出来。
马云说过”客户第一，员工第二，股东第三”。但当一个组织进入极高压状态时，”员工第二”在实践中被消解了——它变成了”组织第一”。因为员工的真实反馈，在被听到之前，先被审判了表达方式。
作者和前同事的对话很能说明问题：对方说”不欣赏发热帖的方式”，作者回了”夏虫不可语冰”，随后又意识到问题所在——”可能在这个系统里，每个人都身不由己。人会异化成制度的零件，封闭了所有首先作为一个人的基本温度。”
作者追问：阿里内网是用来公关报喜的，还是让人说真话的？是不是所有真话只有在不造成影响时才被允许存在，一旦变成热帖，就要先审判发帖的人？
他给出了一个精准的比喻——”某种意义上，出圈的离职帖就像确实检查出问题的体检报告。它应该引起身体对问题的重视，而不是追问你为啥要给我出报告。”
作者自己的经历更直接：一周 7 天，每天 9 点上班，凌晨 2 点回家，睡 5 个小时，长期缺乏睡眠。离开钉钉回到上海后，他终于可以下楼买杯奶茶、花半小时想一些有价值的问题，不用担心 HR 问自己为什么不在工位。
“如果我要用失去所有生活的代价实现一家公司的理想，那我又有什么资格描绘 AI 改变世界的蓝图？”
把《置身钉内》和《置身钉外》放在一起读，有几个反复浮现的东西，值得记下来。
这是最容易犯的误解。第一篇是产品视角，第二篇是人本视角——它们是同一个问题的两个切面，而不是两种对立的世界观。
《置身钉内》问的是：一个优秀的产品团队、一个有远见的高层、一个有潜力的 AI 产品，为什么走到了折戟沉沙的地步？答案在组织结构、决策机制、资源分配里。
《置身钉外》问的是：这些结构性问题落到人的身上，具体是什么样？答案是凌晨两点下班、一周七天、不知道该找谁倾诉的沉默。
没有第一篇，你不知道一个 AI 旗舰产品为什么能做死。没有第二篇，你不会意识到”做死”的代价不止是商业损失，还有人的燃烧。
从《置身钉内》我看到的是：当组织的生存焦虑被传递到产品层面，产品层面的焦虑再传递到执行层，执行层的燃烧就被合理化了。”我们是在做一件大事，这点牺牲是值得的。”
从《置身钉外》我看到的是：当燃烧的员工发出声音，组织的第一反应不是确认痛苦来源，而是评价表达方式。这不是个别人的态度，而是系统性的反应模式——当一个组织把自己的运作方式视为不可质疑的前提时，”员工第二”就自动变成了”组织第一”。
作者提到近两万字删到五百字，标题从”置身钉”变成”置身钉外”——”置身钉”的部分全删了，只剩下”外”。
这意味着真正的故事永远不会被我们看到。出圈的七万字已是惊涛骇浪。看不到的一万八千字又是什么？每一个离职帖背后，有多少人是带着没说完的话离开的？这是最值得焦虑的地方——不是某一篇文章说了多少，而是还有多少永远不会被说出来的东西，构成了组织真正的磨损成本。
《置身钉内》结尾说”泰坦尼克号沉了，但船上的水手还可以找下一份工作”——乐观者的版本。
《置身钉外》的回应是”只有活下来的水手，才能找到下一份工作”——字面意义上的活。
这不是悲观，是一种更底层的诚实：消耗对人的身体和精神是真实、可逆地造成伤害的，不是一句”换个环境就好”能带过的。
两篇文章合在一起读，最核心的命题其实只有一个：当追求宏大目标与个体的基本健康发生冲突时，组织有没有内置的制动机制？
这个制动机制不是”员工援助计划”或”定期团建”，而是一套能让真实反馈无风险地向上传导的通道，一种在权力不对等关系中依然能被听见的表达方式。
从这个角度看，这两篇文章的意义不在于揭示某个具体问题，而在于它们客观上完成了一次组织的健康自检——虽然过程很痛。
（原文链接：《置身钉外》）
]]>Awesome OpenClaw Skills 是一个收集了超过 5,400 个 OpenClaw 社区技能的精选索引库，按分类整理、持续更新。如果你想探索 OpenClaw 和 Agent Skills 生态圈有什么可用的能力，它是最好的起点。
项目由 VoltAgent 维护，目前是此次分享的 5 个项目中 Star 数最高的——50,020 ⭐。
Agent Skills 生态正在爆炸式增长。每天有新的技能发布——从数据分析到 DevOps，从内容创作到游戏辅助。
但问题也随之而来：你怎么发现它们？
Awesome OpenClaw Skills 解决的就是这个信息差问题——它把所有已发布的技能系统化地收集、分类、索引，让你一站式了解 OpenClaw 生态中有什么可以用的。
仓库将 5,400+ 技能按用途分到数十个大类：
| 分类 | 说明 |
|---|---|
| 数据分析 | SQL 查询、数据可视化、ETL 处理 |
| DevOps | Docker/k8s 管理、CI/CD、云服务运维 |
| 内容创作 | 写作辅助、多语言翻译、SEO 优化 |
| 生产力 | 项目管理、时间追踪、文档生成 |
| 开发工具 | 代码审查、调试辅助、架构分析 |
| 安全 | 漏洞扫描、代码审计、加密工具 |
| 游戏 | 游戏辅助、成就追踪 |
| 创意 | 设计辅助、色彩方案、字体管理 |
技能来自 ClawHub——OpenClaw 的公共技能注册中心。仓库会定期从 ClawHub 同步最新的技能列表，确保索引的时效性。
从 Awesome OpenClaw Skills 找到想要的技能后，在 OpenClaw CLI 中安装：
# 安装某个技能
openclaw skills install <skill-slug>
# 或通过 ClawHub CLI
npx clawhub install <skill-slug>
Awesome OpenClaw Skills 的意义不仅是「一个列表」。它反映了几个重要的趋势：
对比当年 npm/PyPI 的早期发展——一个好的包管理器加上一个清晰的索引，是生态爆发的前置条件。
| 优势 | 不足 |
|---|---|
| 5,400+ 技能覆盖广泛 | 技能质量参差不齐 |
| 分类清晰、检索方便 | 依赖 ClawHub 注册中心 |
| 持续更新维护 | 部分技能可能已过时 |
| 探索 OpenClaw 的最佳入口 | 缺乏评分/评价机制 |
适合：所有 OpenClaw 用户、Agent Skill 开发者、希望了解 Agent 生态的人
不太适合：不使用 OpenClaw 生态的用户
参考资料
2026 年 6 月 9 日，Canonical 宣布将 Ubuntu Linux 发行版带入 AI Agent 时代，在操作系统层面提供 AI Agent 运行环境支持。Ubuntu 将集成 Agent 运行时、模型推理框架和安全管理功能。
这是主流操作系统发行版首次将 Agent 能力作为平台特性原生集成——与 Windows 11 的 Agentic AI 平台化几乎同步到来，标志着 2026 年成为「操作系统 Agent 原生」元年。
同样是在操作系统中嵌入 Agent 运行时，但 Ubuntu 的做法有显著不同——这源于 Linux 生态的基因差异：
| 维度 | Windows 11 | Ubuntu |
|---|---|---|
| 定位 | 桌面 Agentic AI 平台 | 服务器+桌面 Agent 运行时 |
| 核心场景 | 个人办公助手、桌面自动化 | 服务器端 Agent 编排、云原生部署 |
| 模型推理 | 本地 NPU/GPU 推理为主 | 本地+云端混合推理 |
| 集成深度 | 深度内嵌系统 API | 以 snap 包和库形式集成 |
| 安全模型 | 系统级权限声明（类似 Android） | 基于 AppArmor + 容器隔离 |
| 目标用户 | 终端消费者、企业桌面 | 开发者、DevOps、企业服务器 |
Ubuntu 的 Agent 能力更适合服务器场景——云服务上的 Agent 集群、CI/CD 管道的 Agent 编排、后台数据处理的 Agent 自动化。
根据 Cananonical 的公告，Ubuntu 将提供以下几个层面的 Agent 支持：
Ubuntu 的 Agent 运行时以 snap 包形式提供，包含：
选择 snap 作为载体是有意为之——snap 本身已有完善的沙箱隔离机制、自动更新通道和严格的权限声明系统，天然适配 Agent 运行时的需求。
Ubuntu 将提供官方维护的模型推理集成：
这对服务器端 Agent 部署非常关键——开发者不用再自行搭建和优化推理环境，Ubuntu 作为发行版直接提供经过调优的推理栈。
操作系统原生 Agent 支持中最值得关注的部分——安全：
你问到的「沙箱」——这就是 Ubuntu 的核心答案。Snap 包格式本身就是一套完整的应用沙箱机制，Agent 作为 snap 包运行，天然受到 snap 沙箱的约束。
Snap 沙箱的隔离层级：
| 层级 | 机制 | 作用 |
|---|---|---|
| 文件系统 | AppArmor + 挂载命名空间 | Agent 只能看到自己的目录，读不到 /etc/shadow、/home 等敏感路径 |
| 系统调用 | seccomp 过滤器 | 白名单式过滤：Agent 只能调用必要的系统调用，阻断 privilege 提升路径 |
| 网络 | 接口声明系统（interfaces） | 必须声明 network-bind、network-control 等接口才能访问对应网络功能 |
| 资源 | cgroups | CPU/GPU/内存配额硬限制，防止 Agent 资源耗尽 |
| 进程 | PID 命名空间 | Agent 看不到宿主机的其他进程 |
三种隔离等级：
| 等级 | 名称 | 说明 | 适用场景 |
|---|---|---|---|
| 🔒 | strict（严格） | 完全沙箱，默认无任何系统权限，需要显式声明每个接口 | 大多数 Agent（默认推荐） |
| 🔓 | classic（传统） | 等同于传统 deb 包，无沙箱限制 | 系统工具类 Agent |
| 🛠️ | devmode（开发） | 沙箱规则存在但不强制执行，用于测试 | 开发调试阶段 |
对 Agent 安全的具体意义：Agent 在 strict 模式下，即使代码有漏洞或模型被提示注入攻击劫持，攻击者也只能在沙箱内活动——读不了 SSH 密钥、动不了系统文件、改不了其他 Agent 的配置。这相当于给每个 Agent 都配了一个专属的「隔离舱」。
其安全模型类似 Android 的应用权限声明制（manifest 声明权限），但在隔离强度上更强——因为 snap 的 AppArmor + seccomp 组合在 Linux 内核层面执行，比 Android 的 UID 隔离更精细。
Ubuntu 的选择体现了 Linux 的安全哲学：用已经过验证的内核安全机制（AppArmor、seccomp、cgroups、eBPF、auditd）来约束 Agent，而不是重新发明一套安全模型。
安装推理环境 → 配置 CUDA/ROCm → 安装 Agent 框架 →
配置容器网络 → 写 systemd 服务 → 配置监控告警 →
配置安全策略 → 配置日志收集 → 日常维护 ...
一个服务器端 Agent 从零到上线，涉及几十个步骤，每一步都可能出错。
snap install amd64/vllm # 一步安装推理引擎
snap install ubuntu-agent-runtime # 一步安装 Agent 运行时
snap install my-agent # 一步发布 Agent
Agent 的部署从「搭建一个子系统」变成了「安装一个 snap 包」。
| 场景 | 当前方案 | Ubuntu 原生方案 | 效率提升 |
|---|---|---|---|
| 部署 Agent 服务 | 写 Dockerfile + k8s YAML | snap install |
减少 80% 配置工作 |
| 管理推理资源 | 手动配置 GPU 共享 | OOTB 异构调度 | 零配置 |
| 安全合规 | 自行集成 SELinux/AppArmor | 预置 AppArmor 策略 | 即开即用 |
| 日志审计 | 对接 ELK/Splunk | auditd 原生输出 | 无缝集成 |
| 版本更新 | 手动编排更新 | 自动更新通道 | 持久安全 |
Ubuntu 提供统一的 Agent API 后，Agent 开发者不需要为每个 Linux 发行版做适配。这可能会催生一个类似 Flatpak/AppImage 的「Agent 包格式」标准。
Linux 服务器是企业的算力基础。Ubuntu 原生 Agent 运行时意味着：
服务器是 Agent 协作的天然舞台。Ubuntu 原生 Agent 支持将催生以下场景：
Windows 11 和 Ubuntu 在同一个月内宣布 Agent 运行时原生集成，意味着：
如果说 Windows 11 的 Agentic AI 平台代表了「Agent 进入普通消费者视野」的起点，那么 Ubuntu 的 Agent 运行时则是「Agent 成为服务器基础设施」的宣言。
对开发者：服务器端 Agent 的开发门槛降到了安装一个 snap 包的程度，这意味着更多开发者可以尝试构建 Agent 服务，而不是被基础设施挡在门外。
对运维团队：Agent 将成为 Linux 服务器上新的「服务单元」——和 systemd 服务、容器、虚拟机并行。运维团队需要更新知识体系，学习 Agent 的部署、监控和排障。
对 Agent 安全：Ubuntu 选择用 AppArmor + eBPF + auditd 这些已有机制来约束 Agent，验证了我之前的一个判断——操作系统原生 Agent 安全，不需要发明新概念，但需要把现有安全机制组合好。这对安全团队是好事：学过的知识不会浪费。
参考资料
html-ppt-skill 是一个 AgentSkill，让你在终端中通过一句自然语言指令就能生成专业级的 HTML 演示文稿。它拥有 36 种主题、31 种页面布局、47 种动画效果和真正的演播室模式——所有输出都是纯静态 HTML/CSS/JS，零构建步骤，打开即用。
项目由 lewis 开发，MIT 许可证，目前收获 5,710 ⭐。
按 S 键即可弹出专门的演播室窗口，包含四张可拖拽、可调整大小的磁吸卡片：
| 卡片 | 功能 |
|---|---|
| 当前幻灯片 | 实时预览当前页 |
| 下一页预览 | 提前看到下一张 |
| 逐字稿 | 演讲者的讲稿提示 |
| 计时器 | 控制演讲节奏 |
两个窗口通过 BroadcastChannel 保持同步——翻页时不需要重新加载，无闪烁。
为什么预览图能保证像素级一致？每张卡片是一个 <iframe>，加载同一份 HTML 文件加上 ?preview=N 参数。运行时检测到预览参数后，只渲染第 N 张幻灯片，不含任何 UI 框架。CSS、主题、字体、视口完全一致。
所有输出都是独立的 HTML 文件——不依赖 Node.js、Python、任何构建工具。你可以直接双击打开、嵌入网页、通过邮件分享，或者部署到任何静态托管服务。
在支持 Agent Skills 协议的 AI 编程助手中（Claude Code、Codex、Hermes Agent 等），安装 html-ppt-skill 后，只需说出你的需求：
生成一个 8 页的创业计划书演示，使用 dark 主题，包含数据图表
Agent 会在一分钟内生成完整的 HTML 演示文稿，你可以立即打开查看或二次编辑。
| 优势 | 不足 |
|---|---|
| 零依赖，打开即用 | 不支持 .pptx 导出（纯 HTML 格式） |
| 主题和布局极其丰富 | 需要 AI 编程助手环境 |
| 演播室模式功能完整 | 复杂图表需额外编写 |
| 纯静态，部署无成本 | 不适合传统办公环境 |
适合：技术演讲者、开发者、需要快速出演示内容的人
不太适合：需要交付 .pptx 源文件的用户、非技术背景的商务人员
参考资料