金融领域模型的实现拆解

金融领域模型的实现拆解

前文我们整理了场景,完成了基础领域模型的建立,并且在LLM的协助下,完成了领域模型的划分和构建。

接下来,我们需要根据具体面向业务领域内的场景结合起来,完成对领域模型的编排,然后才能完成应用的落地。

我们可以根据Github上一个金融量化项目做例子AI-Hedge-Fund

该项目希望为用户提供一个可复刻的金融分析框架,并通过一个主Agent完成信息的整合和评估,并反馈给用户提供辅助决策,其项目最大亮点是,默认内置了六个金融分析框架,是当前国际金融投资比较出名的六个代表人物所使用的分析框架。

整个项目包含了多个Agent,

  1. Ben Graham
  2. Bill Ackman
  3. Cathie Wood
  4. Charlie Munger
  5. Phil Fisher
  6. Stan Drukenmiller
  7. Warren Buffett

分别模拟了不同类型的投资经理处理市场信息时候的方法。

让我们一起看看这些Agent都是如何实现的吧。以下是其中两个Agent案例,其他都是类似。

Warren Buffett Agent的实现

其核心代码在以下py文件中:src/agents/warren_buffett.py,我们同样可以让LLM帮助我们进行分析。
prompt如下:

请阅读以下代码,并且帮我分析其实现逻辑。
warren_buffett.py

返回如下:

# 代码分析:Warren Buffett 股票分析代理

这段代码实现了一个基于沃伦·巴菲特(Warren Buffett)投资原则的股票分析代理。下面我将详细分析其实现逻辑:

## 1. 整体架构

代码主要由以下几个部分组成:
- `WarrenBuffettSignal` 数据模型:定义分析结果的输出格式
- `warren_buffett_agent` 主函数:协调整个分析流程
- 多个分析函数:负责不同方面的财务分析
- `generate_buffett_output` 函数:使用LLM生成最终分析结果

## 2. 主要工作流程

1. **数据收集阶段**:
   - 获取财务指标(`get_financial_metrics`)
   - 获取财务科目数据(`search_line_items`)
   - 获取市值数据(`get_market_cap`)

2. **分析阶段**:
   - 基本面分析(`analyze_fundamentals`)
   - 一致性分析(`analyze_consistency`)
   - 护城河分析(`analyze_moat`)
   - 定价能力分析(`analyze_pricing_power`)
   - 账面价值增长分析(`analyze_book_value_growth`)
   - 管理层质量分析(`analyze_management_quality`)
   - 内在价值计算(`calculate_intrinsic_value`)

3. **综合评分阶段**:
   - 计算总分和最大可能分
   - 计算安全边际(margin of safety)

4. **LLM推理阶段**:
   - 使用LLM生成巴菲特风格的分析结果(`generate_buffett_output`)

## 3. 关键分析函数详解

### 3.1 基本面分析(`analyze_fundamentals`)
- 评估指标:
  - 股本回报率(ROE):>15%为优秀
  - 负债权益比:<0.5为保守
  - 营业利润率:>15%为优秀
  - 流动比率:>1.5为良好

### 3.2 护城河分析(`analyze_moat`)
- 评估指标:
  - 资本回报一致性(ROE和ROIC)
  - 营业利润率稳定性
  - 资产利用效率
  - 业绩稳定性(变异系数)

### 3.3 管理层质量分析(`analyze_management_quality`)
- 评估指标:
  - 股票回购行为(负值为回购)
  - 股票发行行为(正值为发行)
  - 分红记录

### 3.4 内在价值计算(`calculate_intrinsic_value`)
- 使用三阶段DCF模型:
  - 阶段1:高增长期(5年)
  - 阶段2:过渡期(5年)
  - 终值期:长期GDP增长率
- 使用所有者收益(owner earnings)而非净利润
- 应用15%的安全边际

### 3.5 账面价值增长分析(`analyze_book_value_growth`)
- 评估每股账面价值的增长一致性和复合增长率

### 3.6 定价能力分析(`analyze_pricing_power`)
- 评估毛利率趋势和稳定性

## 4. LLM集成

`generate_buffett_output`函数使用精心设计的提示模板,指导LLM以沃伦·巴菲特的思维方式和语言风格进行分析。提示模板包含:
- 巴菲特的核心原则
- 能力圈偏好
- 投资标准层次
- 语言风格指导
- 信心水平定义

## 5. 代码特点

1. **模块化设计**:每个分析功能独立封装,便于维护和扩展
2. **进度跟踪**:使用`progress.update_status`跟踪分析进度
3. **保守估计**:在多个分析中采用保守假设
4. **数据验证**:充分检查数据可用性
5. **详细记录**:保留分析细节和推理过程

## 6. 使用场景

这段代码适用于:
- 价值投资分析工具
- 股票筛选系统
- 投资教育平台
- 财务研究工具

代码实现了巴菲特投资理念的量化表达,结合了传统财务分析和现代LLM技术,能够生成符合巴菲特思维方式的投资建议。

Charlie Munger Agent的实现

其核心代码在以下py文件中:src/agents/charlie_munger.py,我们同样可以让LLM帮助我们进行分析。
prompt如下:

同样,请分析这份代码
charlie_munger.py

返回如下:

# 代码分析:Charlie Munger 股票分析代理

这段代码实现了一个基于查理·芒格(Charlie Munger)投资原则的股票分析代理。下面我将详细分析其实现逻辑:

## 1. 整体架构

代码主要由以下几个部分组成:
- `CharlieMungerSignal` 数据模型:定义分析结果的输出格式
- `charlie_munger_agent` 主函数:协调整个分析流程
- 多个分析函数:负责不同方面的财务分析
- `generate_munger_output` 函数:使用LLM生成最终分析结果

## 2. 主要工作流程

1. **数据收集阶段**:
   - 获取财务指标(`get_financial_metrics`)
   - 获取财务科目数据(`search_line_items`)
   - 获取市值数据(`get_market_cap`)
   - 获取内幕交易数据(`get_insider_trades`)
   - 获取公司新闻(`get_company_news`)

2. **分析阶段**:
   - 护城河强度分析(`analyze_moat_strength`)
   - 管理层质量分析(`analyze_management_quality`)
   - 业务可预测性分析(`analyze_predictability`)
   - 芒格式估值计算(`calculate_munger_valuation`)
   - 新闻情绪分析(`analyze_news_sentiment`)

3. **综合评分阶段**:
   - 按照芒格的权重偏好计算总分(护城河35%,管理层25%,可预测性25%,估值15%)
   - 生成简单的买入/持有/卖出信号

4. **LLM推理阶段**:
   - 使用LLM生成芒格风格的分析结果(`generate_munger_output`)

## 3. 关键分析函数详解

### 3.1 护城河强度分析(`analyze_moat_strength`)
- 评估指标:
  - 投资资本回报率(ROIC):>15%为优秀(芒格最看重的指标)
  - 定价能力:毛利率稳定性和趋势
  - 资本密集度:资本支出占收入比例(<5%为优秀)
  - 无形资产:研发投入和商誉/无形资产

### 3.2 管理层质量分析(`analyze_management_quality`)
- 评估指标:
  - 资本配置智慧:自由现金流与净利润比率
  - 债务管理:负债权益比(<0.3为优秀)
  - 现金管理效率:现金与收入比率(10-25%为理想)
  - 内幕交易活动:买入/卖出比例
  - 股票数量变化:芒格偏好稳定或减少的流通股

### 3.3 业务可预测性分析(`analyze_predictability`)
- 评估指标:
  - 收入稳定性和增长:平均增长率和波动性
  - 营业利润稳定性:正营业利润的时期比例
  - 利润率一致性:营业利润率的波动性
  - 现金生成可靠性:正自由现金流的时期比例

