企业级 AI 工作台的四层架构：从交互到执行到本体到业务系统

本文讨论的是一个成型的 Agent 方案，企业级 AI 工作台。方案采用的一种四层实现方式，从上到下是：交互层、Agent 执行层、本体层、业务系统层。它不是行业里唯一的标准分法，而是为了把职责边界、安全控制和系统集成关系讲清楚。理解这个分层，是后续讨论部署、安全、运维的前提。

第一层：交互层

交互层是用户和 Agent 之间的界面，分两个部分。

一部分是业务人员使用的 CUI（Conversational User Interface 或更简单的 Chat User Interface），也就是对话界面。用户在这里输入任务描述，看到 Agent 的进度反馈和最终结果。这个界面的设计原则是最小化用户需要了解的技术细节。用户不需要知道 Agent 调用了哪些接口，不需要知道本体是什么，只需要用自然语言描述他们想做的事。

另一部分是运维人员使用的配置与审计界面。这里显示的是系统管理员关心的内容：哪些业务应用被注册到了工作台、每个应用的本体版本是什么、近期的调用日志、权限配置、异常告警。这个界面是 IT 部门信任这个系统的基础，他们需要全面、客观地能看到 Agent 做了什么，不只是看到用户满不满意。

两个界面服务的是完全不同的用户角色，但都属于交互层。把它们放在同一层的意义在于它们共享同一个底层数据源（调用日志、会话记录），但呈现的视角不同。

第二层：Agent 执行层

Agent 执行层是工作台的"大脑"，负责接收任务、推理、调用工具、返回结果。这一层包含几个核心组件。

• LLM是推理的核心。它接收上下文，输出下一步行动的判断。选择哪个模型，取决于任务的复杂度、响应速度要求、成本预算，以及是否允许数据离开企业网络。这里没有唯一正确答案，通常选择能够支持多步规划、工具调用和稳定指令跟随的模型就可以。
• 推理框架决定 Agent 的运行方式。常见做法是让 Agent 在每一轮里完成规划、调用工具、观察结果、再决定下一步，也就是一个"计划—执行—观察—再规划"的循环。工程上真正需要记录的，不是把模型的完整思维过程原样暴露出来，而是结构化的执行轨迹：这一轮调用了什么工具、输入了什么参数、拿到了什么结果、为什么进入下一步。这些记录足以支撑调试、审计和回放。
• 长短期记忆解决的是上下文管理问题，第15篇里详细讨论过。短期记忆是当前会话的上下文窗口，长期记忆是持久化存储。这一层的实现质量直接影响 Agent 处理多步任务的能力，以及跨会话的连续性。
• Shell 工具和文件工具是 Agent 执行层里最容易被低估的组件。Agent 能自主编写 Python 脚本处理数据、能读写本地文件、能调用系统命令——这些"胶水代码"能力是 Agent 处理那些没有预先封装好接口的临时性任务的关键。比如，用户让 Agent 把两份 Excel 数据合并，没有任何业务系统提供这个接口，Agent 可以自己写脚本完成。这个能力是 Agent 和固定 Workflow 之间最重要的场景创新能力之一。

第三层：本体层

本体层是整个架构的枢纽，也是这个方案区别于 OpenClaw 等通用型 Agent 的核心所在。

它承担三个职责。

• 业务系统 CLI：本体层通过定制开发的命令行工具调用业务系统的接口。这里复用的是业务系统现有的人机接口和鉴权体系，不需要为 AI 单独开发一套机机接口。更准确地说，Agent 不是拿着一套长期有效的高权限凭证四处调用系统，而是通过本体层以"当前用户代理"或"受限服务身份 + 用户映射"的方式发起请求。这样系统仍然知道这次调用最终是为哪个用户执行的，权限控制和审计链路都能沿用现有机制。
• 安全校验：在调用执行之前，本体层检查当前请求是否符合约束，当前用户有没有权限调用这个接口、参数的类型和取值范围是否符合本体里定义的规则、这个操作是否在白名单范围内。通过校验才执行，不通过则拦截并记录审计日志。这个校验不依赖 LLM 的判断，是确定性的程序逻辑。
• 本体发现与加载： Agent 在处理任务时，需要知道当前会话里哪些业务系统是可用的，每个系统的本体文件在哪里。本体层维护一个注册表，记录已注册的应用、对应的本体文件路径、版本信息。Agent 在构建上下文时，从这个注册表里按需加载相关的本体文件，而不是把所有应用的本体全部塞进上下文。按需加载在注册应用数量多的时候，能显著减少上下文窗口的占用。

