DeFi托管金库的风险管理为何失效

引言

在无需许可的 lending 协议中，risk curators 已悄然成为 DeFi 中最重要——也是最暴露在风险之下——的参与者。他们是设计、部署并管理 curated vaults 的独立团队和专家：这些非托管 credit 策略会将数十亿美元的存款人资本分配到各个 lending 市场。curator 决定接受哪些抵押品、承担多大风险敞口、将流动性路由到哪里，以及何时撤出。本质上，他们充当的是链上 credit 的专业 portfolio managers——而存款人赚取的全部收益，都取决于这些决策的质量。

这项责任的范围极其庞大：抵押品尽职调查、风险参数配置（供应上限、LLTV、集中度限制）、头寸规模管理，以确保 vault 始终能够退出而不会变成流动性陷阱；跨隔离市场的资本分配与再平衡、oracle 的部署与监控，以及与 guardians 和 sentinels 的 governance 协调。最优秀的 curator 走得更远——他们会在 forked 环境中持续运行基于 agent 的模拟，在部署资本之前，对相关性崩盘、oracle 延迟和流动性枯竭进行压力测试。

curator 模式已经成为 DeFi lending 的主导范式。像 Morpho、Euler 以及其他协议，已经将 risk management 的责任从单体式 governance 转移给了专业 curator，每个 curator 都在 risk-adjusted returns 上展开竞争。这种架构非常强大——它将基础设施与策略分离，允许无需许可地创建市场，并让存款人选择适合自己的 risk profile。

但它也造成了一个监管真空。curator 的工作在功能上与传统金融中的 broker-dealer 完全一致：分配客户资本、设定风险限制、按绩效赚取费用。在 TradFi 中，这种职能伴随着 fiduciary duty、capital adequacy 要求、监管 stress testing 和强制披露。而在 DeFi 中，这些都不存在：

当 curator 纪律或存款人尽职调查失败时，没有后备保障。而这两者都可能在压力之下失效。

在过去 18 个月里，这一模式已经变得显而易见。stablecoin 脱锚、发行方密钥被攻破、硬编码 oracle 配置错误——一次又一次，损失并不是来自代码损坏。合约经过审计并按设计运行。真正失败的是配置与运行上下文：一个仍然报告 $1 的 oracle，而资产已经崩塌；一个自动分配器因为利用率驱动的 APY 看起来很诱人，就把新资本继续投入到一个已被攻破的市场；一个 vault 已经成为单一市场中的主导供应方，却无法退出。2025–2026 年间，数亿美元的坏账都源自一个 smart-contract 审计无法覆盖的层面：那些存在于已审计代码与真实市场行为之间空隙中的 operational、economic 和 compositional 风险。这个层面正是 curator 负责的——也是攻击者正学会利用的层面。

本文将梳理针对这一层面的具体攻击向量。它写给 curator、vault deployers，以及依赖他们的协议——聚焦机制、后果，以及在一个最大威胁并非来自破损代码的环境中生存所需的 defense-in-depth 心态。

扩展的前沿：Risk Curator 在哪里运作

curator 模式诞生于 credit 市场，但其逻辑——动态 risk parameterization 加上 vault 架构内的资本分配——是可迁移的。只要一个协议需要在存款人资本与不断演化的机会集合之间做专业判断，curator 就会扩展到那里。

credit 市场仍是核心：抵押品选择、LTV、供应上限、oracle、坏账管理。yield 策略和 Earn Vaults 紧随其后——在 lending 市场之间优化收益，而 automation 风险则是主要的新表面。RWA（tokenized Treasuries、private credit）是增长最快的前沿，需要 curator 将链下尽职调查（法律结构、交易对手风险、赎回机制）与链上参数管理相结合。机构包装产品是另一个明确的增长方向，因为配置者寻求具有更强风险控制的非托管结构。用于集中流动性的 LP vaults 要求在波动条件下进行动态区间管理。stablecoin 策略——delta-neutral、basis trading、reserve management——则需要防止脱锚级联溢出到 lending 市场。restaking 目前看起来更次要一些，curator 采用速度更慢，增长叙事也不够持久。

更远一些：衍生品和结构化产品（options vaults、分层风险产品）、DeFi insurance（承保参数策展）、AI-agent 管理的 vaults（agentic 分配与执行）、跨链流动性管理，以及新兴的 L1/L2 生态（Solana/Kamino、Berachain、Monad、Hyperliquid）。

