publication

Anjney Midha 宣布一篇耗时近两年的研究论文已发表，并透露将在未来几周内分享更多关于这项研究的内容。

# 工作区里的输出，还是可分享的链接？——把「发布」建模为一次状态转换 AI 智能体（Agent）跑完一个任务，产出了一堆东西：文档、原型代码、分析报告、交互式演示。接下来几乎总要回答同一个问题：**这些东西该留在工作区里，还是发布成一个可分享的链接？** 这个问题被反复提出，是因为默认答案往往是错的。直觉上的做法是"把工作区里的东西推上去，生成一个链接"，于是我们立刻撞上三堵墙： 1. **链接会漂移。** 智能体还在迭代，同一个链接三天后指向的内容已经变了，你发给别人看的和他实际打开的，可能已经不是同一份。 2. **审阅变成了追踪移动靶。** 审阅者点开一个链接，读到一半作者又改了，讨论建立在一份已经不存在的内容之上。 3. **"已发布"和"正在变"是同一状态。** 没有任何一个时刻可以理直气壮地说：*这就是那一版*。事后无法复现，无法归责，无法回滚。 要解掉这三堵墙，关键不是"要不要发布"，而是**把发布重新建模为一次明确的状态转换**，并为转换的每一侧赋予不同的语义： > - **工作输出**：私有、可变、随时可改 > - **审阅链接**：指向一份**不可变的修订快照** > - **发布 URL**：一个**稳定的指针**，检查通过后指针可以被移动 下面逐一展开。 --- ## 一、先承认：智能体的工作产物天然是可变的 智能体的产出不是"写完即封存"的。它会改提示、改工具调用、改生成的代码、改数据源，然后重跑。这意味着工作区里的任何文件，在任意两个时刻之间都可能不同。 承认这一点很重要，因为它说明：**可变性不是 bug，是工作流的固有属性**。强行让工作区产物"发布后不可变"，等于强迫智能体停止迭代——你得到的要么是一堆不敢改的僵尸文件，要么是不断覆盖部署的链接。 所以正确的问题不是"如何让产物不可变"，而是"**在哪一层引入不可变性**"。 --- ## 二、三层模型：把状态转换显式化 把一次发布拆成三个层次，每一层都有自己的稳定性契约： ```text ┌───────────────────────┐ │ 1. 工作输出 │ 私有 · 可变 · 内部可见 │ (workspace output) │ 随时可改，改动不产生新版本 └───────────┬───────────┘ │ 冻结（freeze）/ 快照（snapshot） ▼ ┌───────────────────────┐ │ 2. 修订快照 │ 不可变 · 可寻址 · 可审计 │ (immutable revision) │ 内容摘要 = 身份，改动 = 新身份 └───────────┬───────────┘ │ 晋升（promote）/ 检查通过 ▼ ┌───────────────────────┐ │ 3. 发布指针 │ 稳定 URL · 可移动 · 可回滚 │ (stable pointer) │ URL 不变，指向可变 └───────────────────────┘ ``` ### 1. 工作输出：私有、可变、零仪式 这是智能体干活的地方。它的全部价值在于**低摩擦**：改了就改了，不用提交 PR，不用发通知，不用生成版本号。 设计要点： - **私有**：默认不对外可见，链接泄露即事故。 - **可变覆盖**：同一份文件可以被反复重写，**不追加版本历史**。 - **草稿标识**：任何导出物都应该带一个显式的"未审阅 / 未发布"标记，防止草稿被误当成定稿传播。 - **不承诺地址**：这里的内容**不应该有稳定的公开 URL**，因为没有稳定的版本语义。 反模式：把工作区目录直接挂到一个静态托管服务上，然后把那个 URL 发给同事。这是最常见的事故源头——你以为自己在分享"这一版"，实际上对方看到的是你两小时后的下一版。 ### 2. 修订快照：不可变、可寻址、可审阅 冻结的关键动作：**从可变工作区里取出一份快照，使其从此不可变**。 实现方式不必复杂，但语义必须严格： - **内容寻址**：修订的标识符由内容决定，例如 SHA-256 摘要或内容哈希。`.../rev/a3f9c2...` 一旦生成就永远指向同一份字节。 - **快照即身份**：修订号不是"第几次提交"这种会让人误判的序号，而是内容本身的指纹。 - **可审计**：谁在什么时间冻结了这份修订、由哪个智能体会话生成、使用了哪些工具和输入——都绑定到该修订上。 - **可 diff**：两份修订之间可以精确比较差异，审阅讨论能落到具体的字节变化上。 **审阅链接**就指向这里。它的含义被明确限定为： > 这是一个指针，指向一份**不会变**的修订。你读到的任何内容，就是冻结那一刻的内容。 这就把"审阅"从追踪移动靶，变成了对一份固定对象的判断。审阅者的评论可以精确引用"修订 `a3f9c2` 第 47 行"，而不会因为作者的下一次迭代而失效。 ### 3. 发布 URL：稳定的是地址，不是内容 这是整套模型里最容易被误解的一层。 **发布 URL 是一个稳定的地址，它背后可以指向不同的修订。** URL 不变，指针可以移动。两者必须分离，原因很直接： - **书签、文档链接、下游集成、搜索引擎索引**，都依赖 URL 的稳定性； - **产品本身需要持续演进**，新版本必须能被发布出去，而不是每次发版都产生一个新链接。 关键语义设计： | 概念 | 含义 | | --- | --- | | `stable URL` | 用户和集成方使用和信任的地址 | | `pointer` | 该地址当前指向的修订（内部可变） | | `history` | 指针的移动记录（谁、何时、从哪版指到哪版） | 几个必须做出的语义选择： - **支持回滚。** 如果新修订有问题，指针必须能移回上一份已验证的修订——这在只允许"向前发布"的模型里是做不到的。 - **支持并发晋升。** 两份修订可能同时通过检查，指针的移动必须是原子的，不能出现"半新半旧"的状态。 - **"latest" 不是身份。** 如果系统里存在"最新版"的概念，必须让它和具体修订号并存，且明确 `latest` 是指针，不是内容。 - **发布必须可追溯到修订。** 任何一个发布 URL，在任何时刻都应该能回答："此刻你看到的是哪一份修订？"——哪怕那个 URL 永远不变。 --- ## 三、为什么"审阅链接"和"发布 URL"必须是两个东西 这是整套设计里最有价值的一步，也是最容易被省掉的一步。 很多人会问：审阅通过后，直接把审阅链接改个名发布不就行了？不行。原因是两者的**契约不同**： - **审阅链接的契约是"我保证内容不变"。** 它的价值在于审阅者可以引用具体版本。 - **发布 URL 的契约是"这个地址永远有效"。** 它的价值在于集成方不会因为你的发版而失效。 把两者合并，就意味着这个地址必须同时满足"永远不变"和"持续演进"——这在语义上是矛盾的。 分离之后，一次完整的发布流程变得清晰： ```text 工作区 → 冻结修订 → 分享审阅链接 → 检查通过 → 指针移动到该修订 → 发布 URL 生效 ``` 其中： - **冻结**产生不可变身份； - **审阅**针对不可变身份给出结论； - **晋升**只是移动一个指针，不产生新内容。 这里有个很有意思的推论：**"发布"这个动作本身不创造内容，它只改变可见性。** 内容在冻结时就已经确定了，检查只是在验证它是否配得上被指针指向。这让"发布"可以被严格审计、被原子化执行、被精确回滚——这些性质在"发布 = 上传一份文件"的模型里都不存在。 --- ## 四、一个可以落地的状态机 ```text (生成/迭代) │ ▼ ┌─────────────┐ │ WORKING │ 私有、可变、随时可改 └──────┬──────┘ │ freeze（冻结） │ · 生成不可变修订 + 摘要 │ · 绑定来源会话与工具轨迹 ▼ ┌─────────────┐ │ REVIEWING │ 审阅链接已生成，内容已锁定 └──────┬──────┘ │ promote（晋升，检查通过） │ · 原子移动发布指针 │ · 记录指针历史 ▼ ┌─────────────┐ │ PUBLISHED │ 稳定 URL 可用，指针可移动 └──────┬──────┘ │ ┌───────┴────────┐ ▼ ▼ promote 新修订 rollback 回旧修订 （前进） （回退） ``` 约束： 1. **WORKING 不能被直接分享。** 这是唯一的硬性约束，也是最容易被违反的一条。 2. **REVIEWING 期间修订不可变。** 任何修改都必须产生新修订，旧审阅链接可以继续指向旧修订（它仍然是一份合法的历史对象）。 3. **PUBLISHED 状态下，唯一允许的变化是指针的移动。** 内容本身不被修改，被修改的是"URL 指向谁"。 4. **每一次指针移动都必须可追溯。** 谁、何时、依据哪次检查、从哪个修订指到哪个修订。 --- ## 五、几个必须提前想清楚的问题 **部分通过怎么办？** 一份修订里有 8 个文件，3 个通过 5 个有问题。此时不应让"指针部分移动"——要么整份修订晋升，要么产生一份**新的修订**（修改后冻结）再走一遍流程。半通过状态会让发布历史无法解释。 **审阅链接要不要过期？** 建议长期保留，因为它本身就是不可变的历史对象。但它**不应该被当成发布入口**——需要在链接页面上明确区分"这是一个修订快照"和"这是当前发布版本"，避免混淆。 **撤销怎么办？** 移动指针到一个"空"或"已下线"的占位修订，同时在 URL 上返回明确的撤回状态。不要直接让链接 404——那会破坏"URL 永远有效"的契约。 **缓存怎么办？** 发布指针移动后，CDN 与代理缓存中的旧内容必须能被可靠地失效或重新验证。稳定 URL 模型对缓存失效提出了明确要求：**指针本身要缓存友好，且必须有可靠的失效通道**。 **智能体能不能自动晋升？** 可以，但前提是指针移动的检查是确定性的、可复现的。把自动晋升绑定到不可变修订上是安全的——出问题时你永远能精确地回滚到"那一次自动晋升"，而不是"当时大概是那份内容"。 --- ## 六、总结 回到最初的问题：**智能体的输出应该留在工作区，还是发布为可分享的链接？** 答案是：**都不是，而是都要——但要放在状态转换的两端。** - 工作区的产物是**可变的工作输出**，它的价值在于灵活，所以它保持私有。 - 审阅的入口是**指向不可变修订的链接**，它的价值在于稳定和可引用。 - 对外的入口是**稳定的发布 URL**，它的价值在于永不漂移的地址，背后是一个可以移动、可以回滚的指针。 把"发布"从"上传文件"重新建模为"移动指针"，带来的不只是一个更干净的架构，而是一系列原本不可能的性质：**可精确回滚、可原子化执行、可完整审计、可在智能体持续迭代的同时保持对外承诺稳定**。 而这一切的前提，只有一条约束：**在内容冻结之前，不要生成任何可分享的地址。** 一旦这条约束成立，剩下的工程问题——快照格式、指针存储、缓存失效、检查管道——都变成了可以被标准方法解决的常规问题。

本文介绍了《Chip Scale Review》这本关于半导体封装未来的出版物，提供PDF下载链接，并列出了从2020年到2026年的卷号。

这条推文介绍了一篇科学论文，该论文为初学者提供了简化的、循序渐进的指南，涵盖从初步想法到期刊选择和同行评审的整个研究和发表过程。

美国艺术与科学院出版了一期关于人工智能与科学的《Daedalus》特刊，由 James Manyika 主编，收录了包括 Demis Hassabis、Yann LeCun 等著名人工智能研究人员的文章。