本文讨论的是一个成型的 Agent 方案企业级 AI 工作台。方案采用的一种四层实现方式从上到下是交互层、Agent 执行层、本体层、业务系统层。它不是行业里唯一的标准分法而是为了把职责边界、安全控制和系统集成关系讲清楚。理解这个分层是后续讨论部署、安全、运维的前提。第一层交互层交互层是用户和 Agent 之间的界面分两个部分。一部分是业务人员使用的 CUIConversational 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 执行层本体层和业务系统层不需要动。安全策略会调整。修改白名单规则只在本体层里操作不影响业务系统的任何代码。每一层的变更被限制在本层内部不会扩散到其他层。这个特性在一个持续演进的企业系统里价值显著——变更范围越小测试成本越低出错的概率越低回滚的代价越小。四层架构是整个方案的骨架后续的部署策略、安全设计、运维机制都在这个骨架上展开。