鸿途知科网

首尔的一笔交易如何击穿Hyperliquid最大的股票市场

Sat, 29 Aug 2026 01:11:18 +0800

研究 • 2026年7月31日

TradeXYZ 是 Hyperliquid 上最大的 HIP-3 永续合约市场部署方，正在向交易者赔付因第三方价格源一次准确但异常的数据读取所导致的清算损失。值得注意的是，这次故障来自传统金融系统，而非加密领域。

7月28日首尔时间上午8点，韩国 NextTrade 盘前交易时段开盘数秒内，芯片制造商 SK 海力士的一股股票以 1,272,000 韩元（约合 868 美元）的价格成交。这比前一交易日收盘价 1,816,000 韩元低 29.96%，正好触及当日跌停价。大约两分钟后买单才出现，股价回升至 170 万韩元区间。但此时，这笔成交记录已经跨越 5,500 英里，落到了另一个资产类别的订单簿上，并击穿了约 6,000 万美元的杠杆多头仓位。

上述市场是 xyz:SKHYNIX，一个以 USDC 为保证金的永续合约，最高提供 10 倍杠杆，由 TradeXYZ 通过 HIP-3 升级部署于 Hyperliquid。HIP-3 自 2025 年 10 月起在主网上线，允许任何质押 500,000 HYPE（按近期价格约合 2,700 万美元）的团队在 HyperCore（Hyperliquid 的链上订单簿与撮合层）上部署自己的永续合约市场。部署方负责定义市场参数（预言机、杠杆限制、保证金模式和合约规范）。Hyperliquid 提供执行和结算，分摊手续费，但不负责选择价格。

TradeXYZ 是代币化协议 Unit 的永续合约部门，是首个 HIP-3 部署方，基本上垄断了这一类别。它占 HIP-3 未平仓合约的 90% 以上，约占 builder 市场交易量的 98%。这在规模上具有重要意义：HIP-3 占 Hyperliquid 永续合约总交易量的份额已从年初的约 2% 攀升至如今的约一半，30 天 builder 市场交易量约为 980 亿美元，全网 HIP-3 未平仓合约约为 36 亿美元。SK 海力士是 HIP-3 中未平仓合约规模最大的市场，截至 7 月 30 日为 6.38 亿美元。

该合约的行为与其文档描述完全一致：跟踪一股 SK 海力士普通股的美元价值。TradeXYZ 将韩元定价分为两个阶段：内部阶段，预言机价格以自身订单簿为基准漂移；外部阶段，从 NXT 于韩国标准时间上午 8:00 开盘那一刻开始。异常成交恰好出现在这个切换点。链上记录显示，预言机组件在切换后数秒提交了 868.17 美元的外部价格。

TradeXYZ 的标记价格是三个输入的中位数：预言机价格、预言机价格加上（订单簿偏离值的 150 秒指数移动平均），以及最优买价、最优卖价和最新成交价的中位数。面对约 30% 的异常输入，这种平滑机制吸收了其中约 11 个百分点。但这还不够。标记价格下跌了 18.7%，几乎是瞬间发生。该市场的未平仓合约在几分钟内从 4.81 亿美元降至 3.31 亿美元。链上分析师估计，约 960 个多头账户的清算名义金额在 5,700 万至 8,000 万美元之间；盈利的空头在过程中被自动去杠杆（与 10/10 事件期间的情况类似），一个系统兜底地址吸收了 406 个多头仓位，随后自身也被清算。

TradeXYZ 于 7 月 29 日发布了回应，表示将承担因这一异常导致的清算损失，并明确将其定性为一次性酌情决定而非长期政策，资格标准和分配方案将在后续公布。它还坚称预言机"按照其规范说明正常运行"（事实确实如此），并表示正在加快尾部事件期间价格形成机制方面的工作，包括加大自身订单簿的权重——它认为自身订单簿相对于外部来源现已具备可观的深度。

SK 海力士确实因对 AI 支出和中国内存竞争的担忧而承压。该股在首尔常规交易时段收跌 14.65%，报 155 万韩元。次日 Q2 财报公布后再度下跌，连续两个交易日触发熔断，这在韩国市场历史上尚属首次。当天早上盯盘的交易者完全有理由相信这次暴跌是真实的。

我们的看法

预言机没有问题。风险系统出了问题。传统市场早在数十年前就已出于风控目的，将最新成交价、指数价格和公允价值区分开来，正是为了不让单笔本地成交决定杠杆账户的生死。TradeXYZ 拥有这套架构（三输入中位数、EMA 平滑、价格发现边界），在失效之前吸收了异常成交中约 11 个百分点的冲击。保护是真实存在的，只是它校准时所参照的市场，深度超过了实际指向的市场。正确的价格发现与健全的清算设计不是一回事，一份规范说明可以被忠实遵守，却一路通向糟糕的结果。

这种故障模式本身并非加密问题。NexTrade 已经在另一端进行修补，将于 9 月引入静态波动率中断机制。链上增加的只是传输速度和接收端的杠杆。成交记录是真实的，数据提供方是正确的，每个模块都完成了自己的任务。这就是为什么"增加更多预言机"是错误的修复方案。每个数据提供方都在读取同一个 NXT 订单簿，它们的中位数收敛于同一个 868 美元。

JELLYJELLY 迷因币是一个关于问责问题的有用历史案例。2025 年 3 月，Hyperliquid 自己的金库资不抵债，验证者冻结了市场并以选定价格强制结算仓位，协议在接下来一年里都在为此负责。在韩国这个案例中，核心协议没有触碰任何东西。选择预言机的部署方承担了成本。让交易者获得全额补偿的是 TradeXYZ 团队的慷慨。交易者将获得全额补偿，是因为一家在其花费九个月建立的类别中拥有 90% 以上份额的公司，认为自己的业务价值高于这张支票。TradeXYZ 本可以提出完全不赔付的合理理由，但它没有这样做。

接下来会发生什么值得关注。TradeXYZ 表示将加大自身订单簿相对外部数据源的权重。链上市场的成熟路径是：起初参照现实世界市场，然后逐步成为参照本身。股票永续合约在这条曲线上走得比大多数人想象的更远，这次事件就证明了这一点。外部（TradFi）数据源是脆弱的输入，而内部（链上）订单簿才是稳定的。

Hyperliquid 的共享基础设施是让这一转型能够存续的关键。这里的 builder 无需编写撮合引擎、保证金系统或清算引擎。TradeXYZ 只有一个难题需要解决，而它正是在这唯一需要自己负责的事情上，收到了一张 6,000 万美元的学费账单。对于一个每月处理 980 亿美元的类别来说，这很便宜。

原文链接： galaxy.com/insights/rese...

鸿途知科网 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

Zcash的Ironwood升级强化隐私特性

Sat, 29 Aug 2026 01:11:17 +0800

Zcash 于周二推出了其 Ironwood 网络升级，永久封存了该区块链此前的核心隐私交易池 Orchard，使其不再接受存款或内部转账，并开放了一个名为 Ironwood 的隐私池。

在 Zcash 中，交易既可以发生在透明（公开）地址中（类似于比特币），也可以发生在隐私池中。隐私池使用零知识密码学来隐藏转账金额和参与方身份，同时仍允许网络验证交易的有效性。Orchard 自 2022 年 5 月推出以来一直是该网络的主要隐私池，在升级时持有约 366 万 ZEC（价值约 17 亿美元）。

Ironwood 是在 Shielded Labs 研究员 Taylor Hornby 于 5 月 29 日发现 Orchard 的零知识证明电路存在可靠性漏洞后开发的。该缺陷自 2022 年 Orchard 上线以来一直存在，理论上可能允许创建在公共区块链上无法检测到的伪造 ZEC。6 月初的紧急升级为新的交易修复了电路。Ironwood 更进一步，创建了使用修正后电路的隐私池，同时限制 Orchard 的资金只能通过 Zcash 中一个长期存在的机制（称为旋转门）流出。这是隐私池边界上的一项会计规则，确保流出的 ZEC 数量不会超过已验证存入的数量。

持有 Orchard 资金的用户必须通过更新后的钱包自愿将其迁移到 Ironwood 池；迁移不是自动的。截至 7 月 30 日，公共追踪器显示已有约 410,000–413,000 ZEC 进入 Ironwood 池，约 329 万 ZEC 仍留在 Orchard。

我们的看法

隐私池中的可靠性缺陷带来了独特的挑战。隐藏金额和参与方的密码学同样也隐藏了任何可能的伪造行为。你无法看到该缺陷正在被利用，最终只能发现供应量出了问题。Ironwood 通过旋转门封存旧池，并强制每一枚希望继续流通的币通过会计检查点，从而弥补了这一缺口。这意味着离开池子的价值不会超过进入池子的价值。任何可能存在的伪造币现在都被永久隔离了。

Zcash 开发者社区的响应令人印象深刻。Hornby 借助 AI 辅助工具发现了一个已存在四年的漏洞，电路在发现后几乎立即得到修复，Ironwood 在披露两个月后即部署上线，并配有经过形式化验证的池子和量子可恢复的票据。在生产环境中对伪造风险进行形式化验证仍然少见。

现在的不确定因素是迁移速度。约 11% 的旧 Orchard 余额在前两天内已经完成迁移，这是一个不错的开端。旋转门使其成为一个排队过程，而非采用率指标。如果池子出现缺口，损失将由最后离开的人承担。这激励了用户尽早转移币。但 Ironwood 的匿名集又带来了等待的激励，因为早期迁移者只能隐藏在规模小得多的人群中。在临界规模的资金和日常活动进入 Ironwood 之前，Zcash 网络的有效私有流动性仍然分散在两个池子之间。最终，如果 Orchard 被清空而旋转门没有报出任何超额供应，就能证明该缺陷从未被利用，并平息 5 月的供应量疑问。在这种情况下，Zcash 将凭借新的密码学保证、独立的供应量可验证性以及更清晰的量子可恢复性长期路径而变得更加强大。对于希望接触隐私论点的资产配置者来说，残余风险将从“供应量是否真实？”转变为更常见的采用、流动性和执行问题。

退一步看，更深层的问题是为什么隐私日益成为加密领域不可妥协的特性。两种通常各说各话的力量正在汇聚。一方面是经典的密码朋克观点，认为隐私是一项固有的权利，并且市场对在基础层内置隐私的数字不记名工具有需求。Zcash 是市场目前最青睐的这一论点的代表。正如团队所说，“金融自由需要金融隐私。”另一方面是机构现实。完全透明的公共链对真正的金融业务来说根本无法使用。交易对手方不会在公开场合执行策略、管理库存或结算大额交易。这就是为什么隐私如今处于以太坊 Strawmap、Solana 的基础设施优先事项以及几乎所有主要区块链路线图的核心位置。隐私不再只是加密领域中的一个类别。它正在成为基础层的要求。

对 Zcash 来说，令人不安的含义在于：如果隐私成为每条链的属性，那么作为隐私链的溢价就会消失。Ironwood 通过将强大的密码学隐私与独立的供应量验证相结合，如今巩固了 Zcash 对这一溢价的诉求。随着业内其他项目迎头赶上，这种定位能否持久，才是真正悬而未决的问题。

原文链接： galaxy.com/insights/rese...

鸿途知科网 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

北极熊当选Glamsterdam升级吉祥物 - Magicians / Primordial Soup

Sat, 29 Aug 2026 01:11:17 +0800

Glamsterdam 升级需要一个吉祥物（EIP-7773: 硬分叉 Meta - Glamsterdam）。

投票已结束

排除重复投票（相同的注册 IP + 相同的创建日期）：13 票，均投给 Flamingo
排除在 2026-07-10 之后创建的账户的投票：63 票，其中 Flamingo 39 票，Polar bear 24 票
总共排除：189 票中的 76 票
调整后的结果：Flamingo 50 票 vs Polar bear 63 票

由于一些潜在的舞弊行为*，Flamingo 的若干选票被从计票中移除，导致与 Polar Bear 形成平局。

如果你在 7 月 10 日之前注册了 Ethereum Magicians 账户，你就有资格参与决胜投票。

此外，任何被发现共享注册 IP 地址和创建日期的选票都不会被计入。

新的投票将持续两周，并于 7 月 31 日中午 12 点（墨尔本时间） 自动结束。

请投票！！ 你在社区中的声音确实很重要！！作为回顾，以下是这两个潜在吉祥物被选中的原因：

🦩 Flamingo

火烈鸟确实很迷人，以粉红色、夸张的羽毛和长腿脱颖而出。此外，在技术方面：

火烈鸟以其非常长且平行的双腿而闻名，就像 BAL 将改进并行化一样。
火烈鸟是滤食性动物，它们用喙中类似过滤器的结构将猎物（卤虫和蓝细菌等生物）从水中分离出来，有点像提议者-构建者分离（proposer-builder separation）。

此外，一群火烈鸟的集合名词是 flamboyance（华丽）……还有什么比一群火烈鸟（a flamboyance of flamingoes）更迷人的呢？

‍️ Polar Bear

专注于 Glamsterdam 的核心开发者协议贡献者参加了 Soldøgn Interop，北极熊可能在场，遭遇它们可能很危险。

如果你们之中有人知道如何解决女巫攻击（sybil attacks）和人性证明（proof-of-humanity）问题，请告诉全世界 :)。事实证明，即使是 emoji 吉祥物投票也无法幸免于此类问题。

投票结果

吉祥物决胜投票

Polar bear：51%
Flamingo：49%

178 位投票者

初始提名统计

吉祥物	理由	占比
🦩 Flamingo	平行的腿（BAL）+ 滤食性（ePBS）+ flamboyance（Glamsterdam）	36%
‍️ Polar Bear	Soldøgn Interop	33%
Hamster	Gl amster dam，颊囊（BAL）	17%
🦫 Beaver	水坝建造者（Glamster dam）	15%
Arctic Octopus	半自主触手（ePBS）+ 平行触手（BAL）	8%
Ant	构建者（ePBS）	7%
Poodle	优雅的狗	4%
Bee	协同、并行的工人	2%

118 位投票者，共 148 票

EIP-8066: 升级吉祥物规定了吉祥物要求、协调者（Mascot Wrestler）的角色，以及 Mascot Wrestler 与客户端团队的否决权。

@EvilJordan 被提议担任 Glamsterdam 的 Mascot Wrestler。

建议

吉祥物	Emoji	理由
Ant		因为 ePBS 而被推荐——这个重头戏全都与构建区块有关，而蚂蚁正是构建者
Beaver	🦫	字面意义上的水坝建造者——ePBS 中的 Builder——而且“dam”就正好在 Amster dam 里。
Bee		蜜蜂很努力：高效、协同、并行。
Flamingo	🦩	长而平行的腿：就像 BAL 将改进并行化。滤食性动物（喙中类似过滤器的结构将猎物分离出来）：有点像 ePBS。集合名词是 flamboyance。还有什么比一群火烈鸟（a flamboyance of flamingoes）更迷人的呢？🦩🦩🦩🦩
Hamster		就藏在 Gl amster dam 之中，显而易见却又不易察觉。颊囊会在匆忙行动前预先声明自己的货物——这是 Block Access List 的一个生动隐喻。
Arctic octopus		北极章鱼通过半自主的触手协调运作，没有中央控制器，这映射了 ePBS 将区块构建与提议解耦，以及 BAL 实现并行、预声明的状态访问以达到高效执行。
Polar Bear	‍️	Soldøgn Interop（核心协议贡献者）专注于 Glamsterdam。北极熊可能在场，遭遇它们可能很危险。
Poodle		Glamsterdam 听起来很优雅，贵宾犬是优雅的狗。

这是一篇可编辑的 wiki 帖子。

所有核心开发者 - 共识（ACDC）#168，2025 年 10 月 30 日
所有核心开发者 - 执行（ACDE）#224，2025 年 11 月 6 日
所有核心开发者 - 执行（ACDE）#239，2026 年 6 月 18 日
所有核心开发者 - 共识（ACDC）#169，2025 年 11 月 13 日

原文链接： ethereum-magicians.org/t...

鸿途知科网 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

最佳实践：从Multi-Agent到Agent Team

Sat, 29 Aug 2026 01:11:16 +0800

这是一篇长文，也是一份 Agent Team 的最佳实践。

如果你刚开始使用 Agent，后面有些实践可能会显得过于复杂，比如长期身份、Domain、Agent 之间的协作、跨 Agent 工作的收口、Team 的可观测性，以及对外关系中的身份与权限边界。

你不需要现在就把它们全部掌握。可以先读楔子、01 和 07，理解一个 Agent 为什么会逐渐变成一支 Team。

等你开始同时维护多个 Agent，发现自己不断重复解释背景、搬运 Context、追踪状态，甚至发现“Agent 更多了，人却更忙了”，再回来读 02 到 06，这些问题会立刻变得具体。

这篇文章希望提前给你一张地图：你今天可能还没有遇到这些问题，但当 Agent 从一次性工具变成长期协作者，它们会一个接一个出现。

它来自我长期运行一支真实 Agent Team 的过程。

Agent 怎样从一次性 Task 变成长期责任主体；Scope 过大以后怎样分化；不同 Agent 怎样发现彼此、直接协作并持续收口。

Human 怎样从唯一的 Router 变成整支 Team 的 Owner；以及 Agent 怎样在受治理的边界下进入真实外部关系。

CodexLoom 是承载这套工作方式的产品。这篇文章既介绍它提供了什么，也解释为什么一支 Agent Team 需要这些能力。

它讨论的不是怎样同时启动更多 Agent，而是：

当 Agent 开始长期存在、形成不同 Domain，并且需要相互协作时，怎样把原本全部集中在 Human 脑子里的责任、关系、交接方式、当前状态和边界，逐渐变成整支 Team 可以使用的工作结构。

在这个过程中，Human 不再负责串联每一步，而是从唯一的 Router，逐渐上移为整支 Agent Team 的 Owner。

你可以怎样读

你不需要一次读完。可以先根据自己正在面对的问题，直接进入对应章节。

如果你想先理解“为什么多个 Agent 不等于 Agent Team”，可以读楔子、01 和 07。
如果你已经在同时维护多个 Agent，并开始被 Human Routing 拖累，可以重点读 02、03 和 04。
如果你关心 Agent 的负载、瓶颈、Scope 调整和 Team Governance，可以直接读 05。
如果你想让 Agent 进入 Slack、飞书、客户、社区或者其他真实外部关系，可以直接读 06。
如果你想完整理解 CodexLoom 的产品逻辑，可以从头读到最后。

正文也会配合真实产品界面、协作链路和机制示意图。

第一次阅读时，你可以先看标题、加粗句、引用和图片配文，建立完整框架；之后再回到具体章节，阅读其中的实践、机制和边界。