### 3.4 芒格式估值计算(`calculate_munger_valuation`)
- 使用简化方法:
  - 基于3-5年平均自由现金流(FCF)进行估值
  - 计算FCF收益率(自由现金流/市值)
  - 应用简单的倍数范围(保守10x,合理15x,乐观20x)
  - 评估安全边际(当前价格与合理价值的差距)

## 4. LLM集成

`generate_munger_output`函数使用精心设计的提示模板,指导LLM以查理·芒格的思维方式和语言风格进行分析。提示模板包含:
- 芒格的10条核心原则
- 分析规则和偏好
- 推理要求(应用2-3个心智模型)
- 芒格的语言风格指导

## 5. 代码特点

1. **芒格特色权重**:分析分数按芒格偏好加权(护城河最重要)
2. **长期视角**:使用10年数据进行分析
3. **多维度验证**:结合定量数据和定性因素(如内幕交易)
4. **保守估值**:避免复杂DCF,使用简单倍数
5. **逆向思维**:强调"避免愚蠢"而非追求聪明

## 6. 与巴菲特代理的对比

1. **重点差异**:
   - 芒格代理更强调ROIC而非ROE
   - 更关注内幕交易和管理层行为
   - 估值方法更简化直接
   - 权重分配反映芒格偏好(护城河35%)

2. **共同点**:
   - 都重视护城河和定价能力
   - 都偏好低债务和稳定现金流
   - 都使用LLM生成风格化分析

## 7. 使用场景

这段代码适用于:
- 价值投资分析工具
- 长期投资者筛选系统
- 投资教育平台
- 公司治理研究工具

代码实现了芒格投资理念的量化表达,结合了传统财务分析和现代LLM技术,能够生成符合芒格思维方式的投资建议。

总结

基于两份代码,我们得到以下规律:

  1. LLM给出总结如下:
以下是两份代码实现的对比分析表格及总结的实现规律:

---

### **沃伦·巴菲特代理 vs 查理·芒格代理对比分析**

| **对比维度**     | **沃伦·巴菲特代理**                                                                     | **查理·芒格代理**                                                                          | **异同总结**                                                                     |
| ---------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------- |
| **核心指标**     | - 重点分析ROE(股本回报率)<br>- 关注账面价值增长<br>- 强调安全边际(Margin of Safety) | - 核心指标为ROIC(投资资本回报率)<br>- 关注自由现金流(FCF)<br>- 简化估值方法(FCF倍数) | **差异**:巴菲特更重ROE和账面价值,芒格更重ROIC和FCF;**相同**:均重视资本回报率 |
| **估值方法**     | - 三阶段DCF模型(复杂)<br>- 计算内在价值后附加15%安全边际                              | - 简单FCF倍数法(10x/15x/20x)<br>- 直接比较FCF收益率与市值                                | **差异**:巴菲特用复杂DCF,芒格用简化倍数;**相同**:均要求估值保守性            |
| **管理层分析**   | - 检查股票回购/发行<br>- 评估分红记录                                                   | - 结合内幕交易数据(买入/卖出)<br>- 分析现金转换效率(FCF/净利润)                        | **差异**:芒格更依赖内幕交易数据;**相同**:均关注资本配置行为                   |
| **护城河分析**   | - 评估ROE一致性、利润率稳定性<br>- 检查资产效率                                         | - 强调ROIC一致性、资本密集度(Capex/Revenue)<br>- 关注无形资产(R&D、商誉)               | **相同**:均重视持久竞争优势,但芒格更量化资本效率                               |
| **数据周期**     | - 默认TTM(最近12个月)+10期历史数据                                                    | - 默认年度数据+10年历史                                                                    | **差异**:巴菲特偏短期趋势,芒格偏长期;**相同**:均需多期数据验证稳定性         |
| **LLM提示设计**  | - 强调"能力圈"和具体行业偏好(如消费品、银行)<br>- 引用巴菲特名言和案例(如可口可乐)  | - 要求应用"心智模型"(如逆向思维)<br>- 引用芒格语录(如"避免愚蠢")                       | **相同**:均需模仿投资大师的思维和语言风格                                       |
| **权重分配**     | - 均等权重(各分析模块分数简单相加)                                                    | - 明确权重:护城河35%、管理层25%、可预测性25%、估值15%                                     | **差异**:芒格代理显式定义权重,反映其"质量优先"理念                             |
| **输出信号逻辑** | - 依赖LLM综合判断生成信号                                                               | - 先量化评分(7.5分以上为买入)<br>- LLM补充理由                                           | **差异**:芒格代理更依赖量化阈值;**相同**:最终均由LLM生成风格化分析            |

---

### **实现规律总结**

1. **模块化分析框架**  
   - **规律**:均将投资理念拆解为独立分析模块(护城河、管理层、估值等),通过子函数实现。  
   - **目的**:增强可维护性,便于单独优化某一维度的逻辑。

2. **数据驱动的保守假设**  
   - **规律**:在估值和分析中刻意采用保守参数(如安全边际、增长率上限)。  
   - **示例**:巴菲特代理限制增长率为8%,芒格代理使用10x FCF的保守倍数。

3. **长期一致性验证**  
   - **规律**:均要求多期历史数据(5-10年),避免短期波动干扰判断。  
   - **体现**:`analyze_predictability()`和`analyze_moat()`均依赖长期趋势。

4. **LLM的角色分工**  
   - **规律**:量化分析提供结构化输入,LLM负责风格化输出。  
   - **分工**:  
     - 量化部分:计算分数、比率等硬性指标  
     - LLM部分:解释数据、应用投资哲学、生成自然语言

5. **差异化权重设计**  
   - **规律**:权重分配反映投资大师的偏好。  
   - **案例**:芒格代理中护城河权重(35%)>管理层(25%),体现其"质量优先"原则。

6. **逆向思维检查**  
   - **规律**:均包含"避免什么"的分析(如巴菲特代理检查负债,芒格代理检查内幕卖出)。  
   - **实现**:通过负向指标(如高负债、稀释股份)扣分或生成警告。

7. **渐进式状态跟踪**  
   - **规律**:使用`progress.update_status()`实时记录分析进度。  
   - **价值**:提升可观测性,便于调试和用户反馈。
  1. 从产品视角,结合我们前文的文字类AI应用,我们可以得到一个全新的应用,即金融分析类型的AI应用,其扩展思路完全可以参照以上分析做领域模型增强。
  2. 因为能够一贯的使用同一个模型结合其他领域的模型,我们称这个领域模型有很好的泛用性。
  3. 模型与模型之间的结合,完全可以依赖LLM带来的能力完成,我们只需要把控最终输出产物。
  4. 基于以上开发流程,我们可以总结一般性文字类相关的Agent开发流程:
    1. 设计基础的聊天类型的领域,并设置扩展点
    2. 扩展点需要结合新的领域内容,进行定向设置
    3. 尽量选择领域内容相互不相交的内容进行组合
    4. 人一定要把控最终输出内容

拆解AI应用领域模型

拆解AI应用领域模型

作为软件的Owner和开发人员,为了项目的可控性,笔者建议读者还是需要自行拆解,尽管拆解的实际步骤可以让模型来完成,但是我们需要知道其中过程是怎么样的。

以下是笔者实际如何完成核验的全过程,希望能给您的开发和设计起到帮助和启发。

场景表格化

作为软件项目的整个起始,按照DDD的原则,实际是需要拉取到相关利益方,坐下来一起讨论,软件应该满足哪些基本的需求。但是本书面向的是面向个人使用者和独立开发人员,其中利益相关方就是我们自己,所以这里完全就从简,由开发人员直接列举可能的场景,并将其格式化,形成软件需求说明书。

