项目总览与定位

一句话：企业智能体平台不是“再做一个更聪明的 Agent”，而是把模型、工具、技能、知识和执行环境收敛成一套共享基础设施，让业务线只描述场景；换来的是规模化与可控，代价是要长期承担平台工程和组织治理。

适用：2026 年企业级 Agent 平台实践。四层是责任视图，七层是交付视图；治理贯穿各层，不单独设“第八层”。协议与组件能力以官方文档为准。

为什么需要

平台化之前，常见形态是每个业务团队各接一套模型、各写一版提示词、各自封装内部系统。前三个场景还能靠人扛，到第十个场景会同时暴露三个问题：

• 能力重复建设：同一个数据库查询、同一份制度文档、同一套身份核验，被不同团队分别接了三遍，口径还不一致。
• 权限与审计失控：每个应用各自持有长期凭证，AI 以什么身份、调了什么、结果给了谁，说不清也查不到。
• 替换成本极高：换模型、换编排框架、从内网迁到云上，业务代码要跟着重写，最后没人敢动。

平台要回答的不是“怎么让模型更聪明”，而是四个运营问题：谁能用哪些能力、以什么权限用、花了多少成本、出了问题拿什么证据还原。把这些问题收敛到平台层，业务团队才只需要关心场景本身。

核心机制

先划边界：平台不替代什么

做	不做
统一模型接入、工具网关、技能与知识供给	替代核心交易、账务等既有系统
提供运行环境、调度、状态与恢复	替代业务人员的判断与责任
统一身份、权限、审计、配额与成本	做一个什么都能聊的通用聊天机器人
把重复场景沉淀为可复用 Skill	为单个场景写一次性脚本并长期维护

边界不清的平台会同时得罪两类人：业务方嫌它不够贴场景，基础设施团队嫌它把业务逻辑吸进平台。判断标准是“这件事是否被多个场景重复需要”，是则上平台，否则留在场景侧。

四层逻辑架构

四层从上到下是责任递进，不是调用顺序：治理层说“不许做什么”，平台层说“任务怎么跑”，能力层提供“用什么做”，基础设施层提供“在哪跑”。看这张图只要抓两条线——实线向下是依赖，上层可以换下层实现；虚线是治理绕开中间层直接落到能力和资源上，它不做成一层，是因为治理必须每时每刻约束每一层，而不是上线前检查一次。

这样切的好处是替换单层不影响其他层；代价是跨层调用变多，必须有统一的身份、trace 和配额贯穿。

七层工程模型

逻辑架构回答“谁负责什么”，工程模型回答“按什么顺序交付”。两者不是一一对应：治理能力渗透在每一层，而不是单独一层。

工程层	主要组件	交付判据
L1 接入	API 网关、SSO、限流、协议转换	鉴权、租户隔离、入口限流可用
L2 会话路由	意图识别、边界判定、任务路由	多轮延续判断准确率达标
L3 编排	图编排、Supervisor、人工审批	固定 DAG 与多 Agent 协作可跑
L4 运行态	沙箱、Pod 池、生命周期管理	任务可中断、可恢复、可回收
L5 状态	Redis、关系库、向量库、对象存储	记忆可读写、可隔离、可审计
L6 生态市场	MCP 注册、Skill 市场、知识摄入	新能力可发布、可审核、可下线
L7 模型网关	路由、熔断、降级、计量	多模型可切换、成本可归集

口径统一为 L1 接入 → L2 会话路由 → L3 编排 → L4 运行态 → L5 状态 → L6 生态市场 → L7 模型网关。旧资料里把“可观测治理”放成 L7、把模型层放成 L6 的写法，是把交付层和横切能力混在一起；本书不再保留“第八层治理”，治理作为横切约束落在每层的准入、审计和配额里。按层交付的意义是每层都有独立验收标准，把“平台上线”当成一个整体里程碑，通常会导致所有层都差一点，却没有任何一层可以独立证明可用。

