跳到主要内容

Goose 项目介绍

AI 的出现并没有让系统变简单，反而第一次系统性地暴露出工程架构的结构性问题。

过去，工程系统的核心任务是能力构建：围绕检索、排序、存储、调度等基础能力，构建稳定、高效、可扩展的分布式系统。这一范式成立的前提是——能力是稳定的，变化是局部的，系统的复杂性可以通过模块化与分层来控制。

但当 AI 深度进入业务之后，系统承载的对象发生了根本性变化：

系统不再只是“能力的载体”，而是开始承载持续变化的决策过程。

从更抽象的角度看，这标志着系统架构的一次范式迁移：

从“能力驱动的系统”， 走向“表达驱动的系统”， 再进一步走向“决策可建模的系统”。

因为商业系统必须满足三个基本要求：

决策是可复现的（否则无法评估效果）
策略是可对比的（否则无法优化）
系统是可治理的（否则无法规模化）

对应到系统结构上，会出现三条关键变化：

第一，组合不再分散，而是收敛为统一结构。
第二，策略不再嵌入实现，而是提升到表达层进行调整。
第三，执行不再理解业务，而只需忠实执行表达。

一、问题与矛盾​

1.1 问题的本质：从能力组织到决策组织​

传统系统中，各类能力（如分词、语义理解、实体识别、召回、排序等）通常以模块形式存在，并通过固定流程进行编排。这种模式的核心特点是：

  • 执行路径相对固定

  • 能力边界清晰

  • 变化主要发生在局部

  • 系统整体结构稳定

在这种前提下，工程优化主要围绕性能、扩展性和可靠性展开。

但在 AI 场景中，变化的本质发生了转移：

  • 同一请求不再对应固定执行路径

  • 多种能力需要在不同目标下动态组合

  • 多目标（用户体验、商业收益、风控等）同时存在且权重动态变化

  • 不同用户、场景、时间维度下策略均可能不同

也就是说，系统不再是“调用能力”，而是在做：

基于目标与上下文，对能力进行动态组合的决策过程。

能力本身并没有变化，变化的是它们之间的组织方式。

1.2 结构性矛盾：变化进入系统核心​

传统架构的隐含假设是：

  • 能力是稳定的对象

  • 变化是局部的

  • 组合是实现细节

但在 AI 场景中，这一假设被彻底打破：

  • 能力成为可组合单元

  • 组合成为核心逻辑

  • 变化成为系统驱动因素

当“组合逻辑”成为核心，但又没有被显式表达时，系统会出现一个必然结果：

变化以隐式方式扩散，最终转化为不可控的复杂度增长。

具体表现为：

  • 策略分散在多个服务与链路中

  • 业务逻辑跨越多个系统边界

  • 修改一项策略需要联动多个模块

  • 系统行为难以整体理解与推理

  • 故障定位依赖全链路追踪

系统逐渐从“结构化系统”演化为“历史叠加系统”。

1.3 核心缺失：业务表达层​

从架构角度看，问题的根源并不在能力不足，而在于系统缺少一层关键抽象：

业务表达层

传统系统具备两类抽象：

  • 能力抽象（模块 / 服务）

  • 执行抽象（调度 / 计算 / 存储）

但缺少第三类关键抽象：

对“业务本身”以及“能力如何被组合”的显式表达能力

因此，最关键的部分——能力组合逻辑——只能以隐式方式存在：

  • 分散在代码中

  • 隐藏在配置中

  • 融合在调用链路中

这导致一个根本问题：

能力可以被执行，但组合无法被表达；变化可以发生，但无法被系统性约束。

更重要的是，隐式存在带来的不只是效率问题，而是结构问题：

  • 组合逻辑分散在代码、配置、链路之中
  • 不同模块各自承担一部分决策职责
  • 策略修改需要跨系统联动
  • 系统行为无法被整体建模
  • 演化路径依赖人为理解，而非结构约束