此步骤可交由模型完成,prompt如下

请根据我之前给出的应用场景描述,整理成表格,按照[场景,角色,交互形式]来整理,有不足的地方请帮我补充

回答如下:

AI问答系统场景分析表

场景分类 参与角色 交互形式 补充说明
推理生成 用户、推理引擎、工具代理 1. 用户提问 → 2. 引擎补全问题 → 3. 调用工具 → 4. 整理输出 需增加「结果校验」环节,确保工具返回数据的有效性
代码自生成执行 用户、代码引擎、沙箱环境 1. 用户需求 → 2. 生成初始代码 → 3. 沙箱执行 → 4. 错误修复 → 5. 返回结果 建议增加「执行历史」记录,支持代码片段复用
工具使用 用户、工具路由、MCP服务 1. 用户指令 → 2. 工具匹配 → 3. 鉴权调用 → 4. 结果适配 → 5. 响应输出 需补充「降级策略」,当首选工具不可用时自动切换备用方案
多工作流编排 用户、流程引擎、验证模块 1. 触发流程 → 2. 节点跳转 → 3. 自动验证 → 4. 人工复核 → 5. 流程归档 建议增加「版本快照」功能,支持流程回滚
知识库(RAG) 用户、检索引擎、推理辅助 1. 提问向量化 → 2. 知识检索 → 3. 结果排序 → 4. 逻辑增强 → 5. 最终响应 需补充「反馈学习」机制,根据用户采纳率优化检索权重

补充场景(根据模型特性新增)

场景分类 参与角色 交互形式 补充说明
混合决策 用户、仲裁引擎、多机器人 1. 并行调用多个机器人 → 2. 结果对比 → 3. 置信度评估 → 4. 最优结果选择 适用于医疗/金融等高风险场景
持续学习 管理员、训练模块、日志系统 1. 收集交互日志 → 2. 标注典型case → 3. 增量训练 → 4. 模型热更新 需设置「灰度发布」机制,避免全量更新风险
跨场景路由 用户、分类器、各场景入口 1. 意图识别 → 2. 场景匹配 → 3. 上下文迁移 → 4. 无缝衔接目标场景流程 关键在「上下文保持」技术,避免重复询问

请注意,使用模型时候,一定要把干的事情描述清楚,不要意图让模型读空气。

表格整理

表格整理的目的在于,我们需要梳理场景,并且尝试将场景进行归类。初步形成核心领域,周围支撑领域,方便下一步工作。

领域模型的初步整理

此步骤依然可以交给语言模型整理,开发人员负责将内容进行收敛,给予以下prompt

根据场景和模型,按照DDD的方法,构建类,请按照类所处领域范围,生命周期,是否持久化,进行分类,形成表格。类内字段不需要展开。

以下是回复

DDD领域模型分类表

核心领域(Core Domain)

类名 生命周期 持久化 领域职责说明
UserContext 用户会话周期 维护当前用户状态和安全上下文
Conversation 交互会话周期 管理问答会话的生命周期
BotOrchestrator 请求处理周期 协调多个机器人的执行流程
ExecutionTracker 任务执行周期 部分 记录分布式执行的中间状态

支撑子领域(Supporting Subdomain)

类名 生命周期 持久化 领域职责说明
MessageBus 系统运行周期 处理跨领域事件通信
AuthGateway 请求处理周期 统一鉴权和访问控制
LogAggregator 系统运行周期 集中处理操作日志和审计跟踪

通用子领域(Generic Subdomain)

类名 生命周期 持久化 领域职责说明
FileStorage 资源访问周期 统一管理多媒体文件存储
Notification 事件触发周期 部分 处理系统通知和用户提醒
ConfigManager 系统运行周期 管理运行时配置和参数

推理生成场景(Reasoning Context)

类名 生命周期 持久化 领域职责说明
PromptEngine 请求处理周期 问题补全和提示词优化
ToolBroker 工具调用周期 外部工具的发现和适配
EvidenceValidator 结果处理周期 部分 验证工具返回结果的合理性

代码执行场景(Coding Context)

类名 生命周期 持久化 领域职责说明
CodeGenerator 任务执行周期 根据需求生成可执行代码
SandboxRuntime 代码执行周期 隔离环境下的代码执行管理
DebugAssistant 错误处理周期 部分 分析执行错误并提供修复建议

工作流场景(Workflow Context)

类名 生命周期 持久化 领域职责说明
FlowDesigner 流程编辑周期 可视化流程编排和版本管理
NodeExecutor 节点执行周期 负责单个工作流节点的执行
Compensation 异常处理周期 实现分布式事务的补偿机制

知识库场景(Knowledge Context)

类名 生命周期 持久化 领域职责说明
VectorEngine 检索处理周期 实现向量相似度计算
ChunkManager 知识处理周期 管理知识分块和索引
FeedbackLearner 训练周期 根据用户反馈优化检索模型

生命周期类型说明

  1. 用户会话周期:随用户登录到注销
  2. 交互会话周期:单个问答会话的存活期
  3. 请求处理周期:单个API调用过程
  4. 任务执行周期:跨服务的长时间运行任务
  5. 系统运行周期:与应用程序同生命周期

持久化策略

  • :需要持久化到数据库
  • :仅内存中存在
  • 部分:部分数据需要持久化
  • 部分:部分数据需要持久化

模型返回内容审查

此时我们必须要进行检查,经过瞪眼法检查,其内容缺失了关键部分,我们前序整理模型到当前模型的映射关系 ,所以我们应该prompt如下:

检查发现没有融合前面所生成的领域模型,现请格式不变,并请将前文所述的《增强版本地问答交互模型(领域分层设计)》融合进去。

此时可以得到真实的模型如下:

DDD领域模型分类表(融合增强版)

核心领域(Core Domain)

类名 生命周期 持久化 领域职责说明 对应前文模型
UserContext 用户会话周期 维护当前用户状态和安全上下文 核心用户
Conversation 交互会话周期 管理问答会话的生命周期 交互会话
BotOrchestrator 请求处理周期 协调多个机器人的执行流程 机器人代理+执行编排
MessageRouter 消息处理周期 路由不同类型消息到对应处理器 交互消息

推理子领域(Reasoning Subdomain)

类名 生命周期 持久化 领域职责说明 对应前文模型
ReasoningEngine 任务执行周期 部分 实现多步推理和工具调用 推理引擎
ToolAdapter 工具调用周期 标准化外部工具接口 工具网关
EvidenceCache 系统运行周期 存储中间推理结果 媒体处理(分析结果)

代码子领域(Coding Subdomain)

类名 生命周期 持久化 领域职责说明 对应前文模型
CodeGenerator 任务执行周期 生成可执行代码 代码环境
SandboxController 代码执行周期 管理隔离执行环境 代码环境(沙箱配置)
DebugAnalyzer 错误处理周期 部分 提供代码修复建议 代码环境(修复策略)

工作流子领域(Workflow Subdomain)

类名 生命周期 持久化 领域职责说明 对应前文模型
FlowEngine 流程执行周期 驱动工作流节点执行 工作流引擎
NodeRepository 系统运行周期 存储可复用流程节点 工作流引擎(节点类型)
VersionSnapshot 流程变更周期 管理流程版本历史 工作流引擎(版本控制)

知识子领域(Knowledge Subdomain)

类名 生命周期 持久化 领域职责说明 对应前文模型
VectorSearcher 检索处理周期 执行向量相似度计算 知识融合
ChunkIndexer 知识处理周期 管理知识分块和索引 知识融合(嵌入模型)
HybridReasoner 结果处理周期 结合检索结果与逻辑推理 知识融合(增强模式)

支撑子领域(Supporting Subdomain)