市场仍然集中。新团队往往通过利基垂直领域进入，而在这些领域中，domain expertise 比 incumbency 更重要。下面描述的攻击向量主要来自 credit 市场，但经过适当调整后，同样适用于此列表中的每个垂直领域。

攻击向量

下面这些向量并非假设。每一种都已在生产环境中被观察到——有些还不止一次。它们可分为两大类：基础设施与访问风险（针对合约、角色和集成）以及经济攻击（利用已完全审计系统中的激励、参数和 oracle 行为）。在实践中，最具破坏性的事件往往会结合两者。

有一个特性使攻击面尤其宽广：现代 vault framework 允许 curator 执行几乎任意交易——部署 adapter、通过多跳策略路由资本、配置 oracle、调整权限。这意味着，仅仅对 vault 本身做标准 smart-contract 审计是不够的。漏洞未必存在于任何单一合约中——它可能只会在 curator 策略把原本安全的组件组合在一起时才显现出来。

1. Oracle 失效：陈旧、错误或被操纵的价格源

它如何运作。oracle 持续报告某个抵押资产被高估的价格——无论是因为它被硬编码为固定值、依赖过时的链上来源，还是通过 flash loan 和 AMM 失衡被临时操纵。借款人以“纸面”抵押品建立最大杠杆头寸。清算永远不会触发，或者触发得太晚。

为什么危险。vault 会系统性地变得可被抽取。坏账悄无声息地积累，并在所有 liquidity providers 之间被社会化。这个向量会被 automation 放大（见向量 2），并且与上游抵押品失败（见向量 5）紧密相关——当发行方被攻破但 oracle 仍报告 $1 时，这种组合是毁灭性的。oracle 配置错误是 2025–2026 年 curator 损失最常见的单一根因。

2. 自动分配器成为非自愿的退出流动性

它如何运作。在上游事件之后——抵押品脱锚、协议被黑、密钥被攻破——受影响 lending 市场的利用率飙升。表面 APY 暴涨。一个自动分配器（public allocator、基于 keeper 的再平衡器，或规则驱动的 bot）将此解释为一个有吸引力的机会，并将 vault 中的新资本路由到这个陷入困境的市场。

为什么危险。vault 非但没有撤出，反而成了攻击者的退出流动性——或者在脱锚的情况下，继续按面值承保一个毫无价值的抵押品。这是最昂贵的失败模式，它会把局部上游问题转化为系统性的 vault 级损失，并且在人工 curator 介入之前就能耗尽数百万。每延迟一小时，永久损失的资本都在增加。

3. 角色与 governance 被攻破（Owner / Curator / Guardian）

它如何运作。攻击者获得 vault owner 密钥或 multisig 的控制权，然后替换 curator、移除 timelock、添加危险市场、提高供应上限，或修改费用结构。另一种情况是，curator 自己的操作密钥被攻破——而由于 curator 角色通常拥有快速通道权限（没有 timelock 延迟），攻击者可以在几分钟内重新配置 vault。

这也包括一种更隐蔽的失败模式：签名密钥本身完好无损，但签名界面被攻破并显示误导性的交易数据。Bybit 案例是最清晰的提醒——一位被授权的签名者批准了一笔通过被攻破的 frontend 上下文修改过的交易。

为什么危险。curator 是 vault 架构中的单点信任。一个被攻破的密钥就能同时覆盖所有风险参数。timelock 可以为某些 governance 攻击提供缓冲，但它并不能抵御拥有直接操作访问权限的 curator 被攻破。而且，长期社会工程攻击——攻击者在数周内缓慢提升权限——甚至可以完全绕过 timelock。

4. 集中度与流动性陷阱

它如何运作。vault 成为了单一 lending 市场中的主导供应方——50%、70%，有时甚至超过总流动性的 90%。当 curator 需要去风险时，可撤出的流动性几乎为零：利用率接近 100%，借款人没有偿还，清算又太慢。

为什么危险。vault 被卡住了。存款人无法提取。知情存款人会争相通过剩余的闲置缓冲区退出，耗尽这些缓冲并让陷阱更严重——这就是典型的银行挤兑动态在链上上演。

5. 上游抵押品风险（脱锚、黑客攻击、发行方密钥被攻破）

