前面讨论 IT 部门的顾虑时提到了权限不可控的问题AI 可能访问不该访问的数据调用不该调用的接口。这个问题的工程解法是这篇的主题。传统方案的做法和代价在没有本体层的方案里让 AI 调用业务系统的常见做法是为 AI 单独开发一套机机接口machine-to-machine API。逻辑是清晰的人机接口是为人类用户设计的带有会话状态、Cookie、前端验证逻辑AI 直接调用人机接口会遇到各种障碍机机接口专门为程序调用设计输入输出格式规范鉴权方式简单AI 可以直接使用。这个做法在小系统上是可行的。但一个中型的业务系统人机接口可能有三四百个。如果每个接口都要改造出一个对应的机机版本开发工作量是可观的而且维护成本会持续存在每次业务系统的接口发生变化机机接口也要跟着更新两套接口的同步是一个永续的负担。更深层的问题是权限。很多粗糙的机机接口实现会使用一个固定的服务账号鉴权这个服务账号要么权限太大能访问所有数据要么权限太小某些接口调用不了很难精确对应当前操作用户应有的权限。比如张三发起了一个查询请求AI 用服务账号去调系统看到的是服务账号而不是张三而是“xxx AI 智能体”张三没有权限看的数据AI 可能也能查到。这不是 AI 的问题是接口设计和身份传递方式的问题。设计良好的机机接口可以通过 OAuth On-Behalf-Of、Token Exchange、委托作用域等方式保留用户上下文但如果只是给 AI 一个固定服务账号是谁在操作这个信息还是会被抹掉除非在开发阶段针对每个环节做大量特殊处理。当前用户上下文是什么业务系统里的大多数操作都依赖当前是谁在操作这个信息。一个仓库管理员查库存系统返回他所在仓库的数据。一个采购员创建采购订单系统自动填入他的工号作为经办人。一个部门经理审批出库单系统检查这张单据是否在他的审批权限范围内。这些行为的背后是系统在每次操作时都知道当前用户是谁并据此决定能看什么数据、能做什么操作、操作结果记录在谁名下。这套机制在人机交互场景里运转得很好因为用户登录之后系统一直持有这个用户的会话信息每次操作都隐含地附带了是谁在操作的上下文。AI 调用系统时这个上下文断掉了。AI 不是一个登录了系统的用户它是一个外部程序发起的调用没有用户会话附着系统不知道这个调用代表的是哪个用户。用服务账号鉴权是一种妥协但它解决不了当前用户是谁这个根本问题。本体层的设计目标就是在不改造业务系统接口的前提下完整地重建这个当前用户上下文。本体层怎么做到的在我们的解决方案中本体层通过活字格低代码平台配套的 CLI 调用业务系统这个 CLI 在调用时保留的是当前用户上下文不是一个脱离用户的高权限服务账号。具体机制可以有几种实现。在活字格生态里常见方式是工作台和业务系统接入同一套身份体系用户登录工作台后本体层通过当前用户代理、短期会话令牌或者受限服务身份 用户映射的方式发起调用。这里的关键不是保存用户账号密码而是让每一次调用都能带上明确的用户主体、会话边界和授权范围。相关令牌需要短期有效、加密保存、绑定会话并支持过期、刷新和撤销。之后每次 Agent 通过本体层调用业务系统本体层都以这个用户的授权上下文发起请求。从业务系统的权限判断来看这次请求代表的是一个已认证用户而不是一个拥有全局权限的 AI 服务账号。系统按这个用户的权限处理请求他能看的数据才返回他能做的操作才执行。在活字格这类可以复用既有人机接口和鉴权机制的系统里这通常不需要为 AI 另行改造一套机机接口因为业务系统接收到的请求格式和人机操作保持一致。但这不意味着审计上要把 AI 代理隐藏起来。更好的做法是权限判断沿用用户身份审计链路同时记录用户主体和 AI 代理主体。这意味着什么这个设计的工程价值要放在对比里才能看清楚。粗糙的机机接口方案开发三四百个机机接口维护两套接口用固定服务账号鉴权权限是粗粒度的操作日志记录的是服务账号而不是真实用户。本体层方案尽量复用既有人机接口减少单独机机接口改造调用时带上当前用户上下文权限和人机操作对齐审计时同时记录真实用户和 AI 代理。对 IT 部门来说后者在安全模型上比固定服务账号方案更容易治理不是更宽松。AI 通过本体层调用系统首先受到当前用户权限约束在此之外本体层还加了白名单约束只有在白名单里的接口才能被 AI 调用。即便这个用户在系统里有权限调用某个接口如果这个接口不在白名单里AI 也调不了。这个特性是第四篇里讨论的 IT 部门顾虑的直接回应AI 的权限边界不应该比人类用户更宽而且可以通过白名单进一步收窄。对于写入、删除、外发、批量操作这类高风险动作还应该叠加参数约束、操作限额、人工确认和异常中止机制。审计日志的完整性这个设计的另一个收益是审计日志的可读性。粗糙的服务账号方案里操作日志里的主体是服务账号比如ai_service_account。审计人员看到一条ai_service_account 在 14:23 查询了采购订单表不知道这次查询是哪个用户发起的是什么任务触发的出了问题也无法追溯到具体的人。本体层方案里审计日志应该同时保留两个主体subjectzhang.san表示权限判断和业务责任归属于张三actorai_workbench或actoragent表示这次操作是由某个数字员工代理执行。审计人员看到这条记录时既知道它代表哪个用户的权限上下文也知道它不是张三手工点击产生的而是一次 AI 代理调用。两层日志合在一起构成了一个完整的审计链路用户说了什么、AI 做了什么判断、实际调用了什么接口、这次调用代表哪个用户、由哪个 Agent 执行、系统返回了什么、最终呈现给用户的是什么。这条链路的完整性是企业 IT 治理的基础要求之一。一个需要注意的边界这个方案有一个前提用户在工作台登录时工作台和业务系统之间要能建立可靠的身份映射。如果业务系统用的是独立的账号系统和工作台的登录体系没有打通当前用户代理或委托授权就需要额外的适配工作。在活字格生态里这个前提通常更容易满足。活字格自带用户管理或者可以对接企业的统一身份认证LDAP、SSO工作台和业务系统共享同一套用户体系当前用户上下文就比较容易传递。如果企业的系统存在多套身份认证体系需要在部署阶段评估统一认证的改造成本这不是本体层设计的缺陷而是企业 IT 基础设施的历史问题独立于 AI 工作台的引入而存在。从能不能用到该不该信任IT 部门对 AI 系统的顾虑通常分两个层次。第一层是能不能用也就是 AI 调用系统在技术上行不行得通。第二层是该不该信任也就是 AI 的行为是否在可控范围内出了问题是否有迹可查。粗糙的机机接口方案解决了第一层但在第二层留下了空白。服务账号权限宽泛日志不可追溯IT 部门没有办法回答AI 到底做了什么这个问题。设计良好的委托授权接口也可以解决这些问题但需要额外建设身份传递、作用域控制和审计关联机制。本体层方案的价值是把这些治理能力集中到一个控制面里。调用技术上可行权限跟随真实用户日志能同时关联用户和 Agent白名单控制额外的操作边界。这四个特性合在一起才构成了一个 IT 部门可以评估和放行的安全模型。第四篇说 IT 部门和业务部门的矛盾根源是企业对 AI 行为缺乏治理能力本体层是这个问题在工程上的具体回答。
本体层如何解决“当前用户上下文“的难题？告别机机接口改造
发布时间：2026/6/16 12:10:28
前面讨论 IT 部门的顾虑时提到了权限不可控的问题AI 可能访问不该访问的数据调用不该调用的接口。这个问题的工程解法是这篇的主题。传统方案的做法和代价在没有本体层的方案里让 AI 调用业务系统的常见做法是为 AI 单独开发一套机机接口machine-to-machine API。逻辑是清晰的人机接口是为人类用户设计的带有会话状态、Cookie、前端验证逻辑AI 直接调用人机接口会遇到各种障碍机机接口专门为程序调用设计输入输出格式规范鉴权方式简单AI 可以直接使用。这个做法在小系统上是可行的。但一个中型的业务系统人机接口可能有三四百个。如果每个接口都要改造出一个对应的机机版本开发工作量是可观的而且维护成本会持续存在每次业务系统的接口发生变化机机接口也要跟着更新两套接口的同步是一个永续的负担。更深层的问题是权限。很多粗糙的机机接口实现会使用一个固定的服务账号鉴权这个服务账号要么权限太大能访问所有数据要么权限太小某些接口调用不了很难精确对应当前操作用户应有的权限。比如张三发起了一个查询请求AI 用服务账号去调系统看到的是服务账号而不是张三而是“xxx AI 智能体”张三没有权限看的数据AI 可能也能查到。这不是 AI 的问题是接口设计和身份传递方式的问题。设计良好的机机接口可以通过 OAuth On-Behalf-Of、Token Exchange、委托作用域等方式保留用户上下文但如果只是给 AI 一个固定服务账号是谁在操作这个信息还是会被抹掉除非在开发阶段针对每个环节做大量特殊处理。当前用户上下文是什么业务系统里的大多数操作都依赖当前是谁在操作这个信息。一个仓库管理员查库存系统返回他所在仓库的数据。一个采购员创建采购订单系统自动填入他的工号作为经办人。一个部门经理审批出库单系统检查这张单据是否在他的审批权限范围内。这些行为的背后是系统在每次操作时都知道当前用户是谁并据此决定能看什么数据、能做什么操作、操作结果记录在谁名下。这套机制在人机交互场景里运转得很好因为用户登录之后系统一直持有这个用户的会话信息每次操作都隐含地附带了是谁在操作的上下文。AI 调用系统时这个上下文断掉了。AI 不是一个登录了系统的用户它是一个外部程序发起的调用没有用户会话附着系统不知道这个调用代表的是哪个用户。用服务账号鉴权是一种妥协但它解决不了当前用户是谁这个根本问题。本体层的设计目标就是在不改造业务系统接口的前提下完整地重建这个当前用户上下文。本体层怎么做到的在我们的解决方案中本体层通过活字格低代码平台配套的 CLI 调用业务系统这个 CLI 在调用时保留的是当前用户上下文不是一个脱离用户的高权限服务账号。具体机制可以有几种实现。在活字格生态里常见方式是工作台和业务系统接入同一套身份体系用户登录工作台后本体层通过当前用户代理、短期会话令牌或者受限服务身份 用户映射的方式发起调用。这里的关键不是保存用户账号密码而是让每一次调用都能带上明确的用户主体、会话边界和授权范围。相关令牌需要短期有效、加密保存、绑定会话并支持过期、刷新和撤销。之后每次 Agent 通过本体层调用业务系统本体层都以这个用户的授权上下文发起请求。从业务系统的权限判断来看这次请求代表的是一个已认证用户而不是一个拥有全局权限的 AI 服务账号。系统按这个用户的权限处理请求他能看的数据才返回他能做的操作才执行。在活字格这类可以复用既有人机接口和鉴权机制的系统里这通常不需要为 AI 另行改造一套机机接口因为业务系统接收到的请求格式和人机操作保持一致。但这不意味着审计上要把 AI 代理隐藏起来。更好的做法是权限判断沿用用户身份审计链路同时记录用户主体和 AI 代理主体。这意味着什么这个设计的工程价值要放在对比里才能看清楚。粗糙的机机接口方案开发三四百个机机接口维护两套接口用固定服务账号鉴权权限是粗粒度的操作日志记录的是服务账号而不是真实用户。本体层方案尽量复用既有人机接口减少单独机机接口改造调用时带上当前用户上下文权限和人机操作对齐审计时同时记录真实用户和 AI 代理。对 IT 部门来说后者在安全模型上比固定服务账号方案更容易治理不是更宽松。AI 通过本体层调用系统首先受到当前用户权限约束在此之外本体层还加了白名单约束只有在白名单里的接口才能被 AI 调用。即便这个用户在系统里有权限调用某个接口如果这个接口不在白名单里AI 也调不了。这个特性是第四篇里讨论的 IT 部门顾虑的直接回应AI 的权限边界不应该比人类用户更宽而且可以通过白名单进一步收窄。对于写入、删除、外发、批量操作这类高风险动作还应该叠加参数约束、操作限额、人工确认和异常中止机制。审计日志的完整性这个设计的另一个收益是审计日志的可读性。粗糙的服务账号方案里操作日志里的主体是服务账号比如ai_service_account。审计人员看到一条ai_service_account 在 14:23 查询了采购订单表不知道这次查询是哪个用户发起的是什么任务触发的出了问题也无法追溯到具体的人。本体层方案里审计日志应该同时保留两个主体subjectzhang.san表示权限判断和业务责任归属于张三actorai_workbench或actoragent表示这次操作是由某个数字员工代理执行。审计人员看到这条记录时既知道它代表哪个用户的权限上下文也知道它不是张三手工点击产生的而是一次 AI 代理调用。两层日志合在一起构成了一个完整的审计链路用户说了什么、AI 做了什么判断、实际调用了什么接口、这次调用代表哪个用户、由哪个 Agent 执行、系统返回了什么、最终呈现给用户的是什么。这条链路的完整性是企业 IT 治理的基础要求之一。一个需要注意的边界这个方案有一个前提用户在工作台登录时工作台和业务系统之间要能建立可靠的身份映射。如果业务系统用的是独立的账号系统和工作台的登录体系没有打通当前用户代理或委托授权就需要额外的适配工作。在活字格生态里这个前提通常更容易满足。活字格自带用户管理或者可以对接企业的统一身份认证LDAP、SSO工作台和业务系统共享同一套用户体系当前用户上下文就比较容易传递。如果企业的系统存在多套身份认证体系需要在部署阶段评估统一认证的改造成本这不是本体层设计的缺陷而是企业 IT 基础设施的历史问题独立于 AI 工作台的引入而存在。从能不能用到该不该信任IT 部门对 AI 系统的顾虑通常分两个层次。第一层是能不能用也就是 AI 调用系统在技术上行不行得通。第二层是该不该信任也就是 AI 的行为是否在可控范围内出了问题是否有迹可查。粗糙的机机接口方案解决了第一层但在第二层留下了空白。服务账号权限宽泛日志不可追溯IT 部门没有办法回答AI 到底做了什么这个问题。设计良好的委托授权接口也可以解决这些问题但需要额外建设身份传递、作用域控制和审计关联机制。本体层方案的价值是把这些治理能力集中到一个控制面里。调用技术上可行权限跟随真实用户日志能同时关联用户和 Agent白名单控制额外的操作边界。这四个特性合在一起才构成了一个 IT 部门可以评估和放行的安全模型。第四篇说 IT 部门和业务部门的矛盾根源是企业对 AI 行为缺乏治理能力本体层是这个问题在工程上的具体回答。