双闭环：同一套代码，两种基础设施

维度	内网闭环	互联网闭环
模型	自托管推理集群	公有云模型 API
沙箱	自托管隔离运行时	托管沙箱服务
向量库 / 存储	自建集群 + 兼容 S3 的对象存储	托管向量库与对象存储
可观测	自托管追踪与评测	托管追踪服务
网络	默认拒绝出站，白名单放行	正常出站 + WAF + 租户隔离
适用	涉及内部数据、强合规场景	面向外部用户、非敏感场景

双闭环的关键不是部署两套，而是把差异收敛到基础设施适配层：编排、技能和业务代码保持一致，只切换部署配置。如果业务代码里出现 if 内网，说明抽象漏了，后面每加一个环境都会再漏一次。

三层治理：优先级，而不是并列

层	性质	能否被业务覆盖	典型内容
Constitution	系统级硬规则	不能	默认拒绝出站、不可逆操作必须人工确认、审计不可删除
Guidance	业务域规则	可按域配置	审批流程、检索策略、限流、预算
Context	运行时约束	随会话计算	当前用户权限、token 预算、知识域、相关性阈值

三层不是并列配置，而是优先级：Constitution 永远压过 Guidance 和 Context。这样设计的原因很直接——如果业务配置可以把“数据不得出网”调低，那它就不是红线，只是一条建议。

四大基石与四种范式

基石	职责	关键设计
Runtime	执行环境	可插拔沙箱、Pod 生命周期、空闲回收
Control Plane	调度与治理	任务分配、健康检查、生命周期钩子、容错
Skills	业务能力	声明式定义、四种执行类型、双审发布、版本管理
MCP	原子工具	注册发现、统一鉴权、限流审计、版本契约

四者的关系是：Control Plane 调度，Runtime 执行，Skill 提供业务步骤，MCP 提供原子操作。缺 Runtime 就只剩提示词，缺 Control Plane 就只能手工运维，缺 Skill 则每个场景重复编排，缺 MCP 则每个工具各写一套适配。

范式	自主性	确定性	适用
工作流型（固定 DAG）	低	高	合规检查、发布审查、故障处置
主管编排型	中	中	多专家协作、需要任务分解的场景
自主型	高	低	探索性分析、信息不完整的调查
对话驱动工具组合	中高	低中	长尾需求、临时数据分析

选型顺序是先看合规与可审计要求，再看任务步骤能否预先枚举，最后才看模型能力。反过来先选“最自主”的范式，通常会在评审阶段被要求补审批、补证据、补回滚，最后又退回工作流。

12 类交互场景与场景叠加

交互场景要穷举，但不必写成大表：单轮问答、多轮对话、多 Agent 协作、文件上传、代码执行、长时任务、流式输出、中断恢复、多模态输入、人工审批、定时触发、并发排队。单看每一类都不难，真需求往往把它们叠在一起——例如“多 Agent 处理上传文件、跑二十分钟、中途断网恢复、关键步骤等人工审批”。叠加后问题不再是“某个功能有没有”，而是“会话状态放哪、预算怎么跨子任务传播、恢复时哪些副作用不能重放、审批挂起时资源怎么释放”。这也是四层与七层必须存在的原因：每一层负责一类横切能力，组合才不会退化成一次性脚本。这 12 类不在本篇逐项展开；业务场景到范式的匹配见 08-落地路线与关键取舍。

实战场景

场景一：平台做成一个应用，第二个业务方接入时全要重做

现象：第二个业务方（风控分析线）来接入，发现要从头重做：权限模型绑死客服的用户体系，审计日志只有客服的字段，想复用一份制度文档检索只能复制代码——第一个版本把模型接入、知识库、身份核验全写死在这一个应用里。平台组被迫抽两人做了六周“拆耦合”专项，第二个业务方才勉强进来；随后第三个团队绕开平台自建，同一份制度文档被接了三遍，口径开始不一致（时间与代价为经验值，需校准）。“第十个场景才暴露”的三个问题，在第二个场景就提前发生了。