全文地图

一个 Agent，是怎么变成多个 Agent 的 为什么真实工作会把 Task Agent 推向 Long-running Agent；为什么一个越来越好用的 Agent 最后又必须分化；多个 Agent 出现以后，瓶颈为什么会转移到 Human。
先让“谁负责什么”离开 Human 的脑子 Agent 怎样获得稳定身份、Domain 和 Scope；Human 与 Agent 怎样查询当前 Team 的责任结构；真实协作又怎样逐渐沉淀为 Organization 与 Collaboration。
让 Agent 自己开始协作 Agent Message 带来了什么变化；一个 Agent 怎样把工作直接交给另一个 Agent；为什么 Agent 沟通不是一次把一切说完。
Message 负责沟通，Topic 负责收口 当工作跨越多个 Agent、多个 Turn 和多天以后，怎样保留唯一的当前版本；Responsible、Participant、Artifact 和 Needs You 分别解决什么问题。
Overview：让一支持续变化的 Agent Team 变得可治理 当 Human 不再阅读每个 Agent 的全部过程，怎样从更高层观察 Team；怎样发现等待、积压和瓶颈候选；为什么治理关注的是工作流动，而不是让每个 Agent 看起来都很忙。
Agent Team 怎样进入真实的外部关系 为什么把 Agent 接入 Slack、飞书还远远不够；Agent 对外以后，身份、角色、信任、权限和现实后果为什么必须被分别治理。
CodexLoom 在织什么 Multiple Agents 与 Agent Team 的真正分水岭是什么；Human 在 Team 中的新位置是什么；为什么需要稳定的 Agent 和动态的 Team。

一条连续责任线依次穿过 Task、Long-running、Domain Agents、Human Router 和 Agent Team 五个阶段。

机制示意：从一次 Task 到长期 Agent，再到 Domain 分化、Human Routing 和 Agent Team。Agent 数量增加只是中间阶段，真正的变化是协作责任开始从 Human 转移给 Agent。

楔子：一次意外的外发

这篇文章，其实有点搞笑。我本意是打算把这个做了一个多月的项目先上线 Landing Page，然后慢慢打磨，一次整个大的。

结果负责 Web 的 Agent 接到我上线的指令后，按照之前的协作关系，通知了对外沟通的 Community Agent。Community Agent 一看，大新闻啊，就马不停蹄地整理素材，发到飞书群里。

等我看到的时候，消息已经发出去了。

codexloom.ai 桌面首页，使用大字标题、暖白编辑画布和下方产品界面作为证据。

CodexLoom 当前 Landing 页面。开头的外发故事来自这次真实上线，但页面上线、渠道发送和受众反应是三个不同的事实层级。

虽然事情有些意外，但也并没有脱离我对 Agent Team 的设定，甚至可以说，“它们”这次，干得不错。

我没有站在几个 Agent 中间，亲自选择下一步该找谁、搬运 Context、转交结果；工作仍然沿着已有的责任、协作关系和授权边界继续向前走。

这正是我做 CodexLoom 的原因。

过去，我们一直关心怎样让 Agent 变得更强，怎样让它完成更长、更复杂的任务。

但是单个 Agent 的能力范围总是有上限的。于是，越来越多人开始同时使用多个 Agent。

Agent 多了，新的问题也随之出现：真正的瓶颈不再只是单个 Agent 能做什么，而是怎样把这些 Agent 组织起来。

多个 Agent，并不会自动成为一支 Agent Team。

如果每一项工作仍然要由 Human 选择入口、整理背景、搬运 Context，再把一个 Agent 的结果交给下一个 Agent，那么这些 Agent 本质上仍是一组独立工具。

Human 仍然是整个系统里唯一的 Router，也是事实上的瓶颈。

我理解的 Agent Team，是另一种工作方式。

首先，每个 Agent 会长期负责自己的 Domain。它知道自己应该处理什么、边界在哪里，也知道遇到其他问题时应该去找谁。

其次，一部分原本由 Human 承担的协作责任，开始转移给 Agent。它们可以在明确的责任关系中直接协作，自己完成工作的交接和结果回流，而不是所有事情都要经过 Human 中转。

Human 并没有退出这支 Team。只是不用再串联每一个步骤，而是在方向、事实、选择、Review 和授权的位置回来。

但当 Human 不再盯着每一步，另一个问题也会随之出现：我怎么知道这支 Team 到底运行得怎么样？

所以，Agent Team 的真实工作还需要能够被观察、理解和持续调整。否则我只是从“亲自调度每个 Agent”，变成了“看不见它们在干什么”。

CodexLoom，就是我为这种工作方式做的产品。

它不是为了让你同时打开更多 Agent，而是把一条条独立的 Codex Thread，逐渐织成一支长期负责、能够协作、由 Human 治理的 Agent Team。

那么，多个 Agent，究竟怎样才能真正成为一支 Team？

01 一个 Agent，是怎么变成多个 Agent 的

Task Agent 并没有问题

大部分人开始使用 Agent 时，面对的其实都是一个 Task。

新建一个 Codex Thread，告诉它这次要完成什么，Agent 根据当前的 Context 调用工具、执行任务，给出结果。任务完成，这段工作也就结束了。

这种方式非常自然。一次性、边界清楚的工作，本来就不需要一个 Agent 长期存在。

然而在真实工作中，很多工作并不是一个个彼此独立的 Task。一个 Task 可以完成，它背后的责任却不会随之结束。

工作会围绕同一个长期目标持续发生，并带着新的事实、反馈和限制反复回来。

一篇文章写完了，之后还会继续修改；一个页面上线了，后面还要不断迭代；今天研究过的公司，下个月有了新产品、新融资、新数据，还会再次进入视野。

而且，每一次回来都不是简单重复。上一次的背景、判断和错误仍然有用，Human 给过的纠正、偏好和边界，也应该继续影响下一次工作。

Task 是一次工作的切片，但真实工作是一条持续流动的责任线。

一条持续责任线穿过四个错落的 Task 切片，并把 Context、Correction 和 Boundary 带入 Long-running Agent。

机制示意：Task 可以结束，责任仍会带着新的 Context、纠正和边界再次回来。Long-running 的意义，不是把一次对话无限拉长，而是让同一类责任持续回到同一个主体。

如果每次都新建一个 Agent，人就要重新解释背景、重新告诉它自己的偏好、重新说明什么能做、什么不能做，甚至重新踩一遍已经纠正过的错误。

所以，反复冷启动更深的成本，不只是 Token，也不是多写几个 Prompt，而是每次都在重新建立合作关系。

最自然的选择，就是不要再把这个 Agent 用完即弃。让它保留在同一个 Thread 中，下一次从上一段工作继续。

过去的工作、人的纠正，以及被 Summary、Memory、Skill 等机制保留下来的经验，开始影响下一轮。

这时，它就从一个 Task Agent，逐渐变成了 Long-running Agent。

Long-running 不是单纯把一次对话拉得很长，而是同一类责任开始有了一个持续存在的主体。

Human 也会在反复合作中慢慢形成对它的判断：什么时候应该找它，它擅长什么，通常会怎样工作，哪些边界还需要提醒。

Long-running Agent 也有自己的上限

一个 Agent 变得越来越好用以后，接下来通常会发生另一件事：人会不断把更多工作交给它。

一开始让它写文章，后来也让它找材料、研究事实、管理内容；再往后，可能连页面、SEO 和对外分发也一起交给它。

很少有人能在创建 Agent 的第一天，就准确画出它最终的 Scope。

更正常的过程，是 Scope 先随着使用不断扩张，直到问题在真实工作中暴露出来。

不同工作的高分辨率 Context、工作方法和专业判断开始挤在一起。

Agent 可能越来越慢，质量开始下降，需要反复纠正；也可能一直满负荷工作，新的任务不断排队，其他工作都在等它。

这不一定说明模型不够强。很多时候，问题是一个 Agent 已经承担了太多并不内聚的责任。

于是，就需要思考边界。

哪些工作应该共享 Context，放在一起会越来越好；哪些工作其实需要完全不同的方法和判断，继续塞在同一个 Agent 里，只会互相干扰。

Domain 不是先画出来的领域标签，而是在持续使用、Scope 扩张和能力劣化中逐渐显现的工作边界。

它回答的是：哪些事情适合由同一个 Agent 长期负责，哪些事情应该从中分出去。

这时，一个 Long-running Agent 就会开始分化。

研究工作交给 Research Agent，页面和上线交给 Web Agent，内容收集和写作分别交给 Content、Writer Agent，对外沟通交给 Community Agent。

Task 是工作单位，Long-running 是生命周期，Domain 回答的是一个 Agent 长期负责什么，又在哪里停止。

多种工作流进入一个不规则压力场，发生拥堵和冲突后从不同边界分化为多个 Domain Agents。

机制示意：Scope 通常先扩张，直到不同 Context、方法和判断互相干扰，边界才从压力与能力劣化中显现。Domain 分化是对真实摩擦的回应。

多个 Agent 的瓶颈，转移到了 Human

Agent 分化以后，单个 Agent 的 Context 压力下降了，不同工作可以同时推进，每个 Agent 也能在自己的 Domain 里积累经验。

但这个时候，它们仍然只是 Multiple Agents，不是 Agent Team。

因为它们虽然已经分工，协作却仍然发生在 Human 的脑子里。

每次有新工作，还是由人判断应该找哪个 Agent；开始之前，由人整理背景、限制和材料；一个 Agent 做完以后，由人读懂结果、判断能不能用，再转交给下一个 Agent。

不同 Agent 的结论发生冲突时，也仍然只有人知道谁才是这件事真正的 Owner。

看起来，多个 Agent 在并行工作。实际上，所有工作的入口、Context、结果和下一步，最后仍然汇聚到了 Human。

Agent 可以并行，但 Human 仍然只能逐个阅读、逐个判断、逐个路由。Agent 越多，Human 需要维护的 Context 和协作关系也越多。

多条并行 Agent lane 汇聚成 Human 前的 Context queue，再沿一条朱红色串行路由逐项输出。

机制示意：多个 Domain Agent 可以同时工作，但如果 Context、选择和交接仍然必须经过同一个 Human，系统最终仍然从一个窄出口串行流出。

于是，系统的瓶颈发生了转移：

核心判断

真实工作反复回来，逼出了 Long-running Agent；Scope 扩张与能力劣化，逼出了多个 Domain Agents；Agent 的分化，又把协作瓶颈集中到了 Human。

单个 Agent 过载，推动了 Domain 分化。Human Routing 过载，则推动多个 Agent 继续向 Agent Team 演化。

Agent 分化，只是产生了多个 Agent。只有原本藏在 Human 脑子里的责任、关系和交接方式被逐渐外化，一部分协作责任开始从 Human 转移给 Agent，它们才可能真正成为一支 Team。

而这件事的第一步，是让每个 Agent 长期负责什么、在哪里停止、遇到其他问题时应该找谁，变得清楚而且可以被整个 Team 使用。

02 先让“谁负责什么”离开 Human 的脑子

多个 Agent 出现以后，我很快发现，新的问题不是没有分工，而是这份分工只存在于我的脑子里。

我知道研究问题应该找 Research Agent，页面和上线应该找 Web Agent，对外沟通应该找 Community Agent。

我也大概知道每个 Agent 擅长什么、最近做过什么、什么事情不应该交给它。

但这些信息如果只有我知道，就没有真正成为 Team 的一部分。

每个 Agent 也许知道自己正在做什么，但它不会因此自动知道这支 Team 里还有谁、别人长期负责什么，以及遇到自己边界之外的问题时可以去找谁。

Human 不仅是整个系统的 Router，也是唯一保存这份分工的 Directory。

所以，CodexLoom 做的第一件事，并不是让 Agent 之间立刻开始互相发消息，而是先让每个 Agent 成为一个稳定、可以被识别的长期主体。

在 CodexLoom 里，一条 Codex Thread 不再只是某次任务留下来的对话。它可以绑定到一个长期 Agent，拥有稳定的名字、身份和工作入口。

之后新的工作仍然回到同一个 Agent，由同一个主体从当前状态继续。

这不代表 Agent 拥有无限、无损的长期记忆，也不是把所有历史记录重新塞回每一次 Context。它解决的是更基础的问题：下一次工作回来时，究竟是谁继续负责。

在此之上，每个 Agent 都有自己的 Profile。

Profile 回答三个非常简单，但对组织非常重要的问题：

Identity：它是谁
Domain：它长期负责什么
Scope：它在哪里停止，什么事情不属于它

Profile 不是给 Agent 发一张工牌，也不是写一段更长的 System Prompt。它是把 Human 已经从真实工作中发现的边界明确记录下来：你是谁，长期接住什么，又在哪里停下。

而且，这份 Profile 不是创建 Agent 时一次写死的。

第一章里提到，人的 Scope 判断一开始通常并不成熟。

一个 Agent 先在真实工作中持续承担责任，Scope 不断扩张，直到不同 Context 和判断开始互相干扰，边界才逐渐显现。

所以，更准确的顺序不是：

不是

创建 Agent → 填写 Profile → 得到一个 Domain Agent。

而是：

而是

真实工作暴露边界 → Profile 保存当前理解 → 后续工作继续验证和修正。

Profile 不是最终答案，而是这支 Team 当前采用的组织假设。

它先把此刻最值得采用的责任边界稳定下来，让 Human 和 Agent 可以据此工作；新的事实出现以后，再继续修正。

它也不是这个 Agent 已经胜任工作的证明。

比如，在开头的 Landing 故事里，Web Agent 的责任是页面实现、上线和生产结果。当页面完成 site-live，它也就走到了自己的边界。

接下来是否应该对外发送、发到哪个渠道、应该怎样表达，是 Community Agent 的判断。反过来，Community Agent 也不会因为负责对外沟通，就接管页面实现、部署或产品事实。

这就是 Scope 的意义。

Scope 不只告诉 Agent“你负责什么”，也告诉它“你在哪里停下，什么时候已经需要另一个 Domain 的专业判断”。

在 CodexLoom 中，一个 Agent 开始工作时，会带着自己的完整 Profile，以及与自己直接相关的 Organization 和 Collaboration。

它因此不只知道当前 Task，也知道自己长期是谁、负责什么、在哪里停止，以及有哪些已经声明的直接关系。

这里先简单理解即可：Organization 表达责任上的 parent/child 关系，Collaboration 表达两个独立 Domain 之间有方向的长期协作接口。后面还会继续展开。

但它不会自动得到整支 Team 的全部 Profile，也不会获得其他 Agent 的 Thread、历史和私有 Context。

需要了解更大的 Team 时，Human 和内部 Agent 可以主动查询：

loom team
loom team &lt;agent>
loom team links &lt;agent>
loom profile get &lt;agent>

loom team 提供当前这支 Team 的整体视图；loom team <agent> 可以查看一个 Agent 的完整 Profile、相邻关系和相关 Activity；loom profile get <agent> 则只读取它的 Identity、Domain 和 Scope。

这里的 Activity，指的是从真实 Message 中聚合出来的协作迹象。

WebUI 的 Team 页面也提供 Directory、Organization、Collaboration 和 Activity 四个视图。

Directory 让 Human 浏览当前 Team 中的 Agent 与 Profile；其他 Agent 也可以通过 Loom 的查询入口主动读取这些声明。

CodexLoom Team Directory 展示多个匿名 Agent。

CodexLoom Profile 详情分区显示 Identity、Domain 和 Scope。

当前产品界面 · 隔离构造工作区。Team Directory 提供长期 Agent 的可查询入口；Profile 明确保存一个 Agent 当前声明的 Identity、Domain 与 Scope。声明是共同工作基线，不是能力、记忆或授权证明。

Team 层提供的是可查询的 Profile 和关系，而不是把每个 Agent 的完整 Context 复制给所有人。每个 Agent 完整、细致的专业工作过程，仍然保留在自己的 Thread 中。

随着 Agent 继续分化，Team 还需要表达它们之间相对稳定的关系。

CodexLoom 用 Organization 记录 parent/child 的长期责任边界：一个更大的责任下面，是否已经分化出稳定的子责任。

CodexLoom Organization 关系图，一个父级 Agent 通过细线连接多个子级 Agent。

当前产品界面 · 隔离构造工作区。Organization 可视化当前声明的 parent/child 长期责任结构；它不会自动选择 Owner、发送 Message 或授予权限。

用 Collaboration 记录有方向的长期协作接口：两个独立 Domain 是否已经形成反复出现、值得明确保存的协作边界。

Agent 可以查询这些声明，把它们作为理解责任结构和可能协作接口的依据。

在 CodexLoom 里，声明结构和实际发生的工作，本来就是分开记录的。

Profile、Organization 和 Collaboration 保存的，是这支 Team 当前采用的组织假设。它们先提供一个共同工作的基线，再由后续真实工作继续检验和修正。

Activity 记录一定时间里真实发生过的 Message 协作。前者是声明，后者是运行证据，二者不能互相替代。

Collaboration 图显示多个匿名 Agent 之间的有向关系。

当前产品界面 · 隔离构造工作区。Collaboration 保存有方向的长期协作接口；关系本身不自动完成交接、共享 Context 或授予权限。

Activity 图显示一段时间内实际记录到的 Message 方向。

当前产品界面 · 隔离构造工作区。Activity 按记录到的 Agent Message 呈现协作迹象。它可以帮助检验一条声明关系，但不是绩效，也不会自动把重复往来升级成 Collaboration。

Organization 和 Collaboration 不会自动替 Agent 选择或联系下一个 Agent，也不会因为画了一条关系，就给 Agent 增加工具、凭证、部署、生产或外发权限。

两个 Agent 经常互发消息，也不会自动形成一条长期 Collaboration。反过来，写下了一条 Collaboration，也不能证明它们已经配合得很好。

真正值得沉淀的 Collaboration，要先在多次真实工作中表现为稳定的输入、输出和升级条件。

CodexLoom 通过 Message 与 Activity 提供观察证据，再由 Human 明确写下这条关系，并在后续工作中继续验证。后文讲可观测性与治理时，我们会回到这个过程。

这些声明做的事情非常基础：把原本隐藏在 Human 脑中的责任结构，变成一套 Human 和 Agent 都可以查询、检查，也可以继续修改的组织假设。

所以，从 Multiple Agents 走向 Agent Team 的第一个分水岭是：

关键问题

当工作需要协作时，当前 Agent 仍然只能回头问 Human“我应该找谁”，还是它已经可以根据自己的 Scope、直接关系和主动查询到的 Profile，判断下一位候选 Domain Owner？

