基线可追溯：fork 来源与验证记录

内核 fork 自 OpenCode（MIT 许可）。本页锁定的是 fork 时的上游提交，此后内核不跟随上游滚动，安全修复与内核演进需主动跟进。

项	值
上游仓库	`sst/opencode`（锁定时的路径，现已迁移到 `anomalyco/opencode`）
上游分支	`dev`
锁定 commit	`9c1c061b84cfc4b132faa9dc2e0de3a1e34d87dc`
提交说明	`fix(lsp): remove CMakeLists.txt and Makefile from clangd root markers (#21466)`
锁定时间	2026-08-22
许可	MIT
导入目标	`agent-forge-runtime`

上游此后继续演进；上表回答的是“我们基于哪一次提交”这一确定事实。

企业交付里，版本问题通常被问成：底座钉在哪一次提交、出了问题能否二分到上游变更还是本地改动、运行路径里有没有未授权的商业代码。基线把这三件事落到 commit、hash 与加载边界。

为何冻结 commit

内核冻结在一次提交上，而不是跟随上游活动分支滚动：

可复现：同一 commit 上文件集合稳定；活动分支随时变化，无法作为审查锚点。
责任边界：故障时可判断变更落在基线之上还是基线之外。
供应链审查：受监管场景需要说清底座来源与精确版本。

代价是安全修复与内核演进要主动跟进，而不是默认漂移。

粒度：commit，而不是版本号

BASELINE.md 记录的锚点即上表各项。粒度落在 commit：大版本内部仍会变，commit 不会。审查“改动落在基线之内还是之外”，靠的就是这个粒度。

hash：核对文件一致

核对记录要求关键文件与基线 hash 一致。hash 一致可以机械比对，目视“看起来一样”区分不了单字节差异。后续任意时刻要回答“内核文件改没改”，靠的是同一套 hash 口径。

验证记录

验证项	结果	备注
文件一致性	通过	关键文件 hash 与基线一致
`bun install`	有条件通过	见下方环境坑
`typecheck`	0 错误	含基线 SDK 生成物修复
`build`	通过	单目标构建 + smoke
身份绑定实例路由	通过	认证用户名透传至实例路由

Windows 上可复现的安装与构建示例：

bun install --ignore-scripts
bun run --cwd packages/opencode script/build.ts --single --skip-embed-web-ui

命令里的 packages/opencode 是内核包在仓内的目录名，随上游基线一并保留；对外的可执行文件名与配置项前缀已改为 agent-forge 命名。

第一个真实的坑

完整 bun install 在 Windows 上可能失败：原生依赖 tree-sitter-powershell 需要 Windows SDK。用 --ignore-scripts 跳过该构建脚本即可继续。这是环境限制，不是业务逻辑缺陷；不影响 Linux/生产镜像构建，但会挡住首次在 Windows 拉仓的人。

core 与企业实现的边界

范围	内容
内核基线	对齐上述锁定 commit
治理与企业能力	治理模块 + 企业实现树

设计约束：MIT 核心从不静态加载企业实现。企业代码经两处 seam 挂载：

端点壳：组织写入、审计 verify/rehash 等先检查许可特性；无钥匙或缺特性 → 403，且不加载企业实现；已授权 → 动态加载。
谓词：审批他人发起的工单需要 HITL 特性；本人确认留在开源核心。

flowchart TD
  Req[商业能力请求] --> Lic{许可含特性?}
  Lic -->|否| Deny[403 且不加载]
  Lic -->|是| Dyn[动态加载企业实现]

无许可时企业代码从未被加载或执行，运行路径本身可审计，无需依赖许可协议文本的约束。展开见Open-Core seam。

相关阅读：