把一家企业的内部知识库接入大模型助手之后最让人头疼的往往不是模型“能力不够”而是它“太自由了”。我见过一个项目用户明明没有华东区域的销售数据权限却能在对话里问出该区域的月度总结模型明明只被要求“基于知识库回答”却在一次闲聊中顺手调用了邮件发送工具。技术团队最初以为是权限系统没接好后来把请求链路回放了一遍才发现真正的瓶颈不在权限系统也不在模型能力而在我们很少单独拎出来讨论的 Context Rules——上下文规则。上下文规则不是提示词里那句“请遵守公司规定”的空话。它是企业治理和生成式 AI 应用之间真正的执行层。从工程实践看企业级的 AI 治理要落地需要把上下文规则拆成四类身份与访问控制类、数据与内容边界类、行为与输出约束类、审计与合规支撑类。这四类规则不是四段提示词模板而是每轮请求里都会生效的治理逻辑。这篇文章就围绕这个判断展开讲清楚每一类规则解决什么问题、怎么落地以及四类规则如何协同运作。1. 为什么企业治理的真正抓手是更早的“上下文规则”而不是下游过滤1.1 传统治理模型在下游生成式 AI 的治理要前移过去做企业系统治理习惯把控制点放在下游接口网关校验权限敏感词系统过滤文本事后审计追踪操作记录。这套思路放到传统软件里够用因为传统系统的行为是确定的一个用户能不能访问某个接口在请求进入业务逻辑之前就可以判断。到了大模型应用里问题变复杂了。模型输出是逐 token 概率生成的它不是一个确定性的函数。如果你等模型把话说完再去做关键词过滤、敏感信息拦截等于让模型已经“想到”了不该想的内容只是你在最后一步把它拦截下来。这种下游拦截面对已知模式有效但面对用户换一种措辞、换一个绕弯的提问很容易漏。所以要把治理前移。真正稳定的方式是在模型生成之前就通过上下文规则限定它“能接触什么信息、能调用什么动作、能输出什么格式、能留下什么痕迹”。这不是取消下游过滤而是让下游过滤只作为兜底而不是主要防线。1.2 “上下文规则”到底约束了什么上下文规则是指写入模型输入上下文的一组策略化约束。它回答四个核心问题当前用户是谁拥有哪些权限这次任务允许接触哪些数据源和数据范围模型允许调用哪些工具禁止调用哪些工具输出应该遵守什么格式请求需要保留哪些审计标记这和普通提示词不一样。普通提示词解决的是“把任务说清楚”上下文规则解决的是“把任务的边界定死”。一个偏引导一个偏约束。企业治理需要的不是模型“尽量遵守”而是规则“强制生效”。1.3 一个核心判断真正让 AI 应用变得“合规可控”的不是换一个更强的模型而是把上下文规则分类设计好。更强模型解决的是理解和生成质量问题但治理问题本质上是边界问题。边界没定义清楚模型越强越容易在错误方向上做得很出色。后面四节就是四类上下文规则的具体拆解。每一类规则都对应一组常见治理事故也对应一套可以落到代码和配置里的做法。2. 第一类上下文规则身份与访问控制先回答“你是谁、能看什么、能做什么”2.1 系统层鉴权解决不了“模型替谁干活”的问题很多企业做 AI 应用时会把大模型封装成一个服务后端统一用一个服务账号去调用。这时候系统层鉴权只能确认“调用者通过了网关”但模型内部不知道当前用户是谁。当两个不同权限的用户在同一个应用里提问时如果上下文里没有用户身份信息模型就只能按默认权限回答问题。这会造成一个很典型的横向越权用户 A 没有财务数据权限但因为他能正常访问 AI 助手而 AI 助手背后连接着一个权限很高的向量库或数据库他只要问对问题就可能拿到不该看的内容。问题不在模型而在上下文里缺少“当前用户是谁、能看什么数据、能做什么操作”的规则。2.2 最小实现把身份和权限摘要注入上下文常见实践里可以在服务端组装请求时把当前用户的身份和权限摘要拼进系统提示词。下面是一个示例结构不是唯一写法但思路可以参考system_prompt build_base_prompt() current_user get_current_user(request) permission_summary get_permission_summary(current_user) system_prompt f # 访问控制规则 当前用户ID: {current_user.user_id} 角色: {current_user.role} 允许访问的数据域: {, .join(permission_summary.data_domains)} 允许调用的工具: {, .join(permission_summary.allowed_tools)} 禁止调用的工具: {, .join(permission_summary.forbidden_tools)} 关键在于“权限摘要”不能是全部权限表的原文。一个大型企业的用户可能关联几十个角色、数百条权限全部塞进上下文既浪费 token也会让模型在判断时失焦。工程上需要把权限预处理成一句话或一个短列表只保留与本次任务相关的数据域、工具和操作范围。权限摘要字段可以按下面的样子设计字段示例值说明user_idu_1002用户唯一标识用于审计roleregional_manager角色名称data_domains华东销售数据, 产品目录允许访问的业务数据域allowed_toolssearch_orders, get_customer_info允许调用的工具白名单forbidden_toolssend_email, delete_record明确禁止调用的工具2.3 落地时不要把完整权限树塞进提示词实际项目里最常见的错误是权限规则只写在应用层没有写进上下文。比如后端代码里判断“用户能否搜索订单”但模型仍然可以基于用户说的话去推测订单内容。另一个常见错误是把权限规则写成一大段自然语言“你应该尊重用户的权限不能展示用户无权访问的信息。”这种话对模型的约束力非常弱因为它没有给出具体清单。更稳妥的做法是给模型一个明确的权限摘要列表并在检索和工具调用环节同步生效。也就是说上下文里说“用户只能访问华东销售数据”后端检索时也要真正按这个范围过滤。上下文规则负责约束模型的语言和行为后端策略负责约束数据和动作两者必须一致。注意上下文规则里的访问控制不是一句“请遵守权限”。它应该是一份可以被模型直接引用的清单当前用户是谁允许哪些数据域允许调用哪些工具禁止调用哪些工具。3. 第二类上下文规则数据与内容边界限制模型能“接触”和“引用”的信息3.1 没有数据边界RAG 会把不该看到的内容带进回答身份与访问控制规则解决“谁有权限”数据与内容边界规则解决“这次任务能接触哪些信息”。两者容易混但其实是两个维度。一个用户可能拥有“华东销售数据”的权限但这次提问属于“产品故障排查”。如果没有数据边界规则模型在 RAG 检索时可能把华东销售数据、人员信息、财务摘要等一堆相关但越界的内容一起检索出来。后面的访问控制规则即使生效也只能决定“能不能往前端输出”但模型可能已经看到了这些内容并在回答过程中被它们影响。数据边界规则的核心是控制检索范围和引用范围。它不是禁止模型“知道”某些事而是让模型这次任务根本不需要去检索那些事。3.2 用元数据过滤和标签规则实现数据边界实际落地时数据边界往往通过检索器的元数据过滤来实现。你可以给文档或数据源打上业务域、敏感级别、所属部门等标签然后在检索请求里带上过滤条件{ query: Q2 回款情况如何, filters: { business_domain: sales, region: east_china, sensitivity_level: [internal, confidential] }, top_k: 5 }在上下文规则里同样可以把允许引用的数据范围写进去# 数据边界规则 本次任务允许引用的数据源 - 数据域sales - 区域east_china - 敏感级别internal, confidential 本次任务禁止检索的数据源 - 人事档案 - 财务明细未脱敏 - 其他 BU 销售数据这条规则要和检索器配置一起落实。上下文规则告诉模型“不要引用范围外的数据”检索器则保证范围外的数据根本不会被查出来。只有两层同时生效才不会出现在中间环节就已经越界的情况。3.3 脱敏规则不是“请保护隐私”而是输出层强制约束除了限制检索范围数据边界还包含脱敏规则。对话场景里模型经常需要引用客户名称、订单号、金额等字段。如果企业要求最小化暴露就不能只靠提示词里写一句“请保护隐私”。更可控的写法是在上下文规则里指定输出要求# 脱敏规则 - 客户姓名只保留姓氏和首字母例如“张*” - 地址只显示城市级别 - 金额保留到百位 - 不输出完整身份证号、银行账号、手机号同时在检索和数据准备阶段也要做脱敏或字段裁剪让模型压根没有机会拿到完整字段的明文。依赖模型自我约束来保护敏感信息等于把安全寄托在概率上不推荐。3.4 内容边界不是一句“不要泄露”很多项目失败是因为把内容边界规则写成了道德口号。模型不是不理解“不要泄露”而是它不知道“泄露”在本项目里的具体边界是什么。哪些字段算敏感哪些数据域属于越权哪些场景下可以输出联系方式这些都要落到可判定的规则里。边界的本质是确定性的。规则越靠近“可判断”模型执行起来越稳。4. 第三类上下文规则行为与输出约束定义模型能触发哪些动作、输出什么形状4.1 行为规则把 Agent 的“手”关进白名单模型不只是回答问题很多场景里它还会调用工具、执行动作、发送消息、更新数据。这时候行为规则就非常关键。一个没有行为约束的 Agent可能会因为用户说“顺便帮我发个邮件”就去调用邮件接口。如果上下文规则里没有限定工具范围模型很有可能做出超出真实任务边界的动作。最小实现是给模型一个工具白名单和黑名单# 行为约束规则 允许调用工具 - search_orders - get_customer_info - generate_report 禁止调用工具 - send_email - delete_record - update_order - transfer_money 在调用任何工具前必须先输出工具名称、用途和参数摘要。 如果用户要求执行禁止列表中的操作直接拒绝并说明原因。行为规则的核心是把“模型可以做什么”从默认状态改成“只能在白名单内做事”。这比事后审计更安全因为有些动作一旦触发后果很难挽回。4.2 输出规则让结果像接口一样稳定企业系统里模型输出往往不是给人看一眼就结束而是会进入下游流程生成工单摘要、填报表单、更新 CRM、触发通知。如果输出格式不稳定下游解析就会报错。输出约束规则通常要求模型按 JSON Schema 输出并使用固定枚举值{ reply: string, confidence: HIGH|MEDIUM|LOW, sources: [string], needs_human_review: true|false }上下文里可以这样写# 输出格式规则 你必须按以下 JSON Schema 输出 { reply: 对用户问题的回答, confidence: HIGH | MEDIUM | LOW, sources: [引用来源ID], needs_human_review: true 或 false } 不要输出多余的说明文字。在高风险业务里还可以要求模型输出一个“人工复核标记”。这比让模型写一段流畅回答更有治理价值因为下游系统可以直接根据标记决定是否进入人工流程。4.3 拒绝行为也要规则化行为约束不能只规定“可以做什么”还要规定“遇到什么情况必须拒绝”以及“怎么拒绝”。很多场景里模型直接说“我没权限”会显得生硬但如果不拒绝又可能违反流程。可以这样写拒绝规则# 拒绝规则 在以下情况下你应拒绝执行并给出理由 - 用户请求调用禁止列表中的工具 - 用户请求跨数据域检索 - 用户请求删除/修改生产数据 - 用户请求绕过审批直接发送外部邮件 拒绝话术模板 “抱歉该操作不在当前任务的允许范围内。如需执行请联系管理员开通权限。”拒绝规则让模型在面对越权请求时行为可预期。审计时也知道模型为什么拒绝。如果发现模型偶尔“自作主张”调用工具先别急着改模型参数先检查行为约束规则里是否真的写明了工具白名单。Agent 框架默认启用的工具是这类问题最常见的隐藏来源。5. 第四类上下文规则审计与合规支撑让每次生成都可以复现和追责5.1 审计不是靠“事后日志”而是靠上下文里保留决策依据模型跑完之后日志里记录了输入和输出是不是就算审计了不够。企业治理需要回答的不只是“模型输出了什么”还要回答“模型当时拿到了哪些规则、哪些权限、哪些数据以及为什么这样输出”。如果不在上下文规则里加入审计标记事后拿到一段输出很难判断它是基于哪个版本的提示词、哪个数据范围、哪个工具列表生成的。5.2 记录规则版本与输入快照是复现问题的关键工程上可以在上下文里注入一组审计字段# 审计标记 - request_id: req_20250601_001 - rules_version: context-rules-v1.4.2 - user_id: u_1002 - data_scope: east_china_sales - tool_calls: []同时服务端要把完整的上下文输入、规则版本、模型参数、输出结果一起写入审计日志。这样遇到问题才能回放是不是规则版本变更后某类数据被放开了是不是权限摘要少了一个字段是不是某个工具的权限被默认打开。如果只记录输出不记录规则版本很多问题会变成“不可复现”。等到合规审计问起来你只能回答“当时应该没问题”这会非常被动。5.3 隐私与数据保留审计日志也要做最小化审计规则和隐私保护之间存在张力。你要记录足够的信息来追溯问题但又不能把所有敏感原始数据都落盘。更稳妥的做法是审计日志里记录“引用了哪些数据源ID”而不是记录完整内容记录“用户ID”而不是用户全名记录“规则版本”而不是完整提示词。上下文里可以用脱敏后的审计标记让模型输出中带上来源引用但不在日志里保留不必要的原始敏感字段。{ request_id: req_20250601_001, rules_version: context-rules-v1.4.2, user_id: u_1002, data_domains: [east_china_sales], tool_used: [search_orders], output_summary: 已生成Q2回款摘要, raw_input_length: 342, sensitive_field_exposed: false }这样既能满足审计要求又不会把审计系统变成第二个敏感数据仓库。5.4 规则版本本身就是合规快照上下文规则不是写一次就固定了。它会随着业务、权限、合规要求变化。每次修改规则都应该像修改代码一样走版本管理。版本号写进上下文和日志是连接“输出结果”和“治理策略”的桥梁。没有版本的规则等于没有规则的规则。6. 落地顺序与排查链路四类规则不是四张纸条而是一套协同策略6.1 推荐实施顺序先数据边界再访问控制再行为约束最后审计四类规则虽然要同时存在但实施顺序有讲究。我一般建议从外到内先明确“能碰什么数据”再明确“谁能碰”再明确“能做什么动作”最后才做“怎么留痕”。顺序的理由是数据边界决定了治理空间的下限。如果一个模型可以检索所有数据那后面无论怎么做访问控制风险都已经存在了。所以先做数据边界把能检索的信息范围缩窄再做访问控制的权限摘要最后加行为约束和审计。对已上线的系统也可以反过来补规则先补审计规则让现有请求具备可追溯性。再补行为约束防止继续发生工具乱调用。再补数据边界逐步收窄检索范围。最后补访问控制到上下文解决用户级越权问题。6.2 最小可运行流程从一次单轮对话跑通不要一开始追求所有规则都完美先跑通一次最小闭环。大致流程如下选定一个业务场景例如“销售助理查询订单”。提前准备好该场景的数据源标签和权限清单。在系统提示词里注入身份权限、数据边界、工具白名单、输出格式、审计标记。用一条用户请求验证模型输出是否符合规则。查看审计日志确认 request_id、规则版本、工具调用都有记录。再逐步增加异常场景越权提问、工具调用请求、格式错误等。单次跑通只能说明流程没有断不能说明治理稳定。接下来要补批量验证和回归测试。6.3 常见问题排查先看规则有没有生效再看规则有没有写对四类规则同时生效时一旦出问题排查顺序非常重要。下面是一个可以直接参考的排查表现象排查顺序常见根因用户看到无权访问的数据1. 访问控制规则是否注入 2. 数据边界过滤是否生效 3. 检索器元数据过滤上下文没传权限摘要或检索器没按数据域过滤模型调用了不该调用的工具1. 行为约束规则 2. Agent 框架默认工具列表 3. 工具注册白名单行为白名单未写入或 Agent 默认启用了所有工具输出格式无法解析1. 输出规则是否明确 2. 模型温度 3. 后处理解析逻辑JSON Schema 约束不清晰或输出规则与系统提示词冲突事后无法追溯1. 审计日志 2. 上下文快照 3. 规则版本记录没记录 request_id、规则版本或日志里没有上下文快照提示词太长导致成本上升1. 权限摘要是否过度 2. 审计字段是否冗余 3. 规则是否可以压缩把完整权限表、完整规则文档塞进了上下文排查时有个顺序原则先确认规则确实进入了模型输入再确认规则本身表述清晰最后才怀疑模型能力问题。很多所谓的“模型不听话”其实是规则没到达。6.4 协同示例一次请求要经过哪些规则一个用户问“帮我把华东区Q2回款整理成简报”四类规则协同工作的大致路径是服务端获取用户身份生成权限摘要。根据权限摘要生成数据边界过滤条件。模型检索数据时检索器按数据域和权限过滤。模型在上下文中看到工具白名单只允许调用查询类工具。模型按输出 Schema 生成 JSON包含来源和人工复核标记。审计日志记录 request_id、规则版本、数据范围、工具调用结果。这看起来比普通提示词工程复杂但它才是企业治理真正落地的样子。7. 治理不是限制模型而是给模型一个清晰、可执行、可追溯的决策边界7.1 四类规则叠加后最终体验反而更稳定很多人担心加了这么多上下文规则会让回答变得更机械、更生硬。但从实际项目看规则清晰的系统用户体验反而更稳定。因为模型知道自己的边界在哪里不会为了讨好用户而编造权限、调用危险工具或输出混乱格式。用户得到的回答虽然可能不会“什么都能聊”但至少是真实、可追溯、符合预期流程的。企业级应用稳定性比惊喜更重要。7.2 这套框架不适用的场景四类上下文规则并不是所有场景都需要。下面这些情况可以不做完整治理纯学习和个人实验没有真实用户数据不需要访问控制和数据边界。一次性问答玩具不接数据库、不调工具行为约束可以简化。单机离线演示不涉及审计和合规审计规则可以省略。一旦进入真实业务系统涉及真实用户、真实数据、真实操作四类规则就缺一不可。越早纳入设计后续返工成本越低。7.3 下一步把规则本身当作代码来维护上下文规则不应该散落在各个提示词文件里。它应该有独立的规则库、版本号、发布流程和回归测试。每次规则变更都要能回答改了什么、影响哪些场景、是否和现有权限体系一致。企业治理在大模型时代本质上不是选一个更“守规矩”的模型而是把治理要求变成模型上下文里清晰、可判定、可追溯的规则。而这四类上下文规则的分类就是一个可以直接上手的起点。下次当 AI 助手出现越权行为时先别急着骂模型。去看看它的上下文里四类规则是不是都写清楚了。