CodexLoom 不会自动替 Agent 找到“正确的人”。查询结果只提供责任声明和关系依据。

具体应该找谁，仍然需要 Agent 根据当前工作作出判断；边界不清楚时，也应该继续升级给 Human。

但如果每一次都必须由 Human 指定下一位 Agent，那么 Human 依旧是唯一的 Router。这些 Profile 和关系，也仍然只是一张给人看的组织图。

Agent 能够查询并判断候选责任人，解决的是“应该找谁”。

要真正不再由 Human 搬运 Context，它还必须能够直接把一段有边界的工作交给对方，让对方在自己的专业 Context 中完成，再把结果沿着原来的工作链路交回来。

这就是 Agent Message 开始发挥作用的地方。

03 让 Agent 自己开始协作

判断出候选责任人，只解决了一半问题。

如果当前 Agent 走到自己的边界以后，仍然要先回来告诉我，那么 Human 依然是整个系统的人工总线。

我仍然要打开另一个 Agent，重新解释背景、复制材料、转述要求，等它做完以后再把结果搬回来。

只是这一次，我不再负责判断“该找谁”，却仍然负责把所有工作接起来。

所以，Agent Team 的下一步，不只是让 Agent 能够发现其他 Agent，而是让它们能够直接建立协作。

在 CodexLoom 里，这种协作从 Agent Message 开始。

Human 不再是 Agent 之间唯一的通信通道

这里最重要的变化，不是多了一个聊天框，也不是把 Human 写的交接文档电子化。

一条 Message 有明确的发送方和接收方，也会说明这次沟通是否期待对方返回结果。

它进入接收方自己的长期 Thread，由接收方带着自己的 Profile、直接关系，以及已经积累的专业 Context 来理解和处理。

发送方的完整 Thread、全部历史和私有 Context，并不会因此复制过去。

这意味着，协作不再需要 Human 先把一个 Agent 的工作读懂，再人工翻译给另一个 Agent。

发送方只需要交出这次协作所需的 Context；接收方则从自己的 Domain 出发，判断这个问题应该怎样处理、还缺什么、发送方的前提是否准确，以及它是否已经超出自己的边界。

原本发生在 Human 脑子和手上的过程：

发现工作已经越界
    ↓ 找到更合适的 Agent
    ↓ 解释为什么找它
    ↓ 转交必要 Context
    ↓ 等待处理
    ↓ 把结果带回来

开始能够直接发生在 Agent 之间。

但这不意味着 Human 完全退出。

更准确地说，Human Router 原来承担的一整块工作，开始被拆开。

发送方负责判断为什么需要协作，以及交出必要的 Context
接收方负责用自己的专业 Context 校正问题并返回结果
负责整件事收口的 Agent 负责整合局部结果
Human 继续保留方向、重大选择、Review 和授权

协作责任发生了转移，也发生了分层。

Request、Notification 和 Reply

CodexLoom 会区分不同的沟通意图。

如果发送方需要对方返回判断、行动或结果，可以发送一个 request：

loom msg TARGET --from SELF --subject "有界请求" --response required --body "当前问题、边界、证据要求与返回义务"

如果只是同步一个对方必须知道的状态变化，不要求回复，则可以发送 notification：

loom msg TARGET --from SELF --subject "状态或事实" --response none --body "变化、影响和核验入口"

接收方回答 request 时，结果会沿着原 Message 返回，保留真实的因果关系；而 notification 不需要为了“收到”制造一条没有业务价值的确认消息。

CodexLoom Agent Message 详情显示一条需要回复的请求，以及 reply、delivered、completed 和下方因果回复。

当前产品界面 · 隔离构造工作区。Agent Message 分开记录请求的因果关系、送达状态与接收方处理状态；这些状态不等于业务结果正确。

如果回复以后又出现了新的事实缺口，双方可以继续发起下一轮有边界的追问。

多轮沟通不是漫无目的地聊天，而是每一轮都说明：现在新增了什么、接下来要解决什么、结果必须回到哪里。

这些看起来像通信细节，但它们决定了一件很重要的事。

当 Human 不再站在中间以后，系统仍然知道一段工作从哪里来、交给了谁、对方是否需要返回结果，以及后续沟通为什么发生。

Landing 发布中的真实协作

开头那个 Landing 的意外外发，就是一个已经相对成熟、不需要先来回澄清的协作接口。

Web Agent 完成页面实现和 site-live 以后，已经走到了自己的 Scope 边界。页面是否值得对外发送、发到哪个渠道、应该怎样表达，不再是 Web 的专业判断。

于是，它按照已有的协作关系，向 Community Agent 发送了一条上线通知。

这条 Message 不只有一句“页面上线了”，还包含正式 URL、页面与生产验证、哪些事实可以公开、可以使用的素材、需要避免的重复发送，以及当前仍然存在的限制。

Web Agent 没有替 Community Agent 决定“必须发布”。它只是把一个已经超出自身边界、需要对外沟通判断的问题交给了对应的 Domain Owner。

Community Agent 在自己的 Thread 中判断这件事是否值得发送、面向哪个渠道、怎样根据受众改写、是否使用图片，以及应该立即发送、排期、延后还是跳过。

最终，它选择了对外渠道并完成发送，再把发送结果、回执和异常状态交回原来的工作链路。

这里还有一个很小但重要的细节：Web Agent 最初发送的是一条不要求回复的 notification。

Community Agent 完成以后，没有把完成结果伪装成原消息的 reply，而是沿着同一项工作重新发送了一条 completion notification。

因为这次协作的含义不是“Web 等待 Community 回答一个问题”，而是“Web 告知一个已经发生的状态变化，Community 独立承担后续判断，再明确通知结果”。

左右两个独立 Context 之间，一条折返的因果消息路径经历 Open、Correct、Align 和 Converge。

机制示意：两个 Agent 保留各自长期 Context，通过 Open、Correct、Align 和 Converge 逐轮增加共同理解。多轮不是把一条完整消息拆碎，而是让真实返回成为下一轮的新 Context。

最佳实践：Agent 沟通不是“一次把一切说完”

Landing 这次不需要多轮澄清，是因为 Web 与 Community 的责任边界、输入内容和结果回流方式，已经在过去的真实工作中逐渐稳定下来。

但更多时候，发送方和接收方拥有各自长期积累的 Context。

接收方不是一个等待填写 Prompt 的空白执行器：它可能知道发送方不知道的事实，拥有不同的工具和专业判断，也可能发现问题的前提本身就是错的。

如果发送方试图在第一条 Message 里把一切定义完整，它也在替接收方预设：你知道什么、问题为什么发生，以及最后应该得出什么结论。

这很容易把发送方自己的盲区一起带进协作。

多轮沟通的好处，是让接收方尽早从自己的 Domain 校正问题；后续每一轮都建立在真实返回而不是想象之上。

两个 Agent 不需要复制彼此的完整 Thread，也能逐步形成这次协作真正需要的共同理解。

我们在实践中逐渐形成了几条原则：

不假设对方知道什么，也不替对方预设原因和结论
第一条 Message 只需要让对方正确开始，而不是一次穷尽全部背景
下一轮根据对方的真实返回继续，而不是照着预先写好的问题清单机械追问
每一轮都应该带来新的信息或决定；Context 足够以后就及时收敛

最佳实践

好的多轮沟通，不是把一份完整消息机械地拆碎，而是让上一轮的真实返回成为下一轮新的 Context。

多轮也不是越多越好：当责任边界、输入、授权前提和结果回流都已经清楚，一次自包含的 handoff 通常更有效。

回到这次 Landing 协作，整个过程中，我没有打开 Community Agent 的 Thread，没有重新复制 Landing 的背景，也没有亲自把 Web Agent 的结果转述给它。

这才是 Agent Message 真正重要的地方。它传递的不只是信息，而是让两个拥有不同长期 Context 的责任主体，能够直接建立一条有来源、有边界、可以逐轮校正的沟通回路。

边界

Message 被送达，只代表接收方的 Codex Turn 已经接受了这段输入，不代表接收方已经理解、同意或者作出了正确判断。

处理状态显示完成，也只说明这次运行正常结束，不代表业务结果已经完成，更不代表它因此获得了新的工具、生产或对外权限。

结果是否正确、是否应该继续、是否涉及新的授权，仍然要回到对应的 Domain Owner，必要时再升级给 Human。

所以，能互相发 Message，仍然不等于已经成为一支 Team。

真正的变化是，Agent 开始接住原本由 Human 承担的协作责任：识别自己的缺口，判断候选 Owner，直接建立沟通，在各自的专业 Context 中逐步对齐，再把结果接回原来的责任链路。

但真实工作很少只涉及两个 Agent，也很少在一个 Turn 内结束。

一件事情可能跨越多个 Agent、多个阶段，还会经历等待、中断、事实更新和 Human 决策。

Message 可以让 Agent 直接沟通，却还不能单独回答：现在整件事进行到哪里，谁负责最后收口，大家在等待什么，最终结果和证据又应该保留在哪里？

这就需要比 Message 更高一层的协作结构。

04 Message 负责沟通，Topic 负责收口

Agent 可以直接互相发送 Message 以后，Human 不再需要搬运每一段 Context。

但真实工作一旦跨过两个 Agent，很快又会出现一个新的问题。

一件事情可能先由 Content Agent 梳理命题，再由 Research Agent 核验事实，由 Product Agent 确认产品实现。

中间还会等待新的材料、Human 的选择，或者外部事实发生变化。

每个 Agent 都可能完成了自己负责的部分，却没有人知道整件事现在进行到哪里。

有些结论留在某条 Message 里，有些限制只存在于某个 Agent 的 Thread 中；有人还在等待上一阶段的结果，另一个人却以为工作已经结束。

局部工作都完成了，整件事依然可能没有收口。

如果这些状态最后还要由 Human 逐条阅读 Message、进入不同 Thread，再在脑子里拼成一张完整进度图，那么 Human 只是从“通信 Router”变成了“项目状态 Router”。

所以，Message 解决点对点沟通以后，Agent Team 还需要一层更高的协作结构：

核心判断

不是让所有 Agent 共享同一个 Context，而是让一项跨 Agent 工作拥有一个明确的当前版本，以及一个负责最后收口的 Agent。

在 CodexLoom 里，这个结构叫 Topic。

Topic 不是把 Agent 拉进一个群聊

如果只说“多个 Agent 围绕同一个 Topic 工作”，很容易把它理解成一个 Agent 群聊：所有 Agent 进入同一个会话，共享同一段 Context，谁看到问题谁就回答。

但 Topic 的形态并不是这样。

每条 Topic 只有一个 Responsible。

Human 对整件事的方向、选择和纠正，首先回到 Responsible；Responsible 再根据当前需要，把有边界的问题通过 Message 交给不同 Participant。

Participant 不会进入一个公共聊天窗口。Research Agent 仍然在自己的 Thread 中研究，Product Agent 仍然在自己的 Thread 中核验产品。

它们收到的，是与自己那一段责任相关的 Topic Context 和 Message，而不是其他 Agent 的全部对话与工作过程。

完成以后，它们再把局部结果交回 Responsible，由 Responsible 更新 Topic 的 current brief。

它大致是这样的：

Human / Owner 把方向、选择和纠正交给 Responsible。
Responsible 通过 Message 向不同 Participant 派发有边界的问题。
Participant 在自己的 Thread 中完成专业工作。
局部结果回到 Responsible，由 Responsible 更新 Topic。

三个独立 Agent Thread 通过 Message 围绕中央 Topic 协作，Topic 分层显示 Responsible、Current、Waiting、Evidence 和 Result。

机制示意：Message 连接局部 request 与 reply；Topic 由唯一 Responsible 维护 Current、Waiting、Evidence 和 Result。参与者仍在各自 Thread 中工作。

如果群聊更像一间所有人同时说话的会议室，那么 Topic 更像一份有明确主责人的协作事项档案。

它保存整件事目前采用的版本，但不替代参与者各自的专业工作空间。

这也意味着，同在一个 Topic 里，不代表所有 Message 都会广播给所有人；Participant 之间也不会因为被放进同一个 Topic，就自动共享彼此的 Thread、历史和私有 Context。

CodexLoom Topic Current 页面显示 brief 版本、等待对象、下一步、限制、Responsible、Participants、Purpose 与完成条件。

当前产品界面 · 隔离构造工作区。Topic Current 由唯一 Responsible 维护共享 brief、等待条件、下一步、限制和 scoped Participants；各 Agent 的高分辨率工作仍留在自己的 Thread。

Team 需要共享当前状态，不需要共享全部 Context

在这种结构里，Topic 首先会说明这项工作为什么存在，以及什么才算完成。Responsible 和每个 Participant 的责任边界也会被明确记录下来。

Topic 会持续保存：

由 Responsible 维护的 current brief，也就是这项工作目前采用的事实、判断、下一步和限制
每个 Participant 负责什么
工作正在等待谁、等待什么
关键证据锚点和阶段结果在哪里
Topic 当前是否已经被标记为收口

这份 current brief 会随着工作推进不断更新。

它不是整件工作的全部历史，也不是把所有 Agent 的 Thread 合并到一起。

它只是让参与者在任何一个阶段回来时，不需要重新翻遍所有消息，就能先知道：我们现在走到了哪里。

每个 Agent 完整、细致的专业过程，仍然保留在自己的 Thread 中。

Research Agent 不需要把全部研究轨迹塞进 Topic；Product Agent 也不需要把代码、日志和每一步核验过程复制给所有人。

它们只需要把这项共同工作必须知道的结果、证据、限制和开放问题返回给 Responsible。

所以，Topic 共享的是整项工作的当前状态，而不是所有人的全部 Context。

Responsible 不是“什么都自己做”

这里很容易产生一个误解：既然 Responsible 对最终结果收口，是不是所有事情最后又集中到了一个 Agent 身上？

不是。

Responsible 的责任，不是替其他 Agent 做专业判断，而是维护整件事的连续性：

把整体目标拆成有边界的专业问题
找到合适的 Participant
接住不同 Agent 返回的局部结果
识别结果之间的冲突、缺口和等待
更新所有人应该知道的当前版本
最后把整项工作的结果交回发起者

Research 仍然拥有事实与证据强度，Product 仍然拥有当前实现，Community 仍然拥有具体外部渠道的判断。

Responsible 不能因为负责收口，就改写其他 Domain 的专业结论；Participant 也不能因为完成了自己的一段，就宣布整项工作已经完成。

这是一条很重要的协作边界：

协作边界

本地完成，不等于协作完成。

只有局部结果、证据、限制和下一步回到 Responsible，并被整合进整项工作的当前版本，这一段责任转移才真正闭环。

这篇文章本身，就是一个 Topic

我们现在写的这篇文章，就是一个真实例子。

我和 Content Agent 持续讨论文章到底想表达什么，哪些判断已经确认，哪些材料应该进入正文，哪些应该停放。

遇到产品实现问题时，Content Agent 不会自己猜，而是把有边界的问题交给 Product Agent。

Product Agent 在自己的 Thread 中回读当前代码、运行状态和产品对象，再返回它能证明什么、不能证明什么。

讨论到 Agent 之间应该怎样沟通时，它又把问题交给 Communication Coach。Coach 从真实协作中整理出多轮沟通的特点、已验证实践和失败边界，再把局部结果返回。

Content Agent 不接管产品事实，也不接管沟通方法的专业判断。它负责把这些结果与我的作者判断重新放在一起，更新文章当前讲到哪里、哪一章已经确认、下一步还缺什么。

如果没有 Topic，这些工作仍然可以通过 Message 完成。但每次我回来，都要重新问：

恢复工作时真正需要的问题

Product 核验到哪里了？Coach 返回了吗？哪一个版本才是我们现在认可的？还有什么没有解决？

Topic 让这项工作拥有了一份可以持续更新的当前状态。

我不需要进入每个 Participant 的 Thread，也不需要把每个专业过程都读一遍；但我仍然可以知道整件事为什么停住、谁正在负责、证据在哪里，以及下一步需要什么。

Artifact 让正式结果有稳定版本

跨 Agent 工作最后交付的，也不总是一段文字回复。

它可能是一份研究报告、一张截图、一段代码、一个章节草稿、一份 evidence ledger，或者某个已经确认的最终文件。

如果这些文件只存在于某条 Message 或某个不断变化的本地路径里，协作很快又会遇到另一个问题：

版本问题

你现在看到的，究竟是哪一版？

CodexLoom 用 Artifact 保存需要交付的文件快照。

Artifact 会拥有稳定的 ID、文件信息和校验值。即使原文件后来继续修改，已经发布的快照也不会跟着变化。

在这篇文章的 Topic 中，多个章节草稿、Product 和 Communication Coach 的回读、sourcebook 与素材账本，已经被保存为独立 Artifact，再由 Responsible 链接回 Topic。

这样，current brief 负责说明“我们现在怎样理解这项工作”，Artifact 负责保存“这个判断具体对应哪一个文件版本”。

后续 Agent 引用的是同一个已经固定的结果版本，而不是猜测某个本地文件现在又被改成了什么样。

同样，Topic resolved 也只表示：这条协调记录已经被标记为收口。

按照 CodexLoom 的协作责任，这一步应该由 Responsible 对照 completion boundary 来完成。

但系统不会自动验证边界是否真的满足，也不会因为状态变成 resolved，就替 Team 执行后续动作。

所以，它不代表所有相关的下游动作、外部发送或现实结果都已经完成。

开头的 Landing 就有一个很准确的时间边界：页面 site-live 的截图和阶段结果先被记录，Landing Topic 随后被标记为 resolved；Community Agent 的外部分发发生在之后。

更准确地说，是页面上线的独立验证和 Responsible 发布的阶段结果支撑了 site-live；resolved 只记录这项协调工作当时已被收口。

之后飞书和 Parall 的发送，则由另外的 Outbox 与 provider receipt 记录。

所以，Topic 和 Artifact 并不是为了制造一个“完成”的假象。

它们真正解决的是：当工作跨越多个 Agent、多个 Turn 和多个阶段以后，Team 仍然拥有一份明确的当前状态，一个负责收口的主体，以及可以回查的正式结果。

Needs You：在正确的位置找回 Human

Topic 可以记录“这项工作正在等待 Human”、对应的引用，以及 Human 回答后应该怎样恢复。

但如果 Agent 缺少的是人的事实、选择、Review 或授权，它不能替 Human 作出回答。

这时，Agent 也不应该把一句模糊的“接下来怎么办”扔回给 Human。它需要先说明：

现在正在完成什么工作
已经确认了哪些事实
具体缺少人的哪一个判断
有哪些可选路径以及各自影响
Human 回答以后，原工作应该从哪里继续