类名 生命周期 持久化 领域职责说明 对应前文模型
MediaProcessor 资源处理周期 部分 统一处理多媒体内容 媒体处理
PriorityScheduler 系统运行周期 管理机器人执行优先级 机器人代理(执行优先级)
DataBridge 请求处理周期 处理跨领域数据转换 执行编排(数据传递规则)

通用子领域(Generic Subdomain)

类名 生命周期 持久化 领域职责说明 对应前文模型
ConfigRegistry 系统运行周期 管理系统配置参数 执行编排(超时设置)
MetricCollector 系统运行周期 收集运行时性能指标 工具网关(熔断机制)
EventPublisher 事件触发周期 处理领域事件分发 交互消息(时序标记)

关键映射说明

  1. 领域整合
  • 前文”机器人代理”拆分为BotOrchestrator(核心) + ToolAdapter(推理) + PriorityScheduler(支撑)
  • “执行编排”转化为DataBridge(支撑) + FlowEngine(工作流)
    1. 生命周期优化
  • 原”媒体处理”的瞬时分析状态归入EvidenceCache

  • 持久化部分升级为MediaProcessor

    1. 能力下沉
  • 原”增强模式”逻辑上移至HybridReasoner

  • 核心的”交互会话”保持最简状态,复杂逻辑外移到子领域

    1. 新增能力

持久化策略增强

存储类型 对应类 存储内容示例
关系型数据库 Conversation,VersionSnapshot 会话元数据、流程版本
文档数据库 ChunkIndexer,EvidenceCache 知识块、推理中间结果
键值存储 ConfigRegistry,MetricCollector 运行时配置、性能指标
对象存储 MediaProcessor 多媒体文件和分析结果

经过以上整理,我们基本可以得到一个可用的顶层模型,一般而言,作为架构师的工作就接近结束了 ,但是作为独立软件的开发人员,目前仅仅是迈出了最重要的一步,得到一个可用的模型。

接下来我们需要验证模型,此时我们要为领域内模型定义出具体的行为,并按照场景逐个事例验证。

领域内模型行为整理

同样的,我们可以利用语言模型协助我们完成行为的初步整理。prompt如下:

至此,请为领域内的模型设计其行为,请在各子领域内的列表扩展三列,1. 模型的行为中文名,2. 模型行为英文命名,3. 模型行为说明。

返回如下:

DDD领域模型行为设计(完整版)

核心领域(Core Domain)

类名 行为中文名 行为英文命名 行为说明 对应模型
UserContext 身份验证 authenticate 验证用户token并加载权限上下文 核心用户
会话绑定 bindSession 将用户与当前会话建立关联
权限检查 checkPermission 验证用户对指定资源的操作权限
Conversation 会话初始化 initialize 创建新会话并设置默认参数 交互会话
状态转换 transitionState 管理会话生命周期状态(进行中/挂起/结束)
超时处理 handleTimeout 检测并处理空闲会话
BotOrchestrator 机器人调度 scheduleBots 根据优先级和依赖关系调度机器人执行 机器人代理+执行编排
结果聚合 aggregateResults 合并多个机器人的输出结果
异常熔断 circuitBreak 当连续失败时自动隔离故障机器人

推理子领域(Reasoning Subdomain)

类名 行为中文名 行为英文命名 行为说明 对应模型
ReasoningEngine 问题重构 reformulateQuestion 使用思维链技术优化原始问题 推理引擎
工具选择 selectTools 根据问题类型匹配最佳工具集
结果验证 validateOutput 检查工具返回值的逻辑合理性
ToolAdapter 协议转换 convertProtocol 将内部请求转换为目标工具API格式 工具网关
负载均衡 balanceLoad 在多个工具实例间分配请求
结果标准化 normalizeResult 将异构工具输出转为统一格式
EvidenceCache 证据存储 storeEvidence 缓存推理过程的中间结果 媒体处理
相关性过滤 filterRelevance 根据当前会话筛选相关历史证据
版本快照 takeSnapshot 保存特定时间点的完整推理上下文

代码子领域(Coding Subdomain)

类名 行为中文名 行为英文命名 行为说明 对应模型
CodeGenerator 代码生成 generate 根据自然语言描述生成可执行代码 代码环境
注释补充 addComments 自动生成代码解释文档
代码优化 optimize 应用性能优化模式重构代码
SandboxController 环境隔离 isolateEnvironment 创建安全的执行沙箱 代码环境(沙箱配置)
资源限制 enforceLimits 监控和控制CPU/内存使用量
环境回收 cleanup 终止运行并释放所有资源
DebugAnalyzer 错误分类 classifyError 识别语法/逻辑/运行时异常 代码环境(修复策略)
修复建议 suggestFix 提供可执行的修复方案
模式学习 learnPattern 从历史错误中归纳常见问题模式

工作流子领域(Workflow Subdomain)

类名 行为中文名 行为英文命名 行为说明 对应模型
FlowEngine 流程驱动 driveFlow 按节点顺序执行工作流 工作流引擎
条件评估 evaluateCondition 计算节点转移条件的布尔值
自动回滚 autoRollback 失败时执行预定的补偿操
NodeRepository 节点注册 registerNode 添加新的可复用流程节点 工作流引擎(节点类型)
依赖解析 resolveDependencies 检查节点间的输入输出匹配
性能分析 analyzePerformance 统计节点执行耗时和资源占用
VersionSnapshot 版本创建 createVersion 保存当前流程的完整快照 工作流引擎(版本控制)
差异比较 diffVersions 显示两个版本间的变更点
版本回退 revertToVersion 将流程恢复到指定历史版本

知识子领域(Knowledge Subdomain)

类名 行为中文名 行为英文命名 行为说明 对应模型
VectorSearcher 向量检索 semanticSearch 执行基于embedding的相似度搜索 知识融合
混合排序 hybridRanking 结合关键词匹配和语义相似度综合排序
结果解释 explainScore 生成检索结果的置信度说明
ChunkIndexer 分块处理 chunkDocument 将文档分割为带语义的段落 知识融合(嵌入模型)
增量索引 incrementalIndex 只更新变更部分的向量索引
质量评估 assessQuality 检查知识块的信息完整性和准确性
HybridReasoner 逻辑验证 logicalVerify 对检索结果进行因果推理验证 知识融合(增强模式)
矛盾检测 detectConflict 识别结果中的逻辑矛盾点
证据加权 weightEvidence 根据可信度调整不同来源的权重

行为设计原则

  • 单一职责:每个行为对应一个明确的业务目标,三者形成递进关系但职责分离
  • 分层调用
   # 典型调用链示例
   class BotOrchestrator:
       def execute(self):
           self.scheduleBots()  # 核心领域
           ToolAdapter.convertProtocol()  # 推理子领域
           FlowEngine.driveFlow()  # 工作流子领域
  • 异常处理
行为类型 重试策略 降级方案
工具调用 指数退避重试(3次) 返回缓存结果+标记”可能过时”
代码执行 立即重试(仅语法错误) 提供等效API调用方案
知识检索 扩展查询条件重试 返回部分匹配结果+建议修正查询
  • 性能关键行为
    • 向量检索:支持近似最近邻(ANN)算法
    • 代码生成:使用预编译模板加速
    • 流程驱动:异步执行独立节点
  • 可观测性

内容核验

我们可以要求模型将行为和场景联系在一起,此时我们检查的工作量会减少很多。
prompt如下:

回复如下:

AI问答系统场景行为映射表

