企业智能体平台如何建设？架构与落地路径指南
企业智能体平台不是“大模型 + Prompt”的简单组合，而是一套让智能体可构建、可连接、可执行、可治理的工程底座。它的核心价值在于把概率性的模型决策约束在确定性的企业边界内，让智能体从演示走向生产。下面按模块拆解建设路径。
一、先选路径，再定架构
平台建设的第一步不是选框架，而是判断组织适合哪条落地路径。三条路径的边界大致如下：
| 路径 | 适用组织 | 核心特征 | 周期与代价 |
|---|---|---|---|
| 低代码 SaaS | 无专职 IT 的中小团队 | 可视化搭建，快速验证 | 周级上线，数据管控能力有限 |
| 混合部署 | 有 IT 运维团队的中型企业 | 敏感数据本地存，通用能力用云端 | 1—3 个月，兼顾灵活与合规 |
| 私有化自研 | 金融、制造、政务等高合规组织 | 完全掌控框架、模型与数据 | 3—6 个月起步，需算法 + 工程 + 运维配套 |
路径选择的核心判断依据是数据敏感度与合规要求，而非技术偏好。混合路径下，核心经营数据走本地向量库，通用办公资料走云端 SaaS，两套资源独立授权，是一条务实的折中线。
二、用七层架构框住能力边界
无论哪条路径，平台的能力骨架可以收敛到同一张分层图：
用户与应用入口层
↓
Agent 构建与资产层 ← Studio / 低代码 / 高代码 SDK
↓
接入、连接与协作层 ← MCP Gateway / Tool Center / A2A
↓
Agent 编排与执行层 ← Runtime / Workflow Engine / State
↓
模型、知识、数据与记忆层 ← Model Gateway / RAG / Memory
↓
安全执行与基础设施层 ← Sandbox / Egress Gateway
↓
质量、治理、交付与运营层 ← Observability / IAM / Cost / Audit这张图最重要的作用是防止用“构建层”的视角去覆盖“执行层”和“治理层” 。一个能在 Studio 里跑通的 Agent，离生产还差身份、策略、沙箱、可观测四件事。
三、构建层：让 Agent 成为可复用资产
构建层的关键不是“能搭出来”，而是“搭出来的东西能被复用和治理”。
Agent 不应被视为孤立的应用，而应作为带版本、带 Owner、带依赖关系的资产注册到统一 Registry 中。Workflow、Skill、Prompt、Tool 同样如此。Skill 和 Tool 需要区分：Tool 是单一可调用动作（如 git.create_comment），Skill 是包含 Prompt、知识、脚本和工具依赖的复合“做事方法”，前者适合直接暴露给模型，后者更适合封装为可评估、可迭代的能力包。
低代码界面解决的是可及性，但构建层的长期价值取决于资产模型的设计深度。一个只有画布、没有 Registry 和版本管理的“构建平台”，在 Agent 数量超过个位数后就会迅速退化为配置泥潭。
四、连接层：MCP 网关是工具调用的治理入口
企业智能体要“能干活”，就必须连接外部系统。但让每个 Agent 直接对接每个工具的 API，会带来凭证分散、权限失控和审计断链。更务实的做法是把存量 API 网关升级或旁路为 MCP 统一接入层，由网关集中承担协议转换、身份认证、工具发现和调用审计。
MCP 网关在调用链上回答四个问题：谁在调用、以谁的身份、能做什么、做了什么。具体执行时，一次典型的工具调用经过：
Agent Runtime → MCP Gateway
→ 工具发现与版本解析
→ 身份与权限检查（工具级、动作级）
→ 参数 Schema 校验
→ 高风险动作转人工审批
→ 执行并记录审计日志
→ 结果过滤后回填上下文对于存量系统中没有标准 API 的老旧 ERP、CRM，可以考虑 LLM + RPA 融合的方式：模型负责理解与规划，RPA 负责模拟人工操作完成执行，绕过接口缺失的限制，但必须在沙箱和出站管控的约束下运行。
五、执行层：沙箱与出站控制是安全底线
智能体的执行能力越强，运行时隔离的必要性越高。Prompt 注入一旦生效，Agent 可能尝试越权读取或外发数据。执行层需要两道防线：
沙箱隔离。每个 Agent 或每个任务应在独立的隔离环境中运行，基于 Kubernetes 的沙箱方案可以提供进程级、网络级和文件系统级的边界。沙箱内只暴露任务必需的文件和工具，高风险操作（数据删除、对外写入）强制进入人工审批节点。
出站控制。Egress Gateway 负责管控 Agent 和沙箱的网络出口：域名/IP 白名单、DNS 过滤、云元数据地址封锁、敏感数据外发检测。一个常见的生产事故是 Agent 被诱导调用了“查询天气”的工具，实际却发起了对内网服务的探测——出站白名单是这类风险的直接刹车。
六、治理层：可观测性与成本必须同时上线
可观测性不是“先上线再补”，它需要和第一批 Agent 同时进入生产。Agent 的行为不确定，同一个问题今天调工具 A，明天可能直接回答，没有 Traces、Logs 和 Metrics 就无法定位失败发生在模型、工具、策略还是网络层。
可观测性的最低可用集：
- Trace：记录一次 Run 的完整决策链——模型调用、工具调用、审批节点、上下文变更。
- 审计日志：谁在什么时间、以什么权限、对哪个系统做了什么。
- 成本归因：Token 消耗和工具调用费需要按 Agent、任务、租户多维度归集。成本失控往往不是“用多了”，而是“不知道谁在用”。
成本治理和权限治理在运行时是同一件事的两面。派生凭证（而非共享 API Key）让“人、Agent、环境”进入同一身份模型；每次调用的策略检查同时输出“允许/告警/阻断”和“本次消耗归属谁”。Token 预算可以在模型网关层设置阈值，耗尽时返回 HTTP 429 Too Many Requests，避免月末才在账单上发现问题。
七、一个可以启动的最小闭环
如果不想从七层架构的全景开始，可以先跑通一条最小但生产相关的路径：
- 选定一个边界清晰、失败可回滚的场景（如售后工单分拣、日志告警初筛），不要从跨部门核心流程起步。
- 用混合路径搭底座：本地向量库存敏感文档，云端跑模型推理，中间用 MCP Gateway 连接 1—2 个只读工具。
- 给 Agent 派生凭证 + 工具级只读权限，所有写操作走人工审批。
- 沙箱内执行，Egress 白名单只放行明确的目标域名/IP。
- 从第一天开启 Trace 和 Token 归因，按 Agent 和任务维度记录。
跑通这条闭环之后，再逐步引入多 Agent 协作、Workflow 编排和评估优化。平台的能力增长应该由场景的复杂度驱动，而不是由框架的丰富度驱动。
八、落地参考：实在Agent的“双引擎+技能库”解法
在跑通上述理论框架后，如果企业希望选择成熟的商业组件来加速平台建设，可以参考业界如“实在智能”的Agent产品架构。其设计思路与我们前文提到的七层模型高度契合，并在“认知与执行的闭环”、“技能资产化”上给出了具体的工程实现。
1. 架构映射：从大模型到执行底座
实在Agent的架构自下而上完美匹配了我们的分层逻辑。底层依托自研的TARS垂直大模型（提供复杂任务规划和认知能力）与GPU算力调度；中间层通过统一的Model Gateway接入内外模型群；在执行层，它创新性地引入了“认知Agent + 执行Agent（RPA）”双引擎驱动。认知引擎负责理解意图、检索知识与生成内容，执行引擎负责调用系统、填报表单、跨系统协同。这种设计直接解决了大模型“只会说不会做”的断层问题。
2. 构建层落地：企业级技能库（Skills）
前文强调“Agent要成为资产”，实在Agent的做法是构建统一的企业级技能库。它将RPA、API、数据分析等能力统一封装为标准化的Skill。业务专家只需口述流程或上传文档，即可自动转换为技能模板，并按组织架构分层管理。这相当于把个人的隐性经验，转化为了企业级的可复用资产，且支持精细化的权限配置（谁能调、调哪个版本的Skill），在构建层就内置了治理。
3. 执行与治理：混合编排与全链路监控
系统内部实现了Loop驱动（灵活探索）与Workflow驱动（稳定执行）的双飞轮。对于要求高合规、确定性输出的流程（如财务审批），走Workflow的DAG编排，条件分支明确且全链路可审计；对于未知探索、异常处置（如排班策略推演），走Loop驱动的ReAct逻辑。底层的网络与数据交互均通过零信任、加密传输与审计合规拦截，满足企业级安全要求。
4. 脱敏场景实践
在这种双引擎架构下，实际落地跑通了不少闭环场景：
- 财务单据审核：在财务共享中心场景中，利用大模型直接生成“代码公式级”的审核规则，替代传统硬编码。结合OCR与RPA，自动提取发票、比对合同，实现单据审核的高效流转。
- 生产车间排班：面对多工序、场地与工时等多条件约束，Agent通过大模型深度规划任务，调用特定排班技能，结合历史负荷校验规则，生成可视化排班策略，并可由系统直接下发执行。
- 设备异常处置：通过监测物联网时序数据，发现异常后由Agent自动调取设备数字孪生模型进行量化分析，生成维修或备品备件计划，并推送到工单系统。
总结
企业智能体平台建设可以概括为：先选路径，再用分层架构框住能力边界，在构建、连接、执行、治理四个层面逐层补齐生产约束。构建层要把 Agent 当资产而非应用来管理；连接层用 MCP 网关把工具调用收束到可治理的入口；执行层以沙箱和出站控制守住安全底线；治理层让可观测性和成本归因与第一批 Agent 同时上线。最小可行的启动方式是选定一个可回滚的场景，跑通“凭证 + 只读工具 + 沙箱 + Trace”的闭环，再根据场景复杂度逐步扩展。在自研成本较高时，合理参考成熟商业方案（如实在Agent的双引擎架构）也可以有效缩短平台从建设到产生业务价值的周期。