它如何运作。风险完全源于 lending 协议之外。某个抵押品发行方遭遇私钥被攻破、铸造合约中的 bug、储备支持丧失，或 governance 攻击。抵押品变得部分或完全无价值。oracle——尤其是硬编码或更新缓慢的 oracle——未能反映新的现实。清算者不会被触发。坏账悄然积累。

为什么危险。这是 curator 最无法控制的向量。即使保守的 LLTV 和紧缩的供应上限，也无法完全防住一个一夜之间归零的抵押品。curator 唯一真正的防线是事前尽调（评估发行方的密钥管理、铸造流程、储备证明机制和合约升级路径）以及配备自动化 circuit breakers 的实时监控，以便在 oracle 追上之前冻结分配。

6. 抢跑 curator 操作与参数操纵

它如何运作。curator 提交一笔 timelocked 交易——移除市场、降低供应上限、修改费用——攻击者对其进行 front-run，利用提案与执行之间的窗口。在某些设计中，攻击者可以在 mempool 或链上队列中观察到待执行动作，并在中间状态中布局以提取价值。通过在低流动性 vault 中捐赠来操纵 share price 是一个相关变体。

为什么危险。存款人获得的份额比预期更少，或者 vault 承担了 curator 正在积极试图降低的风险。根本问题在于，timelocked governance 在设计上就是透明的——这意味着 sophisticated actors 可以预见并利用每一个 curator 动作。这在 governance 透明性（有利于存款人信任）和 operational security（易受 front-running 影响）之间制造了张力。

7. 激进的参数博弈与收益追逐

它如何运作。curator——或自动化策略——通过设置过于激进的供应上限、高 LLTV，或上线高收益但理解不足的抵押品，来追求最大收益。参数被调校到最佳情形。当市场冲击到来时——哪怕只是轻微的一次——头寸都会剧烈平仓。

为什么危险。这不是外部攻击，而是由 curator 自身激励结构驱动的内部经济风险（绩效费与收益Hook）。当损失显现时，存款人会把它视为剥削。声誉损害极其严重：TVL 流出、社交媒体反弹，以及对 curator 模式本身的信任流失。更糟糕的是，激进的参数设置会放大本列表中的每一个其他向量——高 LLTV 会让 oracle 失效更致命，过大的 cap 会加深流动性陷阱，而速度快的分配器再配上宽松限制，会把每一次上游事件都变成 vault 级危机。

8. 坏账社会化——损失如何扩散到未直接受影响的存款人

它如何运作。当某个市场积累坏账时，损失会按比例在所有 vault 存款人之间社会化——即使他们的资本完全位于其他健康市场中。在某些架构里，未实现坏账会一直隐藏，直到有人提款，此时损失才会以不可预测的方式结算出来。

为什么危险。局部失败变成了 vault 范围内的损失。存款人看到的是 headline APY，而不是他们对 curator 分配到的每个市场的敞口。较新的架构通过每个 adapter 的损失跟踪以及在流动性不足期间的实物赎回路径改进了这一点，但根本性的张力仍然存在：pooled vault 意味着共享风险。

9. 组合与集成风险（审计之间的空隙）

它如何运作。每个组件——vault 合约、adapter、lending 市场、oracle、allocator——都可能单独经过审计且正确运行。但漏洞会从它们的组合中出现：意外的 callback sequence、特定 adapter-oracle 交互中的舍入误差、在孤立状态下安全但在两个 adapter 同时激活时可被利用的权限边界。

为什么危险。组合风险是涌现式的，并且在触发之前是不可见的。它无法通过审计单个合约来发现——只能通过将已部署的完整策略作为一个集成系统来审查。随着 vault 架构变得越来越复杂，这一表面扩张的速度远超任何一次性审计所能覆盖，因此每一次重大的策略或配置变更都应重新审计。

10. 自动化基础设施被攻破（Keepers、Bots、链下系统）

它如何运作。Keepers、rebalancers、监控 bots 和托管在云上的 allocator 脚本，都对 vault 资本拥有直接执行权限。攻击者可以攻破 keeper 的 hot-wallet 密钥，利用托管基础设施（AWS 凭证、未轮换的 API keys），或者干脆在危机期间让 bot 离线。