在 CodexLoom 里，这条路径叫 Needs You。

Needs You 页面显示一个有背景说明、两个选项和回答输入区的 Human 决策请求。

当前产品界面 · 隔离构造工作区。Needs You 把需要 Human 提供事实、选择、Review 或授权的精确阻断点持久化。问题被回答，不等于后续动作已经发生或有效。

Needs You 会把问题、必要 Context、被阻断的工作、候选选项和期待回答保存下来。Human 回答以后，结果会回到原来的 Agent 和原来的工作，而不是重新打开一个没有上下文的新对话。

这样，Human 不需要站在所有 Agent 中间推动每一步。大部分工作可以继续向前流动；真正需要人的事实、取舍、Review 或授权时，再把 Human 带回准确的工作位置。

当然，创建 Needs You 并不等于已经获得批准。Human 的回答也只覆盖回答中明确给出的范围。

如果 Human 只同意“继续起草”，Agent 不能把它理解成“可以直接发表”；如果 Human 回答了一个事实，也不代表后续所有相关动作都已经获准。

到这里，一项工作已经可以在多个 Agent 之间被发现、交接、持续协调，并在正确的位置找回 Human。

但当这样的工作越来越多、Agent Team 真正开始长期运行以后，还会出现另一个问题：

Human 怎样看见整支 Team 实际是怎么工作的？

05 Overview：让一支持续变化的 Agent Team 变得可治理

当 Agent 有了长期身份，能够找到彼此、直接发送 Message，并通过 Topic 持续推进一项跨 Agent 工作以后，多个 Agent 已经开始像一支 Team 那样协作。

但这支 Team 并不会因此稳定下来。

第一章里我们提到，Domain 不是在创建 Agent 的那一天就能准确画出来的。它是在长期真实工作中，随着 Scope 扩张、能力劣化和协作摩擦，逐渐暴露出来的责任边界。

而且，这个边界还会继续变化。

模型能力提升以后，过去必须拆开的工作，也许可以重新放到一个 Agent 中。

新的工具出现以后，一个 Agent 能够承担的责任可能变大；业务进入新的阶段，会产生新的任务、依赖和风险；外部环境变化，也可能让原本稳定的流程和权限边界突然失效。

Agent 本身也在发展。

它会在长期工作中积累新的经验，被 Human 反复纠正，形成新的 Skill、Memory 和工作方法。随着能力与可靠性发生变化，Human 对它的使用方式也会改变。

所以，Agent Team 不是一张设计完成以后就不会再变的组织图。

Profile、Organization 和 Collaboration 保存的，是这支 Team 当前采用的组织假设。它们先提供一个共同工作的基线，再由后续真实工作继续检验和修正，而不是成为永久正确的答案。

真实工作仍然可能不断暴露新的失配：

某个 Agent 的 Scope 变得过大，长期满负荷运行，逐渐成为整支 Team 的瓶颈
两个 Agent 虽然已经分开，却花费大量时间反复解释和通信，说明它们的边界可能切错了
一个新 Agent 被创建出来，却长期没有真实工作进入
声明上互不相关的两个 Domain，在实际工作中却频繁协作
问题看起来像 Agent 数量不足，实际原因却可能是工具、方法、路由、权限或者外部 Connector 出了问题

这意味着，建立 Agent Team 不是一次性的设计任务，而是一项持续发生的管理工作。

真正的问题也不再只是：

最初的问题

Human 怎样知道这支 Team 实际是怎么工作的？

而是：

真正的治理问题

Human 怎样知道当前的 Agent Team 是否仍然适合正在发生的工作？

当声明的结构与真实运行开始出现偏差时，又怎样找到可以调查和调整的抓手？

这也是 CodexLoom 为什么需要 Overview。

管理的前提，是先让问题暴露出来

Human 的注意力是有限的。

当 Team 中只有两个 Agent 时，我还可以分别打开它们的 Thread，看看最近做了什么、卡在哪里、有没有跑偏。

当 Agent 变成十个、二十个以后，这种方式就会失效。

如果我仍然试图阅读每个 Agent 的完整过程，很快就会被信息淹没。

更糟的是，我花了大量时间理解局部细节，却不一定能看见 Team 层真正的问题。

这和管理一支 Human Team 很像。

管理者不可能通过阅读每个人的全部工作记录来管理组织。Team 越大，就越需要先从更高的层级观察运行，让值得关注的问题暴露出来，再沿着证据向下调查。

在精益管理里，可视化不是把更多数据堆到屏幕上，而是让问题先显露出来。

Overview 提供的，就是这样一个运行观察与分诊入口。

它不是一张用来展示“今天运行了多少 Agent”的热闹 Dashboard，也不是给 Agent 做绩效排名。

它更不会自动告诉我应该拆分、合并或者替换哪个 Agent。

它把原本散落在 Agent 状态、Codex Turn、Needs You、Inbox、外部 Connection、队列和 Token 记录中的运行信号，压缩到同一个入口。

时间范围、时区、追踪覆盖、图例和 Data quality 会和这些信号一起出现，让 Owner 知道自己现在看到了什么，又有哪些工作可能没有被当前数据覆盖。

这里有一个很重要的管理选择：Overview 首先度量的是工作怎样发生、等待和流动，而不是评价 Agent。

指标的作用，是帮助 Owner 理解并改善系统，而不是把每个 Agent 排成名次。

如果公司里有 HR 管理 Human Resource，那我自己开玩笑，会把这里叫作 AR，也就是 Agent Resource。

这也是我做 CodexLoom 时最在意的一层：不仅让 Agent 工作，还要让一支持续变化的 Agent Team，可以被 Human 观察、理解和持续调整。

Status：现在发生了什么

Overview 的 Status 先回答最直接的问题：现在有哪些 Agent 正在执行，哪些事情正在等待 Human，内部 Inbox 是否出现积压，外部 Connection 或处理过程是否留下了需要关注的问题。

在它下面，Daily Activity 会按照时间，把记录到的执行、Turn 和 Token 对齐到 Team 与各个可追踪 Agent 的活动行中。

我可以从这里看到，某一天的工作主要集中在哪些时段，什么时候出现了多个 Agent 并行工作的波次，以及记录到的活动主要分布在哪些 Agent 身上。

至于这种集中是不是已经成为长期模式，还需要继续比较多个日期和观察窗口，不能从一天的页面直接得出结论。

但 Activity 只能说明当前被记录到的工作。

一个 Agent 没有出现在活动行里，可能是它没有进入真实工作，也可能是对应的 Codex rollout 无法读取，或者当前数据覆盖并不完整。

多个 Agent 并行时，汇总的 Agent 执行时间甚至可能超过自然墙钟时间。

所以，低 Activity 不等于低价值，高 Activity 也不等于高绩效。

它只是让我知道：这里可能值得继续调查。

Overview Status 显示四个摘要、日期、八名 Agent 的 30 分钟活动时间轴、图例、Tracked 8/8 和 Asia/Shanghai。

当前产品界面 · 隔离构造工作区。Status 和 Daily Activity 压缩当前状态与记录到的执行节奏；Tracked、时区和图例限定读数范围。这些是调查信号，不是绩效评分。

Capacity：哪里正在形成等待和积压

Status 告诉我工作在哪里发生，Capacity 则进一步展示记录到的 Turn 执行、新工作等待、当前 backlog、工作来源和排队证据。

其中我比较关注一个指标，叫 New-work wait。

它看的不是“一条消息多久得到回复”，而是一项新的可追踪工作进入队列以后，过了多久才第一次真正开始处理。

这项新工作可能来自另一个 Agent 的 Message，也可能来自 External Inbox、Needs You、Schedule 或 Trigger。

Capacity 还会展示当前 backlog：此刻有哪些可追踪工作仍然在排队或处理中。

需要注意的是，它是当前快照，不是对过去所有队列的完整重建。

精益管理区分资源效率和流动效率。

资源效率关注每一个局部是不是被充分利用；流动效率关注一项工作能不能端到端地顺畅向前。

对 Agent Team 也一样：一个 Agent 时刻满负荷，却让所有下游都在等待，并不是值得追求的高效率。

它可能只是把局部的忙碌，变成了整支 Team 的瓶颈。

如果在连续多个观察窗口中，同一个 Agent 的被记录执行反复集中，指向它的新工作等待较长，而且当前仍然存在 backlog，我会得到一组值得调查的瓶颈候选信号。

但我不会立刻得出“它已经成为瓶颈”的结论。

我会先查看对应的 queue evidence，确认究竟是什么工作在等待。

再进入相关 Agent 和 Messages，并通过 Loom 中的 Topic 等其他入口，检查其他工作是否真的依赖它，以及阻塞发生在哪一层。

只有在这些证据能够互相印证时，我才会进一步追问：这个 Agent 是否正在成为 Team 的瓶颈？

即使答案是“是”，原因也仍然可能完全不同。

可能是 Domain 太大，也可能是工作方法低效、缺少工具、权限卡住、外部 Connector 失败，或者上游把不属于它的任务全部路由了过来。

Capacity 提供的是调查入口，不是自动诊断。

Overview Capacity 页面显示五个 signal cards、时间图、来源分布和 Agent table。

Data quality 说明 Capacity 统计口径与已知限制。

当前产品界面 · 隔离构造工作区。Capacity 将 recorded execution、new-work wait 与 current backlog 放在同一观察面，帮助 Owner 选择下一步调查对象；单个页面不能证明瓶颈、历史趋势、利用率或原因。

它还会显示一项 calendar non-executing proxy，也就是日历时间中没有被记录为 Turn 执行的部分。

但它可能同时包含机器关机或者服务停止的时间，因此不能直接理解为“Agent 的空闲产能”，更不能据此判断还能向它塞入多少工作。

Token Usage：计算投入主要去了哪里

Token Usage 展示记录到的 input、cached input、output、reasoning output 和 model calls，以及这些计算量在日期、Agent 和模型之间的分布。

我可以从这里看到，哪些 Agent 或 Organization 分组的计算投入比较集中，缓存怎样被使用，不同模型主要被用在了哪里。

但 Token 多不代表一个 Agent 更重要，也不代表结果质量更高。

它能提供的，是另一个继续调查的入口：某个 Agent 的 Context 是否过大，是否存在重复工作，模型组合是否合理，或者这个 Domain 本身是否确实需要大量研究和推理。

最终仍然要结合真实产物与业务结果判断，而不是只看 Token。

Overview Token Usage 页面显示总量、每日堆叠图、图例和各 Agent 的 allocation。

当前产品界面 · 隔离构造工作区。Token Usage 展示选定时段内不同 token 类型、模型调用和 Agent allocation 的分布；它不等于成本效率、质量、重要性或业务价值。

Overview 不会自动理解组织

这里还有一个必须说明的产品边界。

CodexLoom 的 Team 页面保存 Agent 的 Profile、Organization 和 Collaboration，也就是当前声明的责任与关系；Overview 保存的是运行状态、活动、执行、排队和计算投入等观察证据。

当前产品不会自动读取 Profile 中的 Domain 和 Scope，判断实际工作有没有超出边界；也不会把 Collaboration 与真实 Activity 自动对照，然后告诉我哪条关系已经失效。

把声明结构与运行证据放在一起理解，是 Owner 的工作。

我可能先从 Overview 发现某个 Agent 的等待正在上升，然后回到它的 Profile 和 Organization，检查它是否承担了超出当前 Scope 的工作。

也可能先在 Team 页面看到一条长期 Collaboration，再回到 Activity 与 Message，观察它是否真的进入了日常工作。

Overview 不替我完成这个判断，但它让这种判断有了可以追踪的证据入口。

Signal 不是 Diagnosis

Overview 最重要的价值，不是替 Owner 得出结论，而是把问题暴露出来。

忙不代表有价值，低执行不代表无用，Token 多不代表结果更好，等待也不自动证明 Agent 数量不够。

所以，Signal 不是 Diagnosis。

Owner 需要先从 Overview 把范围缩小到某个日期、Agent 或排队来源。

Overview 可以直接打开部分 Agent、External Inbox、Needs You，以及通用的 Messages 入口；Topic、具体 Turn、Artifact 与业务结果，则需要通过 Loom 的其他页面、对象 ID 和因果关系继续调查。

然后，Owner 还需要询问负责 Agent 怎样理解问题。

最后的干预也不一定是拆分或增加 Agent。

方法有问题，可以修改 Skill 和工作方式；工具不足，可以补工具；路由错误，可以调整 Collaboration；权限造成阻塞，可以修正授权门。

只有当问题长期、反复地来自 Domain 边界，才需要考虑拆分、合并或重新划分责任。

然后，还要继续观察后续的真实工作，判断这次调整是否真的解决了问题，还是只是让某一个局部指标暂时变得更好看。

这不是一次性的组织设计或者 Reorg，而是一轮持续改善：先让问题显露出来，再调查原因，试行一个尽量小、可逆的调整，然后用后续真实工作检查结果。

所以，一套更完整的治理循环是：

治理循环

发现 Signal → 下钻 Evidence → 判断原因 → 选择干预 → 用后续真实工作验证。

Signal 进入多条 Evidence 记录，再汇聚到 Human Diagnosis、Small Change，并沿 Next Work 回到新的观察。

机制示意：运行信号先缩小调查范围，再沿证据下钻，由 Human 判断原因、尝试小幅可逆调整，最后用下一轮真实工作验证。Signal 不是 Diagnosis。

这个循环属于 Human 使用 CodexLoom 的治理方法，不是 Overview 已经自动执行的产品流程。

改善成立以后，新的做法才进入 Profile、Organization、Collaboration 或 Skill，成为下一轮工作的基线。

完整的 Agent Team Governance 会比这复杂得多，我们会在后面的文章里专门讨论。

在这篇文章里，我更想说明的是：

Human 的新位置

Human 没有从 Agent Team 中消失，而是从每一段工作的人工 Router，上移成了观察、追问、诊断和调整整支 Team 的 Owner。

Agent Team 不是为了把 Human 排除在外，而是为了让 Human 的注意力用在真正需要人的地方。

当内部 Team 已经能够长期负责、直接协作、持续收口，并且可以被 Human 看见和治理以后，下一个问题才是：

这些能力，怎样进入客户、社区、合作伙伴，以及 Slack、飞书这些真实的外部环境？

06 Agent Team 怎样进入真实的外部关系

当内部的 Agent Team 能够长期负责、直接协作、持续收口，并且可以被 Human 看见和治理以后，我自然会走到下一个问题：

下一个问题

这些 Agent 能不能不只帮助我完成内部工作，也能够直接帮助我服务外部？

对个人来说，真正稀缺的资源仍然是自己的时间和注意力。

每天可能会有人来讨论问题、询问信息或者寻求帮助。我也需要服务用户、参与社区、回应客户，或者为合作伙伴和公司里的其他部门提供专业能力。

如果这些对外工作最终都必须回到我本人，由我理解需求、组织内部 Agent、检查结果，再亲自回复，那么无论内部 Agent Team 多么强大，它提升的仍然主要是我的个人效率。

我的能力，仍然被我一个人的时间限制住。

但在长期工作中，一些 Agent 已经逐渐形成了稳定的 Domain 能力。

它们不只是临时调用模型回答问题，而是长期理解同一类工作，积累自己的信息来源、工具、方法、历史判断和停止边界。

内部 Team 也可以通过 Profile 和声明关系，查询谁可能负责哪类问题，以及结果应该回到哪个既有工作链路。

如果这些能力只能被我在内部调用，它们仍然只是我的私人生产力工具。

只有当这些成熟的 Domain 能力可以在明确身份和责任边界下进入外部，它们才可能开始持续服务客户、社区、协作者或者其他部门。

这时，Agent 带来的就不只是效率提升，而是能力扩展。

一部分原本只能由我本人提供的能力，开始可以由一支 Agent Team 持续交付。

这就是我做 External 的原因。

Agent 一旦对外，风险模型就变了

但是，让 Agent 参与内部工作，和让它进入真实的外部关系，并不是同一件事。

在内部，我非常熟悉自己的 Agent。

我知道它擅长什么、容易在哪里犯错，知道哪些表达只是候选判断，哪些结果已经经过核验。即使它说了一句不准确的话，我也可以继续追问、纠正、重做，或者根本不采用。

我们之间已经存在许多不需要每次说出来的合作默契。

一旦 Agent 对外，这些默契就不存在了。

外部的人并不了解这个 Agent。

他不知道它过去接受过哪些纠正，也不知道它的知识和权限边界，更无法自然分辨一句话究竟是草稿、推断、正式答复，还是可以代表我作出的现实承诺。

同一句不准确的话，在内部可能只是一次容易修正的工作误差；到了外部，却可能被理解成产品事实、组织立场或者已经成立的承诺。

而且，外部输入本身也不能被默认信任。

有人可能提供错误背景，试探 Agent 能看到什么、可以做什么，诱导它披露内部信息，要求它绕过原有规则，甚至主动尝试攻击这个 Agent。

这时，一条进入 Agent 的消息就不再只是一个普通 Task。它也可能是一段带有错误前提、越权意图或者对抗性的输入。

所以，External 要解决的从来不只是“消息能不能进来，结果能不能发出去”，而是五个更具体的问题：

谁在代表这支 Agent Team
它在当前外部关系中扮演什么角色
什么输入可以触发它，它又可以回答或行动到哪一步
需要其他专业能力时，怎样调用内部 Domain Team，并让结果回到原来的关系
什么情况必须停止，把事实、选择、Review 或授权交回 Human

左侧 Internal correction loop 与右侧多种不确定 External input 被一条垂直 Trust Boundary 分隔，输入从 Governed Entry 进入。

机制示意：内部协作建立在长期纠正与熟悉边界上；外部输入可能带有错误前提、越权意图或对抗性。受管入口改变通信路径，但不是完整安全隔离。

这也是为什么 CodexLoom 的 External 看起来远比“接一个 Bot”复杂。

外部只面对一个受管入口

CodexLoom 不会把一个 Provider Bot 直接接到整支 Agent Team。

外部用户通过已经配置的 Address 和 Membership，进入拥有这个 Address 的长期 Agent，而不是获得内部 Profile、Organization、Collaboration、Thread、工具或凭证的直接入口。

这个入口通常由一个长期 Agent 承担。

这里的 Interface Agent 不是 CodexLoom 中一种写死的 Agent 类型，而是一种组织形态：某个 Agent 长期负责理解特定外部关系，并把外部需求与内部 Domain Team 连接起来。

有时，Domain Agent 可以直接持有这个外部入口。比如商务关系本身就是它长期专业 Context 的一部分。

有时，对外身份、受众理解、渠道适配、隐私和反馈回流会形成一套独立责任，这时才值得由 Community Agent 这样的 Agent 专门承担 Interface。