排查：按四层责任视图逐层核对，结论是“层”根本没被拆出来，只有一个应用壳。治理层：没有租户维度，审计回答不了“谁以什么身份、调了什么、结果给了谁”。能力层：MCP 与 Skill 没有注册和 owner，复用只能靠复制。平台层：会话路由里混着客服的业务判断，换业务域就要改平台代码。基础设施层反而是唯一完整的——力气全花在离交付最近的一层，责任视图缺了三层。

对症：接入评审先过一张上收判定表，每个候选项只回答一个问题：这件事是否被多个场景重复需要。

候选项	被几个场景需要	结论
制度文档检索	客服、风控、内审	收进知识库，挂 owner 与权限标记
工单查询	客服、内审	注册为 MCP Server，走统一鉴权与限流
客服开场白策略	仅客服	留在场景侧，不进平台
身份核验	全部	收进 L1 接入，接 SSO

复盘：平台的交付物是“第二个业务方不用重做权限、审计、供给”。“不做”那一列在接入期最值钱：业务方嫌不贴场景、基础设施团队嫌吸业务，同时得罪两类人的根因都是边界失守，而判断标准从来只有一条——是否被多个场景重复需要。

场景二：一次强合规接入，验证四层与七层到底省了什么

现象：第三个业务方是内网数据分析——数据不得出网、模型只走自托管推理集群，若照客服那次的接入方式，编排和技能供给要全部再写一遍，按前两次实际投入推算就是 6 周（经验值，需校准）。业务方只问了一个问题：这次接入，你们的平台帮我省了什么。

排查：改用七层交付视图做接入盘点，逐层标记复用还是新活：L1 接入复用 SSO 与租户隔离；L2 会话路由新增一条边界判定规则；L3 编排选工作流型范式跑合规检查，固定 DAG 现成；L4 运行态复用 Pod 池的冷 / 暖 / 热回收配置；L5 状态新建知识域；L6 生态市场复用 3 个已有 MCP、1 个已有 Skill；L7 模型网关把路由切到自托管集群。七层过完，真正的新活只剩两处，接入实际两周完成（经验值，需校准）。

对症：接入动作收敛成一次 profile 切换，与最小上手同一条配置链路：

platform:
  profile: internal        # 只切基础设施适配，编排与 Skill 代码不动
  model_gateway:
    primary: local-primary
    fallback: local-small
    budget_tokens_per_task: 60000
  governance:
    deny_all_egress: true
    audit: append_only

复盘：验证的不是“这次接得快”，而是业务代码里没有出现 if 内网——出现一次，双闭环就退化成两套平台，后面每加一个环境都会再漏一次；新场景边际成本能不能降，才配得上“平台上线”这个词。

场景三：红线被业务配置“合规地”调低

现象：两份标注“内部”的制度全文被外发到公网文档解析 API，涉及 11 个会话（经验值，需校准），合规事故上报——起因只是某业务域赶接入时申请把该 API 加进出站白名单，理由“解析 PDF 提效”，审批走的是平台自己的配置通道，记录齐全。每一步都“合规”，红线却没了，这才暴露三层治理的实现缺陷。

排查：沿审计链回放配置合并过程。网络层本该拦住：默认拒绝出站、白名单放行。查到白名单的下发通道对业务域配置开放，Guidance 层的改动直接改写了系统级规则。平台把 Constitution、Guidance、Context 实现成了三层并列配置，后写的覆盖先写的——“数据不得出网”在这种实现里不是红线，只是一条优先级不稳定的建议。问题定位在治理层，不在提示词，也不在业务域。

对症：把三层优先级做成机制而不是文档——Constitution 永远压过 Guidance 和 Context，冲突的配置进不了生产：