为什么危险。链下 automation 与 curator 拥有同样的权力，却很少得到同等程度的安全审查。一个被攻破的 keeper 可以强制执行不利的再平衡、提取 MEV、抽干闲置缓冲区，或者在最糟糕的时刻让操作停摆。这是许多原本设计良好的 vault 架构中最薄弱的一环。

11. AI-Agent Curator 风险（Agentic Vault 管理）

它如何运作。在由 agent 管理的 vault 中，策略决策和执行被委托给 AI agents，这些 agents 会消费市场数据、风险信号和工具输出。攻击者可以通过数据投毒、经由工具集成的 prompt/context injection、被操纵的外部信号、目标博弈（让策略优化错误目标），或 agent 栈中的执行权限被攻破来利用这一层。

为什么危险。AI agents 提高了速度和覆盖面，但它们也创造了一个新的控制平面，而且可能会以不透明的方式失效。人类 curator 能发现明显异常；agent 却能以机器速度跨多个市场执行这些异常操作。如果没有严格的 guardrails（硬性风险限制、allowlist 动作、确定性的 fallback 规则，以及人工 veto），agentic vault 可能会比人工操作更快地放大损失。

为什么这很重要

这些都不是理论上的漏洞。它们是 operational 现实——数千万美元的损失，全部来自无需许可的 composability、以机器速度放大错误的 automation、curator 无法消除的外部依赖，以及人为配置之间的交汇：一个错误配置的 cap，就可能将最优变为灾难。

对 curated vault 最危险的威胁并不是破损代码，而是在对抗性条件下正确执行已审计代码。优秀的 curator 会构建 defense in depth——但首先，有必要审视塑造 curator 对这些向量响应方式的激励结构。

激励张力：Curator 费用 vs. 存款人安全

curator 赚取 performance fee——通常是 vault 收益的 5–15%。更高的 APY 意味着更高的费用，这就产生了一个直接激励：设置激进的 LLTV、宽松的供应上限以及较薄的闲置缓冲。与之对冲的力量是声誉：存款人可以随时退出，而糟糕的风险管理会立刻受到资本外流的惩罚。但声誉也有极限——散户存款人看到的是 APY，而不是 LLTV；看到的是 TVL，而不是 concentration；看到“audited”，就默认“safe”。

实际结论是：让费用结构与你的风险 profile 对齐。一个被宣传为“safe”的高收益 vault，在不可避免的事故到来时，往往会导致灾难性的声誉损害。

责任缺口

这种激励张力带来了更深层的问题：收益被私有化，尾部损失被社会化。curator 通过 performance fee 捕获上行收益。当尾部风险显现时，存款人损失本金；curator 失去未来的费用收入和声誉——但并不损失资本。

没有可被 slash 的 bond，没有强制保险基金，也没有法定赔偿机制。一些 curator 会自愿从储备中覆盖坏账——并因此赢得应有的信任——但这完全是自愿的。大多数 vault 的损失瀑布都很简单：存款人首先吸收损失。

在协议强制最低标准、而外部评级框架使这种不对称变得可见之前，存款人应当把每个 curated vault 都视为一个没有保险的头寸。

风险缓解手册

上面的攻击向量有一个共同点：没有任何一个可以被完全消除。无需许可的 composability、外部依赖以及链上执行的极致速度，保证了风险永远存在。目标不是零风险——而是结构化韧性：确保没有单一失败模式能够变成灾难，确保检测速度快于利用速度，并且在事故发生前就完成恢复计划。

下面是一份实用手册，按 curator 的运营生命周期组织：在资本部署之前、在资本活跃期间、在事故期间，以及恢复之后。

部署前：在分配一美元之前先打好基础

1. 深度抵押品尽职调查——在证明无害之前，把每个新资产都当成敌对资产。

在将某个抵押资产加入白名单之前，调查完整的信任链：铸造密钥管理、multisig 阈值、铸造量合理性检查、储备支持可验证性、合约升级路径，以及脱锚时的 oracle 行为。为每一种抵押品生成书面的风险画像——这不是一次性检查——并在每次发行方升级时重新审视。

在可用时，用外部 risk ratings 作为补充（例如 Credora/RedStone 评分：基于 Default Probability 和 Significant Loss Probability，从 A+ 到 D 的字母等级）。外部评分不能取代内部分析，但可以增加一层独立验证。

2. 对整个部署进行安全审查——不只是 vault 合约。