但“外部只有一个入口”并不等于已经获得完整安全隔离。

承载这个入口的 Agent 仍然在自己的 primary Thread 中工作，那里可能已经存在内部历史、工具和本地权限。

如果入口 Agent 选择错误、权限过宽，或者角色和 guidance 设计不当，仍然可能带来泄露和越权。

所以，不同信任边界是否应该使用独立 Agent，这个 Agent 应该拥有多少 Context 和工具，以及如何配置 sandbox、approval 与最小权限，仍然是真实的组织和安全设计。

同一个 Agent，在不同 Conversation 中也不是同一个角色

CodexLoom 把外部连接、外部身份和具体关系中的局部角色分开保存。

Connection 建立一个 Provider app、bot、account 或 tenant 的连接、能力和健康状态。

它只是平台连接与能力入口；消息能否进入、结果能否发出，还取决于 Address、Membership、Connector 能力和当时的运行状态。

Agent Address 则把一个外部 identity 绑定到一个长期 Agent，回答“究竟是哪一个 Agent 以这个身份出现在外部”。

同一个 Address 进入不同群、频道或者私聊时，使用的仍然是同一个外部身份，但它在每个 Conversation 中可以拥有不同的局部角色和通信策略。

这些差异由 Conversation Membership 保存。

Membership 会记录这个 Agent 在当前 Conversation 中为什么存在、扮演什么角色、应该遵循什么 guidance，以及几类重要的通信边界：

什么样的入站消息可以触发它
它的结果怎样映射成外部回复
它只能回复已有问题，还是也允许主动发送
这个 Conversation 使用什么 trust-domain 标签

一份 Membership 只适用于它对应的 Conversation。

Agent 在一个飞书群里被允许主动发送，不代表它自动获得另一个群、另一个平台或者另一个外部身份中的相同行为边界。

但 Membership 解决的是局部角色和通信策略，不是完整权限系统。

它不会给每个 Conversation 创建独立 Thread，不授予仓库、文件、凭证或部署权限，也不会自动识别机密、现实承诺和业务风险。

trust-domain 只是用于记录和约束的标签，不是安全沙箱。

Agent 的长期身份可以保持稳定，但它在每段外部关系中的局部角色和行为边界，必须分别治理。

CodexLoom External 页面显示已连接的飞书身份、启用的匿名 Membership，以及 When mentioned、Send final answer、Proactive + replies 策略。

当前产品界面 · 匿名真实运行记录。一个已连接的飞书身份及其已启用 Conversation Membership。Membership 保存该 Conversation 的局部角色与 mention、reply、outbound 策略；名称与标识已匿名。

外部请求怎样调用背后的 Agent Team

当一个外部消息满足当前 Address、Membership 和触发条件以后，它会进入拥有这个 Address 的长期 Agent，而不是自动分发给整支 Team。

完整链路大致是：

Provider event
    ↓ Connection / Address / Membership
    ↓ Inbox / Handling
    ↓ Interface Agent primary Thread
    ↓ 可选的内部 Agent 协作
    ↓ Outbox
    ↓ provider result / receipt

Identity、Membership、Interface、Internal Team、Human、Outbox 和 Delivery 以分层协议结构连接。

机制示意：External 不是接上一个 Bot。Identity、Conversation Membership、Interface、可选的 Internal Team 协作、Human 边界、Outbox 与 Delivery 分别保存不同责任。

Inbox 和 Handling 会记录外部实际送来了什么、由哪个 Agent Turn 按哪一个 Membership version 处理。

Interface Agent 可以结合 Membership context 和当前输入，判断请求是否属于范围、还缺少什么 Context，以及是否需要停止，或者向内部 Agent、Lead、Coach 或 Human 求助。

这些仍然是 Agent 的判断，不是 Membership 自动完成的诊断或授权。

如果问题需要其他专业能力，Interface Agent 可以查询内部 Profile 和声明关系，再通过 Agent Message 或 Topic，把一段有边界的工作交给候选 Domain Owner。

External 不会根据 Profile、Organization 或 Collaboration 自动替它选择正确的内部 Agent。

研究问题仍然由 Research Agent 判断，产品事实仍然由 Product Agent 核验，页面和生产结果仍然由 Web Agent 负责。

Interface Agent 不会因为接住了外部请求，就成为所有专业事实的新 Owner。

它拥有的是外部入口、意图翻译、内部路由、受众表达和结果回流，而不是背后每个 Domain 的事实所有权。

内部结果通过 Message 或 Topic 回到 Interface Agent。

它再依据当前 Membership 的 role、guidance 和 outbound policy，以及当前公开边界与实际授权，判断是否创建 Outbox，把结果送回原来的 Conversation。

内部 Domain Agent 不会绕过这个外部角色，直接获得向 Provider 发送结果的权力。

Outbox 会保存目标、内容、幂等信息、发送尝试、状态和 Provider 返回的结果，使这次外部动作可以被追踪和核对。

但 CodexLoom 执行和记录的是已经请求的外发，不会自动验证这次动作拥有的授权是否充分。

Provider receipt 也只能证明 Connector 或 Provider 当时返回了相应的 message 或 attachment 标识，并被 Loom 保存下来。

它不代表对方已经阅读、理解、接受，更不代表结果正确或者产生了业务效果。

CodexLoom Inbox 显示一条匿名飞书消息为 handled，处理尝试为 1，使用 Membership v2，并显示 Reply sent。

当前产品界面 · 匿名真实运行记录。来自同一匿名 Conversation 的入站消息已进入 Community Agent 的处理记录；UI 保留 handled、attempt、Membership 版本、Context used 与 Reply sent。

CodexLoom Outbox 显示一条匿名飞书回复为 sent，尝试次数为 1，并保留已脱敏的 provider message result。

当前产品界面 · 匿名真实运行记录。同一入站消息产生的出站回复已进入 Outbox，并记录 sent、尝试次数与 provider message result。它不证明对方已读、理解、接受或采取行动。

Human 保留的是外部后果的边界

External 不是让 Agent 无限制地跑到外面自主行动。

知道一个答案、可以起草一段表达、可以回复已有问题、可以主动发布、可以代表别人作出承诺，以及可以执行具有现实副作用的动作，是完全不同的权限层级。

一个 Agent 长期承担某个 Interface，只说明它负责判断和收口，并不会自动获得更高一级的行动权。

当 Agent 判断工作缺少事实、选择、Review 或授权时，可以主动用 Needs You 暂停当前工作，并向 Human 提出一个明确问题。

但当前产品不会因为内容敏感而自动创建 Needs You，也不会在 Outbox 发送前，自动验证某个 Needs You 的回答是否充分授权了这次外发。

真实授权是否存在、范围是否足够、是否仍然适用于当前动作，仍然需要 Agent 和工作流诚实执行。

Human 不再负责搬运每一段 Context，但仍然拥有外部后果的最终边界。

回到开头那次意外外发

现在再回到文章开头。

这次 Landing 外发并不是一个外部请求经过 Inbox 进入 Agent Team 的案例。它走的是另一条主动外发路径。

Web Agent 完成 Landing Page 的上线和验证以后，把正式 URL、可以公开的事实、素材状态和已知限制，通过一条内部 notification 交给 Community Agent。

Community Agent 在自己的长期 Thread 中检查当时的渠道 Context 和 Membership，独立判断这件事是否值得发送、应该发到哪里，以及怎样为不同受众组织表达。

它随后分别为飞书和 Parall 创建了 proactive Outbox。两个 Provider 返回的 message 和 attachment 信息被保存成 receipt。

允许主动发送的 Membership 约束了这次通信路径，但它不是授权本身。

这次外发依赖的是此前已经存在的 Owner 与组织决定，CodexLoom 并没有从 receipt 反推出授权是否充分。

完成以后，Community Agent 又通过一条 completion notification，把渠道判断和投递结果带回 Web Agent 所在的原工作链路。

这段时序还有一个重要边界：Landing 的 site-live 协调事项已经先完成收口，外部分发是随后发生的工作。

不能因为后来保存了 Outbox 和 receipt，就反过来说原 Topic 等待并确认了这次外发。

我看到消息时感到意外，是因为这一次不再需要我亲自站在 Web Agent 和 Community Agent 中间。

但它并不是一次没有边界的自主行动。

Web Agent 只对页面和生产结果负责；Community Agent 只对渠道、受众和外部表达作判断。

主动外发经过具体 Membership 和 Outbox；结果和 evidence 又回到了原来的工作链路。

所以，External 真正解决的不是“怎样让 Agent 自动发消息”。

它解决的是：

External 的核心问题

怎样让一个长期 Agent 以明确身份、局部角色和可检查的行为边界，进入一段不完全可信的真实关系？

需要内部专业能力时，它可以调用背后的 Agent Team，但外部表达、权限和现实后果仍然从同一个受治理入口收口。

当成熟的 Domain 能力可以通过这样的 Interface 进入外部，同时保留可检查的外部身份、Conversation policy、Human 决策点和结果回流记录，Agent Team 才开始从一套内部生产力系统，变成一种能够持续对外交付的组织能力。

07 CodexLoom 在织什么

现在再回头看文章开头那次意外外发，真正让我觉得有价值的，并不是“Agent 居然可以自动发消息”。

自动化并不等于 Agent Team。

如果只要按照一条预先写好的 Workflow，从第一个 Agent 运行到最后一个 Agent，就可以称作 Team，那么我们只是把原来的程序节点换成了 Agent。

这次不一样的地方在于，参与其中的是几个长期存在、拥有不同专业 Context 和责任边界的 Agent。

它们没有把所有事情都做完，而是在自己的边界停止，把下一段工作交给更合适的 Domain Owner；结果完成以后，又沿着原来的工作链路继续向前。

整个过程中，我没有站在几个 Agent 中间，亲自选择每一个下一步，复制每一段 Context，再把一个 Agent 的结果转述给另一个 Agent。

但我也没有从系统中消失。

方向、重要事实、Review、公开边界和关键授权仍然属于 Human。

Overview 让我从更高的层级观察 Team，发现哪里可能正在形成新的问题；当模型、工具、业务和外部环境变化时，我也仍然需要继续调整 Agent 的 Scope、关系和工作方法。

Human 不再是每一段工作的唯一 Router，但仍然是整支 Team 的 Owner。

这里有一组看起来矛盾、但对 Agent Team 很重要的关系：

稳定的 Agent，动态的 Team。

五条稳定 Agent thread 进入不规则 Dynamic Team surface，Human Owner 在一侧 Observe 与 Adjust，结果沿 Validate records 回到下一轮。

机制示意：稳定的是长期责任主体，动态的是当前组织假设。Human Owner 通过观察、调整和后续真实工作验证，让 Team 随模型、工具、业务和外部环境持续演化。

Agent 要足够稳定，才能在自己的 Domain 中积累经验；Team 又必须足够动态，才能适应模型、工具、业务和外部环境的变化。

稳定的是长期责任主体，动态的是当前组织假设。

所以，从 Multiple Agents 到 Agent Team，真正发生的不是 Agent 数量的变化。

而是原本全部集中在 Human 脑子里的责任、关系、交接方式、当前状态和边界，开始被逐渐外化，成为整个 Team 可以查询、使用和持续验证的工作结构。

这也是 CodexLoom 想做的事情。

Codex 已经提供了一条条非常强大的 Thread。

CodexLoom 并不是重新做一个更强的 Agent，也不是让你同时打开更多 Thread。

它希望：

让一条 Thread 成为一个长期存在的 Agent，让这个 Agent 拥有稳定的 Identity、Domain 和 Scope
让不同 Agent 能够查询彼此的 Profile 和声明关系，通过 Message 直接协作
让跨 Agent 的工作通过 Topic 保存一个由 Responsible 维护的当前版本
让 Human 在真正需要事实、选择、Review 和授权时重新进入
让 Owner 可以通过 Overview 观察 Team 的真实运行
最后，再通过受治理的 External，把内部能力带入客户、社区和协作关系

这些能力单独拿出来，都不能自动创造一支 Agent Team。

Profile 只是一份当前组织假设
Message delivered 不代表工作正确
Topic resolved 不代表所有现实结果已经完成
Overview Signal 不是 Diagnosis
Membership 不是权限或安全沙箱
External receipt 不代表对方已经阅读、接受或者产生了业务效果

真正的 Team，仍然是在持续的真实工作中形成的。

这支 Team 是否真的成立，需要继续观察几个问题：

责任是不是清楚
协作是不是有效
Human 是否仍然被迫充当唯一 Router
某个 Agent 是否正在成为瓶颈
对外行为有没有越过真实授权

所有这些，都需要在后续工作中不断验证和调整。

这不是一次性的 Reorg，而是一轮持续改善。

真实工作先让等待、返工、过载和边界冲突显露出来，Human 再做尽量小、可逆的调整，并用下一轮工作验证。

只有真正成立的改变，才继续沉淀进 Profile、Organization、Collaboration 或 Skill，成为新的工作基线。

因此，我理解的 Agent Team，不是一张静态组织图，也不是一次 Workflow 中临时拉起的多个 Agent。

它是一组长期存在的责任主体：各自在自己的 Domain 中积累经验，知道自己负责什么、在哪里停止；需要协作时能够找到彼此、直接沟通并持续收口。

由 Human 保留方向和关键边界，并且随着真实工作不断演化。

这篇文章只给出了这套工作方式的全景。

后面的文章会继续展开这些问题：

Long-running Agent 怎样在 Compaction、Memory 和 Human correction 中保持连续
Agent Team 怎样从摩擦中发现 Scope 问题、调整能力和组织
跨系统的 Agent 协议如何连接
External Interface 怎样长期治理

但至少现在，我们可以更准确地回答文章开头的问题：

最终问题

多个 Agent，什么时候才真正成为一支 Team？

不是当它们同时开始运行。

而是当它们开始长期承担不同责任，能够找到彼此、直接协作、持续收口，并在 Human 的治理下共同推进真实工作。

从一个 Codex Thread，到一支长期负责、能够协作、可以治理，也能够进入真实世界的 Agent Team。

这就是 CodexLoom。

Loom Your Codex.

本文转载自： mp.weixin.qq.com/s/ZloR4... , 如有侵权请联系管理员删除。

ColdCard 硬件签名器安全警告（2026-07-30）

Sat, 29 Aug 2026 01:11:16 +0800

作者：Coldcard

来源： https://blog.coinkite.com/coldcard-mk3-seed-generation-warning/

Coinkit 公司警告所有用户，如果你曾使用一个 Mk3 签名器在固件 4.0.1 版本（2021 年 3 月发行）到 4.1.9 版本（包含在内）上生成种子词，那么你的资金可能处在风险之中，应该尽快转移。

2026 年 7 月 31 日 12:39 p.m. 更新： 已为每一种受相同漏洞影响的款式发布修复后的固件以及版本跟踪：

Mk3：版本 4.2.0 及后续版本
Mk4/Mk5 标准版：版本 5.6.0 及后续版本
Q 标准版：版本 1.5.0Q 及后续版本
Mk4/Mk5 Edge 版：版本 6.6.0X 及后续版本
Q Edge 版：版本 6.6.0QX 及后续版本

标准版（Standard）和 Edge 版使用不同的发行版。如果你使用 Edge 版，请使用专门的 Edge 发行版。不要因为版本号数字比较大就以为旧的 Edge 6.x 版本固件是安全的。

Coinkit 公司警告所有用户，如果你曾使用一个 Mk3 签名器在固件 4.0.1 版本（2021 年 3 月发行）到 4.1.9 版本（包含在内）上生成种子词，那么你的资金可能处在风险之中，应该尽快转移。

使用 Mk4、Q 或 Mk5 在本次修复版固件以前的版本也同样受到影响，所生成的种子词只具有 72 比特的熵，而不是我们希望的 128 比特的熵。

更新固件无法改变已生成的种子词，因此也无法修复它们固有的低熵。如果你的种子词是在使用修复版本以前的固件和设备上生成的，请遵循下文的迁移指南，迁移你的资金，除非你在生成种子词时加入了自己掷骰子所生成的熵。

TAPSIGNER 卡片、OPENDIME 胶囊和 SATSCARD 卡片不受此漏洞影响，因为它们使用另一套代码基础。

本次发现的漏洞出现在 Mk3 的固件版本 4.0.1 到 4.1.9（含）上，也影响 Mk4 和 Mk5 的标准版固件 5.6.0 以前的版本，以及 Edge 版 6.6.0X 以前的版本；影响 Q 的标准版固件 1.5.0Q 以前的版本，以及 Edge 版 6.6.0QX 以前的版本。对 Mk4、Mk5、和 Q 的影响没有那么严重，但依然是相当可怕的。

如果你在生成种子词时掷了骰子

本次发现的漏洞影响的是设备生成的熵，但不会消除你通过掷骰子提供的独立熵源。

（译者注：这里的 “熵” 决定了所生成的种子词本身的随机性，也就决定了它与其他人所生成的种子词意外重合、以及被攻击者暴力搜索而发现的可能性/安全性。）

在受影响的固件上，ColdCard 会将设备生成的种子与每一次掷骰子的结果一起哈希，只要用户通过 “ Add Dice Rolls” 功能输入了骰子点数：

50 到 98 次独立、私密的骰子点数输入：光凭骰子输入就能提供至少 128 比特的熵。
99 次乃至更多次独立、私密的骰子点数输入： 骰子输入自身能提供大约 256 比特的熵。
少于 50 次骰子输入，或者你不急的自己输入多少次了： 应该遵循下列迁移指南迁移。

只要你输入了至少 50 次独立掷骰子的结果，并且这些点数没有记录下来也没暴露，我们不认为得到的种子词会因为本次发现的 RNG（随机数生成器）漏洞而处在风险之中。

请注意，这是对加入了掷骰子的熵所得到的种子词而言。如果你不确定自己所用的种子词有没有添加掷骰子的熵、输入了多少次掷骰子的结果、这些输入有没有保持秘密，那么请迁移到新的种子词。

迁移和固件状态

修复后的 Mk3 固件版本（4.2.0）已经发布。先从正式的 Mk3 下载页面安装它，再生成替换用的种子词。

版本 4.2.0 修复的新种子词的生成过程，但不会修复已经生成的种子词的低熵缺陷。

本警告反映的是我们的初步分析；研究还在继续，正式的技术报告会尽快发布。

如果你使用了 Passphrase

如果你的 Mk3 种子词有缺陷，但你使用了一个强大的、独特的 BIP-39 passphrase（密语），那么这个密语会添加一个独立的屏障。因此，风险将取决于密语自身的强度：短的、常见的、模式化的密语，或是名人名言，可能会被猜测出来，不应认为已经足够抵御风险。