本体层还包含一个独立的组件：本体提取器（huozige-ontology-builder）。它不是运行时组件，而是部署时工具。本方案基于活字格低代码平台的元数据定义构建，所以，开发者只需要把活字格工程文件交给它，它就能扫描工程、生成本体文件。这个工具的存在，让本体的生成从"需要人工逐条描述"变成"运行一个命令"，大大降低了在企业中落地的门槛。

第四层：业务系统层

业务系统层是工作台最终操作的对象，包含所有接入工作台的业务应用，以及知识库。

在方案中，这一层的应用都是用活字格开发的独立系统，如CRM、MES、WMS、采购系统、设备管理系统等。每个系统独立运行，有自己的数据库、自己的服务端命令、自己的权限配置。它们接入工作台的方式是"注册"：把本体文件部署到 Agent 服务器，在工作台的管理界面登记这个应用的地址、身份代理方式和访问配置。这里登记的不是给 Agent 一把可以长期滥用的总钥匙，而是让本体层知道应当如何把用户身份、安全策略和系统接口对接起来。注册完成后，Agent 就能通过本体层调用这个系统，不需要对系统本身做任何改造。

知识库在这一层作为一个普通的业务应用存在，不是 Agent 执行层的内置组件。之前我们专门探讨过为什么要这么做。简而言之，知识库的治理责任、访问控制、审计日志，都应该和其他业务数据遵循同一套机制，而不是成为 AI 基础设施里一个游离的组件。这一层对 Agent 来说是"外部世界"，Agent 通过本体层和这一层交互，不能直接访问，也不能绕过本体层的权限校验、身份映射和审计记录。

四层之间的信息流

把四层合在一起，一次完整的任务执行是这样流动的。

用户在交互层输入任务，请求到达 Agent 执行层。Agent 向本体层请求相关应用的本体文件，本体层从注册表里找到对应文件，加载返回。Agent 拿到本体，开始推理，判断需要调用哪个系统的哪个接口。Agent 通过本体层发起调用请求，本体层做安全校验，通过之后通过 CLI 调用业务系统层的接口。业务系统返回结果，本体层记录调用日志，把结果返回给 Agent。Agent 分析结果，判断是否需要继续，如果需要，进入下一轮循环。最终结果通过交互层展示给用户，运维人员可以在审计界面里看到这次任务的完整调用链路。

这条信息流里，本体层出现在两个关键节点：提供上下文（本体文件）和控制执行（安全校验、身份映射、审计记录）。它不只是一个静态的知识库，而是一个参与运行时执行的活跃组件，这是"枢纽"这个定位的实际含义。

为什么分层

分层架构不是为了分层而分层，它解决的是一个具体的工程问题。当系统需要演进时，怎么控制变更的影响范围。

业务系统会变。新增一个功能，本体需要更新，但 Agent 执行层和交互层不需要改。大模型会换。从当前模型切到下一代模型，只影响 Agent 执行层，本体层和业务系统层不需要动。安全策略会调整。修改白名单规则，只在本体层里操作，不影响业务系统的任何代码。

每一层的变更被限制在本层内部，不会扩散到其他层。这个特性在一个持续演进的企业系统里价值显著——变更范围越小，测试成本越低，出错的概率越低，回滚的代价越小。

四层架构是整个方案的骨架，后续的部署策略、安全设计、运维机制，都在这个骨架上展开。