孤立的 vault 审计会遗漏最危险的表面：composition。在部署之前，对整个配置端到端进行审查——每个 adapter、外部协议交互、oracle 配置和参数选择。重点查找 flash-loan 可利用性、oracle 操纵面、通过第三方合约的权限提升，以及意外的调用流。

3. 保守的初始参数设置——先收紧，再基于数据放宽。

将供应上限设得保守：每个市场设绝对上限，同时设定相对于 vault TVL 的上限（常见起点是 10–30%）。确保 vault 在任何单一市场中的总供应占比都不超过 25–30%——否则退出就会变成流动性陷阱。将 LLTV 设在比最坏情形模拟结果更有余量的位置，而不是贴着边界。保留 5–15% 的 TVL 作为未分配闲置缓冲，以吸收赎回激增而不触发紧急再分配。

4. 在部署前做模拟——并且在部署后持续模拟。

在为新市场分配资本之前，在 forked 环境中运行基于 agent 的压力测试。模拟相关性崩盘（1 小时内 −30% 或更严重）、oracle 延迟、突然脱锚、阻止清算者运行的 gas 价格飙升，以及多个市场同时出现的流动性枯竭。验证 vault 即使在最坏情况下也能在 1–4 小时内退出其最大头寸。随着市场状况、TVL 和利用率变化，持续重复这些模拟。

5. 为角色架构设计抗攻破性。

将 Owner、Curator、Allocator 和 Sentinel 角色分离，并使用不同的密钥。Sentinel 是一个仅限安全用途的角色——它可以 deallocate 和 veto，但不能引入新风险；被攻破的 Sentinel 只会让 vault 更不活跃，而不会更危险。对所有会扩大参数的操作施加 timelock（24h+）。为 Sentinel 分配多个独立地址。所有特权角色都使用 multisig。

活跃管理：监控、约束、响应

6. 多层 oracle 监控——不要信任单一价格源。

部署独立监控，将 oracle 价格与多个链下和链上参考源（CEX feeds、DEX TWAPs、其他 oracle provider）进行交叉比对。为价格偏离设置告警阈值——例如，如果 oracle 价格与参考中位数偏离超过 1–2%，就触发告警。对于硬编码或更新缓慢的 oracle，独立监控底层资产的市场价格，并在 oracle 追上之前触发 circuit breakers。

7. Circuit breakers 和自动化遏制——以机器速度行动。

人类的反应时间是分钟到小时。攻击在区块之间展开。部署自动化 circuit breakers：在 oracle 偏离时暂停分配，将异常活动的供应上限设为零，冻结 public allocator，并通知 Guardian veto 待执行动作。

最有效的 breaker 运行在链上：攻击者如果攻破特权密钥，能够在单个原子交易中 mint、supply 和 borrow——任何链下 bot 都无法对这种情况作出反应。链上 supply rate limits、按区块的 borrow caps，以及异常触发的暂停，是唯一能够拦截区块内利用的机制。但要谨慎校准：阈值过于激进会导致误报或拒绝服务向量。

在实践中，最具韧性的方案会结合三层：用于原子攻击的链上 breaker、用于较慢场景（渐进式脱锚、利用率漂移）的链下 sentinel，以及用于边缘情况的人工接管。所有层级都应使用专用密钥、最小权限——权限足以停止，但绝不足以提取。

8. 集中度纪律——执行硬性限制，而不是指导方针。

持续跟踪 vault 在其参与的每个市场中所占的总供应份额。设置硬性的链上 caps（而不仅仅是 dashboard 告警），防止 vault 超过任何市场总供应的既定百分比。当市场增长、而由于其他供应方离开导致 vault 占比被动上升时，将其视为一个需要主动再分配的风险事件——不要等到头寸变得缺乏流动性才采取行动。

9. 自动化安全——把 bots 当作特权用户对待。

使用专用密钥并赋予最小权限，制定轮换计划，强化基础设施，记录访问日志。实施 dead-man switches——如果 keeper 未按计划执行，就升级响应或冻结。审计自动化架构，而不仅仅是它调用的合约。

对于由 AI-agent 管理的 vault，设定严格基线：仅允许白名单动作、对每个市场和每笔交易设置硬性风险上限、在数据缺失或矛盾时使用确定性的 fallback 规则，以及对策略更新强制人工 veto。