这个结构问题在 kmcmake 上也很典型。很多开源项目的 CMakeLists.txt 往往上千行，并不是因为功能本身更复杂，而是因为“组合逻辑”被散落在大量 if/option/include 与工程约定里，最终只能靠经验维护。kmcmake 之所以能用少量配置完成同类构建目标，关键不在“少写 CMake”，而在“先写表达模型”：把目标、依赖、测试、安装、发布等规则收敛为统一表达，再由执行层按表达落地。比如在 kmcmake 模板测试中，kmcmake_cc_test(...)、kmcmake_cc_test_ext(...) 这类声明式接口把测试组合规则集中描述，避免把策略分散在多处脚本细节里；对应到本文语境，这正是“组合不再分散、策略不再嵌入实现、执行按表达运行”的工程化体现。

系统只能通过不断修改实现来适应变化，而无法在结构层面吸收变化。

1.4 从能力系统到决策系统​

在这一背景下，系统的定位必须发生升级：

能力系统（传统范式）

  • 核心目标：提供稳定能力

  • 结构特点：路径固定、模块清晰

  • 变化方式：局部调整

  • 优化方向：性能与扩展性

决策系统（AI 范式）

  • 核心目标：动态组织能力以完成决策

  • 结构特点：路径动态、组合驱动

  • 变化方式：全局影响

  • 优化方向：策略表达与组合控制

决策系统的本质，不再是“做什么”，而是：

在不同目标约束下，如何组合已有能力以产生最优结果。

因此，系统的核心问题转变为：

如何描述、组织并控制能力的组合过程。

二、Goose 的方法​

2.1 Goose 的核心思想：引入业务表达层​

Goose 的目标，并不是提供新的基础能力，而是补齐系统中缺失的一层结构：

业务表达层

在 Goose 中，业务不再隐式存在于代码和链路中，而是被提升为一种可显式描述的结构。

其核心载体是：

SQL IR（中间表达层）

这里的关键不在 SQL，而在 IR，它的作用是：

  • 统一描述业务逻辑

  • 显式表达能力组合关系

  • 将策略从实现中抽离出来

  • 将变化从代码层上移到表达层

通过这一层，系统获得了三个关键能力：

  1. 组合可表达

能力之间的组合关系不再隐式存在，而是可以被结构化描述。

  1. 变化可约束

策略变化不再直接作用于实现，而是在表达层进行调整，从而被统一管理。

  1. 执行可解耦

执行系统不再关心业务如何组合，只负责按表达执行，从而实现结构稳定。

2.2 系统结构的变化​

引入业务表达层之后，系统结构发生变化：

  • 业务逻辑从“代码中的实现”转变为“表达层中的结构”

  • 能力从“被调用对象”转变为“可组合单元”

  • 系统从“执行导向”转变为“表达驱动”

整体形成一个新的分层模型：

  • 业务表达层（描述组合）

  • 执行与调度层（负责执行）

  • 能力层（提供基础能力）

其中，业务表达层成为连接“变化”与“系统”的关键桥梁。

2.3 Goose 的位置：统一表达与控制层​

在更大的系统（如复杂业务体系或多系统协同架构）中，Goose 位于一个更高的抽象层：

作为统一的表达与协调控制层存在

它承担的职责包括：

  • 将业务需求映射为结构化表达

  • 将表达映射为具体执行路径

  • 在多个系统与能力之间建立一致的组合语义

  • 在变化发生时，将影响限制在表达层

因此，Goose 并不是某一个子系统，而是一个跨系统的“结构协调器”。

三、验证与落地​

3.1 gnef 的意义：结构成立的最小验证​

gnef 可以被看作是 Goose 体系中的一个前置切片，它覆盖的是最早期、最敏感的决策与语义处理部分。

它的意义不在于功能本身，而在于验证：

在组合最频繁、变化最剧烈的位置，是否仍然可以通过统一表达来约束系统行为。

其结果表明：

  • 能力组合可以被显式表达

  • 变化可以被收敛到表达层

  • 执行可以保持结构稳定

  • 表达与执行之间可以建立清晰映射关系

这说明业务表达层不仅是理论成立的，也是工程上可落地的。

作为 Goose 体系的前置验证切片，gnef 已完成内部调用验证，其可核验行为可直接支撑业务表达层的可行性。

