V2 系统架构
慧言是一个面向销售与服务场景的 V2 AI Agent 平台。系统将可复用的业务定义沉淀为资产，将组织实际使用的知识、MCP 和渠道配置绑定到 AI 成员，并通过会话、运行记录和审计持续优化。
当前线上只运行 V2。任何客户消息的线上行为都由两类事实源共同决定：
- 已发布的 V2 资产版本：十类基础资产、技能和岗位组成的可追溯闭包；
- 活跃的团队 AI 成员与接待账号绑定：实例身份、组织资源和渠道接流配置。
草稿只能用于编辑；历史版本、历史会话和历史追踪只能用于回放与审计，不能作为线上决策来源。
一、业务架构：定义、发布与运行
V2 的业务架构分为四层：
| 层级 | 核心对象 | 职责 |
|---|---|---|
| 基础层 | 十类基础资产 | 定义可复用的语义、数据、能力、事件、政策、表达和资源需求。 |
| 技能层 | AI 员工技能 | 将基础资产组合为一件可复用的完整工作。 |
| 业务层 | AI 员工岗位 | 将技能编排成完整业务方案，维护业务词汇、政策、表达与默认资源要求。 |
| 运行层 | 团队 AI 成员、接待账号 | 选择已发布岗位，绑定组织实际资源和渠道，处理客户会话。 |
十类基础资产为：客户表达、业务政策、能力、MCP 要求、记录结构、事实、事件、SOP、表达模板和话术包。它们是基础层的分类；技能、岗位和 AI 成员则是将这些分类组合、发布和运行的对象。
系统基础资产使用 sys_ key，由平台统一维护。组织可以使用或显式覆盖基础资产；系统岗位或系统技能需要先物化为组织资产，再绑定到组织的线上 AI 成员。
二、发布闭包与线上生效
上线不是“保存配置”，而是发布一个通过校验的 V2 业务闭包：
组织草稿
→ Schema、引用和资源约束校验
→ 发布不可变 V2 版本与审计报告
→ AI 成员按稳定岗位 key 解析最新已发布闭包
→ 本轮版本、资源和结果写入 Run / Trace
发布会校验：资产结构、引用完整性、任务与基础资产闭包、业务包装配、资源需求和默认蓝图归属。任一缺失或不匹配都会阻止发布；运行时也不会读取未发布草稿。
AI 成员保存的是岗位 key 和组织运行配置，不复制业务规则。岗位发布新的有效版本后，AI 成员在后续处理时解析该岗位的当前已发布闭包；实际使用的版本会被记录，便于回放和定位问题。
三、一次客户消息的运行链路
客户渠道消息
→ 接待账号匹配团队 AI 成员
→ 装配已发布岗位闭包、会话事实与实际资源绑定
→ LLM 进行语义理解、事实候选、能力选择与回复计划
→ 运行时执行结构校验、授权/风险门禁和工具调用
→ 写入事实、状态、事件及异步 Outbox
→ 生成回复，并记录 Session / Run / Trace / 审批结果
在这条链路中：
- LLM负责语义判断：理解客户表达、判断缺失信息、选择已声明能力和组织回复计划；
- 运行时负责可靠执行：候选召回、结构校验、资源解析、授权与风险门禁、幂等、事件投递和可观测性；
- 资产负责业务边界：不把行业、产品、业务状态或具体话术路由硬编码到运行时代码中。
如果模型不可用、超时、低置信度或没有有效输出，运行时可以采用可观测的安全回退；回退原因必须进入 Trace，而不能静默改变业务行为。
四、服务模块与边界
| 模块 | 职责 | 不承担的职责 |
|---|---|---|
| 资产装配与发布 | 解析已发布资产、校验闭包、生成运行读模型和发布审计 | 临时猜测缺失的业务规则或依赖 |
| AI 成员管理 | 管理成员身份、运行策略、知识/MCP 实际绑定和接待账号关联 | 保存或覆盖岗位业务语义 |
| LLM 决策服务 | 基于已发布读模型和会话上下文做语义理解、能力选择与回复规划 | 绕过资产白名单、守卫或授权 |
| 能力执行服务 | 调用已绑定的平台工具或 MCP 工具，处理结果与幂等 | 执行未声明、未绑定或未授权的能力 |
| 事实、状态与事件服务 | 校验和写入业务事实，产生事件并驱动 SOP/Outbox | 根据运行时代码自创业务状态或流程 |
| 知识服务 | 使用成员绑定的 FAQ 和 RAG 来源提供事实依据 | 把未绑定知识当作可用来源 |
| 审批与 Outbox | 对高风险或主动外发动作留出审批边界，并可靠投递异步事件 | 绕过审批直接执行高风险动作 |
| Trace 与 Eval | 记录决策、资源、门禁、执行结果；回放和验证关键场景 | 用单次线上对话替代回归验证 |
五、知识、MCP 与资源绑定
资源遵循“岗位声明需求，AI 成员绑定实际来源”的规则：
| 类型 | 岗位/技能声明 | AI 成员实际绑定 |
|---|---|---|
| FAQ | 是否需要精准问答能力 | 本组织选用的 FAQ 题库 |
| RAG | 是否需要检索知识 | 本组织可用的知识文档、连接和数据集 |
| MCP | 需要哪个能力组，以及读写安全边界 | 对应的 MCP server 与 tool |
知识中心负责将素材整理为 FAQ 或 RAG 语料；知识库配置负责连接和数据集；MCP 服务负责组织业务系统工具接入。它们都需要在 AI 成员中完成实际资源绑定后，才会进入线上运行。
读取型 MCP 可用于查询产品、解决方案或案例等事实。写入型 MCP 则必须同时满足能力契约声明的输入输出结构、授权事件、守卫、审批和幂等边界。缺失任何一项时，系统应拒绝执行并记录原因。
六、渠道、会话与数据层
渠道与接待
Web、企业微信客服、公众号、个人微信、小店、抖音等渠道通过接待账号接入。接待账号只负责消息进出与渠道身份；它绑定团队 AI 成员后，消息才会进入相应的 V2 会话运行链路。
客户身份、联系人、客户档案和多渠道会话由客户与会话基础设施统一管理。这些基础设施提供上下文，但不定义行业业务规则。
运行数据与审计
系统持久化保存：
- 资产记录、草稿、已发布版本、关系边和发布报告；
- AI 成员、接待账号绑定、会话、运行和跨轮事实；
- 事件消费、异步 Outbox、审批和发送结果；
- 每轮 Trace 所使用的资产版本、资源绑定、决策与门禁结果。
关系型数据库承担事务性配置和运行审计；Redis/搜索索引用于消息去重、检索和相关运行加速。外部 LLM、RAG 和 MCP 服务只通过受控集成进入运行链路，不成为业务事实源的替代品。
七、观测、排查与持续优化
当线上结果不符合预期时，按以下顺序排查：
- 在 Trace 中确认本轮实际使用的 AI 成员、岗位发布版本、知识与 MCP 绑定；
- 判断问题属于业务资产、资源绑定、模型决策、运行时门禁或外部服务结果；
- 先补充可复现的 Eval 场景，再修改对应的基础资产、技能、岗位或组织资源；
- 完成预检与发布，用新的测试或真实会话确认新版本生效。
不要通过修改运行时代码、将特定关键词写死或绕开审批来修复单个业务问题。业务行为的源头应始终是 V2 资产与组织实例绑定。
八、V2 架构原则
- 资产和实例是事实源：业务资产定义可复用语义，AI 成员定义组织运行配置。
- LLM-first：模型做语义判断；规则只做候选召回、结构约束、安全门禁和回退。
- 发布后才运行：草稿不进入线上，发布版本必须可解析、可审计。
- 资源显式绑定：岗位不保存服务器地址、工具名或知识库 ID；AI 成员不承载业务规则。
- 风险 fail-closed：未声明、未绑定、未授权或校验失败的能力不得执行。
- 全链路可观测：决策、门禁、工具、事件、审批和回退均可在 Trace 中追溯。
- V2-only：新增能力、资源和渠道绑定均直接使用 V2，不引入 V1 回退或兼容入口。