这里说的是 BIP-39 密语，不是 ColdCard 本身的 PIN 码。即使你使用了强大的密语，尽快迁移到新生成的种子词也有意义。请继续保守你的密语，不要输入任何网页和你不信任的设备。

（译者注：再次提醒，本次的漏洞源于使用特定版本的固件会生成有缺陷的种子词，种子词本身可能遭遇意外重合或被暴力搜索发现，因此设备本身的 PIN 码无法提供保护。相应地，骰子输入的保护作用来自它提高的最终生成的种子词的熵；而密语的保护作用则来自生成比特币地址的私钥的过程用到了密语，而不仅仅依赖于种子词。）

如果 Mk3 是你唯一的设备

固件 4.2.0 让 Mk3 可以正确地生成种子词作为替代，所以理论上，你不需要新的 ColdCard 来迁移资金。升级签名器的固件无法修复已经生成的种子词的缺陷，因此仍需迁移。

使用一个 Mk3 建立两个钱包并完成资金的迁移，需要谨慎地在新旧两套种子词之间切换。如果有另一台设备（比如更新了修复版固件的 ColdCard），那么应该转去使用它。如果 Mk3 是你唯一的一台设备，可以这样迁移资金：

先验证有缺陷的种子词的写下来的备份和钱包指纹。
为 Mk3 安装 4.2.0 乃至更新版本的固件并确认版本。
在清空的 Mk3 上，生成新的种子词。记录下种子词（即备份）、钱包指纹和一个收款地址，并验证它们。
在 Mk3 上复原有缺陷的种子词，并发送一笔小额的测试交易到新钱包的地址。
复原新的种子词，确认钱包指纹以及收到了测试款项。
复原有权限的种子词，将剩余资金发送到新钱包。
复原新种子，确认迁移完成。不要急着销毁旧的办法，要等到全部余额都已到达新钱包。

修复版固件的设备生成的种子词已经有足够的上。可以加入摘骰子的结果，但并非解决本次发现的问题的必要措施。BIP-39 密语是一个另外的钱包安全性选择；如果使用了密语，请务必备份密语，并且不要跟种子词备份放在一起。

（译者注：鉴于 ColdCard 面市的所有型号都受此漏洞影响，任何使用 ColdCard 签名器生成种子词的单签名钱包用户都应考虑生成新种子词并迁移资金。尤其是使用 Mk3 的单签名钱包用户，甚至可以考虑先迁移到软件钱包生成的钱包，再更新 Mk3 的固件、生成安全的种子词，再将资金迁移到新种子词。这样虽然会多花一些手续费，但比较容易操作。）

在 Mk 3 上使用骰子生成新种子词

在升级到 4.2.0 版本后，对自己的能力有自信的用户可以不使用设备的随机数生成器、只用掷骰子生成一个新的替换用种子词，然后迁移资金。这并非严格必要，因为在 4.2.0 中，普通的 New Wallet （新钱包）流程已经是正确的了。

在清空的 Mk3 上使用 4.2.0 版本固件，选择 Import Existing > Dice Rolls（导入已有种子词 > 晒骰子），然后输入至少 99 次独立摘骰子的结果，需要使用非常均匀的 6 面骰子。这个专门用于骰子生成种子词（不使用设备熵源）的流程会直接哈希完整的骰子点数序列。

这是一种需要技能的流程。仅使用骰子生成种子词，依然需要安全地在两套种子词之间切换，才能完成迁移。在擦除 Mk3 存储的任何种子词之前，要验证写下来的备份和 XFP；记录新钱包的一个收款地址后，恢复并验证旧钱包，发送小额测试交易，然后再全面迁移资金。保留旧钱包的备份，直到所有资金都完成迁移。

如果使用这套流程，则骰子点数序列本身成了死要材料。绝对不要拍照、不要保存为电子文档，也不要输入联网的计算机。在尝试这个选项之前，请阅读 COLDCARD 骰子方法指南。

谨慎迁移

在迁移到新钱包时，务必保持冷静和谨慎。鲁莽地迁移钱包可能立即给你带来危险，而不是帮你解决问题。

在以下各款式及相应固件上生成的种子词，除非加入了独立且充足的骰子熵，都有风险：

Mk3 的固件版本 4.0.1 到 4.1.9（含）；
Mk4 和 Mk5 的标准版固件 5.6.0 以前的版本，以及 Edge 版 6.6.0X 以前的版本；
Q 的标准版固件 1.5.0Q 以前的版本，以及 Edge 版 6.6.0QX 以前的版本。

在生成替换用的种子词之前，先升级到修复版本的固件：

Mk3 升级到 4.2.0 或更新版本；
Mk4 和 Mk5 标准版升级到 5.6.0 或更新版本；
- Edge 版升级到 6.6.0X 或更新版本；
Q 标准版升级到 1.5.0Q 或更新版本；
- Edge 版升级到 6.6.0QX 或更新版本。

然后：

确认已安装了修复版本的固件。
在升级后的 ColdCard 上生成新的种子词。
记录并验证新种子词的备份。
在 ColdCard 屏幕上验证新钱包的一个收款地址。
向新钱包发送一个小额测试交易，确认新钱包是安全的。
测试交易确认后再迁移剩余资金。
保留旧钱包的备份，直到迁移完成。

我们会继续研究此次发现的漏洞。更多细节将会披露。

本文转载自： btcstudy.org/2026/08/01/... , 如有侵权请联系管理员删除。

新链上没有 Gas？如何带着可用的 ETH 抵达

Sat, 29 Aug 2026 01:11:16 +0800

TL;DR

你将 USDC 跨链到一条新链，余额显示出来了，但之后什么也做不了：你没有该链的原生代币，所以无法为任何操作支付 gas。
解决办法是指定你希望在目标链上收到什么。通过 Across Swap API，你可以设置输出代币和最小输出金额，这个输出可以是目标链的原生 gas 代币。
你到达时钱包里已经有 gas，所以第一次尝试就能顺利批准 swap、mint 或 stake，而不用到处找水龙头，也无需再发送第二笔转账。
Across 在约 2 秒内完成大多数路由的填充，覆盖 20 多条链；relayer 垫付资金，结算由 UMA 的 Optimistic Oracle 处理。
一些链从自身角度解决同样的问题：Plasma，一个专注于稳定币的 L1，运行协议级 paymaster，让用户可以用 USDT 支付 gas。
使用 Across 跨链

你将 200 USDC 跨链到一条从未使用过的链。转账确认后，钱包显示了余额，接着你想把其中一部分 swap 成其他资产。钱包要求你先批准该代币。你点击批准，交易在广播前就失败了：gas 不足。你有 200 美元在链上，却一分都动不了，因为任何操作都需要该链的原生代币来支付交易费用，而你一个都没有。

这就是冷启动 gas 问题。它是首次跨链到新链时最常见的失败方式，也是一个鸡生蛋、蛋生鸡的困局：你需要原生代币才能进行任何操作，包括获取原生代币本身。但这个问题也是可以避免的。解决办法是，到达时就已经持有 gas。

这个困局是结构性的，不是你的错

EVM 链上的每笔交易都要消耗 gas，而 gas 总是以该链的原生代币支付。Arbitrum 和 Base 以 ETH 作为 gas，Polygon 以 POL 作为 gas。稳定币余额无论有多少，都无法支付自身的转账费用——这笔费用只能来自原生资产。

当你把 USDC 这样的单一资产跨链到一条没有其他任何资产的链时，你会发现，你恰好差一个代币，结果什么也做不了。你无法 swap，因为 swap 需要授权，而授权需要 gas。你无法把 USDC 转回去，因为转账同样需要 gas。资金就在那里，却被困住了。唯一的出路是再发起一笔跨链转账，获取一点原生代币，或者找水龙头，或者请人借你几美分的 gas。这些都是在你以为已经搞定之后才会遇到的摩擦。

把原生代币设为输出，到达时即可持有

更干净的答案是：在转移资产的同一笔跨链转账中，同时收到该链的 gas 代币。Across 围绕意图（intent）构建。你声明在目标链上想要的结果，协议负责交付。gas 问题正是在这个声明环节得到解决。

Across Swap API 接受来源链上的输入代币，以及目标链上的输出代币和最小输出金额。推荐的交易类型是 minOutput，意思是“我希望在目标链上至少收到这么多”，API 会反向计算所需的输入。你指定的输出代币不必与输入代币一致。它可以就是目标链的原生代币。

把输出代币设置为该链的原生 gas 代币，那么到账的就是它。你到达时手里就有可用的 gas，随时可以交易，无需单独的充值步骤。冷启动困局根本没有机会形成，因为你在新链上收到的第一样东西，就是之后每一笔交易都需要的资产。

relayer 会垫付目标链上的资金，并在主网上约 2 秒内即可完成路由填充。gas 与其余余额到账的速度一样快。结算随后通过 UMA 的 Optimistic Oracle 完成：一旦存款通过验证，relayer 就会获得报销。Across 自 2021 年以来一直运行这一模式，覆盖 20 多条链，从未发生过用户资金损失。

如何带着 gas 到达，分步指南

无论你使用网页应用还是直接调用 API，流程都是一样的。

选择你的来源链和要发送的代币，例如 Arbitrum 上的 USDC。
选择你的目标链，并将输出代币设置为该链的原生 gas 代币，例如 Base 上的 ETH。
选择最小输出金额。通常，能覆盖你最初几笔交易的原生代币数量，就绰绰有余了。
确认报价：签名前会显示预计的填充时间和费用。
在来源链上签署存款交易。relayer 会在约 2 秒内将原生代币送达目标链，随后你就可以开始操作了。

如果你希望资产分两部分到账，可以这样设置转账：一部分余额以你持有的资产形式到账，另一部分以 gas 形式到账。关键在于，gas 是你决定接收的东西，而不是事后才去凑的东西。

一些链从自身角度解决这个问题

带着 gas 到达是路由层面的解决方案，适用于 Across 支持的任何链。少数链则在协议层面解决同样的问题。Plasma，一个专注于稳定币的 L1，运行内置的 paymaster，用户可以用 USDT 支付 gas，简单的 USDT 转账也零费用。因此，持有者完全无需接触单独的 gas 代币，就能转移稳定币余额。这是链侧而非桥侧给出的关于冷启动问题的答案，两者可以很好地组合：如果你希望拥有完整的操作空间，依然可以带着该链的原生代币到达。

到达后可以做什么

到达时钱包里已有 gas，新链上的第一笔交易，就只是一笔普通交易。批准代币并 swap；存入借贷市场；mint、stake 或 claim。任何操作都不会因为缺少费用资产而无法进行，你也不用回到来源链去凑几美分。

对于开发者来说，同样的机制还可以进一步扩展。Across 通过 MulticallHandler 支持嵌入式跨链操作：一笔转账可以先让原生代币到账，然后在同一流程中执行后续操作。这意味着应用可以在同一个流程中，同时处理好用户在新链上的 gas 和第一笔操作。

冷启动 gas 问题之所以存在，是因为人们把 gas 当作到达之后才需要解决的事情。把原生代币指定为你要接收的资产的一部分，就再没有什么需要解决的了。

使用 Across 跨链

原文链接： across.to/blog/no-gas-on...

鸿途知科网 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

黑盒AI代码正成为一项责任：为什么溯源是下一个合规层

Sat, 29 Aug 2026 01:11:15 +0800

在软件发展历史的大部分时间里，问责是隐性的。代码由人编写、由人理解，一旦出了问题，人也能够解释它为什么会这样做。从一行代码追溯到某个决策、某个人的脉络始终存在，即便从来没有人把它写下来。

AI 悄无声息地打破了这种状况。当代码库的大部分内容由模型生成时，那条隐含的脉络便消失了。大部分代码并非出自人手，也没有人能完全理解全部代码。当监管者、审计员或法院问起"为什么这段代码会这样做？是谁批准的？"时，诚实的回答越来越多地变成"我们也不确定"。这不是技术差距，而是责任风险。

解决之道不是停止使用 AI，而是让 AI 生成的代码有意地变得可追溯。Provenance（溯源）——一份可验证的记录，标明某次变更满足了哪份 spec、由哪个模型生成、由哪位真人审核接受——正在成为下一个合规层。现在就开始构建它的团队，将能把 AI 代码送入受监管的市场；不构建的团队，则只能困于解释自己都无法交代的代码。

是什么让黑盒 AI 代码成为责任？

黑盒 AI 代码，是指那些能正常运行、却没人能完全解释、也无法追溯到具体决策和所有者的代码。当这样的代码出现故障、违反规则或造成伤害时，你无法说明它为什么会这样运行、它本来应该做什么、又是谁批准放行的。监管者要求可追溯性，这构成法律责任；你无法推理自己不理解的代码，这构成安全责任；没人能理解的系统将变得无法安全地修改，这构成运营责任。

危险不在于 AI 写出有缺陷的代码，而在于 AI 大规模地产出不透明的代码——正是这种不透明，把小 bug 变成了无法回答的问题。

当一个人手写某个函数时，背后有你可以还原的意图；而当模型根据一段早已不存在的 prompt 生成它、又在匆忙中被审查通过时，意图便消失了。把这种情况放大到整个代码库，你得到的就是这样的系统：一直正常工作，直到某一天忽然不行了，而在它崩溃之后，没有人能自信地解释原因。

监管者已经注意到了，法院也是如此。"是 AI 干的"这类辩护正在被堵死，举证责任转移到了部署系统的一方，要求他们证明系统本应做什么、由谁负责。没有记录，你就无法满足这样的举证要求。

代码溯源到底是什么？

代码溯源，是一份附加到每个 AI 生成变更上的可验证记录，回答它从何而来、由谁负责。一份最小可用的记录应包含：该变更所满足的 spec 版本、生成它的模型与提供商、产生它的 prompt 或任务、审查并接受它的人，以及它通过的测试。它把一段匿名的生成代码，变成了一件拥有清晰谱系与明确所有者的可审计产物。

溯源，说到底就是把"这段代码从哪里来"的答案，以日后可以验证的方式写下来。

真正有用的溯源是具体的。对于 agent 产生的每一个变更，你都要记录：它为满足哪份 spec 而构建、编写它的确切模型与提供商、触发它的任务、接受它的人，以及它通过的检查项。这五个事实，随变更一并留存。

只要捕获得当，溯源就不是最后才额外补上的工作。在 spec 驱动、审查把关的工作流中，这些事实在每个交接节点上本就存在。你只需把它们发出来并保存下来，记录便会作为现有开发流程的副产品自然累积。

为什么溯源正在成为合规要求？

因为法规正在要求 AI 系统具备可追溯性，而代码正是系统的一部分。欧盟《AI 法案》的高风险义务自 2026 年 8 月 2 日起生效，要求系统具备防篡改的审计追踪、记录输入与决策、留存记录，并内建人类监督。文档是监管者首先检查的对象。产品责任规则正越来越多地把软件和 AI 视为产品并适用严格责任，而新近的法律也禁止以系统的自主性作为抗辩理由。溯源，就是你拿出这些法规假定你本应握有的证据的途径。

到了 2026 年，这已不再是纸上谈兵。

欧盟《AI 法案》的主要高风险义务将于 2026 年 8 月 2 日起正式执行，而这些义务正是围绕可追溯性展开的。系统必须生成相关事件的审计追踪，记录足以还原行为的信息，保留这些记录，并具备一开始就设计在内、而非事后补加的人类监督。关键在于，文档是监管者首先检查的对象；只有当文档记录不足以说明问题时，才会触发更深入的检查。如果你的 AI 生成代码没有文档化的谱系，那么你的文档记录从一开始就是不合格的。

责任层面的变化进一步强化了这一点。软件和 AI 正越来越多地被视作可能存在缺陷的产品，由此打开了严格责任的风险敞口；同时，新法律也堵死了把责任归咎于系统自主性的选项。在这样的环境中，能够证明某次变更满足了哪份 spec、由谁批准的团队，是有防御能力的；做不到的团队，则完全暴露在风险之中。溯源，正是这些规则假定你早已维护好的证据层。

实践中如何捕获溯源？

在工作流的每一个环节发出溯源记录，并让它成为变更本身的一部分。生成一条包含 spec、模型、任务、审查者和测试的结构化记录，把它附加到提交上，最好再签名使其防篡改。然后以"记录是否存在"作为合并的门槛，让没有谱系的 AI 生成变更根本无法落地。由于这些事实在 spec 驱动、经过审查的流程中早已存在，溯源便成为流水线自动产出的结果，而非事后手工补写的文书。

一旦你认定这条记录必不可少，具体操作其实非常简单。

首先，定义记录——它是整个机制赖以运转的核心构件。

{
  "change": "a3f9c21",
  "spec": "specs/payments.md@v4",
  "generatedBy": { "model": "claude-opus-4-x", "provider": "anthropic" },
  "task": "implement idempotent refund handler per payments spec",
  "reviewedBy": "engineer:jdoe",
  "testsPassed": ["refund.idempotency", "refund.authz", "refund.limits"],
  "timestamp": "2026-06-29T10:14:00Z"
}

其次，把它绑定到变更之上，并使其防篡改。将记录附加到提交并签名，使谱系在事后无法被悄悄改动。

## 将溯源附加到提交并签署证明
git commit --trailer "Provenance: $(sha256sum provenance.json | cut -d' ' -f1)"
cosign attest --predicate provenance.json --key cosign.key "$ARTIFACT"

第三，让它成为强制要求。用一道 CI 关卡拦截任何缺少完整有效溯源记录的变更，把这项实践从"愿望"变成"现实"。

## 没有完整有效谱系的 AI 生成变更不得合并
- run: provctl validate provenance.json --require spec,model,reviewer,tests
- run: provctl verify-signature provenance.json --key cosign.pub

这就是完整的闭环：定义记录，绑定并签名，强制执行。只要做一次，之后每一个变更都会自带可问责的记录。

为什么溯源也是一种安全控制？

因为溯源就是 AI 生成代码的供应链完整性保障。它精确地告诉你每一份产物由什么生成、依赖了什么，这正是你发现幻觉（hallucination）或恶意依赖、把漏洞归因到引入它的那次变更和那个模型、并证明代码在审查后未被篡改的方法。防篡改的签名谱系，同时就是你的事件响应线索：一旦出了问题，你可以在几分钟内——而不是几天内——追溯到确切的变更、spec、审查者和测试。

溯源与安全，其实是同一件事的两个视角。

一份签名记录，写明了某个变更由什么生成、引入了什么依赖，这正是 AI 时代捍卫软件供应链所必需的。它让你注意到模型凭空发明的陌生依赖，让你把漏洞追溯到引入它的那一次具体生成，也让你证明交付上线的正是审查通过、未被篡改的内容。