场景分类 参与角色 交互形式 模型行为组合 补充说明
推理生成 用户、推理引擎、工具代理 1. 用户提问 → 2. 引擎补全问题 → 3. 调用工具 → 4. 整理输出 ReasoningEngine.reformulateQuestion + ToolAdapter.convertProtocol + EvidenceCache.storeEvidence 需增加「结果校验」环节,确保工具返回数据的有效性
代码自生成执行 用户、代码引擎、沙箱环境 1. 用户需求 → 2. 生成初始代码 → 3. 沙箱执行 → 4. 错误修复 → 5. 返回结果 CodeGenerator.generate + SandboxController.isolateEnvironment + DebugAnalyzer.suggestFix 建议增加「执行历史」记录,支持代码片段复用
工具使用 用户、工具路由、MCP服务 1. 用户指令 → 2. 工具匹配 → 3. 鉴权调用 → 4. 结果适配 → 5. 响应输出 ToolAdapter.balanceLoad + UserContext.checkPermission + ToolAdapter.normalizeResult 需补充「降级策略」,当首选工具不可用时自动切换备用方案
多工作流编排 用户、流程引擎、验证模块 1. 触发流程 → 2. 节点跳转 → 3. 自动验证 → 4. 人工复核 → 5. 流程归档 FlowEngine.driveFlow + NodeRepository.resolveDependencies + VersionSnapshot.createVersion 建议增加「版本快照」功能,支持流程回滚
知识库(RAG) 用户、检索引擎、推理辅助 1. 提问向量化 → 2. 知识检索 → 3. 结果排序 → 4. 逻辑增强 → 5. 最终响应 VectorSearcher.semanticSearch + ChunkIndexer.incrementalIndex + HybridReasoner.logicalVerify 需补充「反馈学习」机制,根据用户采纳率优化检索权重
混合决策 用户、仲裁引擎、多机器人 1. 并行调用多个机器人 → 2. 结果对比 → 3. 置信度评估 → 4. 最优结果选择 BotOrchestrator.scheduleBots + BotOrchestrator.aggregateResults + ReasoningEngine.validateOutput 适用于医疗/金融等高风险场景
持续学习 管理员、训练模块、日志系统 1. 收集交互日志 → 2. 标注典型case → 3. 增量训练 → 4. 模型热更新 DebugAnalyzer.learnPattern + EvidenceCache.filterRelevance + VectorSearcher.hybridRanking 需设置「灰度发布」机制,避免全量更新风险
跨场景路由 用户、分类器、各场景入口 1. 意图识别 → 2. 场景匹配 → 3. 上下文迁移 → 4. 无缝衔接目标场景流程 Conversation.transitionState + UserContext.bindSession + FlowEngine.evaluateCondition 关键在「上下文保持」技术,避免重复询问

行为组合说明

推理生成场景

代码自修复场景

工具路由场景

典型行为参数映射

场景 关键行为参数
知识检索 semanticSearch(query: string, filters: {minScore: 0.7, maxResults: 5})
工作流编排 driveFlow(flowId: string, context: {timeout: 5000, retryPolicy: 3})
混合决策 aggregateResults(strategy: "weightedVote", weights: {botA: 0.6})

异常处理行为映射

异常类型 应对行为
工具调用超时 ToolAdapter.circuitBreak + EvidenceCache.filterRelevance
代码安全违规 SandboxController.enforceLimits + DebugAnalyzer.classifyError
流程节点卡死 FlowEngine.autoRollback + VersionSnapshot.revertToVersion
知识检索空结果 HybridReasoner.weightEvidence + ReasoningEngine.reformulateQuestion

性能关键行为组合

感兴趣的读者可以自行核验一下。
至此,整个建模工作就可以结束了,接下来就是比较无聊的开发时间。后文不再赘述。

总结

纵观以上内容,我们可以总结出人与模型应该如何进行交互。

  1. 我们总是要将问题尽可能的收敛,此时模型的回复才可以尽可能的精确
  2. 我们要自行掌握校验模型内容的方法,可以将繁琐的表格工作交由模型,但是最后的核验如果不亲自上手,后续步骤会导致开发中问题发散
  3. 使用模型时候需要渐进式的提问,预期中一句话生成一个应用的想法既不现实,也不会可行。

我们也可以看看模型是怎么帮我们总结的:

总结:架构师如何与大模型互动及渐进式提问指南

1. 明确目标,分阶段拆解

架构师在利用大模型辅助设计时,需将复杂问题拆解为多个阶段,逐步细化。例如:

  • 场景分析:先整理核心场景(如“推理生成”“代码执行”),再补充细节(如异常处理、性能优化)。
  • 模型设计:从领域分类(核心/支撑子领域)到类定义,最后填充行为逻辑,避免一次性生成完整模型导致偏差。

2. 渐进式提问,逐步收敛

  • 初始阶段:用宽泛问题获取框架(如“按DDD方法整理领域模型”)。
  • 细化阶段:通过追加条件修正结果(如“检查并融合前文模型”)。
  • 验证阶段:要求模型关联场景与行为(如“将行为映射到具体交互流程”)。

3. 模型为助手,人为决策者

  • 生成内容:将重复性工作(表格整理、类定义)交给模型,提升效率。
  • 核验关键:人工审查模型输出的逻辑一致性(如生命周期、持久化策略是否合理)。
  • 补充上下文:通过迭代提问(如“增加异常处理行为”)完善细节,而非依赖单次生成。

4. 工具化协作模式

  • 输入清晰:避免模糊描述,明确约束(如“按[场景,角色,交互形式]列表”)。
  • 输出结构化:要求模型以表格、流程图(如Mermaid)或分层列表呈现,便于后续开发直接复用。
  • 异常处理:针对高风险场景(如工具调用超时),单独提问设计降级策略。

5. 持续反馈与优化

  • 动态调整:根据模型反馈修正问题描述(如发现缺失“版本快照”功能后补充提问)。
  • 知识沉淀:将验证过的模型输出转化为文档,作为团队共识的领域语言(Ubiquitous Language)。

最终原则:大模型是架构设计的“加速器”,但核心决策(领域边界、关键行为)必须由架构师掌控。通过渐进式交互,既能发挥模型的高效性,又能确保系统的可控性与一致性。

文字类AI的几种场景

文字类AI的几种场景

推理生成

主要指的是各大Reasoning类型的模型结合了外部工具,帮助用户补全提问,然后再通过环境(Enviroment)执行得到结果后,由模型整理输出的结果

代码自生成执行

这一类应用通常是提供了代码执行环境,让LLM自行输出需要执行的代码,是最接近科幻样子的形态,但是由于模型的限制,通常一次生成的代码不能够很好的完成用户的提问意图。

工具使用

这一类主要是指functionCall或者LLM,与代码子生成不同,人类的MCP-Server总是保证可以正常执行,这里的问题在于,需要Tool的种类非常多,如果应用面向的问题空间过于宽泛,为了把可用的所有MCP工具让AI使用起来会极大的压缩了用户提问的空间。

多工作流编排

这类应用多出现在智能客服,智能销售类,其天然的缩小了问题范围,且通过流程完全的将解和验证固化下来。

缺点是,迁移和修改成本高,是落地应用最多的一类应用

知识库(RAG)

这种应用依赖于embedding对提问和答案的关联关系,计算出固定的最佳结果,常见于非标知识库构建,回答的答案质量极高。但是因为其只有相关性,没有因果推导,极大的限制了应用场景,通常会配合工作流作为其中一个小节点来提供服务。

领域模型的重构

以上我们列举了常见的几种文字类的AI应用的场景,我们能够轻易的发现,其有一些共同的特点,也有一些不同,共同的地方都是按照Q&A的方式进行服务的,不同的地方在于接收到Q之后,如何与LLM进行编排,才能够服务。尽管应用面向的场景可能非常多,不过我相信基本逃脱不了以上描述的场景。
因此,我们需要对前文提到的会话模型进行重构,要填入一些辅助的模型,以满足以上场景。
以下是让LLM协助我们完成原初步会话模型的模型重构的提示词:
第一次提问

