Beam 更值得被看作 AI Coding 工作流中的“执行模型替换候选”，而不是整套开发流程的接管者。能否替换，取决于它在你的仓库里能否完成任务，以及完成后还需要多少人工修正，不取决于开放权重这个标签。
先验证可检查、可回滚的任务，再考虑扩大权限。本文事实边界为 2026 年 10 月 18 日；下文任务例子均为待验证方案，不包含实测成绩。
1. 先分清：权重、服务和开发工具分别开放了什么
2026 年 10 月 16 日，Reflection 正式开放 Beam 权重，采用 Apache 2.0 许可，同时推出 API 公测与 Mirror CLI；官方发布还列出 40 多家伙伴或集成。此前 10 月 5 日只是预告，不能作为权重正式开放日期。以上信息见官方发布 。
这几项信息回答的是不同问题：权重许可涉及使用和分发条件，API 提供服务入口，CLI 则影响开发者如何组织任务。伙伴数量不能代替任务成功率，开放权重也不能证明代码质量或服务稳定性。
评估前先写清楚要替换哪一层：只是更换模型，还是连终端代理一起更换？前者应尽量保留原有工具和验收规则，后者需要额外验证会话、权限和状态管理。不要把两种变化混成一次“模型测试”。
2. 优先替换执行节点，而不是交付责任
据官方说明 ，Mirror 支持可恢复会话、在不同 worktree 中并行运行 agent，以及项目指令、skills、MCP 和 Python 扩展。
这些能力覆盖了代理工作流的部分组织方式，但“支持并行”不等于改动能够自动安全合并，“支持恢复”也不等于长任务恢复后一定不会遗漏约束。模型生成代码之外，仍有工具权限、状态保存、执行隔离与验收规则需要处理。这些边界可以结合站内的 Agent Harness 一起梳理。
首批替换候选可以是三个节点：
- 只读定位：查找相关文件、解释调用关系，输出可核对的代码证据。
- 受限修改：在指定目录内修复一个可复现缺陷，或补充明确缺失的测试。
- 分支内执行：在独立 worktree 中完成小型重构，交由现有检查与人工审查验收。
这些都是待验证方案。跨服务架构调整、生产数据操作和发布授权，不宜作为首批放权任务。若现有代理框架已经稳定，建议先确认接口与工具协议是否适配，再只替换模型；Mirror 则另设一组评估，避免无法判断收益或问题来自哪里。
3. API、托管、自部署，按责任边界选择
这三条路线首先改变的是谁负责运行环境、数据流向和故障处理，不会自动改变同一任务的完成质量。这里将官方公测接口称为 API 路线，将运行维护交给选定服务方称为托管路线；具体托管服务是否可用，仍须确认。
按下面的顺序做选择，而不是先问哪种路线“最强”。
| 路线 | 建议适用情形 | 接入前必须确认 |
|---|---|---|
| API | 先验证任务适配性，暂不承担底层部署 | 公测限额、计费、数据留存、错误与重试行为 |
| 托管 | 希望借助服务方管理运行环境 | 模型版本、隔离方式、区域、故障责任与退出方式 |
| 自部署 | 有明确部署边界，且团队能维护推理栈 | 精度适配、容量、监控、升级与运维成本 |
AWS 的 Beam 部署文章 可作为部署参考。不要由此直接推定某个区域、实例或托管套餐当前可用，应逐项核对。
代码能否上传、提示词与日志保存在哪里、如何删除，也应在接仓库前确认。若这些条件尚不清楚，建议先用脱敏副本验证流程，而不是直接交出完整业务仓库。
4. 23B 激活参数，不是 23B 权重内存
Beam 模型卡 标注：模型采用 MoE，总参数为 501.3B，激活参数为 23.4B，上下文为 1M，仅处理文本；列出的精度包括 BF16、FP8 和 NVFP4。
激活参数不能当成完整权重容量。不能因为名称中有“23B”级别的激活规模，就按一份 23B 权重估算部署内存。
仅作粗略算例：按十进制 GB，将三种精度理想化为每参数 2、1、0.5 字节，以“总参数量 × 每参数字节数”计算，纯权重分别约为：
- BF16：1002.6 GB；
- FP8：501.3 GB；
- NVFP4：250.65 GB。
这些只是位宽算术，不含量化元数据、KV cache、运行时及并发开销，不是实测占用，更不是显卡采购配置。实际部署仍须核对推理框架、分片方式和精度支持。
1M 上下文是容量规格，不是长任务正确率承诺。先提供任务相关文件，再逐步增加上下文，观察定位与修改是否仍然准确；不要一开始就塞入整个仓库。依赖界面截图理解的任务，也不应直接纳入这轮纯文本能力评估。
5. 用固定仓库任务验证，而不是凭聊天印象
选择自己的仓库，冻结基线提交、依赖环境和测试入口。每个任务预先写明允许修改的目录、禁止操作、时间预算与验收条件，再与现用方案对照。先由人确认验收测试有效，避免把原本就能通过的检查误当成修复证据。
下面是一份可复制的待验证任务清单：
- 代码定位：给定一个入口和目标行为，要求列出调用路径与文件位置；人工对照预先核实的路径，不允许修改文件。
- 缺陷修复：提供可复现失败，要求最小修复；原失败检查须通过，且不得删除测试或放宽断言。
- 补充测试：指定模块与边界条件；检查新增测试能否识别预设错误，而不只看测试数量。
- 跨文件重构：限定修改目录并要求保持外部行为；检查调用点、静态检查与回归测试。
- 会话恢复：在任务中途结束会话后恢复；检查已完成工作、剩余步骤与限制条件是否保留。
- 并行执行：让两个独立 worktree 承担互不依赖的任务；检查文件、分支和任务状态是否混淆。
后两项用于验证 Mirror 或对应代理框架，不应全部归因于模型能力。重复次数在开测前确定，保存所有尝试，包括失败、超时和人工救场；不要只留下最成功的一次。
6. 评分记录要覆盖人工介入与失败成本
每次运行复制下面的空白模板。模型替换组与 CLI 替换组分别记录；提示词、工具权限或配置发生变化时，另开一条记录，不覆盖旧结果。
任务 ID：____
基线提交／环境：____
接入路线／模型版本／精度：____
代理框架与配置：____
输入材料／允许修改范围：____
验收条件／预算／尝试编号：____
补丁、日志与测试证据位置：____
| 指标 | 记录规则 | 本次记录 |
|---|---|---|
| 功能验收 | 0＝未完成；1＝部分完成；2＝全部完成 | ____ |
| 改动边界 | 0＝越界；1＝需清理；2＝符合约束 | ____ |
| 验证证据 | 0＝不可复现；1＝不完整；2＝完整 | ____ |
| 人工介入 | 次数、耗时、介入原因 | ____ |
| 执行成本 | 端到端耗时、实际用量与可取得的账单 | ____ |
| 恢复与并行 | 成功／失败／不适用，并附证据 | ____ |
评分只作内部判断，不合成为模型排行榜。越权修改、删除关键测试或泄露秘密应列为阻断项，不能用其他高分抵消。
成本记录要纳入失败重试和人工修正；没有取得价格或账单，就写“未提供”，不要记成零。最终补丁看起来正确，也不代表过程值得采用：若必须频繁接管，替换范围就应收缩。
7. 让证据决定替换范围
在测试前写好放行门槛：完成既定验收、没有阻断项，并且人工介入、耗时与实际成本处于团队可接受范围。不要看到一次成功后才临时降低标准。
如果只读定位通过验证，就先用在定位环节；如果受限修复也通过，再开放指定目录的修改权限。若 Mirror 的恢复与并行执行尚未验证，就保留现有编排方式，不必同时更换整套工具。
允许代码进入外部服务时，可以先用 API 做小规模筛选；有明确数据边界限制时，则从允许的托管或自部署路线开始。任何路线都建议保留原方案、限制任务权限，并准备可执行的回退方式。
“能生成补丁”“能在代理流程中完成任务”“能承担生产交付”是三个不同层级。Beam 开放权重增加了选择空间，但它能替换你哪一部分工作流，最终只能由仓库里可复现的证据决定。