当事故发生时，这份记录是你最快控制局面的路径。你无需在成千上万个 AI 生成的变更中猜测究竟是哪一个造成的，只需查询谱系，就能找到对应的变更、它声称满足的 spec、生成它的模型，以及批准它的人。溯源让"我们正在调查"变成"我们已经知道"。

为什么溯源是竞争优势，而不只是成本？

因为合规正在成为采购的硬性要求，而溯源正是让你通过筛选的东西。金融、医疗、政府和关键基础设施领域的受监管买家，在签约之前会越来越多地要求你拿出证据，说明 AI 生成代码是如何生产、如何被管控的。能够按需出示签名谱系的团队可以赢得订单，做不到的团队连门都进不去。尽早构建，溯源就不再是额外成本，而会成为一座护城河：它是信任的证明，为你打开那些对仍在交付黑盒代码的人紧闭着的市场。

本能的反应是把溯源当成一种税负；而走在前面的团队，则把它当成打开市场的渠道。

随着 AI 生成代码进入受监管的系统，这些软件的买家自身也要向监管机构负责，于是他们会把同样的要求传导给你。采购环节的问题就变成了："给我们看看，这段代码是如何生产、如何治理的？"一份干净且签名完整的谱系，就是"可以"；沉默，则意味着出局。

这就是"合规即优势"的关键一招：你为满足监管而建立的纪律，最终成为赢得合同的资质。当竞争对手还在争相拼凑一份并不存在的文档记录时，你已经交出审计材料，直接进入签约阶段。早期构建的溯源不是成本中心，而是你能够留在牌桌上的原因。

团队应该从哪里开始？

从把溯源设为 AI 生成代码的一项强制且自动的要求开始。定义最小记录项：spec、模型、任务、审查者和测试；在 spec 驱动、审查把关的工作流的每一个交接点自动发出它，让记录随之自然累积；为它签名以防篡改，并以它的存在作为合并的门槛；按你所属监管框架的要求留存记录；然后把这份谱系同时用作合规证据和事件响应线索。

以下是一份可供起步的简短清单：

你是否为每一个 AI 生成的变更，都定义了包含 spec、模型与提供商、任务、审查者和测试在内的最小溯源记录？
这条记录是否由工作流自动生成，而不是事后手工补写？
记录是否已附加到变更并经过签名，使谱系无法被篡改？
CI 是否会拦截任何缺少完整有效溯源记录的 AI 生成变更？
记录是否留存了足够长的时间以满足你所处监管体系的要求，并支持审计导出？
今天，你是否能把任何已上线的变更，追溯到它的 spec、模型、审查者，以及它通过的测试？

如果这份清单你能全部回答"是"，那么你的 AI 生成代码就是可辩护的：对监管者可解释、在事故中可追溯、对买家可证明。如果连最后一个问题都答不上来，那你就是在交付黑盒代码——责任已经在不断累积。

让你的 AI 代码为自己作答

这个时代令人不安的转变在于，我们现在交付的代码数量庞大，却没有任何单个人写过、也没有任何单个人能完全理解。这一趋势不会逆转。可以改变的，是这些代码能否为自己作出解释。

黑盒 AI 代码之所以是责任，恰恰因为它做不到这一点。它能正常工作，直到有一天被质疑，然后就再也没有任何东西可以指认。溯源，就是用一条显式的、实际上更好的线索，去取代被 AI 抹去的那条隐含线索：它经过签名、可以查询、内容完整——这是人类记忆永远无法做到的。

法规正在落地，责任真实存在，买家也开始发问。那些把溯源视为下一个合规层、并将其内建到代码生成流程中（而不是事后补救）的团队，将把义务转化为优势。在一个 AI 撰写代码的世界里，能够证明代码的来龙去脉，不是官僚主义，而是"可信代码"的新定义。

构建溯源层——这条让 AI 生成代码可解释、可追溯、合规的签名谱系——正是把监管负担转化为竞争优势的治理工作。而这，正是我们在做的事。

原文链接： medium.com/@ancilartech/...

鸿途知科网 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

COLDCARD 熵漏洞专业复盘：卷走 3800 万美元的随机数缺陷

Sat, 29 Aug 2026 01:11:15 +0800

以下内容由 OneKey 安全实验室 @OneKey_Anzen 撰写校对完成，英文原文见评论。

在密码学里，“随机”是一个可以量化、经得起算力检验的硬指标。

一套 12 个词的助记词，背后是一串 128 位的随机数，按 BIP-39 规范编码成一组人能读写的单词。这串数字的不可预测程度，直接决定钱包能不能扛住暴力破解。128 位意味着 $2^{128}$ 种可能——把全世界的算力加在一起，穷举到宇宙消失也跑不完。

所以硬件钱包理论上应该在这件事上很严谨：必须要有专门处理随机数生成的真随机数发生器单元（TRNG），从电路噪声里取物理世界的随机，再配一颗过了 EAL 认证的安全元件（SE），最后用成熟的算法把这些随机搅匀。

2026 年 7 月 30 日，约 594 枚比特币（约 3800 万美元）在不到半小时内，从近 500 个 COLDCARD 钱包里被席卷一空。次日，厂商 Coinkite 在《Technical Deep Dive into the Entropy Issue》中确认了根源[1]：自 2021 年 3 月的一次固件改动起，一处编译配置错误让代码悄悄回退到了 MicroPython 自带的软件伪随机数生成器（PRNG）。

后果按型号不同：官方初步估计，Mk3 的有效搜索空间只剩约 40 位，Mk4、Mk5 和 Q 约 72 位，而设计目标是 128 位。40 位约等于 1.1 万亿种可能，听起来仍是天文数字，但对一个租得起 GPU 集群的攻击者来说，它已经从“物理上不可能”，降级为一个数学期望上可行的工程项目。从 128 到 40，搜索空间缩小了 $2^{88}$ 倍——三百亿亿亿倍。

这次 3800 万美元的失窃，把风险变成了既成事实。

注：OneKey 用户的资金是安全的，OneKey 的所有代码均不涉及相关问题，也不使用其相关实现和依赖。详见声明： https://x.com/OneKeyCN/status/2083104424764018990?s=20

太长不看？结论

使用 COLDCARD Mk3 生成助记词并使用的用户，立刻在其他钱包重新生成助记词并逐步转移资金到新钱包
使用 COLDCARD Mk4 或 Mk5 生成助记词并使用的用户，如果生成初始助记词的系统版本低于 5.6.0，立刻在其他钱包重新生成助记词并逐步转移资金到新钱包
使用 COLDCARD Q 生成助记词并使用的用户，如果生成初始助记词的系统版本低于 1.5.0Q，立刻在其他钱包重新生成助记词并逐步转移资金到新钱包
使用 OneKey 硬件钱包的用户，都不受同样的漏洞困扰，可以放心使用

漏洞根因：一次静默的软件回退

从硬件 RNG 接口迁移到 libNgU

2021 年的加密栈迁移将钱包种子生成从 ckcc.rng_bytes() 改为 ngu.random.bytes()[6]：

ngu.random.bytes() -> libNgU rng_get() -> 最终链接到的 rng_get 符号

风险不在函数名或输出长度，而在最后一个 rng_get() 实际由哪个目标文件提供。#ifndef 只检查“有没有定义”，不检查值。

目标板配置把 MICROPY_HW_ENABLE_RNG 定义为 0，表示 MicroPython 的硬件 RNG 路径未启用。但 libNgU 当时使用[8]：

#ifndef MICROPY_HW_ENABLE_RNG
#error ...
#endif

#ifndef 只判断宏是否存在。一个被定义为 0 的宏依然是“已定义”，所以预期用于阻止错误构建的 #error 没有触发。

同名符号让错误实现静默进入最终固件

MicroPython 在硬件 RNG 未启用时仍提供同名 rng_get()，但它是 Yasmarang 软件 PRNG fallback[9]。于是发生了完整的失败链：

宏存在但值为 0
libNgU 的构建保护未触发
固件仍能成功编译
同名 rng_get 解析到 MicroPython fallback
钱包建种没有获得预期硬件 RNG 输入

这条链上每一环单独看都只是小疏忽，连起来却让整个构建系统的把关形同虚设：安全实现即使存在于源码或二进制中，也不代表安全关键调用真正到达了它。

混合熵源补不回缺失的熵

fallback 初态涉及 UID 的一部分、SysTick、RTC 时间和子秒状态，之后由 Yasmarang 确定性推进。libNgU 还将其与另一个固定初态的 Yasmarang 流混合。两个可重建或枚举的确定性流，经过异或或 SHA-256 后仍不会获得新的物理不可预测性。哈希可以调理输入，却不能把有限候选集合扩展为真正的 $2^{256}$ 未知空间。

40 位和 72 位到底意味着什么

Coinkite 使用的有效搜索空间估计，并非经过测量和认证的熵值。这两个数字描述的是攻击者需要遍历的候选状态规模，它不是 min-entropy 的实测结果，也换算不出平均搜索次数，更推不出具体的攻击时间和成本。

实际攻击成本取决于一连串前提：攻击者是否知道或能推测设备 UID，能否收窄 RTC、SysTick 和启动时间的范围，种子生成前发生过多少次 RNG 调用，手上有没有 xpub、地址或公钥可以离线验证候选，以及 BIP-39/BIP-32 派生和并行硬件要花多少钱。

所以准确的说法是：Coinkite 在当前初步攻击假设下，估计 Mk3 的有效搜索空间约为 40 位，Mk4/Q/Mk5 约为 72 位。这不等于“每个 Mk3 钱包恰好只有 40 位熵”，不等于“较新型号经过证明拥有 72 位密码学安全性”，更不等于“任何普通电脑都能在固定时间内恢复所有钱包”。

为什么 Mk4、Mk5 和 Q 也受影响

Mk5 与 Q 电路板上的两颗安全元件（来源：coldcard.com）

Mk4、Mk5 和 Q 的确会从两个安全元件取得随机材料，但修复前的实现并没有把全部输出注入一个密码学 DRBG。公开源码显示，它把安全元件材料哈希后，只取四字节传给 ngu.random.reseed()，并仅替换 Yasmarang 的一个 32 位状态字。因此，在 fallback 其余状态和调用轨迹固定时：

由安全元件 reseed 区分的输出流数量 $\le 2^{32}$

这与官方“约 72 位”并不矛盾。72 位模型还计入 UID、计时器、RTC 和调用历史等状态的不确定性。Block Engineering 给出的宽松组合上界低于 $2^{73.3}$，并明确指出这不等于 73 位密码学安全认证[10]。

换句话说：Mk3 的问题最严重，因为没有安全 reseed；Mk4/Q/Mk5 的安全元件输入降低了风险，但四字节 reseed 没有恢复设计目标中的 128 位安全性。

官方公告与实际影响范围

Coinkite 当前正式警告从 Mk3 4.0.1 开始。但 v4.0.0 的不可变源码已经包含相关建熵生成路径[7]，4.0.0 到 4.0.1 之间也没有对应的 RNG 修复。Block Engineering 进一步将 Mk2/Mk3 v4.0.0–v4.1.9 一并纳入源码分析[10]。

因此需要区分两层：

Coinkite 正式范围：Mk3 4.0.1+；
源码能够支持的技术范围：Mk2/Mk3 v4.0.0–v4.1.9。

不能说 Coinkite 已经正式确认 Mk2 或 v4.0.0，但也不能因为官方没有点名就推断它们安全。

修复如何工作

Mk4/Mk5 5.6.0 和 Q 1.5.0Q 的热修复不止修改了一个条件表达式，还增加了构建级强制保证[3][4][5]：

排除 MicroPython 的 fallback RNG object；
确保板级对象提供全局 rng_get()；
使用 nm 检查目标文件的符号；
如果 fallback 仍导出符号，或板级对象没有正确提供 rng_get()，构建直接失败。

用户应该如何处置

Mk4、Mk5 和 Q

Mk4/Mk5 先升级到 5.6.0 或更高版本；Q 先升级到 1.5.0Q 或更高版本。
在修复后的固件中生成全新种子。
记录并完成备份恢复验证。
在设备屏幕核对钱包 fingerprint 和接收地址。
先进行小额测试交易，再迁移其余资金。
在全部迁移确认前保留旧备份，但不要继续向旧钱包收款。

Mk3

Mk3 当前没有已发布的修复固件，4.1.9 不是修复。用户不应等待未来可能出现的固件，因为任何新固件都无法增加旧种子的熵。按照 Coinkite 当前迁移指引，在可信路径生成新种子，完成备份、地址和小额交易验证后迁移资产。

两个不同的骰子阈值

关于骰子有两个数字：50 和 99。它们服务于两个不同的目标，不能混用。

原始建种时加入 50+ 次骰子。 如果种子最初生成时加入了至少 50 次公平、独立、私密、未记录或保存且未泄露的六面骰结果，Coinkite 表示不认为该种子仅因本 RNG 问题而处于风险[11]。

$$ 50 \times \log_2(6) \approx 129.25 \text{ bits} $$

这是针对本事件的约 128 位门槛，不是整个操作流程的绝对安全证明。

空白 Mk3 的 Dice Roll Import 流程。 Coinkite 还提供一个不同流程：在空白 Mk3 4.1.9 上选择 Import Existing > Dice Rolls，并输入至少 99 次公平掷骰。该专用路径直接处理骰子序列，不使用有问题的设备生成器。

$$ 99 \times \log_2(6) \approx 255.91 \text{ bits} $$

99 次是官方流程的门槛；如果按“至少 256 位”的字面标准倒推，则需要 100 次。

Passphrase 是独立屏障，不是修复

强、唯一、随机且保密的 BIP-39 passphrase 会派生一个不同钱包，可以增加独立搜索因子；设备 PIN 只控制本地访问，不参与 BIP-39 根密钥派生[12]。但 passphrase 不能补回助记词缺失的熵。短口令、名言、规律模式或复用口令仍可能被猜中。输入错误也会生成一个看似有效但完全不同的钱包，因此必须验证 fingerprint，并建立可靠、经过恢复测试的备份。

结语

这起事件暴露的核心问题，是安全关键实现的实际可达性没有被构建系统强制验证——“一个宏写错了”远不足以概括它。

硬件钱包和其他密钥生成系统至少应做到：

安全 API 验证最终链接到的 object 和 symbol，而不只检查函数签名；
能力检查同时验证宏的存在和值；
安全关键 fallback 必须 fail closed，不能静默提供普通 PRNG；
CI 检查 object composition、link map、符号来源和端到端数据流；
测试证明真实硬件熵进入最终种子，而不只是检查输出长度、非零或无重复；
公告明确区分生成版本、当前固件、修复版本和旧种子处置。

参考链接

Coinkite：Technical Deep Dive into the Entropy Issue
Coinkite：Mk3 Security Advisory
Coldcard 5.6.0 / 1.5.0Q 修复提交
Coldcard 5.6.0 release commit
Coldcard 1.5.0Q release commit
2021 libNgU 建种迁移提交
正式 v4.0.0 源码快照
libNgU random.c
MicroPython fallback 引入提交
Block Engineering 技术分析
Coldcard 骰子说明
Coldcard Passphrase 说明
OneKey trezorcrypto.random source 分支
OneKey 建种逻辑
OneKey 标准 Makefile
OneKey SCons

本文转载自： x.com/onekeycn/status/20... , 如有侵权请联系管理员删除。

当 random.bytes() 运行却失效时

Sat, 29 Aug 2026 01:11:14 +0800

bitcoin++ 是一个国际性的 bitcoin 开发者会议系列。“Insider Edition” 是我们的新闻编辑室，报道 bitcoin++ 世界内外正在发生的事情。

OpEd

当 random.bytes() 运行了却没有生效

一条 commit message 能告诉我们的关于最近 COLDCARD bug 的内容

本文来自知名 Core-Lightning 开发者 ddustin ，他深入研究了 Coldcard 固件的 commit 历史，以揭示发生了什么以及代码为何失败。

引言

我开始调查 Coldcard 黑客事件，并立即感到震惊。我需要解释为什么。

当我们开发者处理代码时，我们会把代码变更组织成我们称之为 “commits” 的变更集。这样做的目的是为了清晰地展示代码被修改的历史，包括为什么和怎么修改的。

这恰恰是为了此类情况而做的：当看起来 Bitcoiners 的资金正被大规模盗取时，我们可以调查并确切理解它是如何发生的。

优秀的开发者会编写清晰的 commit message，即伴随代码更改的文字说明，解释具体更改在实现什么。

要写出清晰的 commit message，通常你会希望该 commit 代表一次较小的代码更改，这样需要注释的内容就较少。

作为开发者，一个好的目标是让 commit message 与代码更改的比值保持较高。你更改的代码行数越多，就需要越多的注释来解释你为什么要改这些代码。每个 commit 包含更多的说明和更少的代码更改通常是个好主意。

这里有一个例子，随机选自我自己的一些工作。

这条 commit message 有 235 个字符，而这个 commit 更改了 15 行代码。比值为 235/15 = ~16。

在 Coldcard 中，引入低熵 bug 的 commit 在这里。

这条 commit message 只有 5 个字符，就是单词 “runs”。该 commit 更改了 1534 行代码，比值为 5/1534 = ~0.003。

这是一个糟糕透顶的 comment 与代码更改比值。

在少数情况下，低 comment 比值是可以接受的——但更改代码中最重要的部分绝不在此列！

涉及项目安全关键函数的代码，需要更高的 comments 与更改比值，以及更严格的审查。

导致 Coldcard 弱熵问题的第二个 commit 在这里。

这条 commit message 只有 1 个字符：就是字符 “x”。该 commit 更改了约 1000 行代码，比值为 1/1000 = ~0.001。

问题

在标题为 “runs” 的 commit（比值：~0.003）中，看起来他们正在导入并配置 C 代码，以使自定义 micropython 代码能在 STM32 上运行，STM32 是所有 Coldcards 运行所用的板子。

STM32 是此类小型设备最常见的 CPU，而这个 commit 引入的那种配置也很常见。

在 ‘runs’ commit 中，硬件 RNG（Random Number Generation，随机数生成）通过以下代码行被禁用。

#define MICROPY_HW_ENABLE_RNG (0)

这就是导致 bug 的原因。将此值设为零会告诉默认的 micropython rng 代码不要使用硬件 RNG 设备，而是应该使用 Yasmarang RNG。

开发者添加了一个内联注释来“解释”这一更改

// We have our own version of this code.

COLDCARD 对这个代码的版本似乎指的是 rng.h 和 rng.c 中添加的函数。