现整理的模型为核心模型,请根据以下给定的应用场景描述,帮我补充整个模型,使得模型能够满足给定的场景描述,

+上述内容
第二次提问:

请将模型图划分为核心领域,与周围辅助领域,再重新绘制一次,并将答案更新然后重新返回

以下是LLM帮助我们完成的领域模型重构内容:

增强版本地问答交互模型(领域分层设计)

领域划分说明

核心领域(黄色区域)

辅助领域(蓝色区域)

支撑领域(绿色区域)

完整领域关系图

领域协作流程

核心领域职责

1. 用户身份管理(`核心用户`)
2. 对话生命周期管理(`交互会话`)
3. 机器人调度中枢(`机器人代理`)

辅助领域扩展

| 场景类型 | 核心协作机制                 |
| -------- | ---------------------------- |
| 推理生成 | 机器人代理→推理引擎→工具网关 |
| 代码执行 | 机器人代理→代码环境→执行编排 |
| 工具使用 | 工具网关←→工作流引擎         |
| 知识检索 | 知识融合→交互消息→媒体处理   |

关键交互协议

模型演进建议

  1. 核心领域
  • 保持最小功能集,仅包含会话路由和状态管理
  • 机器人代理作为抽象基类,不实现具体逻辑
    1. 辅助领域
  • 各场景模块实现标准化接口:

    “`python
    class RobotInterface:
    def pre_process(self, input):…
    def execute(self, context):…
    def post_process(self, result):…
    “`

  • 通过配置热加载不同实现类

    1. 支撑领域
  • 提供跨领域公共服务:

  • 消息序列化、异常处理、状态持久化

    1. 领域间通信
  • 使用事件总线实现松耦合:

版本控制策略

领域层级 变更策略 兼容性要求
核心领域 大版本迭代(v1.0→v2.0) 保持接口向后兼容
辅助领域 功能版本(v1.1→v1.2) 可选升级
支撑领域 热修复(v1.1.1→v1.1.2) 向下兼容

AI应用的技术选型

AI应用的技术选型

书接前文,我们的第一版建设的模型是非常高层级的领域模型,只讨论了一般意义上的本地聊天形式的AI软件的模型。属于是核心领域模型。

但是软件开发中,仅有核心领域模型是无法完成功能的组合,此时我们还需要一些周边辅助的领域模型进行结合。考虑到整个AI应用的开发仍是一个非常崭新的领域,我们借鉴了一部分旧有模型的核心领域,我们还需要在开发中不断的迭代、重构,才可以构建出一个完备的AI文字聊天类的应用模型。

因此,我们在粗浅的领域模型构建完毕后,先放下头脑,开始尝试落地第一版模型。

AI应用的技术选型的一些经验

当前时间节点,以下仅为我当初选型时候的参考。

  • 语言选择
    • Python:是LLM的发家语言,优点是拥有最完备的SDK,假如你的应用直接基于Python完成前后端开发,推荐直接使用OpenAI的SDK,这是最有可能一直有人维护的基础软件包。缺点在于,对于个人端其RPC开发成本较高,对个人开发者并不是太友好。
    • Java、C#:此类型语言的大部分软件主要是CS模型软件采用,拥有最多的用户群体,但是目前主要面向的对象是企业后端研发也就是CS中的S端,不推荐面向个人用户的软件采用这种类型的开发语言,语言互操作较为繁琐,其主要是各个MaaS平台提供各自平台的SDK库。优点是,能和原有的大型CS软件直接集成,缺点是,对个人开发者不友好,对个人使用者,设备性能要求极高。
    • TS/JS:此类语言在客户端开发中逐渐的火热起来,其配合Electron能够非常快速的搭建起本地应用,同时因为NodeJS中对于C操作的良好兼容性,能够较好的调用本地资源,且Electron作为本地开发框架,能够非常好的启动多种服务,通过RPC方式完成多语言的交互。缺点是,Windows现在较新的应用都是electron框架,本质是个浏览器,打包之后的应用太大了,普通的应用都需要1GB左右的空间。如果对齐定制裁剪,成本特别高。
  • 模型部署选择
    • 本地自行部署,企业级的如自行部署Sglang,vLLM环境,个人的如Ollama。优点是数据的绝对不外泄,缺点是成本非常高,企业级硬件成本200万人民币到1000万人民币左右,人员成本每年约100万左右,个人级别的,如性价比最高的苹果Mac Stdio顶配,可以运行681B-q4,约8万到10万。如果采用稍微小一点的模型如,70B左右,其量化后表现较差,且人员费用仍然较多。
    • MaaS形式,即云服务平台提供模型运行时环境,用户只需要按照接口调用,按时按量付费(含微调,训练),此类型的好处是启动成本较低,缺点是,信息安全敏感行业会不适用。
  • 模型选择
    • 单模态模型

    • 推理模型,在知识问答类的场景非常适用,本质能够帮助用户完成prompt的扩展,通过较长的前置提示词,完成对问题的解的精确划分。

    • 非推理类模型,适用于指令类场景,例如总结文字,例如扩写文字。
    • 多模态模型

    • 文字,语音,视频等在一个会话中天然全部支持,优点是无需前置将非文字类内容转换为文字后再由模型处理,缺点是,模型较小,模型评分与纯的文字类LLM模型相比,回答质量较差。

    • 特定用途模型,特点是专业领域内的事情,比通用语言模型强非常多,缺点是,非专业领域内的事情无法处理,需要开发人员根据自己的场景进行模型处理流程的编排,且接入较为繁琐不支持openai-sdk的形式,一般有以下几种:

    • 语音转文字

    • 文字生成语音
    • 文字生成图片
    • 文字生成视频

    AI软件的技术选型是非常需要架构人员和产品人员深度参与,结合,分析的,其面向的场景极其复杂,不再是当前企业端软件的标准化开发,模型的能力,技术栈的能力都需要非常的具体化的讨论。上述的一些我当初做技术筛选的内容,如果能够帮助到你,笔者深感荣幸。

我的AI应用的技术选型

结合本书前文提及,我开发的AI软件,在特定时间段时候也是单纯的AI文本类应用。以下是我的技术选型:

  • 我的AI文本类应用的技术选型
    • 基础开发框架,我开发的软件是面向个人用户使用的,其完全在客户的本地完成数据的管理,所以整个开发框架选择了跨平台的Electron。
    • 其前端选择了React+antdX,后端使用Electron的nodejs
    • 模型选择了DeepSeek-V3
    • 模型运行时采用MaaS形式,基础平台采用了阿里云的百炼
    • 模型的调用采用了OpenAI-SDK。

总结

此处采用LLM协助,其Prompt提示词为上述文本加入以下语句

请帮我写一段总结,并以 markdown 格式返回结果:

+上述内容

技术选型总结

核心要点回顾

  1. 领域模型构建
  • 初始构建了高层级核心领域模型,聚焦本地聊天式AI软件
  • 需要结合辅助领域模型才能实现完整功能组合
  • 强调在开发过程中持续迭代重构的重要性
    1. 技术选型关键维度
  • 语言选择:Python/Java/C#/TS-JS的适用场景与优劣对比

  • 部署方式:本地部署与MaaS的性价比与安全性权衡
  • 模型类型:单模态/多模态/专用模型的场景匹配度

    1. 选型决策逻辑
  • 架构师与产品需深度参与场景分析

  • 需综合考虑:
    • 目标用户群体(企业/个人)
    • 数据安全要求
    • 成本约束
    • 技术栈延续性

实践案例

个人级AI文本应用选型方案

  • 框架选择:Electron(跨平台本地化)
  • 技术栈:
    • 前端:React + antdX
    • 后端:Node.js
  • 模型方案:
    • 基模:DeepSeek-V3
    • 部署:阿里云百炼(MaaS)
    • 接口:OpenAI-SDK