第一，gnef 调用过程中，语义处理相关能力组合（分词、实体识别、意图初步判断）均通过 SQL IR 进行结构化描述。调用日志可以追溯每一次组合逻辑的定义与调整记录，无需追溯底层代码。

第二，gnef 输出结构保持稳定统一。即便上游策略发生切换（如语义理解侧重点从关键词匹配转向意图精准识别），输出格式仍保持一致，仅需在 SQL IR 层调整组合规则，不影响下游执行链路。

第三，gnef 支持快速策略切换。相同输入在不同策略下的输出差异，可通过 SQL IR 结构对比直接定位，无需全链路代码排查；这一特征已在内部多轮测试中复现。

3.2 Goose 的本质​

综合来看，Goose 并不是一个传统意义上的系统组件，而是一种面向 AI 时代的系统结构范式，其核心在于：

用表达层取代隐式组合，用结构管理复杂度。

它解决的不是单点问题，而是一个根本性问题：

在 AI 驱动的动态业务中，如何让系统仍然保持可理解、可控制、可演进。

3.3 实际使用示例（从概念到执行）​

为了避免停留在概念层，下面给出两个实际可落地的使用示例。

示例 A：电商搜索中的“低价刚需”与“高端品质”策略切换

业务背景：同一关键词“手机壳”，不同用户意图差异显著。部分用户对价格敏感，部分用户更关注品牌与质量。
传统做法通常是写两套链路并在服务层分流，随着策略增加，代码与配置会快速膨胀。

在 Goose + gnef 方式下，入口保持一致，仅在 SQL IR 层切换策略：

pragma initialize_gnef_default;
select nlp_process('iphone 16 pro max 手机壳', 1); -- 低价刚需策略
select nlp_process('iphone 16 pro max 手机壳', 3); -- 高端品质策略

可观察结果：

  • 调用入口不变；
  • 策略通过参数切换；
  • 输出结构稳定（可统一比较）。

工程意义：业务策略的变化被约束在表达层，执行链路无需同步改造。

示例 B：内容分发中的“强意图导向”与“弱意图探索”策略切换

业务背景：内容平台在高活跃用户和冷启动用户之间，需要采用不同的推荐意图策略。
高活跃用户更适合强意图路径，冷启动用户更适合探索式路径。

在 Goose + gnef 方式下，可通过命名策略实现同入口切换：

pragma initialize_gnef_default;
select nlp_process('新手跑鞋怎么选', 'intent_strong');
select nlp_process('新手跑鞋怎么选', 'intent_explore');

可观察结果：

  • 输入一致，策略不同；
  • 输出字段一致，可用于 A/B 对比；
  • 变化主要集中在策略配置，不侵入下游执行系统。

工程意义：策略试验和上线路径统一，迭代成本显著下降。

3.4 Goose 的实现层技术能力（不是概念清单）​

Goose 的技术价值不在“提出概念”，而在“提供可执行实现”。从实现层看，至少有四个关键能力：

第一，统一入口与可组合函数机制。
Goose 通过扩展与函数注册机制，将能力组合收敛到统一入口，避免策略变化造成接口裂变。

第二，表达层与执行层解耦。
策略通过 SQL IR 与配置表达，执行层按表达执行，减少“改策略=改代码”的联动风险。

第三，稳定输出契约。
在策略切换下保持输出结构一致，保障评估、归因、复盘在同一数据口径下进行。

第四，可观测与可治理路径。
调用、策略、输出的关系可追溯，问题定位不再依赖跨系统盲排，具备工程可治理性。

这四项能力共同构成 Goose 的“实现层闭环”：
表达可写 -> 策略可切 -> 执行可跑 -> 结果可比 -> 问题可追。

四、总结​

AI 并没有创造新的基础能力，而是改变了能力之间的关系，使“组合”成为系统的核心问题。

传统系统隐藏复杂度，而 Goose 的方式是：

显式表达复杂度，并在表达层对其进行控制。

当能力可以被表达，组合可以被建模，变化可以被约束时，系统才具备长期演进的能力。

Goose 的目标，就是提供这样一层结构，使系统从“被复杂度淹没”，转变为“能够管理复杂度”。