--- name: F08_agent_platform_architecture version: 1.0 framework: 智能体管理学 · 模块二 · 框架08 type: 分析型 description: > 当用户需要设计或诊断智能体中台架构时激活。 触发词：Agent中台、智能体中台、双前台、数据飞轮、中台架构、 Agent能力管理、前台怎么分Agent和人、数据后台建设、 中台过重过轻、Agent能力烟囱、组织架构设计AI落地。 凡涉及「Agent能力如何统一管理、前台如何分工、数据如何反哺进化」均适用。 governance_nerves: 数据治理后台 → 合规审计 → 框架11（边界与升级机制） upstream_frameworks: 框架07（人机混合网络组织） downstream_frameworks: 框架09（人机协同治理模型） --- ## SKILL 定位 **做什么**：诊断三层架构适配缺口，设计Agent中台边界、双前台分工、数据治理闭环，建立从执行到进化的完整运作架构。 **不做什么**：不替代框架09（权责治理细化），不做具体Agent技术开发方案，不替代模块四AEA技术架构。 **核心判断**：中台是大脑，前台是行动，后台是记忆。三者缺一系统无法持续进化。最关键的原创结构是双前台——规模交给Agent，复杂留给人。 --- ## 第一步：信息采集 **INPUT-1：当前架构现状** ``` Agent/AI能力管理方式： □ 各业务线独立管理（烟囱状态） □ 有统一平台但功能有限 □ 有成熟的Agent中台 前台执行结构： □ 全人工前台（Agent仅辅助） □ Agent和人混合但职责不清 □ 有明确的双前台分工 数据沉淀情况： □ Agent执行数据基本未收集 □ 有收集但未用于能力优化 □ 有完整的数据飞轮 ``` **INPUT-2：业务场景** ``` 核心前台业务场景（3-5个）：[列出，标注日均工作量和Agent参与程度] 当前最突出的架构痛点：[烟囱/职责混乱/数据未利用/中台瓶颈] ``` --- ## 第二步：执行分析引擎 ### S1 · 三个适配缺口诊断 **缺口一：Agent中台现状** ``` 评估维度 | 现状描述 | 缺口等级（无/轻/重） 模型管理统一度：[是否有统一路由和成本管理] | | Agent注册管理：[是否有统一注册表和版本控制] | | 工具接口统一：[是否有统一API网关] | | 编排调度能力：[是否有多Agent工作流引擎] | | 安全审计覆盖：[是否有统一访问控制和审计日志] | | 中台缺口综合判断： 无中台（烟囱状态）→ 优先级：极高，立即启动中台建设规划 轻度中台（基础设施有，能力管理缺）→ 优先级：高，补全能力管理模块 中台过重（成为业务瓶颈）→ 优先级：高，重新设计边界下放业务自主权 ``` **缺口二：前台分工现状** ``` 当前前台任务分布： Agent处理的任务类型：[列出] 人类处理的任务类型：[列出] 职责模糊区（Agent和人都在处理，无明确规则）：[列出] 升级机制现状： Agent遇到无法处理的情况，当前怎么处理？ □ 给错误答案（沉默失败） □ 让用户等待（无升级机制） □ 有升级但触发条件模糊 □ 有明确的升级触发条件和路径 前台缺口综合判断： 职责不清 → 需要设计双前台边界，定义升级触发条件 升级机制缺失 → 最高优先级：Agent沉默失败是最坏的前台失效模式 ``` **缺口三：数据后台现状** ``` 数据收集：Agent前台执行数据是否在被系统性收集？[是/部分/否] 数据质量：收集的数据是否经过清洗和标注，可用于能力优化？[是/部分/否] 数据回流：高质量案例是否在被用于Agent能力迭代？[是/部分/否] 合规状态：数据处理是否符合隐私合规要求？[是/需检查/否] 数据后台缺口综合判断： 数据不收集 → 立即启动数据收集（越晚启动损失越多不可追回的数据） 收集不利用 → 建立数据清洗和标注流程，激活能力优化节奏 利用不合规 → 优先处理合规问题，否则整个数据体系面临法律风险 ``` --- ### S2 · Agent中台边界设计 ``` 中台边界说明书 · [企业名] · [日期] 【中台统一管理（不可下放）】 ■ 模型层：多模型路由策略 / 成本预算 / 供应商白名单 / 模型版本管理 ■ 安全基础：访问控制策略 / 审计日志要求 / 异常熔断规则 / 敏感数据处理规范 ■ Agent注册：统一注册表 / 版本管理规范 / 能力目录维护 ■ 接口规范：API网关标准 / 工具接入规范 / Skill包装标准 【业务线自主管理（中台设框架，业务线填内容）】 ■ 垂直场景Agent的提示词和工作流设计 ■ 业务场景专有的知识库内容 ■ 前台交互体验和产品形态 ■ 具体任务的优先级和调度策略（在中台调度框架内） 【共同负责（中台提供工具，业务线负责使用）】 ■ 数据质量：中台提供数据平台，业务线负责标注和反馈 ■ Agent评估：中台提供评测框架，业务线负责具体评测执行 ■ 异常处理：中台提供升级通道，业务线定义具体升级规则 中台规模适度性检查： □ 业务线能否在不请示中台的情况下完成日常Agent运营？（应能） □ 中台团队的工作量是否集中在「平台建设」而非「业务需求交付」？（应是） □ 新业务线能在2周内完成接入中台并部署第一个Agent？（应能，若不能则中台过重） ``` --- ### S3 · 双前台配置方案 ``` 双前台设计方案 · [业务场景名称] Agent前台职责范围 标准化处理类型（规则明确，可规模化）： 1. [任务类型 + 处理标准 + 质量指标] 2. ... 处理量级预期：日均X次，并发X个 人类前台职责范围 复杂处理类型（需关系维护/价值判断/异常处理）： 1. [任务类型 + 判断依据 + 典型场景] 2. ... 服务容量：X人，日均承接X次升级任务 升级流设计（Agent前台 → 人类前台） 触发条件（满足任意一条即触发升级）： □ [具体触发条件1，例：客户情绪评分X% 能力优化节奏 每月：基于回流数据评估Agent前台质量趋势报告 → 指标：首次处理达标率 / 升级率变化 / 错误类型分布 每季度：将积累的高质量案例纳入Agent优化迭代 → 目标：Agent首次达标率季度提升>X% 每半年：数据飞轮效果评估 → 判断标准：Agent前台质量是否在系统性提升，而非随机波动 合规检查 □ 数据处理是否有用户/客户知情同意 □ 是否符合所在地区数据隐私法规（GDPR/个人信息保护法等） □ 数据访问是否有角色权限控制 □ 数据保留期限是否符合合规要求 ``` --- ## 第三步：架构健康度评估 ``` 三层架构健康度自检 Agent中台层 □ 是否有统一注册表（所有Agent都在其中） □ 是否有模型成本可见性（每个业务线的模型消耗可追踪） □ 是否有统一安全审计（不存在绕过中台的Agent直接调用） □ 中台响应速度：业务线提出新Agent需求，多久能完成接入？（目标<2周） 双前台层 □ Agent前台和人类前台职责边界是否明确（无模糊区） □ 升级触发条件是否显式化（不靠Agent自行判断） □ 人类前台是否承接了不该由他们处理的标准化任务（若是则Agent前台边界设计有问题） □ Agent前台沉默失败率：X%（目标<1%，超过则升级机制设计有问题） 数据治理后台层 □ Agent前台执行数据收集覆盖率：X%（目标>95%） □ 错误案例标注率：X%（目标>80%） □ 数据到优化的平均周期：X天（目标<90天） □ 数据飞轮是否在转动（Agent质量是否在提升）：[是/暂不明显/否] 综合健康度： 健康 → 三层全部达标，飞轮在转 需关注 → 1-2层有缺口，已有改进计划 高风险 → 数据后台严重缺失（系统正在退化但尚未察觉） ``` --- ## 输出质量自检 - [ ] 三个适配缺口全部评估完成 - [ ] 中台边界说明书已完成（一页纸，清晰列出三类边界） - [ ] 双前台升级触发条件已显式化（非模糊描述） - [ ] 数据飞轮设计完成（有具体的收集/标注/优化节奏） - [ ] 架构健康度自检完成 --- ## 典型误区提醒 **误区①：中台过重，复制互联网大中台臃肿** → 中台边界：通用能力+基础安全统一管理；业务专有能力由业务线自主，中台只设框架 **误区②：双前台升级机制缺失，Agent沉默失败** → 升级触发条件必须显式定义并系统层面强制执行，这是双前台设计的核心 **误区③：数据后台「之后再补」，损失不可追回数据** → 数据后台应与Agent前台同步上线；早期错误案例是最宝贵的训练数据 --- ## 与体系其他框架的衔接 **上承** - 框架07（Agentic Network）→ 五节点形态 → F08三层架构的对应关系 **下启** - 框架09（人机协同治理模型）→ 三层架构内的责任归属和决策分配细化 **互补** - 模块四AEA六层技术架构 → 组织架构（F08）需与技术架构（AEA）对齐