最近在做 LLM agent 工作流的落地时我遇到一个非常典型的问题agent 要调用工具工具需要访问内部 API而内部 API 的鉴权信息、用户敏感数据、数据库连接串到底应该放在哪里最开始大家都图省事直接把密钥、用户手机号、甚至完整的业务数据一并塞进 prompt结果工具调用倒是成功了但日志一翻全是裸奔的敏感信息。更麻烦的是当上下文被一堆无关数据填满之后模型生成的工具参数开始出现莫名其妙的偏差调用链条时不时断掉。这不是一个“再加一层脱敏”就能解决的问题。它真正考验的是你能否把“LLM 做决策需要的上下文”和“工具执行需要的真实数据”彻底拆开同时保证工具调用链路不被打断。1. 先看清一个误区敏感信息不是越多给越聪明而是越给越危险1.1 把密钥写进 prompt等于让每个请求都带上完整的事故证据很多 agent 工作流在最早期都会走一条捷径既然模型要调用工具就把工具需要的全部参数都放进去。比如一个订单查询工具开发者可能会把数据库连接串、API Token、当前用户的手机号、邮箱、家庭住址全部拼进 system prompt 里甚至让模型基于这些字段自行筛选。表面上看模型确实“更聪明”了因为它拿到了所有信息。但代价是灾难性的每次请求和响应都会被日志系统记录。一旦敏感数据进入 prompt就等于把所有机密写进了明文日志。LLM 提供商可能使用请求数据做模型质量评估。这不是说一定会出问题但至少意味着数据已经离开了你可控的边界。你不能审计“模型到底看到了什么”。哪天业务方问起来你无法说清楚哪些敏感字段曾经被发送过。如果一个方案无法回答“敏感数据流向了哪里”那它就不应该进入生产环境。1.2 为什么敏感数据会“打断”工具调用三个真实原因很多人以为敏感数据只会带来泄露风险其实它还会直接影响工具调用的成功率。我总结过三类常见故障第一个原因是上下文稀释。当你把一大堆字段塞进去之后模型需要从长上下文里找到真正和当前问题相关的少数几个字段。比如用户只问“我最近的订单到哪了”结果 prompt 里有 2000 字的用户资料、历史地址、支付方式。模型反而抓错了订单号或者把一个不相关的 ID 传给了工具。第二个原因是参数类型污染。敏感数据往往是字符串、嵌套 JSON 或时间戳而工具函数的 schema 可能要求整数 ID、枚举值或布尔值。一旦模型误把手机号当成用户 ID或者把地址字段传给只接受数字的查询函数就会直接报错或返回空结果。这不是模型能力不行而是我们把不该并存的字段放在了同一个入口里面。第三个原因是日志和审计链路断裂。敏感数据过长时可能会触发日志截断、请求超时、或者内部的安全审核规则导致工具调用在发送阶段就被拦截。这类问题最隐蔽因为代码本身没报错但请求根本没到工具函数那边。所以把敏感数据和工具调用彻底解耦不只是为了安全更是为了调用稳定性。2. 核心设计原则LLM 只负责决定“调用哪个工具”不负责“触碰这份数据”2.1 把敏感数据和工具调用解耦引用式传递我在实践里最推荐的方式是让 LLM 生成的工具调用参数里只包含“业务键”或“引用 ID”不包含真实的敏感数据。真正需要访问的密钥、数据库连接串、用户隐私字段全部由工具执行层在函数内部获取。举个常见场景用户向客服 agent 询问“我的手机号绑定了哪几个订单”。这里有两个处理思路。低级做法是把用户手机号直接传给 LLM并让模型用手机号去查询订单。高级做法是让 LLM 只生成一个resolve_customer(aliasuser_123)调用其中user_123是前面对话流程中已经通过认证环节得到的内部用户标识。真实手机号保存在 Vault 或数据库里由工具函数自己去解析LLM 全程看不到。2.2 在执行层注入真实数据而不是在 prompt 层注入这里的底层逻辑是敏感数据是“执行环境”的一部分不是“对话上下文”的一部分。对话上下文只应该包含完成当前决策所需的最小事实。比如用户需要什么能力→ 查询订单状态用户要查询的对象是谁→ 客户 ID 或订单 ID查询结果的哪些字段可以展示→ 订单号、发货状态、物流单号至于这个客户在数据库里的完整记录、API 的密钥、内部服务的调用地址都应该在工具函数内部完成注入。这个设计有几个直接好处prompt 里不再携带真实机密日志、外部 API 传输、模型服务商的缓存里都不会出现敏感字段。工具函数可以独立测试。你不需要启动一个完整的 LLM 对话流直接调用get_order_detail(order_id123)就能验证逻辑。权限控制边界清晰。哪些工具能访问什么数据由底层函数和权限系统决定而不是由 prompt 里的“临时变量”决定。2.3 用一个最小示例说清边界下面是一个常见的 Python 函数封装示例演示的是“LLM 只传订单 ID工具内部读取数据库凭据并查询”# tool_schema 中给 LLM 看的参数 # { # name: get_order_detail, # parameters: { # order_id: { type: integer } # } # } import os def get_order_detail(order_id: int): # 这一步从环境变量或密钥管理服务中读取真实连接信息 db_uri os.getenv(ORDER_DB_URI) api_key os.getenv(ORDER_SERVICE_API_KEY) # 这里发起真实的内部调用 # 不要在 prompt 或日志中输出 db_uri 和 api_key resp internal_client.get( f/internal/orders/{order_id}, headers{Authorization: fBearer {api_key}}, base_urldb_uri, ) return resp.json()在这个结构里模型能看到的只有order_id这个整数。而真正敏感的数据库连接串和 API Key只存在于工具函数运行时的环境变量里。这才能保证即使模型被诱导输出它见过的一切它也没有见过密钥。注意不要试图把密钥管理做得“只有一层”。生产环境里还需要配合环境隔离、最小权限、密钥轮换和审计日志才能算完整。3. 三种可落地的处理方案脱敏、替换、隔离3.1 方案一占位符替换 可逆映射最适合“用户资料查询”类工具。核心思路是把真实敏感字段替换成一个不可识别的占位符同时保存一张从占位符到真实数据的映射表工具内部需要时再还原。例如用户输入“帮我查一下 138****1234 的订单”agent 需要查询手机号对应的用户。但如果手机号进入 LLM 上下文就可能被日志记录。更稳妥的做法是在进入 LLM 之前先把手机号替换成ph_9f2a这样的占位符LLM 只需要理解“这是一个手机号占位符”工具函数内部再根据ph_9f2a去查询真实手机号。步骤对用户输入做 PII 识别和替换。在上下文里保留占位符与字段语义。LLM 生成包含占位符的工具调用参数。工具执行层根据占位符映射还原真实值并访问内部系统。这个方案的优点是实现成本低对现有代码侵入小。缺点是映射表本身也需要加密存储和访问控制不能直接放在数据库明文表里。另外如果映射关系丢失整个调用就会失败。3.2 方案二最小化字段 规则翻译适合“需要依据业务规则做筛选”的工具比如风控、推荐、营销策略。这类场景常常需要模型理解“什么条件应该被应用”但不一定需要它看到具体值。例如一个营销 agent 需要筛选出“近 30 天消费超过 5000 元的高价值用户”。最安全的做法是让 LLM 输出结构化规则{ metric: total_spend_last_30d, operator: gt, value: 5000 }而不是把用户消费明细列表整个丢给 LLM 去“自行判断”。这个规则可以被工具函数直接翻译成 SQL 或内部查询条件真实用户数据永远留在数据库侧不进入 prompt。这也反映出一个重要的判断LLM 的价值在于理解用户意图和生成结构化参数而不是替代后端执行引擎去做数据计算。一旦你觉得需要把大量数据塞给 LLM 才能完成任务可能不是 LLM 不够强而是你的工具层没有把查询逻辑封装好。3.3 方案三工具权限层 审批闸门有些敏感操作即使参数不包含敏感字段仍然需要流程管控。比如删除用户、导出数据、批量发送消息。这类工具应该默认不可直接调用而是进入一个“待审批”状态。在 agent 工作流里这可以通过 Tool Policy 层实现定义每个工具的敏感级别。LLM 发起工具调用后先经过 Policy 层判断。如果敏感级别高则返回需要人工确认的中间状态。人工审批通过后工具才真正执行。SENSITIVE_LEVEL { delete_user: high, export_csv: high, get_order_detail: low, } def tool_policy(tool_name: str, params: dict): level SENSITIVE_LEVEL.get(tool_name, low) if level high: return {status: requires_approval, tool: tool_name, params_preview: params} return execute_tool(tool_name, params)这个方案的额外好处是即使模型因为提示注入而被诱导发起敏感操作也还有一个独立于模型的人工闸门兜底。三种方案可以叠加使用不是互斥关系。我建议先从占位符替换和最小化字段入手等流程稳定后再引入审批闸门。4. 敏感数据破坏工具调用的排查链路4.1 先看现象是调用失败、参数错乱还是结果不完整很多团队在处理敏感数据和工具调用时第一反应是查“模型哪里回答错了”。但如果工具调用被破坏通常会有更具体的信号工具报错参数类型不对、必填字段缺失、鉴权失败。返回结果为空明明有数据但工具函数查不到。结果不完整字段被截断、脱敏后无法还原。调用链中断LLM 生成了工具调用但 Policy 层拦截agent 不知道下一步。先判断现象分类再去查具体环节效率会高很多。否则你会在日志里白白翻半天。4.2 按三层逐步检查输入、Schema、执行环境我惯用的排查顺序是看输入侧进入 LLM 的上下文里敏感字段是否已经被替换占位符和原始值之间的映射是否还存在如果脱敏是在入口做的那要看这次请求是否走了同一个入口。看 Schema 定义工具函数的 JSON Schema 是否允许 LLM 生成你期望的参数比如参数名是customer_id还是phone_number枚举值、格式、是否允许空值这些都会影响模型输出。看执行环境工具函数内部能否拿到连接数据库所需的凭据环境变量是否配置权限角色是否过期密钥管理服务是否可达很多“工具调用失败”的问题最后都出在环境变量根本没注入容器里。这个顺序背后的逻辑是先确认 LLM 没有拿到不该拿的东西再确认 LLM 能生成正确的参数最后确认工具真正能执行。反过来的话你会很容易误判成“模型太笨”而实际上后端环境早就坏了。4.3 常见坑位清单这里记录几个我实际遇到过的坑每条都值得单独写测试用例坑位现象排查方向脱敏映射丢字段工具返回“用户不存在”检查映射表是否使用同一个 ID 生成规则Schema 枚举过窄模型总是生成默认值检查 tool schema 中enum和description密钥在环境变量中未注入工具函数鉴权失败检查容器启动参数和密钥服务日志系统里打印了完整上下文符合隐私审计却找不出泄露源头检查日志组件的log_prompt开关长上下文截断工具参数缺少后半段检查上下文裁剪策略是否过滤了 JSON 结尾模型生成的占位符和映射表不一致工具无法还原真实字段占位符需要加上前缀或格式校验建议在开发环境里故意通过打印来检查“模型传入工具函数的参数是否包含敏感字段”。如果发现敏感字段又出现在了参数里不要急着修占位符先检查是哪一层导致它漏进来的。5. 长期工程化把敏感数据管理变成基础设施而不是临时补丁5.1 横切关注点Masking、Vault、Audit 三件事敏感数据处理不是一个独立功能而是贯穿所有 agent 工作流的横切关注点。我建议把它拆成三个基础能力来建设Masking Service负责数据的识别、脱敏、占位符映射和还原。它可以是一个内部服务也可以是 SDK核心是让所有 agent 统一走这条路而不是每个业务各自实现一套。Vault / Secret Store负责存放真实凭据和敏感数据。LLM 工作流的工具层必须从统一入口读取而不是把密钥散落在环境变量和代码仓库里。Audit Log记录每条上下文中是否有敏感字段、哪些工具被调用、参数是什么、结果是否包含敏感数据。审计不只是合规需要它也是排查问题的关键工具。这三者最好是独立的模块而不是写死在一个大型 agent 类内部。否则以后新增一个工具你就要在同一个类里继续堆判断逻辑最终没人敢改那一段代码。5.2 可测试性与灰度用合成数据验证脱敏链路敏感数据逻辑很难用真实数据做充分测试因为你还得保护生成测试数据的环节。更稳妥的方式是构造一批合成数据覆盖手机号、邮箱、身份证、地址、密钥等类型写一套自动化测试构造带敏感字段的输入。走一遍脱敏和工具调用流程。断言最终日志里不包含任何真实敏感字段。断言工具函数可以正常还原和执行。断言审计日志可以追踪到每一次敏感字段访问。这套测试最好放进 CI。因为 agent 的 prompt 或 tool schema 一改很有可能把之前封好的口径重新打开一个口子。5.3 适用边界什么时候单纯脱敏不够脱敏、占位符、最小化字段这些方案都有同一个前提LLM 不需要理解真实敏感值的语义。但有些场景里这个前提不成立。比如医疗辅助诊断模型必须读一段症状描述判断疾病方向再比如合同审查模型必须看到具体金额和条款才能给出建议。这类场景不能只靠“数据脱敏”解决因为它不只是保护数据还要求模型理解数据。安全边界会完全不同通常需要使用私有化部署或本地模型确保数据不出域。在细粒度权限下按最小用途开放字段。对模型输出做额外过滤防止生成结果里包含原始敏感信息。做完整的使用审计记录每一次模型访问敏感字段的上下文。这类问题已经超出了“工具调用”的范畴属于更深的合规和架构决策。所以如果你是在高合规行业里做 agent先判断业务是否必须让模型接触敏感语义再决定采用哪种方案才是正确的顺序。回到最初的问题怎么处理敏感数据而不破坏工具调用我的答案很明确不要指望“更聪明的脱敏规则”一劳永逸而是要从架构上把敏感数据和 LLM 决策过程隔离。让模型只负责生成调用意图让工具执行层负责安全地接触数据再通过审计和权限体系把整个链路罩住。这样改完之后不仅敏感数据不再往外漏工具调用的稳定性也会明显提升。因为模型终于不用在一堆无关字段里挑参数了它只需要看清那一个 ID 就够了。这是我在多个 agent 工作流里反复验证过的一条路径先隔离再优化最后才谈智能。
最近在做 LLM agent 工作流的落地时我遇到一个非常典型的问题agent 要调用工具工具需要访问内部 API而内部 API 的鉴权信息、用户敏感数据、数据库连接串到底应该放在哪里最开始大家都图省事直接把密钥、用户手机号、甚至完整的业务数据一并塞进 prompt结果工具调用倒是成功了但日志一翻全是裸奔的敏感信息。更麻烦的是当上下文被一堆无关数据填满之后模型生成的工具参数开始出现莫名其妙的偏差调用链条时不时断掉。这不是一个“再加一层脱敏”就能解决的问题。它真正考验的是你能否把“LLM 做决策需要的上下文”和“工具执行需要的真实数据”彻底拆开同时保证工具调用链路不被打断。1. 先看清一个误区敏感信息不是越多给越聪明而是越给越危险1.1 把密钥写进 prompt等于让每个请求都带上完整的事故证据很多 agent 工作流在最早期都会走一条捷径既然模型要调用工具就把工具需要的全部参数都放进去。比如一个订单查询工具开发者可能会把数据库连接串、API Token、当前用户的手机号、邮箱、家庭住址全部拼进 system prompt 里甚至让模型基于这些字段自行筛选。表面上看模型确实“更聪明”了因为它拿到了所有信息。但代价是灾难性的每次请求和响应都会被日志系统记录。一旦敏感数据进入 prompt就等于把所有机密写进了明文日志。LLM 提供商可能使用请求数据做模型质量评估。这不是说一定会出问题但至少意味着数据已经离开了你可控的边界。你不能审计“模型到底看到了什么”。哪天业务方问起来你无法说清楚哪些敏感字段曾经被发送过。如果一个方案无法回答“敏感数据流向了哪里”那它就不应该进入生产环境。1.2 为什么敏感数据会“打断”工具调用三个真实原因很多人以为敏感数据只会带来泄露风险其实它还会直接影响工具调用的成功率。我总结过三类常见故障第一个原因是上下文稀释。当你把一大堆字段塞进去之后模型需要从长上下文里找到真正和当前问题相关的少数几个字段。比如用户只问“我最近的订单到哪了”结果 prompt 里有 2000 字的用户资料、历史地址、支付方式。模型反而抓错了订单号或者把一个不相关的 ID 传给了工具。第二个原因是参数类型污染。敏感数据往往是字符串、嵌套 JSON 或时间戳而工具函数的 schema 可能要求整数 ID、枚举值或布尔值。一旦模型误把手机号当成用户 ID或者把地址字段传给只接受数字的查询函数就会直接报错或返回空结果。这不是模型能力不行而是我们把不该并存的字段放在了同一个入口里面。第三个原因是日志和审计链路断裂。敏感数据过长时可能会触发日志截断、请求超时、或者内部的安全审核规则导致工具调用在发送阶段就被拦截。这类问题最隐蔽因为代码本身没报错但请求根本没到工具函数那边。所以把敏感数据和工具调用彻底解耦不只是为了安全更是为了调用稳定性。2. 核心设计原则LLM 只负责决定“调用哪个工具”不负责“触碰这份数据”2.1 把敏感数据和工具调用解耦引用式传递我在实践里最推荐的方式是让 LLM 生成的工具调用参数里只包含“业务键”或“引用 ID”不包含真实的敏感数据。真正需要访问的密钥、数据库连接串、用户隐私字段全部由工具执行层在函数内部获取。举个常见场景用户向客服 agent 询问“我的手机号绑定了哪几个订单”。这里有两个处理思路。低级做法是把用户手机号直接传给 LLM并让模型用手机号去查询订单。高级做法是让 LLM 只生成一个resolve_customer(aliasuser_123)调用其中user_123是前面对话流程中已经通过认证环节得到的内部用户标识。真实手机号保存在 Vault 或数据库里由工具函数自己去解析LLM 全程看不到。2.2 在执行层注入真实数据而不是在 prompt 层注入这里的底层逻辑是敏感数据是“执行环境”的一部分不是“对话上下文”的一部分。对话上下文只应该包含完成当前决策所需的最小事实。比如用户需要什么能力→ 查询订单状态用户要查询的对象是谁→ 客户 ID 或订单 ID查询结果的哪些字段可以展示→ 订单号、发货状态、物流单号至于这个客户在数据库里的完整记录、API 的密钥、内部服务的调用地址都应该在工具函数内部完成注入。这个设计有几个直接好处prompt 里不再携带真实机密日志、外部 API 传输、模型服务商的缓存里都不会出现敏感字段。工具函数可以独立测试。你不需要启动一个完整的 LLM 对话流直接调用get_order_detail(order_id123)就能验证逻辑。权限控制边界清晰。哪些工具能访问什么数据由底层函数和权限系统决定而不是由 prompt 里的“临时变量”决定。2.3 用一个最小示例说清边界下面是一个常见的 Python 函数封装示例演示的是“LLM 只传订单 ID工具内部读取数据库凭据并查询”# tool_schema 中给 LLM 看的参数 # { # name: get_order_detail, # parameters: { # order_id: { type: integer } # } # } import os def get_order_detail(order_id: int): # 这一步从环境变量或密钥管理服务中读取真实连接信息 db_uri os.getenv(ORDER_DB_URI) api_key os.getenv(ORDER_SERVICE_API_KEY) # 这里发起真实的内部调用 # 不要在 prompt 或日志中输出 db_uri 和 api_key resp internal_client.get( f/internal/orders/{order_id}, headers{Authorization: fBearer {api_key}}, base_urldb_uri, ) return resp.json()在这个结构里模型能看到的只有order_id这个整数。而真正敏感的数据库连接串和 API Key只存在于工具函数运行时的环境变量里。这才能保证即使模型被诱导输出它见过的一切它也没有见过密钥。注意不要试图把密钥管理做得“只有一层”。生产环境里还需要配合环境隔离、最小权限、密钥轮换和审计日志才能算完整。3. 三种可落地的处理方案脱敏、替换、隔离3.1 方案一占位符替换 可逆映射最适合“用户资料查询”类工具。核心思路是把真实敏感字段替换成一个不可识别的占位符同时保存一张从占位符到真实数据的映射表工具内部需要时再还原。例如用户输入“帮我查一下 138****1234 的订单”agent 需要查询手机号对应的用户。但如果手机号进入 LLM 上下文就可能被日志记录。更稳妥的做法是在进入 LLM 之前先把手机号替换成ph_9f2a这样的占位符LLM 只需要理解“这是一个手机号占位符”工具函数内部再根据ph_9f2a去查询真实手机号。步骤对用户输入做 PII 识别和替换。在上下文里保留占位符与字段语义。LLM 生成包含占位符的工具调用参数。工具执行层根据占位符映射还原真实值并访问内部系统。这个方案的优点是实现成本低对现有代码侵入小。缺点是映射表本身也需要加密存储和访问控制不能直接放在数据库明文表里。另外如果映射关系丢失整个调用就会失败。3.2 方案二最小化字段 规则翻译适合“需要依据业务规则做筛选”的工具比如风控、推荐、营销策略。这类场景常常需要模型理解“什么条件应该被应用”但不一定需要它看到具体值。例如一个营销 agent 需要筛选出“近 30 天消费超过 5000 元的高价值用户”。最安全的做法是让 LLM 输出结构化规则{ metric: total_spend_last_30d, operator: gt, value: 5000 }而不是把用户消费明细列表整个丢给 LLM 去“自行判断”。这个规则可以被工具函数直接翻译成 SQL 或内部查询条件真实用户数据永远留在数据库侧不进入 prompt。这也反映出一个重要的判断LLM 的价值在于理解用户意图和生成结构化参数而不是替代后端执行引擎去做数据计算。一旦你觉得需要把大量数据塞给 LLM 才能完成任务可能不是 LLM 不够强而是你的工具层没有把查询逻辑封装好。3.3 方案三工具权限层 审批闸门有些敏感操作即使参数不包含敏感字段仍然需要流程管控。比如删除用户、导出数据、批量发送消息。这类工具应该默认不可直接调用而是进入一个“待审批”状态。在 agent 工作流里这可以通过 Tool Policy 层实现定义每个工具的敏感级别。LLM 发起工具调用后先经过 Policy 层判断。如果敏感级别高则返回需要人工确认的中间状态。人工审批通过后工具才真正执行。SENSITIVE_LEVEL { delete_user: high, export_csv: high, get_order_detail: low, } def tool_policy(tool_name: str, params: dict): level SENSITIVE_LEVEL.get(tool_name, low) if level high: return {status: requires_approval, tool: tool_name, params_preview: params} return execute_tool(tool_name, params)这个方案的额外好处是即使模型因为提示注入而被诱导发起敏感操作也还有一个独立于模型的人工闸门兜底。三种方案可以叠加使用不是互斥关系。我建议先从占位符替换和最小化字段入手等流程稳定后再引入审批闸门。4. 敏感数据破坏工具调用的排查链路4.1 先看现象是调用失败、参数错乱还是结果不完整很多团队在处理敏感数据和工具调用时第一反应是查“模型哪里回答错了”。但如果工具调用被破坏通常会有更具体的信号工具报错参数类型不对、必填字段缺失、鉴权失败。返回结果为空明明有数据但工具函数查不到。结果不完整字段被截断、脱敏后无法还原。调用链中断LLM 生成了工具调用但 Policy 层拦截agent 不知道下一步。先判断现象分类再去查具体环节效率会高很多。否则你会在日志里白白翻半天。4.2 按三层逐步检查输入、Schema、执行环境我惯用的排查顺序是看输入侧进入 LLM 的上下文里敏感字段是否已经被替换占位符和原始值之间的映射是否还存在如果脱敏是在入口做的那要看这次请求是否走了同一个入口。看 Schema 定义工具函数的 JSON Schema 是否允许 LLM 生成你期望的参数比如参数名是customer_id还是phone_number枚举值、格式、是否允许空值这些都会影响模型输出。看执行环境工具函数内部能否拿到连接数据库所需的凭据环境变量是否配置权限角色是否过期密钥管理服务是否可达很多“工具调用失败”的问题最后都出在环境变量根本没注入容器里。这个顺序背后的逻辑是先确认 LLM 没有拿到不该拿的东西再确认 LLM 能生成正确的参数最后确认工具真正能执行。反过来的话你会很容易误判成“模型太笨”而实际上后端环境早就坏了。4.3 常见坑位清单这里记录几个我实际遇到过的坑每条都值得单独写测试用例坑位现象排查方向脱敏映射丢字段工具返回“用户不存在”检查映射表是否使用同一个 ID 生成规则Schema 枚举过窄模型总是生成默认值检查 tool schema 中enum和description密钥在环境变量中未注入工具函数鉴权失败检查容器启动参数和密钥服务日志系统里打印了完整上下文符合隐私审计却找不出泄露源头检查日志组件的log_prompt开关长上下文截断工具参数缺少后半段检查上下文裁剪策略是否过滤了 JSON 结尾模型生成的占位符和映射表不一致工具无法还原真实字段占位符需要加上前缀或格式校验建议在开发环境里故意通过打印来检查“模型传入工具函数的参数是否包含敏感字段”。如果发现敏感字段又出现在了参数里不要急着修占位符先检查是哪一层导致它漏进来的。5. 长期工程化把敏感数据管理变成基础设施而不是临时补丁5.1 横切关注点Masking、Vault、Audit 三件事敏感数据处理不是一个独立功能而是贯穿所有 agent 工作流的横切关注点。我建议把它拆成三个基础能力来建设Masking Service负责数据的识别、脱敏、占位符映射和还原。它可以是一个内部服务也可以是 SDK核心是让所有 agent 统一走这条路而不是每个业务各自实现一套。Vault / Secret Store负责存放真实凭据和敏感数据。LLM 工作流的工具层必须从统一入口读取而不是把密钥散落在环境变量和代码仓库里。Audit Log记录每条上下文中是否有敏感字段、哪些工具被调用、参数是什么、结果是否包含敏感数据。审计不只是合规需要它也是排查问题的关键工具。这三者最好是独立的模块而不是写死在一个大型 agent 类内部。否则以后新增一个工具你就要在同一个类里继续堆判断逻辑最终没人敢改那一段代码。5.2 可测试性与灰度用合成数据验证脱敏链路敏感数据逻辑很难用真实数据做充分测试因为你还得保护生成测试数据的环节。更稳妥的方式是构造一批合成数据覆盖手机号、邮箱、身份证、地址、密钥等类型写一套自动化测试构造带敏感字段的输入。走一遍脱敏和工具调用流程。断言最终日志里不包含任何真实敏感字段。断言工具函数可以正常还原和执行。断言审计日志可以追踪到每一次敏感字段访问。这套测试最好放进 CI。因为 agent 的 prompt 或 tool schema 一改很有可能把之前封好的口径重新打开一个口子。5.3 适用边界什么时候单纯脱敏不够脱敏、占位符、最小化字段这些方案都有同一个前提LLM 不需要理解真实敏感值的语义。但有些场景里这个前提不成立。比如医疗辅助诊断模型必须读一段症状描述判断疾病方向再比如合同审查模型必须看到具体金额和条款才能给出建议。这类场景不能只靠“数据脱敏”解决因为它不只是保护数据还要求模型理解数据。安全边界会完全不同通常需要使用私有化部署或本地模型确保数据不出域。在细粒度权限下按最小用途开放字段。对模型输出做额外过滤防止生成结果里包含原始敏感信息。做完整的使用审计记录每一次模型访问敏感字段的上下文。这类问题已经超出了“工具调用”的范畴属于更深的合规和架构决策。所以如果你是在高合规行业里做 agent先判断业务是否必须让模型接触敏感语义再决定采用哪种方案才是正确的顺序。回到最初的问题怎么处理敏感数据而不破坏工具调用我的答案很明确不要指望“更聪明的脱敏规则”一劳永逸而是要从架构上把敏感数据和 LLM 决策过程隔离。让模型只负责生成调用意图让工具执行层负责安全地接触数据再通过审计和权限体系把整个链路罩住。这样改完之后不仅敏感数据不再往外漏工具调用的稳定性也会明显提升。因为模型终于不用在一堆无关字段里挑参数了它只需要看清那一个 ID 就够了。这是我在多个 agent 工作流里反复验证过的一条路径先隔离再优化最后才谈智能。