经验启示

  1. 平衡法则
  • 在”数据安全-开发成本-用户体验”三角中寻找平衡点
  • 个人级应用需特别关注安装体积和启动性能
    1. 演进思维
  • 初始选型应保留可扩展性

  • 建议采用”核心不变+插件化”架构应对模型迭代

    1. 特殊考量
  • Windows平台需注意Electron应用体积问题

  • 多模态需求要提前评估模型响应质量

构建AI应用的建模分析

构建AI应用的建模分析

软件开发中较为重要的一点是对软件面向的问题进行建模,建模的方式有很多种,在复杂的业务交互中较为常见的是DDD(Domain Drive Design)领域模型驱动驱动设计。

考虑到AI应用总是需要结合到具体的场景中进行拆解,重组。因此我比较推荐使用领域模型对AI应用建模。

领域划分

从上一章节我们可以分析到,不同场景类型的AI应用,总是需要不同的模型,并且需要有机的组合才能去初步的解决问题,本章我们决定对应用粗浅的分类三类

  • 纯文字交互类
  • 音视频操作类
  • 图像生成类

本书总是以 纯文字交互类的AI应用开发为主线,望各位读者知悉

纯文字交互类的AI应用建模

纯文字类的AI应用是LLM模型出来时候第一个我们接触到的交互形式,具体我们可以回看谷歌Gemini和OpenAI的ChatGPT时候的发布会。

其交互形式为:

  1. 用户输入一段提示词,可能是问题,可能是指令加内容,模型返回答案或者操作结果;
  2. 软件预制了一段提示词,用户以语音形式输入,通过专用模型转换为文字后,实际以文字与模型交互,然后模型吐出字符后,通过文字转语音(TTS)完成交互;

根据以上分析,我们可以参考的最佳领域模型就是聊天软件的领域模型,而且必须是精简后的,非常高层级的领域模型。

聊天软件的领域模型建模

作为AI软件开发的软件工程师,绝对不能采取是自己独自冥思苦想,必须学会利用LLM做为自己最大的助力。

所以,此处实例采用DeepSeek-R1-0524推理模型构建,其prompt提示词为:

我需要构建一个类似聊天问答的输入交互软件,可能包含群聊,单聊,带功能的机器人。聊天的内容包含,文字,语音,图片,视频,文件。请以文字方式帮我整理输出其领域模型,并且需要说明,每个模型划分的原因,面向的场景,并以Markdown格式返回。

聊天软件领域模型

1. 用户模型

  • 属性
    • 用户ID: 唯一标识
    • 用户名: 显示名称
    • 头像: 图片链接
    • 是否机器人: 布尔值
    • 在线状态: 在线/离线/忙碌
  • 划分原因
    区分真实用户与自动化服务,统一管理基础信息
  • 使用场景
    用户登录、联系人列表展示、状态监控

2. 会话模型

  • 属性
    • 会话ID: 唯一标识
    • 会话类型: 私聊/群组/频道
    • 成员列表: 用户ID集合
    • 会话标题: 群组名称
    • 创建时间: 时间戳
  • 划分原因
    抽象沟通场景的共同特征
  • 使用场景
    新会话创建、消息分发、未读消息统计

3. 消息模型

  • 属性
    • 消息ID: 唯一标识
    • 发送者: 用户ID
    • 所属会话: 会话ID
    • 内容类型: 文本/语音/图片/视频/文件
    • 内容主体: 文字内容或文件链接
    • 发送时间: 时间戳
    • 阅读状态: 已发送/已送达/已读
  • 划分原因
    统一消息处理管道,支持多媒体交互
  • 使用场景
    消息收发、状态同步、历史记录查询

4. 媒体资源模型

  • 属性
    • 资源ID: 唯一标识
    • 文件类型: 音频/图片/视频/文档
    • 存储路径: 文件地址
    • 文件大小: 字节数
    • 持续时间: 音视频时长(秒)
    • 缩略图: 预览图链接
  • 划分原因
    独立管理大文件资源,优化传输效率
  • 使用场景
    文件上传下载、多媒体预览、存储管理

5. 智能助手模型

  • 属性
    • 助手ID: 关联用户ID
    • 指令列表: 支持的功能命令
    • 应答规则: 关键词响应配置
    • 服务接口: 外部API地址
  • 划分原因
    扩展标准用户能力,实现自动化服务
  • 使用场景
    指令响应(如/天气)、智能问答、服务对接

6. 功能指模型

  • 属性
    • 指令ID: 唯一标识
    • 触发词: 如/帮助
    • 功能说明: 描述文本
    • 处理器: 本地函数或远程接口
  • 划分原因
    标准化机器人交互方式
  • 使用场景
    快捷操作触发、功能发现、权限控制

模型关系说明

设计要点说明

  1. 多格式消息处理
    通过 内容类型字段自动适配不同消息的展示形式,文本直接呈现,多媒体调用对应渲染组件
  2. 智能助手扩展
  • 基础版:配置 应答规则实现自动回复
  • 高级版:通过 指令列表+服务接口对接外部系统
  • 示例场景:发送”/翻译 你好”触发翻译服务
    1. 资源优化方案
  • 大文件独立存储,消息体仅保存元数据

  • 自动生成 缩略图提升图片加载效率
  • 持续时间字段支持音视频进度控制

    1. 会话统一管理
      私聊视为两人群组的特例,减少系统复杂度,群组专属字段在私聊时自动隐藏
    2. 状态追踪机制
  • 阅读状态实现消息已读回执

  • 在线状态实时显示用户可用性

AI聊天类应用软件的初步建模

考虑到,我们构建的应用软件还不需要那么复杂的富文本交互,我们可以采取精简场景策略。利用LLM帮助我们裁剪模型。以下是本次希望精简模型的prompt:

考虑到,我的软件是面向本地问答类型的,可能暂时不需要多用户参与,但是多机器人交互可能需要,同时需要对不同机器人交互顺序进行编排,不需要人类在线交互,请帮助我修改模型。

本地问答交互软件领域模型设计(单用户多机器人版)

1. 核心用户模型

  • 属性
    • 用户ID: 唯一标识(固定为本地用户)
    • 用户名: “本地用户”
  • 划分原因
    简化多用户系统,聚焦单用户场景
  • 使用场景
    作为所有交互的发起者和接收者

2. 机器人代理模型

  • 属性
    • 机器人ID: 唯一标识
    • 机器人名称: 显示名称
    • 能力类型: 问答/工具/分析等
    • 执行优先级: 数值(用于编排)
    • 输入格式: 支持的数据类型
    • 输出格式: 返回的数据类型
    • 服务端点: 本地函数或API地址
  • 划分原因
    作为核心交互对象,强化编排能力
  • 使用场景
    机器人注册、执行链编排、多机器人协作

3. 交互会话模型

  • 属性
    • 会话ID: 唯一标识
    • 参与机器人: 机器人ID列表
    • 当前状态: 进行中/已完成
    • 创建时间: 时间戳
  • 划分原因
    管理单次问答的生命周期
  • 使用场景
    会话创建、机器人执行顺序管理、结果汇总

4. 交互消息模型

  • 属性
    • 消息ID: 唯一标识
    • 所属会话: 会话ID
    • 发送方: 用户/机器人ID
    • 接收方: 机器人ID(可多个)
    • 内容类型: 文本/数据/文件
    • 内容主体: 问题或结果数据
    • 时序标记: 执行顺序编号
  • 划分原因
    支持多机器人顺序/并行处理
  • 使用场景
    问题分发、中间结果传递、最终答复组装

