前言2：面向AI Programming的服务调用
Created By RV, and licensed with Creative Commons "CC BY-NC-ND 4.0"
来自《重构面向AI Programming服务调用范式》
这一章节，其实是理论书《重构面向AI Programming服务调用范式》的前言。
放在这里，是因为这一章节所讲的内容是当前《Kree4JS：从入门到精通》的骨架和灵魂。
如果，只是要使用Kree4X框架，看看这章，有助于初步理解“Why”，为什么要如此设计、如此取舍。
如果，要深入理解，请去完整阅读：KreeX-RPC: 重构面向AI Programming服务调用范式
以下，是正文。
########假装是分割线########
注意两种“服务调用”概念的区分：
- LLM如何调用工具，eg. 调用MCP、Function Calling
- AI Programming开发模式中，各个软件模块、服务间的调用
我们所讲的是后者。
微服务架构是天选之子
微服务架构是天生适合AI Programming的一种架构。
分治、单一职责、高内聚，一眼望之，正是AI Agent可以大展身手的理想场景。
使用AI来开发微服务，从降低推理成本，加快推理速度的角度来看，面向AI的服务调用，至少应该具备下述的几个特征。
No Schema: Scheme In AI, Not Service
No Service Schema是我们脑海中浮现的第一个念头。
Schema就在AI的脑海、上下文中，不需要在具体的服务层面去定义。
整个AI Programming驱动的生产链条上，没有让您介入去手工编写Service Schema的时机与节点。
- 架构师，切割业务模块，确定采用微服务架构，建立架构和粒度约束。
- AI Agent根据需求描述建立数据结构、存储策略、Coding服务实现。
AI Agent编制了数据结构，根据数据结构，在上下文中动态约定各个服务之间的调用接口、接口的类型约束。
我们最好不要试着去插一脚。
AI驱动的服务调用模型中，还试图显式地在服务层级去定义Schema，这是一种人来实现服务的思维定式。
统一服务调用范式：透明RPC
“方法-函数调用”是编程语言最自然的基本范式，所有不是“方法-函数调用”的编程方式，都是在某种场景下不得不妥协的、某种形式的技术债。
采用透明RPC调用模型，抹除调用本地过程、远程过程的语法差异。
透明RPC框架，支持NodeJS Callback风格的服务实现，及EventEmitter风格的服务实现，从而还可以以一致的“方法-函数调用”方式，支持事件驱动等架构。
所有的浏览器、客户端、服务器，服务间、组件间通信全部统一采用基于透明动态代理的RPC。
const 服务A,服务B,服务C
const info = 服务A.read(id)
const validated = 服务B.validate(info)
validated && 服务C.store(info)
...
使用混合需求描述需求描述需求后，类-->微服务，功能-->方法，交互-->方法调用，使用AI生成特定语言的源码简单、直接。
这也许是，从需求-->数据结构-->服务调用，整个路径中，本地调用与远程调用规范最一致，协议转换次数最少，代码最直观简洁，信息密度最高，推理Token消耗量最小，推理路径最短，速度最快的实现方式。
异构通信网格：通信与服务无关
通信是通信，服务是服务。
传统的类似HTTP之类的服务，从概念到实现，其与通信协议的绑定是强制的。
将“通信”从架构层面与“服务”剥离，使“服务”与“通信”无关，通信仅仅提供传输信息的通道，会大幅简化服务调用的过程，简化服务调用代码编排、降低推理实现的成本。
通信只是传递服务调用请求、服务调用结果的数据通道，在服务层面，我们其实并不关心底层的网络结构。
提供一个异构的、支持各种通讯协议网络互联，组成一个完整的通信网格，可以为服务调用带来更多的灵活性、更多的业务场景可能性。
服务治理原生
传统的技术架构中，通常将服务开发与服务治理，割离到DEV和OPS两个阶段。在AI Programming的语境下，这个结构不再合理。
服务治理，应该是在微服务框架层，內建的、原生的一个Feature。
- 实时可观测性，调用实时透明性
- 在Ops层才可以获取的Tracing能力，对于AI Programming来说太晚了
- 全局Tracing太重，以一次调用为粒度，动态开启的通信-服务链路跟踪
- 不再需要Tracing采样
- 不再需要Tracing框架具有自动注入功能，AI生成Tracing代码，自动注入不再重要
- 动态发现
- 通信节点自动发现机制
- 基于通信节点自动发现，提供服务动态发现机制
- 服务健康检查
- 通信节点的心跳检测
- 服务节点的健康检测
- 服务选择：负载、多路由，自动轮换、失败重试....
- 一次服务调用，可能存在多个可用目标服务实例，由调用者的SelectPolicy来决定，使用哪些服务实例。
- 甚至，可以使用所有的服务实例，eg. 通知类服务、冗余存储类服务
- 流控：限流、熔断、降级。
- 流控是RPC框架的职责，而不是Ops层的职责
- 框架层面支持动态注入各种流控规则
- 调用结果Reduce
- 一次调用，可能调用了多个服务实例，每个实例返回的结果，可以被调用端使用Reduce算法进行规约。
- 其它...
服务动态性
整个服务群开发的过程中，不要对任何所依赖服务的存在性做任何的限定。
服务是动态出现，动态消失的。
在服务A的编写过程中，上下文中仅保留对服务B的“概念想定”，“我思故我在”。
“从Schema生成服务B的Serve端静态存根，编写、实现、测试服务B，然后再回归到服务A，为服务A生成Client端存根进行调用”，没这个必要。
所有的服务开发，应该是一种基于“概念想定”，然后并行进行的非线性流程。
语言无关性
AI Programming的模式下，程序开发语言的重要性大幅降低。
当同一个业务可以使用多种程序语言实现时，采用哪一个，没有本质的差别。根据业务场景，选择最合适的一种即可。
结合RPC，换一个角度，这实际是在要求底层的RPC服务调用框架应该具有类似于一次编写，处处执行的能力：
- 多编程语言支持
- 平台间、编程语言间互调支持
源码即可执行代码，脚本语言具有更大的优势
强类型语言，其存在的诸多目的中，“防止犯错”是其非常重要的一个存在价值。
放到AI Programming的语境中，这恰恰成了最大的短板。
我们不需要在“程序语言”层面引入强类型约束的安全性：
- AI不care
- 人无从介入
从LLM Generation，AI动态Coding，及后续的动态构建、动态执行的角度来看：
“强类型”语法校验、静态编译是累赘。
源码即可执行代码，脚本语言反而会具有更大的优势。
AI Agents是核心竞争力，而源码及可执行代码仅仅是AI Programming这套流程的廉价中间产物和最终产物，是批量化的廉价货。
并且，源码很快会丧失Human-Readable的特性，对于人类而言变成黑盒，想之令人灰心。
大人，世道变了。
如果，不怕板砖乱飞的话，在这里要大喊一声：
- Python是面向AI Programming的一等公民
- 很简单，这是因为，AI相关的各种模型、算法，基本都是Python的，我们无从抗拒。
- Javascript是我们的第二选择
- 这也很简单，因为Javascript是唯一的、同时被浏览器和服务器端支持的编程语言
- 然后，各种特异场景
- 有什么业务场景，您就选择什么合适的编程语言