governance:
  constitution_fields: [deny_all_egress, audit.append_only, require_hitl]
  merge_policy: reject      # 与 Constitution 冲突的配置在发布校验时直接拒绝并落审计
  override_allowed:
    guidance: [budget, approval_flow, retrieval_strategy]
    context: [token_budget, knowledge_domain]

require_hitl 覆盖 delete、publish、payment 三类不可逆操作，任何域配置不得移除；真正兜底的出站拦截放在工具网关和执行环境，配置通道只到 Guidance 的可覆盖字段为止。

复盘：这次事故修复的不是白名单，而是配置合并规则：红线要不可配置，业务配置最多能在 Guidance 与 Context 里选执行方式——这也是三层治理的分工：Constitution 定不可违反的规则，平台层定任务怎么跑，能力层与基础设施层各自兑现，任何一层都不拥有改写红线的权限。

最小上手

不要从“大一统平台”起步。用一个场景、一条链路验证四件事：模型能调、工具能管、状态能存、失败能查。示意配置：

platform:
  profile: internal          # internal | external，只切基础设施适配
  model_gateway:
    primary: local-primary
    fallback: local-small
    budget_tokens_per_task: 60000
  runtime:
    pool: { min: 2, max: 10, idle_recycle_seconds: 300 }
    sandbox: isolated
  governance:
    deny_all_egress: true
    require_hitl: [delete, publish, payment]
    audit: append_only

跑通判据：同一任务连续执行三次都能在预算内结束；断网后除白名单外全部失败且有审计；Pod 被杀后任务能从检查点恢复；模型切换只改配置、不改业务代码。

生产动作

• 定 owner：每个 Skill、每个 MCP Server、每个知识库都要有负责人和用途说明，无 owner 不上架。
• 定 SLO：平台可用性、任务成功率、P95 延迟、恢复时间分别设目标，不要只监控 GPU 利用率。
• 定额度：按租户、业务域、用户三层设 token 与并发配额，超额降级而不是静默失败；预算与降级阶梯见 09-生产治理与降级。
• 定版本与证据：能力资产与代码同一条发布链，先影子运行再灰度，下线保留迁移窗口；每次执行记录输入摘要、工具调用、权限判定、输出校验和终止原因，审计按 trace 还原而不是按日志拼凑。
• 定演练：定期做模型不可用、向量库超时、Pod 批量回收、审计写入失败的故障演练。

边界

• 十人以下团队通常不需要平台：统一配置、集中凭证和一份发布脚本的收益，远高于自建控制面。
• 平台不解决业务定义不清：Skill 的输入输出、成功标准和人工介入点说不清，平台只会把混乱固化得更快。
• 双闭环不是零成本：两套基础设施意味着两套容量、两套监控和两套应急，只有合规或数据边界确实需要时才值得。
• 治理不能只靠提示词：写在系统提示里的“不要删数据”只是提高概率，真正的边界在工具网关和执行环境。
• 平台会改变组织分工：能力上收意味着业务团队从“全栈自建”变成“场景定义 + 平台消费”，没有配套的角色与流程，平台会变成新的瓶颈。

讲清楚

企业智能体平台的价值不是让单个 Agent 更聪明，而是把重复的模型接入、工具适配、知识供给、运行调度和治理收敛成共享能力。架构上用四层划责任，用 L1 接入、L2 会话路由、L3 编排、L4 运行态、L5 状态、L6 生态市场、L7 模型网关划交付，治理作为横切约束贯穿七层而不是“第八层”；用双闭环隔离内网与互联网的基础设施差异，用三层治理保证硬规则不被业务配置覆盖，用 Runtime、Control Plane、Skills、MCP 四块基石支撑四种 Agent 范式。真实需求往往来自 12 类交互场景的叠加，落地时先划清“平台不做什么”，再用一个场景验证模型、工具、状态和证据四条链路；平台真正的难点不在技术选型，而在 owner、版本、配额和审计能否长期运转。

适用：2026 年企业级 Agent 平台实践 | 初稿 2026-10