AIGS的方法论、四层架构与三大应用形态-编程阁

困境一：模型碎片化。同一种业务往往要在不同类型模型之间切换——有的场景用国内通用大模型，有的用国际通用大模型，有的用开源模型做私有化部署。年初对接一家主流厂商，到年底又要支持国产替代和开源部署，每接一家就要重写一次。

困境二：Agent 无法复用。一个项目里写过 FAQ 检索，再做"查询订单"时发现：节点、提示词、工具、会话记忆这一整套又得重写。三个月下来，五个项目，五套代码，连公共类都没沉淀下来。

困境三：知识进得来，业务出不去。知识检索做了向量库，但用户问"上个季度华东区销售额同比"，系统只会返回相似文档片段，不会真的去查业务库做计算。知识检索和业务调用之间缺少统一的执行通道。

这三个困境指向同一个结论：AI 应用需要一个方法论 + 工程底座 + 应用形态都齐备的"框架"。

传统业务系统的执行路径是写死的——菜单点击 → 控制器 → 查库 → 渲染。引入大模型之后最大的变化是：执行路径变成由模型动态生成。AIGS（AI Generated Service）正是为这种新范式而设计的方法论。

AIGS 的核心思想是把系统能力抽象成"可被推理调用的服务"，让模型在每一步推理中决定调用哪一个、传什么参数。落到工程上，就是"推理 + 工具"双引擎：推理层让模型按"思考 → 行动 → 观察 → 再思考"的循环推进，工具层把业务接口、知识检索、数据库查询、文件解析都注册为标准服务，模型按需调用。

这种"推理驱动服务"和传统"流程驱动服务"的区别，可以用一张表对比：

把 AIGS 当成"方法论层"看，后面的工程底座和应用形态都是为了让它真正跑起来。

方法论回答了"怎么做"，四层架构回答"放在哪里"。一套成熟的 AI 框架，通常会按下面四层组织代码和部署单元。

展示层负责和最终用户交互。流式输出和会话状态在这一层完成，渲染交给前端框架。

服务层是 AI 应用的"业务中枢"。一个 AI 应用对应一份应用配置，配置项用结构化方式存储，支持应用级、会话级、节点级多层覆盖。

核心层是框架"发动机"。负责节点编排、上下文组装、治理平台落地。

数据层收纳各类 AI 资产。缓存层支持多种模式组合，业务数据和 AI 检索共用同一份元数据。

四层之间只通过接口对话，不允许跨层调用。这是把 AI "装进"既有 IT 体系的关键——展示层不知道底层是 LLM 还是规则引擎，数据层不知道上层是 AI 还是普通业务。

在四层架构之上，工程底座由三件事决定：模型怎么接、流程怎么跑、资产怎么管。

模型适配的关键是统一抽象。框架通常会定义一个模型基类，把不同厂商的差异收敛到这一层。业务代码只调用标准方法，切换模型时改配置不改代码。

流程编排的关键是可复用节点 + 事件驱动。每个节点是独立单元，节点之间靠事件传数据，好处是任意节点可替换、可插拔。

资产管理的关键是五类资产可装配。新加一个 Function 不用改框架，只写一个标注的类即可。

框架全貌最终要落到可交付的应用形态。通常会提供三种开箱即用的应用类型，覆盖 80% 的 AI 落地场景。

三种类型在数据模型上同构，在节点装配上不同。

这意味着团队可以先用智能问答跑通第一个场景，再平滑升级到智能问数，最后在复杂流程上启用智能编排——同一份框架底座、同一套接口、同一套治理体系。