rng.h

MP_DECLARE_CONST_FUN_OBJ_0(pyb_rng_get_obj);

MP_DECLARE_CONST_FUN_OBJ_1(pyb_rng_get_bytes_obj);

这些看起来是尝试覆盖 stm32 rng 库的 pyb_rng_getobj 函数。这种方法遇到了问题。stm32 的 rng.c 文件已经定义了 pyb_rng_et_obj 变量，并将其值设置为 pyb_mg_get。你不能让同一个变量有两个定义，还要指望它能编译通过。

为了更清楚地理解，这个宏展开后的结果如下。

MP_DEFINE_CONST_FUN_OBJ_0(pyb_rng_get_obj, pyb_rng_get);

展开宏并从逻辑上思考，它就是这个伪代码：

var pyb_rng_get_obj = pyb_rng_get

Commit 37e4af5 添加了一个自定义的 rng.c 文件，他在这里复制粘贴了相同的宏定义

MP_DEFINE_CONST_FUN_OBJ_0(pyb_rng_get_obj, pyb_rng_get);

现在这段代码根本不可能编译通过。看起来开发者天真地想通过创建变量的重复版本来覆盖 pyb_rng_get_obj 变量。C 不是这样工作的。这个错误会给他一个编译错误：“duplicate symbol pyb_rng_get_obj”，因为它现在有两个定义位置：stm32 库和新建的 rng.c 文件。

从这里开始，我猜测他在一阵沮丧中将 MICROPY_HW_ENABLE_RNG 设为 0，这解决了编译错误。

有时开发者在挣扎中会乱试一些随机的东西，看看是否有用。把 MICROPY_HW_ENABLE_RNG 设为 0 确实会让编译错误消失，但因为错误的原因。

这掩盖了两个冲突定义引发的编译错误。

// 我们有自己的这个代码的版本。
#define MICROPY_HW_ENABLE_RNG       (0)

将 MICROPY_HW_ENABLE_RNG 设为零会完全移除使用硬件随机数生成器的代码，即 stm32 的 rng.c 文件中的第 31 到 80 行。这产生了移除 pyb_rng_get_obj 第二个定义的副作用，从而“修复”了编译错误。

那个编译错误是在恳求程序员重新考虑他的逻辑。但这一切没有发生，编译错误只是被压制了。编译器给了开发者最后一次机会去重新考虑他即将要做的事，但这个警报被无视并压制了。

现在一切都对上了。看起来开发者试图覆盖这个变量，却遇到了冲突定义。当面对“duplicate symbol”错误时，他试图修改一些随机的东西来让代码**运行**。

他发现把 MICROPY_HW_ENABLE_RNG 改为 0 可以编译通过。他可能不知道原因，但提出了一个理论：我们不再需要那段代码了，因为我们自己有一个版本。

他对 pyb_rng_get 的定义已经就位，而他本来不想运行的代码已经被关闭了。

令人困惑的调用链

Coldcard 的固件是用 C 编写的。告诉硬件应该做什么的应用层是用 Python 编写的。Python 代码调用 C 代码。开发者覆盖了 pyb_rng_get 函数。

对许多人来说不幸的是，他的代码覆盖的 pyb_rng_get 函数并不是 Python 代码实际调用的函数。Coldcard v4.0.0 中的 Python 代码在其 make_new_wallet() 函数中调用 random.bytes()。

async def make_new_wallet():
    await ux_dramatic_pause('Generating...', 4)
    seed = random.bytes(32) # 糟糕
    assert len(set(seed)) > 4
    seed = ngu.hash.sha256s(seed)
    await approve_word_list(seed)

将 MICROPY_HW_ENABLE_RNG 设为 0 关闭了 stm32 库提供的硬件代码，但允许开发者设置 pyb_rng_get_obj。问题是，pyb_rng_get_obj 是 Python 可见的 pyb.rng() 可调用对象。

这并不是开发者在钱包函数里调用的东西。相反，他们使用的是 random.bytes(32)，它完全绕过了 pyb_rng_get 调用路径，而是调用 rng_get，由于 MICROPY_HW_ENABLE_RNG 被设为零，它使用了 micropython stm32 rng.c 中第 L112 行的定义，而该定义调用的是不安全的 Yasmarang——非硬件钱包熵。

uint32_t rng_get(void) {
    return pyb_rng_yasmarang();
}

简而言之：固件更改覆盖了在创建新钱包时不会用到的函数，同时，作为包含 Python 方法覆盖的副作用，它在所有情况下都关闭了硬件 RNG 的使用，转而使用一个非常弱的随机数生成器。

最后的证据就是 commit message 本身。它就是简单的 “runs” 这个词。

开发者们，如果你们曾处于这种情况下，请停下来。不管你拿到多少报酬，都不值得你可能对他人造成的毁灭性影响。

不要发布你不理解的代码。

对 micropython 的诅咒

从核心来看，这似乎是过多复杂性层次导致的后果。有 micropython 库、C 代码与 Python 应用程序之间的绑定，还有 COLDCARD 正在添加的新函数。做这个补丁的开发者实际上是不是一个被迫编写和处理 C 代码的 Python 开发者？

Micropython 制造了一种错觉：嵌入式开发者不需要理解 C、他们的 CPU 或其它高级概念就能进行嵌入式编程。

那是谎言。

而这场灾难正是相信这个谎言的结果。

你必须理解你发布的代码。到此为止。没有任何借口。层层误导让它更难以理解。

如果你做了更改，请确保你验证过它们确实在做你打算让它们做的事。

这里的 commit messages 讲述了真实的故事。用这里展现出的这种缺乏勤勉和理解的态度对待你代码中最关键的部分，是不可原谅的。

作为一个在 Bitcoin 上工作的开发者，你需要花时间理解你的更改，清楚地记录它们，并验证它们确实如你所想。

当人们的生活被毁时，他们不会也不应该同情你。你需要认识到你所置于风险中的资金。作为 bitcoin 开发者，你的任务至关重要。我自己过去也犯过错误，但当代码如此关键时，无法理解你发布的内容是不可原谅的。

我希望我们作为一个行业，能够从中吸取教训，相互依靠，作为一个开发者社区发布安全的代码。

原文链接： insider.btcpp.dev/p/when...

鸿途知科网 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

视频模型蒸馏技术综述

Sat, 29 Aug 2026 01:11:14 +0800

蒸馏的目标是将一个高质量的视频模型（“教师”）转化为采样速度更快的模型（“学生”）。虽然这可能会导致质量略有下降，但最先进的蒸馏方法可以将推理速度提升 10-50 倍，这对于机器人等应用场景往往至关重要。

在视频建模中，蒸馏可以沿两个轴向发挥作用：

多步扩散 → 少步扩散
双向扩散 → 自回归生成

我将讨论这两个轴向上的代表性方法，以及一些有趣且反直觉的技术现象。

为什么不直接训练一个快速模型？

乍一看，蒸馏似乎很浪费。为什么要投入资源先训练一个慢速的教师模型，然后再让它来监督快速模型的训练？为什么不直接用训练教师模型所用的相同数据，从头训练快速模型呢？其中的原因比人们最初想象的要微妙一些。

密集监督

第一个原因是，直接训练少步扩散模型是一个更困难的优化问题。以一步模型的极端情况为例。从头训练这样的模型，需要直接学习从噪声到数据的映射。相比之下，训练一个多步教师模型要容易得多（这与扩散建模本身之所以有效的道理相同）。一旦多步模型训练完成，我们就可以利用它，在连接噪声与数据的轨迹上为一步模型提供密集监督。例如，一致性蒸馏（Song '23）利用教师的轨迹施加约束：要求学生将同一条轨迹上的两个点映射到同一个干净数据点（见下图）。

图 1：常见蒸馏方法的示意图。

On-policy 监督

第二个原因则更为微妙。训练教师模型让我们能够在学生生成的状态上提供监督（即 on-policy 监督）。例如，分布匹配蒸馏（DMD；Yin '23）会对学生进行 rollout，以让其状态分布与教师相匹配（见上图）。它通过为学生提供 on-policy 修正，缓解了经典的 DAgger 问题（Ross '10）。正如下文将进一步讨论的，对于视频模型，这些修正可以沿两个轴向发生：（1）沿从噪声到数据的去噪轨迹；（2）沿帧轴（即视频时间）。第二种 on-policy 修正对自回归模型尤其关键，因为自回归模型存在曝光偏差：将模型生成的帧作为后续自回归生成的输入，会导致误差迅速累积。

多步 → 少步蒸馏

视频模型蒸馏的第一个轴向沿去噪方向展开：从多步流匹配模型转变为一步/少步模型。最流行的几类方法如图 1 所示。

一致性蒸馏

一致性蒸馏（Song '23）训练模型将噪声到数据轨迹上的任意一点映射到其终点（即干净数据）。蒸馏损失试图强制实现这样的一致性：教师轨迹上的两个点应被映射到同一个终点（见图 1）。Wan 视频模型使用一致性蒸馏（Wan '25）训练了一个 4 步模型；配合一些额外技术，可以在质量损失极小的情况下实现 10-20 倍的推理加速。Fast-Hunyuan 模型也使用了一致性蒸馏（见下面的示例）。

流映射方法

流映射方法（Geng '25，Sabour '25）学习的是比一致性模型学到的映射更为通用的形式：将时刻 t 的状态映射到同一条轨迹上时刻 r 的状态（图 1）。这解决了使用一致性模型进行多步推理（而非其原本训练所针对的一步推理）时会遇到的噪声累积挑战；参见 Sabour '25。论文《如何构建一致性模型》（Boffi '25）对一致性模型、流映射与渐进式蒸馏（Salimans '22）做了很好的综合阐述。

分布匹配

一致性蒸馏和流映射都是基于轨迹的蒸馏方法：它们训练学生沿着教师的轨迹向前跳跃。直观来看，这一要求过强且并无必要。一个好的学生并不需要与教师拥有完全相同的噪声到数据映射：我们只关心输出的分布是否相同。分布匹配方法（DMD：Yin '23；DMD2：Yin '24；MMD：Salimans '24）将这一直觉付诸实践。具体来说，DMD 旨在最小化学生输出分布与教师输出分布之间的 KL 散度（图 1 中的“分布匹配”，t = 1）。

轨迹分布匹配

最近，轨迹分布匹配（TDM；Luo '25）将基于轨迹与基于分布的蒸馏方法的优势结合了起来。其论点在于，纯粹匹配输出分布（即在 t = 1 处）会错失教师沿轨迹提供的潜在而丰富的监督。因此，TDM 提出在分布层面匹配学生生成的轨迹与教师生成的轨迹：

∑{i=0}^{K−1} KL(p{θ,tᵢ}(x_{tᵢ}) ‖ p_{ϕ,tᵢ}(x_{tᵢ})) (Eq. 1)

其中 pθ 是学生的分布，pϕ 是教师的分布。这相当于在多个时间步上对学生与教师的分布进行匹配（图 1，取多个 t 值）。

AnyFlow

AnyFlow（Gu '26）通过两个阶段的蒸馏，将基于轨迹和基于分布的蒸馏方法结合起来：首先学习一个流映射，然后以 DMD 目标进行 on-policy 蒸馏。

等等，学生能超越教师吗？

蒸馏方法中一个有趣的发现是，学生模型往往能超越教师模型。乍一看，这似乎是不可能的（根据数据处理不等式）。然而，这是多篇论文都观察到的稳健现象（例如 MMD 和 TDM）。虽然这些论文对此做了简要讨论并提出了一些假设，但我还没有看到能够将这一机制完全分离出来的严谨实验。

我对这一现象的最佳解释，来自 on-policy 监督所起的作用。在分布匹配方法中，学生会在其访问过的状态上获得来自教师的监督。从式 (1) 中可以直观地看出这一点；由于这是“反向”KL 散度，对数似然的期望是按学生所访问状态的分布来计算的。因此，学生会获得 DAgger 式的 on-policy 修正，从而缓解误差累积。

但为什么 on-policy 修正能让学生超越教师呢？一种理解方式是，教师实际上提供了两种东西。教师是一个“actor”，也就是一个我们可以从中采样的模型。但教师同时也是一个“critic”：其 score 函数提供局部监督，指示样本应向何处移动，以增加其在数据生成分布下的似然。当我们从 actor 中采样时，误差会随采样步骤不断累积。但当我们针对某一点查询教师时，并不存在累积误差。因此，在由学生生成的状态上查询教师的 score 函数，能够为学生提供强有力的 on-policy 监督。

on-policy 监督的益处已在 LLM 领域得到了更深入的研究。事实上，关于 LLM 的 on-policy 蒸馏，原始论文（Agarwal '23）就观察到蒸馏得到的学生模型超越了其教师模型。其他论文（Chen '25，Shenfeld '26）和博客文章（nrehiew '26）也研究了 on-policy 监督对 LLM 蒸馏的益处。如果能在扩散模型领域看到类似研究，那将会非常有趣。

双向 → 因果蒸馏

与图像生成模型不同，视频生成提供了另一个蒸馏轴向：从双向（全序列）的视频帧生成，转向因果（自回归）生成。这借助 KV 缓存显著加速了推理。如 CausVid（Yin 等人 '25）所示，将多步双向教师蒸馏为少步自回归学生（例如通过 DMD），可以让推理速度提升数个数量级。

为什么不直接训练一个自回归模型呢？CausVid 提出的流程似乎有些迂回：先训练一个多步双向教师，然后将其蒸馏为一个少步自回归模型。另一种做法是先训练一个自回归教师，再将其蒸馏为少步自回归学生。然而，正如 CausVid 所证明的，这样得到的少步模型会明显更弱，因为自回归教师比双向教师更弱。

曝光偏差与 self forcing

自回归生成面临的主要挑战是曝光偏差：不完美的生成帧被用作进一步生成的输入，从而导致误差累积（见下方 BAgger 的示例视频；Po '26）。为了解决这个问题，self forcing（Huang '25）在训练期间模拟推理过程，将生成的帧而非 ground-truth 帧（teacher forcing）作为模型输入。然后在视频级别使用基于 DMD 的蒸馏损失，即将自回归生成视频的分布与双向教师生成视频的分布进行匹配。

使用 BAgger 缓解曝光偏差（Po '26）。

另一个缓解曝光偏差的有趣方法来自 BAgger（Po '26），见上图。顾名思义，BAgger 采用了一种 DAgger 式的 on-policy 修正方法：先生成一些带有曝光偏差的帧，再获取修正来消除这些伪影。为了获得修正轨迹，他们使用了一个巧妙的技巧：将已生成的视频直接倒放。倒放的视频提供了这样的示例：从带有曝光偏差伪影的帧过渡到没有伪影的帧。

结语

快速推理对许多应用领域都至关重要。上述技术正被迅速应用于机器人领域，以实现虚拟远程操作等应用——即与世界模型模拟器进行实时交互；例如，参见 RynnWorld（Zhao '26；见下文）和交互式世界模拟器（Wang '26）。我个人感觉，推理时间现在基本上已经不成问题了；我们已经能够获得能力很强、速度足以满足许多现实世界需求的视频模型。

RynnWorld（Zhao '26）使用蒸馏技术，在世界模型中实现了实时远程操作。

在技术层面，我很期待看到视频模型两个后训练步骤的融合：强化学习（见上一篇博文）和蒸馏。有一些很好的新兴工作（Jiang '26）展示了将两者结合如何带来互补优势。

原文链接： x.com/majumdar_ani/statu...

鸿途知科网 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

鸿途知科网

首尔的一笔交易如何击穿Hyperliquid最大的股票市场

我们的看法

Zcash的Ironwood升级强化隐私特性

我们的看法

北极熊当选Glamsterdam升级吉祥物 - Magicians / Primordial Soup

投票已结束

🦩 Flamingo

‍️ Polar Bear

投票结果

吉祥物决胜投票

初始提名统计

最近的升级名称

建议

最佳实践：从Multi-Agent到Agent Team

你可以怎样读

全文地图

楔子：一次意外的外发

01 一个 Agent，是怎么变成多个 Agent 的

Task Agent 并没有问题

Long-running Agent 也有自己的上限

多个 Agent 的瓶颈，转移到了 Human

02 先让“谁负责什么”离开 Human 的脑子

03 让 Agent 自己开始协作

Human 不再是 Agent 之间唯一的通信通道

Request、Notification 和 Reply

Landing 发布中的真实协作

最佳实践：Agent 沟通不是“一次把一切说完”

04 Message 负责沟通，Topic 负责收口

Topic 不是把 Agent 拉进一个群聊

Team 需要共享当前状态，不需要共享全部 Context

Responsible 不是“什么都自己做”

这篇文章本身，就是一个 Topic

Artifact 让正式结果有稳定版本

Needs You：在正确的位置找回 Human

05 Overview：让一支持续变化的 Agent Team 变得可治理

管理的前提，是先让问题暴露出来

Status：现在发生了什么

Capacity：哪里正在形成等待和积压

Token Usage：计算投入主要去了哪里

Overview 不会自动理解组织

Signal 不是 Diagnosis

06 Agent Team 怎样进入真实的外部关系

Agent 一旦对外，风险模型就变了

外部只面对一个受管入口

同一个 Agent，在不同 Conversation 中也不是同一个角色

外部请求怎样调用背后的 Agent Team

Human 保留的是外部后果的边界

回到开头那次意外外发

07 CodexLoom 在织什么

ColdCard 硬件签名器安全警告（2026-07-30）

如果你在生成种子词时掷了骰子

迁移和固件状态

如果你使用了 Passphrase

如果 Mk3 是你唯一的设备

在 Mk 3 上使用骰子生成新种子词

谨慎迁移

新链上没有 Gas？如何带着可用的 ETH 抵达

TL;DR

这个困局是结构性的，不是你的错

把原生代币设为输出，到达时即可持有

如何带着 gas 到达，分步指南

一些链从自身角度解决这个问题

到达后可以做什么

黑盒AI代码正成为一项责任：为什么溯源是下一个合规层

是什么让黑盒 AI 代码成为责任？

代码溯源到底是什么？

为什么溯源正在成为合规要求？

实践中如何捕获溯源？

为什么溯源也是一种安全控制？

为什么溯源是竞争优势，而不只是成本？

团队应该从哪里开始？

让你的 AI 代码为自己作答

COLDCARD 熵漏洞专业复盘：卷走 3800 万美元的随机数缺陷

太长不看？结论

漏洞根因：一次静默的软件回退

从硬件 RNG 接口迁移到 libNgU

同名符号让错误实现静默进入最终固件

混合熵源补不回缺失的熵

40 位和 72 位到底意味着什么