10. 持续进行升级影响评估。

当依赖链中的任何协议升级时，都将其视为潜在的破坏性变更。评估它是否改变了信任假设、权限或经济逻辑。在恢复分配之前重新运行模拟。

事故期间：最初的一小时决定结果

11. 预先写好的事故响应手册——要演练，不只是记录。

为每一个重大场景都准备一份书面的逐步响应计划：抵押品脱锚、oracle 失效、密钥被攻破、上游被黑、流动性紧缩。手册应明确：

• 谁来行动（哪个角色，哪把钥匙）。

• 他们做什么（将 cap 设为零、冻结 allocator、触发 Guardian veto、向存款人沟通）。

• 按什么顺序（分诊、遏制、沟通、修复）。

• 在什么时间内（目标：首次遏制动作在几分钟内，而不是几小时）。

每季度进行桌面演练。最糟糕的发现手册有缺口的时机，就是在真实事故发生期间。

12. 立即遏制——先止血，再诊断。

在发现异常时：(1) 将受影响市场的 cap 设为零，(2) 如果范围不清楚则暂停新存款，(3) 冻结自动化分配，(4) 调用 Sentinel/Guardian veto 待执行动作，(5) 只有在资金外流停止后才开始人工评估。诊断应在 vault 停止失血之后进行。

13. 透明沟通——沉默比损失更快侵蚀信任。

一旦采取遏制措施，就立刻通知存款人。存款人可以接受被管理的损失；他们不能接受自己是最后一个知道的人。

事故后：学习、补偿、加固

14. 取证分析与根因识别。

重建交易序列，识别根因，量化损失，判断手册是否发挥了作用。发布事故复盘——透明的 curator 因为展现了责任承担而更容易吸引资本。

15. 补偿框架——在需要之前先规划好。

预先定义损失如何处理：费用储备、金库、保险，或带有透明会计的损失社会化。提前理解机制的存款人，在事故后更有可能留下来。

16. 更新参数、手册和监控——然后重新模拟。

每一次事故都应当产生具体变更。如果在你的“修复”之后，同一个向量还能产生同样的结果，那么这个修复就是不完整的。

总结：Defense-in-Depth 栈

上面的手册不是一个可随意挑选的菜单——它是一个栈，每一层都弥补了其下层的局限：

没有任何一层是充分的。能够存活下来的 curator，都是那些假设每一层最终都会失效——并构建下一层来接住掉落部分的人。

衡量真正重要的东西：一个优秀 curator 的指标

存款人、协议和 curator 都需要可量化的信号来评估 operational risk 纪律。以下指标提供了一份实用的安全计分卡：

没有任何单一指标是决定性的——但如果一个 curator 在其中大多数指标上都得分很差，那么它承担的风险很可能得不到存款人的补偿。

展望未来：Vault 安全的演进

生态系统正在积极演进，朝着更具韧性的设计发展：

• 更细粒度的角色分离——较新的 vault framework 会将 Sentinel 设定为仅限安全用途的角色，它可以阻止风险，但永远不能升级风险。

• 实时坏账跟踪——每个 adapter 的损失报告，以及在流动性不足期间的实物赎回路径，取代了早期设计那种粗暴的即时社会化。

• 链上 risk oracle——外部评分（例如通过 RedStone 提供的 Credora）被送上链，使 risk assessment 朝着可验证、持续更新的情报方向发展。

• Simulation 成为标准——基于 agent 的压力测试正从竞争优势转变为预期基线，而开源工具（Foundry/Anvil、agent SDKs）降低了门槛。

• 新垂直领域，新风险原语——增长最强劲的方向是 RWA 和机构产品，LP vaults 也在扩展。restaking 目前看起来更次要。与此同时，AI-agent 管理的 vault 正在作为一种新的 curator 模式出现，并拥有其自己的攻击面（数据投毒、prompt/context injection、目标不一致以及执行密钥滥用）。

“已审计合约”与“安全 vault 操作”之间的鸿沟正在被填补——通过更好的架构、更好的工具，以及对最重要的安全层并不是代码，而是配置、监控和管理它的系统这一事实的认知。

Risk curator 的下一波增长将来自新市场。但真正的赢家，会是那些能像扩展 TVL 一样快速扩展安全纪律的团队。

• 原文链接： x.com/mixbytes/status/20...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～