gabrielmoreira AI Native 系统构建 Skill
使用场景
- 试验展开已验证能力成立，需要转为可维护、可交付、可治理的产品系统
- 需要设计 AI Native 产品架构，而不是简单把模型 API 接入旧系统
- 需要判断实验代码中哪些可以继承，哪些必须重写
核心概念
- 系统构建（Building）：把已验证能力改写为可维护、可治理、可观测系统的阶段
- 能力系统：由智能体、技能单元、工具、模型、数据、记忆系统、上下文等共同组成的产品能力底座
- 实验代码：用于快速验证假设的短周期代码
- 产品代码：用于长期承载能力、支持治理和迭代的系统代码
系统构建流程
实验证据输入
→ 系统边界定义
→ 能力模块设计
→ 治理与观测补齐
→ 进入审计放行
第一步：实验证据输入
从试验展开阶段继承：
- 能力边界：哪些场景能稳定成立
- 产品形态建议：问答、Copilot、工作流、智能体
- 资料缺口：已解决和未解决的
- 风险边界：必须人工接管的动作
- 失败案例：已沉淀的失败模式和人工修正
第二步：系统边界定义
系统构建不是补工程细节，而是重写系统形态。需要回答：
- 这项能力如何被稳定调用
- 它如何与产品交互、工作流、知识系统和权限体系协同
- 它在失败时如何退回、解释、降级或交还给人
- 它如何被监控、被审计、被持续优化
第三步：能力模块设计
AI Native 架构的核心结构
User
→ Agent
→ Skill
→ Tool
→ System
→ Model
→ Data
这是一个多层能力系统：
- 智能体（Agent）：负责理解目标与编排任务
- 技能单元（Skill）：封装可复用能力
- 工具（Tool）：连接外部系统
- 模型（Model）：提供推理能力
- 数据（Data）：提供知识与记忆基础
传统架构 vs AI Native 架构
| 维度 | 传统软件架构 | AI Native 架构 |
|---|---|---|
| 稳定中心 | 功能执行链 | 能力执行链 |
| 抽象单元 | 模块/接口 | 智能体/技能/工具 |
| 输入组织 | 数据库/表单 | 上下文/记忆/知识 |
| 失败处理 | 异常捕获 | 回退/降级/人工接管 |
| 治理重心 | 权限/审计 | 边界/观测/放行 |
第四步：治理与观测补齐
系统构建的目标不是尽快交付一个可演示版本，而是形成一个可被审计、可被维护、可被持续优化的系统结构。
必须补齐的治理能力
- 可观测性：系统如何被监控，关键指标是什么
- 可审计性：如何追溯输入、上下文、模型版本、工具调用、人工接管、最终结果
- 可回退性：失败时如何降级、回滚、交还给人
- 可更新性：模型、提示词、知识、工具如何独立更新
实验代码 → 产品代码的转换原则
- 实验代码证明的是"能力在某些条件下可以成立"
- 产品代码要解决的是"能力如何被稳定调用、失败时如何处理、如何被治理"
- 很多团队失败不是因为模型不行，而是因为没有完成这次系统形态转换
输出物：系统构建方案
- 系统边界：能力范围、用户角色、权限分层
- 能力模块图：Agent → Skill → Tool 的层级结构
- 失败处理策略：回退、降级、人工接管的触发条件
- 治理与观测方案：监控指标、审计记录、异常处理
- 进入审计放行的条件：什么条件满足后可以进入审计放行
使用方式
当用户提供实验结论报告时，自动执行：
- 检查实验证据是否充分
- 定义系统边界（能力范围、用户角色、权限）
- 设计能力模块图（Agent/Skill/Tool 分层）
- 设计失败处理策略
- 补齐治理与观测方案
- 输出系统构建方案
示例
示例：AI 客服系统从实验到产品
场景描述： 基于已完成的实验结论，将 AI 客服原型系统转化为可维护、可治理的生产系统。
用户输入： 实验结论报告：AI 客服 Copilot 能力验证
Skill 执行流程：
- 实验证据输入
从实验阶段继承的证据:
能力边界:
- 订单查询: 92%准确率 ✅
- 物流解释: 85%准确率 ✅
- 售后政策: 78%准确率 ⚠️（需改进）
- 投诉处理: 不适合AI ❌
产品形态建议:
- 类型: Copilot（人工确认模式）
- 界面: 侧边栏候选回复
- 关键交互: 一键采纳、快速编辑
资料缺口:
- 需补充200条售后政策边界案例
- 需建立敏感承诺规则库
风险边界:
- 退款、赔付相关: 必须人工确认
- 价格相关: 必须引用最新数据源
- 情感升级: 自动转人工
- 系统边界定义
| 维度 | 实验阶段 | 系统构建后 |
|---|---|---|
| 用户范围 | 内部测试客服 | 全部一线客服 |
| 能力范围 | 订单+物流 | 订单+物流+售后（80%+准确率） |
| 权限分层 | 单一角色 | 专员/主管/管理员 |
| 可用时间 | 工作日白天 | 7x24小时 |
| 失败处理 | 直接报错 | 优雅降级+人工接管 |
- 能力模块设计
# AI Native 架构：AI 客服 Copilot
系统边界:
用户层:
- 客服专员（主要用户）
- 客服主管（审核/管理）
- 系统管理员（配置/监控）
产品层:
- 客服工作台界面
- 浏览器插件 / Web端
能力系统层:
Agent层（CustomerServiceAgent）:
- 目标理解: 识别用户意图、情绪
- 任务规划: 选择Skill、编排执行顺序
- 结果组织: 组装回复、标记风险
Skill层:
- UnderstandIntent: 意图识别（92%准确率）
- QueryOrder: 订单查询
- TrackLogistics: 物流追踪
- GenerateResponse: 回复生成
- CheckRisk: 风险检测
Tool层:
- OrderSystem.query: 订单系统查询
- LogisticsAPI.track: 物流API
- KnowledgeBase.search: 知识库检索
- CRM.getUserProfile: 用户画像
Model层:
- GPT-4o: 主推理模型（意图理解+回复生成）
- text-embedding-3: 向量化（知识检索）
Data层:
- 知识库: 政策文档、FAQ
- 案例库: 成功案例、失败案例
- 记忆系统: 用户偏好、会话状态
治理层:
- 可观测性: 指标监控、日志审计
- 权限控制: RBAC
- 失败处理: 降级+人工接管
- 失败处理策略
| 失败场景 | 触发条件 | 处理策略 | 人工接管 |
|---|---|---|---|
| 意图识别失败 | 置信度<70% | 提示"请重述问题" | 连续2次 → 人工 |
| 订单查询失败 | API超时 | 提供自助查询链接 | 用户要求 → 人工 |
| 高风险内容 | 涉及赔付 | 只生成候选，不发送 | 必须人工确认 |
| 模型服务异常 | API不可用 | 关闭AI建议，纯人工 | 自动 |
| 多轮对话失控 | 超过10轮 | 建议转人工 | 自动转人工 |
- 治理与观测方案
可观测性:
监控指标:
- 采纳率: >60%
- 修改率: <40%
- 响应延迟: P95<2s
- 服务可用性: 99.9%
审计日志:
- 每次请求: 输入摘要、模型版本、上下文
- 每次输出: 建议内容、置信度、风险标记
- 每次人工操作: 采纳/修改/拒绝 + 原因
可回退性:
- 功能开关: 可关闭AI建议（5分钟内）
- 模型降级: 主模型异常时切换备用模型
- 人工接管: 指定场景自动转人工
可更新性:
- 模型: 支持A/B测试切换
- 提示词: 独立配置，热更新
- 知识库: 增量更新，无需重启
- 规则: 实时生效
输出结果:
# 系统构建方案：AI 客服 Copilot
系统边界:
用户: 300名一线客服 + 30名主管
场景: 订单查询(92%)、物流解释(85%)、售后咨询(78%)
边界: 投诉处理、高风险承诺不在范围内
能力模块:
Agent层:
- CustomerServiceAgent
- 负责任务编排、边界控制
Skill层（6个）:
- UnderstandIntent / QueryOrder / TrackLogistics
- GenerateResponse / CheckRisk / SummarizeSession
Tool层:
- 订单系统、物流API、知识库、用户画像
Model层:
- GPT-4o（主）、Claude-3.5（备）
Data层:
- 知识库、案例库、记忆系统
失败处理:
- 12种失败场景定义
- 分级处理策略
- 自动转人工机制
治理方案:
- 7大类监控指标
- 完整审计日志
- 5分钟热回退能力
进入审计放行条件:
✅ 实验证据完整
✅ 系统边界清晰
✅ 失败处理策略完备
✅ 治理方案就绪
✅ 团队准备就绪（已培训）