文字类AI的几种场景
推理生成
主要指的是各大Reasoning类型的模型结合了外部工具，帮助用户补全提问，然后再通过环境（Enviroment）执行得到结果后，由模型整理输出的结果
代码自生成执行
这一类应用通常是提供了代码执行环境，让LLM自行输出需要执行的代码，是最接近科幻样子的形态，但是由于模型的限制，通常一次生成的代码不能够很好的完成用户的提问意图。
工具使用
这一类主要是指functionCall或者LLM，与代码子生成不同，人类的MCP-Server总是保证可以正常执行，这里的问题在于，需要Tool的种类非常多，如果应用面向的问题空间过于宽泛，为了把可用的所有MCP工具让AI使用起来会极大的压缩了用户提问的空间。
多工作流编排
这类应用多出现在智能客服，智能销售类，其天然的缩小了问题范围，且通过流程完全的将解和验证固化下来。
缺点是，迁移和修改成本高，是落地应用最多的一类应用
知识库（RAG）
这种应用依赖于embedding对提问和答案的关联关系，计算出固定的最佳结果，常见于非标知识库构建，回答的答案质量极高。但是因为其只有相关性，没有因果推导，极大的限制了应用场景，通常会配合工作流作为其中一个小节点来提供服务。
领域模型的重构
以上我们列举了常见的几种文字类的AI应用的场景，我们能够轻易的发现，其有一些共同的特点，也有一些不同，共同的地方都是按照Q&A的方式进行服务的，不同的地方在于接收到Q之后，如何与LLM进行编排，才能够服务。尽管应用面向的场景可能非常多，不过我相信基本逃脱不了以上描述的场景。
因此，我们需要对前文提到的会话模型进行重构，要填入一些辅助的模型，以满足以上场景。
以下是让LLM协助我们完成原初步会话模型的模型重构的提示词：
第一次提问
现整理的模型为核心模型，请根据以下给定的应用场景描述，帮我补充整个模型，使得模型能够满足给定的场景描述，
+上述内容
第二次提问：
请将模型图划分为核心领域，与周围辅助领域，再重新绘制一次，并将答案更新然后重新返回
以下是LLM帮助我们完成的领域模型重构内容：
增强版本地问答交互模型（领域分层设计）
领域划分说明
核心领域（黄色区域）
辅助领域（蓝色区域）
支撑领域（绿色区域）
完整领域关系图
领域协作流程
核心领域职责
1. 用户身份管理（`核心用户`）
2. 对话生命周期管理（`交互会话`）
3. 机器人调度中枢（`机器人代理`）
辅助领域扩展
| 场景类型 | 核心协作机制 |
| -------- | ---------------------------- |
| 推理生成 | 机器人代理→推理引擎→工具网关 |
| 代码执行 | 机器人代理→代码环境→执行编排 |
| 工具使用 | 工具网关←→工作流引擎 |
| 知识检索 | 知识融合→交互消息→媒体处理 |
关键交互协议
模型演进建议
- 核心领域
- 保持最小功能集，仅包含会话路由和状态管理
- 机器人代理作为抽象基类，不实现具体逻辑
- 辅助领域
- 各场景模块实现标准化接口：
“`python
class RobotInterface:
def pre_process(self, input):…
def execute(self, context):…
def post_process(self, result):…
“` -
通过配置热加载不同实现类
- 支撑领域
- 提供跨领域公共服务：
-
消息序列化、异常处理、状态持久化
- 领域间通信
- 使用事件总线实现松耦合：
版本控制策略
| 领域层级 | 变更策略 | 兼容性要求 |
|---|---|---|
| 核心领域 | 大版本迭代（v1.0→v2.0） | 保持接口向后兼容 |
| 辅助领域 | 功能版本（v1.1→v1.2） | 可选升级 |
| 支撑领域 | 热修复（v1.1.1→v1.1.2） | 向下兼容 |