5. 执行编排模型

  • 属性
    • 流程ID: 唯一标识
    • 触发条件: 关键词/意图
    • 机器人序列: 有序机器人ID列表
    • 数据传递规则: 输入输出映射
    • 超时设置: 毫秒数
  • 划分原因
    核心控制多机器人协作逻辑
  • 使用场景
    复杂问题拆解、多步骤任务处理、机器人流水线

6. 媒体处理模型

  • 属性
    • 资源ID: 唯一标识
    • 来源消息: 消息ID
    • 媒体类型: 图片/音频/视频/文件
    • 处理状态: 待处理/分析中/已完成
    • 分析结果: 文本/标签/元数据
  • 划分原因
    专门处理多媒体问答需求
  • 使用场景
    图像识别、语音转文字、文件内容提取

模型关系说明

设计要点说明

  1. 单用户多机器人架构
  • 移除多用户相关属性,聚焦本地用户场景
  • 机器人代理模型增强服务端点定义,支持本地函数调用
    1. 机器人编排核心机制
  • 执行优先级:控制机器人调用顺序

  • 时序标记:跟踪多步骤执行过程
  • 数据传递规则:定义机器人间输入输出映射
  • 示例流程

    “`
    用户问题 → 路由机器人(优先级1) → 分析机器人(优先级2) → 执行机器人(优先级3) → 最终答复
    “`

    1. 多媒体处理流程
  • 媒体处理模型独立存储分析状态

  • 支持异步处理:用户上传图片 → 图片分析机器人 → 文本结果返回

    1. 会话生命周期管理
  • 交互会话绑定多个机器人

  • 通过 当前状态跟踪问答进度

    1. 异常处理设计
  • 超时设置自动终止长时间未响应流程

  • 媒体 处理状态跟踪分析进度

    1. 扩展性考虑
  • 机器人 能力类型支持动态扩展

  • 数据传递规则允许自定义输入输出转换
  • 新增机器人只需注册到系统即可参与编排

总结

本文介绍了如何利用领域驱动设计(DDD)对AI应用进行建模,重点聚焦纯文字交互类应用。通过借鉴聊天软件的领域模型,将其精简为适用于单用户多机器人交互的场景,包含核心用户、机器人代理、交互会话、交互消息、执行编排和媒体处理六大模型。这些模型支持多机器人协作、任务编排和多媒体处理,为构建本地问答型AI应用提供了清晰的架构设计思路。

AI应用的分类

AI应用的分类

分类 产品名称 开发公司 主要功能 特点
内嵌AI应用 钉钉AI助理 阿里巴巴 自动文档生成、会议摘要、智能排程、法律助手 支持第三方开发者扩展,基于AIPaaS平台构建生态
飞书智能伙伴(MyAI) 字节跳动 会议纪要自动生成、报告撰写、业务洞察分析 支持多模型切换,可集成至飞书机器人
腾讯会议AI小助手 腾讯 语音转文字、人脸识别、智能翻译 开放API,支持企业定制化集成
WPS AI智能办公助手 金山办公 文档自动生成、智能排版、图表制作 深度整合WPS全线产品,支持企业级部署
百度如流AI助手 百度 会议洞察、知识管理、智能报销 支持多终端接入,深度对接企业系统
工业AI应用 恒生电子-光子 恒生电子 金融咨询、自动化后台操作、投资分析 整合金融工具链,提升金融机构效率
医联-AI医生 医联 智能初诊、病例分析、健康管理 接近三甲医院诊断水平,支持多模态学习
京东京言AI助手 京东 商品推荐、专业知识解答 优化电商客服体验,提升转化率
工程领域大模型平台 宁夏交建等 智能体搭建、工程数据分析 结合行业插件,实现复杂任务自动化
船舶行业大模型“百舸” DeepSeek等 市场指标查询、订单预测 与DeepSeek-R1深度集成,推动行业智能化
独立AI应用 Kimi(月之暗面) 月之暗面 长文本处理、联网搜索、学术辅助 支持20万字上下文,适合深度研究
AutoGLM 沉思 智谱AI 自主浏览网页、深度研究、报告生成 首个免费GUI Agent,支持复杂任务拆解
文心智能体 百度 Prompt编排智能体、多模态生成 支持零代码/低代码开发,商业分发能力强
讯飞星火助手 科大讯飞 结构化指令模板、知识库调用 面向企业场景,支持API集成
百小应 百川智能 多轮搜索、文件阅读、语音交互 基于Baichuan 4模型,适合办公场景
智能硬件AI 小爱同学 小米 语音助手、智能家居控制 深度整合IoT设备,支持持续学习
天猫精灵 阿里巴巴 语音交互、电商服务、技能扩展 开放生态,支持第三方技能接入
毫末智行-自动驾驶 毫末智行 L2-L4级自动驾驶 应用于多款车型,推动智能出行

AI应用分类研究

截止当前时间2025年06月16日的我的观察,当前市场主要曝光度较高的AI应用有以下四类,此分类不算非常严谨,仅供参考,相互之间交叉较多。

一、嵌入式AI应用

指在现有软件产品中集成AI功能的技术实现方式,主要案例包括:

  • 钉钉(智能办公平台)
  • 飞书(协同办公系统)
  • 腾讯会议(视频会议工具)
  • WPS Office(文档处理软件)
  • 百度网盘(云存储服务)

注:百度川流作为新发现案例,尚需进一步验证€‚

二、独立AI应用

2.1 主流产品

  1. Kimi
    由月之暗面公司开发,当前市场热度最高的对话式AI应用。
  2. 讯飞星火助手
    科大讯飞推出的多模态交互系统,在跨境场景中表现突出。
  3. 智谱AutoGLM沉思系统
    智谱科技研发的创新型AI应用,采用独特的多模态交互方案。
  4. 百小印
    市场认知度较低的独立应用,具体技术细节不详。

2.2 技术特点

  • 主要面向C端用户
  • 普遍采用提示词工程实现功能
  • 部分产品尝试工作流编排(如dify工作流)

三、工业AI应用

3.1 典型企业

  • 恒生电子光子AI平台技术演进路径:
    • 初期:自主训练底座模型
    • 现期:改用DeepSeek架构
    • 效果:上层应用性能提升
  • 宁夏交建平台
    采用封闭式数据架构,子公司数据内部流通。
  • 船舶行业应用基于深度求索(DeepSeek) 基座模型模型实现:
    • 市场指标建设
    • 订单预测功能

3.2 应用深度

当前工业AI主要停留在产品订单、金融数据预测等数据预测分析层面,尚未深度整合数字孪生等先进技术。

四、智能硬件AI

4.1 主要产品

  • 消费级设备
    • 小米小爱同学
    • 天猫精灵
    • 华为小艺(基于盘古模型)
  • 车载系统
    • 蔚来NOMI等解决方案
  • 创新设备
    • 智能宠物伴侣:
    • 采用轻量化语言模型
    • 融合电子宠物怀旧元素
    • 具备基础情绪识别能力

4.2 生态对比

产品 技术优势 主要局限
小爱同学 生态设备完善 多任务处理能力不足
天猫精灵 避免电商功能过度植入 用户粘性较低
华为小艺 盘古模型支持 智能家居整合度待提升

五、技术瓶颈分析

5.1 AutoGLM系统问题

  • 操作延迟:3-5FPS识别帧率
  • 无法离线 全程联网操作
  • 稳定性缺陷
    • 窗口布局变化时错误率激增
    • 人机交织操作易崩溃

5.2 市场现状

当前AI应用主要由数字化基础良好的产品演化而来,如:

  • 钉钉(办公数字化)
  • WPS(文档处理数字化)
  • 腾讯会议(会议流程数字化)

原始观察结论维持不变:多数创新应用仍处于技术验证阶段,尚未形成稳定商业价值。