2. 核心细节解析与实操要点
2.1 关键组件选型：为什么选择 Gemma 2 作为底座
聊完整体思路，接下来这部分是很多人最容易纠结的地方：模型到底怎么选？
我最早其实想过直接用更大的闭源模型，但后来评估了一圈，发现企业内网审计场景有个很现实的问题：数据不能出域。审计日志里包含员工操作记录、业务数据访问痕迹、甚至部分敏感配置信息，这些内容法律上有严格的合规要求，根本不可能送到外部 API 去处理。所以本地化部署是刚需，模型必须能跑在自己的机房或者私有云上。
Gemma 2 在这个场景下有几个不可替代的优势：
第一，参数量覆盖范围好。Gemma 2 有 9B 和 27B 两个主力版本，9B 量化后单卡就能跑，27B 在双卡或单卡大显存环境下也能玩得转。这个梯度对预算有限但又需要私有化部署的企业来说非常友好。
第二，上下文窗口够用。审计场景经常需要把一整个流程的操作记录一次性塞进去分析，窗口太小就得做切片，切片又会丢失上下文连贯性，影响判断准确性。Gemma 2 的窗口能力虽然不算业界最大，但配合我的分块策略，实测处理单条审计事件链路是够用的。
第三，指令遵循能力在同量级里确实突出。Agentic RAG 的核心不是让模型背答案，而是让模型按照你给它定义的流程去调用工具、判断证据、输出结构化结论。这个过程对指令遵循的要求远高于普通问答，Gemma 2 在这一点上给了我比较大的信心。
注意：如果你选的基座模型指令遵循能力不够强，Agent 在调用工具的时候经常会出现“自作主张”的情况，比如跳过某一步验证、不按照 JSON 格式输出、把检索结果直接当结论。这是 Agentic 系统最常见的翻车点，选择模型时务必把这个指标放在第一优先级。
2.2 Prompt 编排与 Agent 工作流定义
模型选好以后，真正拉开差距的是 Prompt 编排和 Agent 工作流的定义。
审计系统的工作流我划分成了四个阶段：
第一阶段：意图识别。用户提出一个问题，比如“查一下上个月所有对财务系统的高权限访问记录”，系统先判断这个问题涉及哪些维度的数据，是访问日志、权限变更记录，还是数据导出记录？这个判断直接影响后续要激活哪些检索器。
第二阶段：检索规划。根据意图识别结果，Agent 决定需要查询哪几个数据源，按照什么顺序查询，查询条件怎么映射到具体的字段。这一步是 Agentic 和普通 RAG 最大的区别：普通 RAG 是一个 query 进去向量检索出来，Agentic RAG 会自己判断“我需要查两次数据库，一次查日志，一次查权限表，最后做关联”。
第三阶段：证据收集与验证。Agent 调用具体的检索工具拿到结果后，不是直接给用户看，而是先做一轮自我验证。比如查出来的数据里有没有明显的时间矛盾？有没有缺失的关键字段？如果证据不够充分，Agent 应该主动发起补充检索，而不是将错就错。
第四阶段：结论生成与引用标注。最终生成审查结论时，每一个判断都必须附带检索来源，做到有据可查。
这里有个很关键的设计原则：不要把所有的 Prompt 塞进一个巨大的 system message 里。我踩过这个坑，最初把所有指令放在一段里，结果模型在处理长上下文的时候经常遗漏中间部分的约束条件。后来拆分成模块化 Prompt，每个阶段有独立的指令模板，并加入“当前阶段只需要关注哪些信息”的抑制性提示，准确率明显提升。
2.3 RAG 管道的三个关键细节
RAG 做得是否扎实，决定了 Agent 的“眼睛”好不好用。审计场景的 RAG 和常见的知识库问答 RAG 有显著区别，这里有三个细节非常关键。
第一个细节是索引结构。纯粹的向量索引在审计场景下是不夠用的，因为审计数据里有大量的结构化字段，比如用户 ID、操作类型、时间戳、IP 地址。这些字段用向量检索来做既不精确也不高效。我的方案是混合索引：文本内容做向量化，结构化字段保留在关系型字段映射中。Agent 在规划检索的时候，会先生成结构化过滤条件，缩小候选集，然后再对候选集做语义相关性排序。
第二个细节是分块策略。审计日志的粒度差异非常大，有些是一条独立的操作记录，有些是一个完整业务事务的链路。如果用固定长度做分块，会把完整的事务链路拦腰截断，导致后续分析根本看不到全貌。我采用的策略是基于边界感知的分块，以事务 ID 为边界，保持每个事务的日志片段完整。
第三个细节是重排序。初检召回的结果集里，相关性最高的几个片段不一定就是最关键的证据。比如一个审计问题涉及某个用户的三次操作，其中第一次操作是根源，后面两次是结果。初检召回可能把三次操作都召回了，但排序并不能体现“根源优先”。所以我增加了一个重排序环节，让重排序模型结合时间线逻辑，把有因果关联的证据排到一起。
实操心得：重排序模型的选型不用太纠结，开源的交叉编码器模型就能承担这个角色，不需要上很大的参数。关键是把重排序的输入特征设计好，我把“时间连续性”“操作对象一致性”“会话 ID 一致性”三个特征显式拼接进了重排序的输入序列里，效果提升非常显著。
2. 核心细节解析与实操要点
2.1 关键组件选型：为什么选择 Gemma 2 作为底座
聊完整体思路，接下来这部分是很多人最容易纠结的地方：模型到底怎么选？
我最早其实想过直接用更大的闭源模型，但后来评估了一圈，发现企业内网审计场景有个很现实的问题：数据不能出域。审计日志里包含员工操作记录、业务数据访问痕迹、甚至部分敏感配置信息，这些内容法律上有严格的合规要求，根本不可能送到外部 API 去处理。所以本地化部署是刚需，模型必须能跑在自己的机房或者私有云上。
Gemma 2 在这个场景下有几个不可替代的优势：
第一，参数量覆盖范围好。Gemma 2 有 9B 和 27B 两个主力版本，9B 量化后单卡就能跑，27B 在双卡或单卡大显存环境下也能玩得转。这个梯度对预算有限但又需要私有化部署的企业来说非常友好。
第二，上下文窗口够用。审计场景经常需要把一整个流程的操作记录一次性塞进去分析，窗口太小就得做切片，切片又会丢失上下文连贯性，影响判断准确性。Gemma 2 的窗口能力虽然不算业界最大，但配合我的分块策略，实测处理单条审计事件链路是够用的。
第三，指令遵循能力在同量级里确实突出。Agentic RAG 的核心不是让模型背答案，而是让模型按照你给它定义的流程去调用工具、判断证据、输出结构化结论。这个过程对指令遵循的要求远高于普通问答，Gemma 2 在这一点上给了我比较大的信心。
注意：如果你选的基座模型指令遵循能力不够强，Agent 在调用工具的时候经常会出现“自作主张”的情况，比如跳过某一步验证、不按照 JSON 格式输出、把检索结果直接当结论。这是 Agentic 系统最常见的翻车点，选择模型时务必把这个指标放在第一优先级。
2.2 Prompt 编排与 Agent 工作流定义
模型选好以后，真正拉开差距的是 Prompt 编排和 Agent 工作流的定义。
审计系统的工作流我划分成了四个阶段：
第一阶段：意图识别。用户提出一个问题，比如“查一下上个月所有对财务系统的高权限访问记录”，系统先判断这个问题涉及哪些维度的数据，是访问日志、权限变更记录，还是数据导出记录？这个判断直接影响后续要激活哪些检索器。
第二阶段：检索规划。根据意图识别结果，Agent 决定需要查询哪几个数据源，按照什么顺序查询，查询条件怎么映射到具体的字段。这一步是 Agentic 和普通 RAG 最大的区别：普通 RAG 是一个 query 进去向量检索出来，Agentic RAG 会自己判断“我需要查两次数据库，一次查日志，一次查权限表，最后做关联”。
第三阶段：证据收集与验证。Agent 调用具体的检索工具拿到结果后，不是直接给用户看，而是先做一轮自我验证。比如查出来的数据里有没有明显的时间矛盾？有没有缺失的关键字段？如果证据不够充分，Agent 应该主动发起补充检索，而不是将错就错。
第四阶段：结论生成与引用标注。最终生成审查结论时，每一个判断都必须附带检索来源，做到有据可查。
这里有个很关键的设计原则：不要把所有的 Prompt 塞进一个巨大的 system message 里。我踩过这个坑，最初把所有指令放在一段里，结果模型在处理长上下文的时候经常遗漏中间部分的约束条件。后来拆分成模块化 Prompt，每个阶段有独立的指令模板，并加入“当前阶段只需要关注哪些信息”的抑制性提示，准确率明显提升。
2.3 RAG 管道的三个关键细节
RAG 做得是否扎实，决定了 Agent 的“眼睛”好不好用。审计场景的 RAG 和常见的知识库问答 RAG 有显著区别，这里有三个细节非常关键。
第一个细节是索引结构。纯粹的向量索引在审计场景下是不夠用的，因为审计数据里有大量的结构化字段，比如用户 ID、操作类型、时间戳、IP 地址。这些字段用向量检索来做既不精确也不高效。我的方案是混合索引：文本内容做向量化，结构化字段保留在关系型字段映射中。Agent 在规划检索的时候，会先生成结构化过滤条件，缩小候选集，然后再对候选集做语义相关性排序。
第二个细节是分块策略。审计日志的粒度差异非常大，有些是一条独立的操作记录，有些是一个完整业务事务的链路。如果用固定长度做分块，会把完整的事务链路拦腰截断，导致后续分析根本看不到全貌。我采用的策略是基于边界感知的分块，以事务 ID 为边界，保持每个事务的日志片段完整。
第三个细节是重排序。初检召回的结果集里，相关性最高的几个片段不一定就是最关键的证据。比如一个审计问题涉及某个用户的三次操作，其中第一次操作是根源，后面两次是结果。初检召回可能把三次操作都召回了，但排序并不能体现“根源优先”。所以我增加了一个重排序环节，让重排序模型结合时间线逻辑，把有因果关联的证据排到一起。
实操心得：重排序模型的选型不用太纠结，开源的交叉编码器模型就能承担这个角色，不需要上很大的参数。关键是把重排序的输入特征设计好，我把“时间连续性”“操作对象一致性”“会话 ID 一致性”三个特征显式拼接进了重排序的输入序列里，效果提升非常显著。 ## 1. 内容整体设计与思路拆解
1.1 为什么企业合规审计需要 Agentic RAG
传统意义上的合规审计，基本靠两样东西：一是人工翻日志，二是写一堆固定规则的 SQL 查询。前者的效率低到让人绝望。一个稍微像样一点的企业，每天的审计日志量级就是百万条起步，靠人眼去扫根本不可能；而后者的痛点在于规则写死之后，面对新出现的风险模式完全没有招架之力。你今天写一条规则查“凌晨三点的高权限导出操作”，明天攻击者改成凌晨两点五十，规则就废了，更别提那些复杂的、跨系统的、需要综合判断的异常链路。
RAG 的思路出现之后，很多人觉得看到了希望。把审计文档灌进向量库，然后用大模型去做问答，看起来解决了“灵活理解”的问题。但我实际试下来发现，普通 RAG 在审计场景下有个致命缺陷：它只是个“问答机器”，不具备主动性。你问它“这个操作有没有问题”，它能给你一段检索出来的相关日志片段；但你如果问它“帮我排查一下这个用户最近所有可疑操作的关联链路”，普通 RAG 就懵了。它不会自己拆解这个任务，不知道先去查用户权限变更记录，再去核对访问日志，然后还要交叉验证一下时间线。它只会做一次检索，然后把结果原样吐出来。
这正是 Agentic RAG 上场的原因。Agentic RAG 和普通 RAG 的核心差异在于，它把大模型从一个“被动的回答者”变成了“主动的调度者”。模型可以通过 ReAct 式的推理循环，自己规划要查什么、按什么顺序查、查完之后怎么验证、验证不通过怎么补救。在合规审计这个场景里，这种主动性不是锦上添花，而是刚需。因为审计任务天然是多跳的，你需要把日志系统、权限系统、账号系统、甚至工单系统的数据全部关联起来，才能对一个操作行为做出相对完整的合规性判断。
这套系统构建完成后的能力边界也很明确：它不是一个“自动处罚系统”，它的产出是审计报告、风险标记、证据链和建议措施。最终的决定权留给人，但它能极大程度地把人从“找数据、对数据、拉时间线”的重复劳动中解放出来，让人专注于“判断”本身。
1.2 系统架构：Agent 编排、RAG 管道与审计知识库的三角关系
这套系统的整体架构看起来复杂，其实核心就三大块：Agent 编排层、RAG 管道层、以及作为底座的审计知识库和工具层。
Agent 编排层是整个系统的大脑，它负责理解用户意图、拆解任务、规划检索动作，并且根据中间结果动态调整后续步骤。这一层我基于 LangGraph 实现，核心是定义一个有向图，节点是不同能力的 Agent，边是它们之间的流转条件。例如，一个“风险排查”任务进来，主 Agent 会先调“信息提取 Agent”把问题结构化，然后交给“检索规划 Agent”决定去哪些数据源查，最后汇总给“分析 Agent”产出结论。LangGraph 的好处是流程可控，你不会出现 Agent 乱跑的情况。每一步是哪个节点在做、调用了什么工具、耗时多少、中间结果是什么，全部有记录。这个可观测性在调试的时候帮了大忙。
RAG 管道层则是系统的手脚，负责把 Agent 的规划落地成具体的检索动作。这一层我做了混合检索的设计：不仅包含传统的向量检索，还接入了针对审计数据的结构化查询能力。因为审计数据里大量是字段分明的日志记录，比如操作人、目标系统、操作类型、时间戳。这些数据如果全部塞进向量数据库里做语义检索，反而丢了精度。RAG 管道的核心任务是：把 Agent 的意图映射成“结构化过滤条件 + 语义相似度阈值 + 时间范围约束”，然后到对应的数据源里把候选证据捞回来。
审计知识库和工具层是系统的地基。知识库不只是审计相关的规章制度文档、合规手册，还包括历史审计案例、风险事件库、行业规范等。工具层则是 Agent 可以调用的实际接口，比如查询日志的 API、查询权限变更记录的工具、读取用户主数据的接口等。Agentic RAG 系统最迷人的地方，就是它把“知识”和“数据”打通了。规章制度告诉你应该怎么做，数据告诉你实际发生了什么，Agent 把两者放在一起比对，才能得出合规性判断。
这套架构跑起来的整体逻辑用一句话概括：Agent 负责思考，RAG 负责找证据，知识库负责提供判断依据，最终结论又回流到知识库沉淀成新的审计经验。
1.3 直接检索生成与思考后检索的取舍
在设计 Agent 的检索策略时，我做了很多对比实验，这里有必要展开聊一聊“直接检索生成”和“思考后检索”两种模式的取舍。这个取舍直接影响系统响应延迟和准确率。
最开始我图省事，用的方案是：用户问一个问题，系统直接基于问题文本去检索，然后把检索结果和问题一起扔给模型生成答案。这种直接检索生成模式实现简单、响应也快，但在审计场景下暴露出一个严重问题：用户的问题往往非常模糊，而且是高度口语化的。比如有人问“帮我看看最近系统有没有问题”，这个问题直接拿去检索，出来的全是片汤话。“问题”这个词的语义太宽泛了，系统根本定位不到具体的风险事件。
后来我采用了思考后检索模式。Agent 收到用户问题之后，不会立刻去检索，而是先经过一个“查询改写 + 检索规划”的步骤。查改写这一步干了什么呢？它把口语化的问题改写成结构化的检索表达式。还是拿“帮我看看最近系统有没有问题”举例，改写之后变成三路并行的检索子任务：第一路查最近一周权限变更频率异常的用户；第二路查非工作时间高权限操作记录；第三路查数据导出量超过阈值的事件列表。每一路检索子任务都有明确的查询条件和目标数据源。
从实测数据来看，思考后检索模式在审计场景下的准确率提升非常明显，但代价是延迟增加了大约两到三秒。这个延迟是可以接受的，因为审计任务本身就是离线分析为主，用户关注的是结论的可靠性，而不是对话的即时反馈。如果是做实时风控拦截那种场景，可能就要另当别论了。
实操心得：思考后检索模式里最值得花时间调的是查询改写这一步。改写得好不好，直接决定了后续检索的质量。我的经验是给模型提供一套“改写模板”，比如“用户行为异常”对应哪几类检索子任务，“权限配置不合规”又对应哪几类。让模型基于模板做选择而不是凭空发挥，稳定性会高很多。
2. 核心细节解析与实操要点
2.1 关键组件选型：为什么选择 Gemma 2 作为底座
聊完整体思路，接下来这部分是很多人最容易纠结的地方：模型到底怎么选？
我最早其实想过直接用更大的闭源模型，但后来评估了一圈，发现企业内网审计场景有个很现实的问题：数据不能出域。审计日志里包含员工操作记录、业务数据访问痕迹、甚至部分敏感配置信息，这些内容法律上有严格的合规要求，根本不可能送到外部 API 去处理。所以本地化部署是刚需，模型必须能跑在自己的机房或者私有云上。
Gemma 2 在这个场景下有几个不可替代的优势：
第一，参数量覆盖范围好。Gemma 2 有 9B 和 27B 两个主力版本，9B 量化后单卡就能跑，27B 在双卡或单卡大显存环境下也能玩得转。这个梯度对预算有限但又需要私有化部署的企业来说非常友好。
第二，上下文窗口够用。审计场景经常需要把一整个流程的操作记录一次性塞进去分析，窗口太小就得做切片，切片又会丢失上下文连贯性，影响判断准确性。Gemma 2 的窗口能力虽然不算业界最大，但配合我的分块策略，实测处理单条审计事件链路是够用的。
第三，指令遵循能力在同量级里确实突出。Agentic RAG 的核心不是让模型背答案，而是让模型按照你给它定义的流程去调用工具、判断证据、输出结构化结论。这个过程对指令遵循的要求远高于普通问答，Gemma 2 在这一点上给了我比较大的信心。
注意：如果你选的基座模型指令遵循能力不够强，Agent 在调用工具的时候经常会出现“自作主张”的情况，比如跳过某一步验证、不按照 JSON 格式输出、把检索结果直接当结论。这是 Agentic 系统最常见的翻车点，选择模型时务必把这个指标放在第一优先级。
2.2 Prompt 编排与 Agent 工作流定义
模型选好以后，真正拉开差距的是 Prompt 编排和 Agent 工作流的定义。
审计系统的工作流我划分成了四个阶段：
第一阶段：意图识别。用户提出一个问题，比如“查一下上个月所有对财务系统的高权限访问记录”，系统先判断这个问题涉及哪些维度的数据，是访问日志、权限变更记录，还是数据导出记录？这个判断直接影响后续要激活哪些检索器。
第二阶段：检索规划。根据意图识别结果，Agent 决定需要查询哪几个数据源，按照什么顺序查询，查询条件怎么映射到具体的字段。这一步是 Agentic 和普通 RAG 最大的区别：普通 RAG 是一个 query 进去向量检索出来，Agentic RAG 会自己判断“我需要查两次数据库，一次查日志，一次查权限表，最后做关联”。
第三阶段：证据收集与验证。Agent 调用具体的检索工具拿到结果后，不是直接给用户看，而是先做一轮自我验证。比如查出来的数据里有没有明显的时间矛盾？有没有缺失的关键字段？如果证据不够充分，Agent 应该主动发起补充检索，而不是将错就错。
第四阶段：结论生成与引用标注。最终生成审查结论时，每一个判断都必须附带检索来源，做到有据可查。
这里有个很关键的设计原则：不要把所有的 Prompt 塞进一个巨大的 system message 里。我踩过这个坑，最初把所有指令放在一段里，结果模型在处理长上下文的时候经常遗漏中间部分的约束条件。后来拆分成模块化 Prompt，每个阶段有独立的指令模板，并加入“当前阶段只需要关注哪些信息”的抑制性提示，准确率明显提升。
2.3 RAG 管道的三个关键细节
RAG 做得是否扎实，决定了 Agent 的“眼睛”好不好用。审计场景的 RAG 和常见的知识库问答 RAG 有显著区别，这里有三个细节非常关键。
第一个细节是索引结构。纯粹的向量索引在审计场景下是不夠用的，因为审计数据里有大量的结构化字段，比如用户 ID、操作类型、时间戳、IP 地址。这些字段用向量检索来做既不精确也不高效。我的方案是混合索引：文本内容做向量化，结构化字段保留在关系型字段映射中。Agent 在规划检索的时候，会先生成结构化过滤条件，缩小候选集，然后再对候选集做语义相关性排序。
第二个细节是分块策略。审计日志的粒度差异非常大，有些是一条独立的操作记录，有些是一个完整业务事务的链路。如果用固定长度做分块，会把完整的事务链路拦腰截断，导致后续分析根本看不到全貌。我采用的策略是基于边界感知的分块，以事务 ID 为边界，保持每个事务的日志片段完整。
第三个细节是重排序。初检召回的结果集里，相关性最高的几个片段不一定就是最关键的证据。比如一个审计问题涉及某个用户的三次操作，其中第一次操作是根源，后面两次是结果。初检召回可能把三次操作都召回了，但排序并不能体现“根源优先”。所以我增加了一个重排序环节，让重排序模型结合时间线逻辑，把有因果关联的证据排到一起。
实操心得：重排序模型的选型不用太纠结，开源的交叉编码器模型就能承担这个角色，不需要上很大的参数。关键是把重排序的输入特征设计好，我把“时间连续性”“操作对象一致性”“会话 ID 一致性”三个特征显式拼接进了重排序的输入序列里，效果提升非常显著。
3. 实操过程与核心环节实现
3.1 环境搭建与模型部署准备
下面进入真正动手的部分。我会把实操过程尽量还原，方便你照着落地方案验证。
环境方面，我建议的最低配置是单张 24GB 显存的 GPU。Gemma 2 27B 用 INT4 量化之后大概占用 14GB 到 16GB 显存，再留出一些给推理缓存，24GB 是比较稳妥的起步线。如果你只有 16GB 显存，那就用 9B 版本，效果在审计场景下也够用，只是复杂推理的稳定性略逊一筹。
部署方案我推荐 vLLM，相比直接用 Transformers 的 generate 接口，vLLM 的吞吐量在并发场景下的优势非常明显。审计系统虽然以离线分析为主，但往往会有多个部门同时提交审查任务，vLLM 的 continuous batching 机制能让 GPU 利用率高出一个量级，响应时间也更稳定。
部署完成之后，有一个非常容易被忽略的步骤：模型能力基线评测。不要急着往下走，先准备一组评测用例，涵盖意图识别、工具调用、结构化输出三个维度，把模型的基线能力摸清楚。这一步相当于给后面的 Agent 编排设一个“参照系”。我在项目里就吃过亏，一开始先写了复杂的 Prompt 框架再去调模型，结果出了问题根本说不清是模型能力不行还是编排逻辑有 bug。先跑基线，后面排查问题会轻松得多。
实操心得：基线评测集不用太大，三四十条就够了。重点是每一条都得有明确的是否判断标准，否则评测结果主观性太强。比如评测工具调用的时候，不要只看模型有没有调对工具名称，还要看传给工具的参数字段是否完整、格式是否正确。
3.2 知识库加工与混合索引构建的详细步骤
数据是审计系统最重要的资产，知识库加工这一步值得花大量时间打磨。
第一步，梳理数据源。这一步的产出是一个数据资产清单，包含数据源名称、对接方式、字段结构、更新频率。以我的项目为例，主要数据源有四个：操作日志库、权限变更记录库、用户主数据库、合规制度文档库。前三个是结构化数据，第四个是非结构化文本，处理方式完全不同。
第二步，ETL 与标准化。日志和权限记录通常散落在多个系统里，需要对时间格式、用户 ID、系统名做统一映射。这步没有太多技术含量，但非常费时。我在做的时候把时间统一成 ISO 8601 格式，用户 ID 统一映射到内部工号，系统名统一用规范化别名。这些看似琐碎的标准化工作，直接决定了后续 Agent 做跨系统关联时能不能对得上。
第三步，非结构化文档分块。合规制度文档我采用的是语义分块而非固定长度分块。具体做法是：先用自然语言处理工具把文档切开，切的时候依据是章节标题和段落语义完整性，每块控制在 800 到 1200 个 Token 左右。分块之后再做向量化，我在实验里对比过 OpenAI 的嵌入模型效果和开源的本地嵌入模型效果，考虑到数据不出域，最终选择了本地的嵌入模型，在中文合规文本上的语义相似度表现足够可靠。
第四步，构建混合索引。这是最容易出问题的一步。我的做法是：把标准化后的操作日志、权限记录、用户数据全部导入一套支持“向量 + 结构化过滤”的系统里。Agent 检索的时候，先是通过结构化条件过滤，比如“用户 ID = 某员工编号 AND 时间范围 = 最近一个月”，把数据量压到几千条以内，再在这几千条里做向量检索和重排序。这套策略把检索范围控制得越小，精度和性能就越好。
3.3 Agent 工具定义与 ReAct 循环实现细节
Agent 和外部数据源打交道的通道是工具，所以工具定义的严谨程度直接决定了系统行为边界是否可控。
工具定义我采用 JSON Schema 格式，一个完整工具包含工具名称、功能描述、输入参数、输出格式四個部分。这里要特别提醒：功能描述这一栏，写的时候要尽量详细，包括这个工具适合处理什么类型的问题、不适合处理什么、返回结果的格式是怎样的。因为大模型 Agent 是通过描述来判定该不该调用这个工具的，描述写得含糊，Agent 就会在工具选型上出现混乱。
在 ReAct 循环的实现上，我的核心思路是：限制最大迭代轮数，同时为每个工具调用设定超时和异常分支。ReAct 循环如果没有限制，Agent 可能会在一个问题上反复检索几十次，严重浪费资源。我在实践中把最大迭代轮数设定在 5 到 8 轮之间。轮数太少了，复杂问题跑不完；轮数太多，多半是检索环节出了问题，需要触发告警而不是继续无意义地跑。
另外，Agent 在检索之后可能拿到的结果集非常大，直接全量塞给模型会导致内容超出窗口限制，也会稀释关键信息。我的做法是在工具返回结果定义中增加一项预过滤：工具端返回给模型的结果，是经过格式整理和条数截断的摘要，而不是原始的全量日志。例如，某次查询命中了三千条记录，工具会返回一个统计摘要以及最重要的十五条明细。这样的输出既能让 Agent 掌握全局统计数据，又能聚焦关键证据。
3.4 一次完整审计任务的端到端运行记录
这部分我用一个具体的模拟场景来完整展示系统是怎么跑起来的。
场景设定：审计人员输入问题“最近两周有没有员工在非工作时间访问了核心财务系统并且发生了数据导出”。
第一步，意图识别。Agent 分析出这是一个“高权限访问 + 数据导出”的复合风险行为，需要拆解成两个子任务分别检索。
第二步，检索规划。Agent 首先调用用户权限查询工具，找出最近两周有核心财务系统访问权限的所有员工名单；然后调用操作日志查询工具，过滤条件是时间范围锁定在非工作时间段、访问对象是核心财务系统；再调用数据导出审计工具，查询那些在相同时间窗口内发生过导出行为的会话 ID。
第三步，证据收集与验证。三路子任务返回后，Agent 执行了一次关联验证，把员工名单、非工作时间访问记录、导出会话 ID 三方数据做交集匹配。如果交集为空，系统会返回“未发现符合条件的行为”；如果交集非空，则进入下一步。
第四步，结论生成与引用标注。Agent 把命中的行为逐条生成审查意见，说明行为涉及哪些具体操作、发生在什么时间点、违反了哪条合规制度条款，并且每条意见后面紧跟相应的日志记录编号。
从录入问题到输出完整报告，实测耗时大约在 20 秒到 40 秒之间。这个耗时对于审计任务来说完全可以接受，如果换成人工来操作，同样的排查可能需要二十分钟甚至更久。
4. 常见问题与排查技巧实录
4.1 Agent 检索空结果时的循环卡死问题
做这套系统的时候，我遇到的最棘手问题之一就是 Agent 检索空结果后的循环卡死。
现象是这样的：Agent 调用某个查询工具后，返回结果为空，但 Agent 不认为任务已经完成。它反复重试同样的查询，或者尝试用略微不同的措辞重复查询同一个工具，导致整个流程陷入死循环，直到触发最大迭代终止限制，输出一堆毫无价值的中间过程。
排查之后发现根因在两点：一是工具返回空结果的表达方式太笼统，Agent 判断不了“真的没有数据”和“查询条件可能写错了”的区别；二是 Agent 的 Prompt 里没有明确规定“检索结果为空后该如何处理”。
解决方法是先给工具的返回结果增加状态字段，明确标识本次查询是正常返回空，还是查询失败异常。正常返回空时，Agent 应该能接受这个结果并基于“无异常访问记录”的事实来回答用户；查询失败时则应该转入异常处理分支，向用户报告数据源暂时不可用。接着在 Agent Prompt 里补充一条明确规则：如果某个工具连续两次查询结果为正常空，不应再重复查询，而是转向分析其他维度数据或者汇总结论。
4.2 输出格式不稳定与解析失败问题
Agent 在生成最终结论时经常出现格式不稳定的情况，这在审计报告中是不可接受的。审计报告需要机器可读，后续可能要接入存档流程或者发送到审批系统。如果模型输出的格式时好时坏，解析脚本就会频繁报错。
我在这个项目上用了两层保障。第一层是约束生成解码，直接对模型的输出做正则约束，只生成符合 JSON 语法定义的内容。第二层是设计了格式校验和修复后端，对模型生成的内容做格式校验；针对 JSON 缺少逗号或括号不配对等轻微语法问题，直接做程序化修复。
除此之外，我还在 Prompt 中对输出格式做了三层强制提示，一层是说明字段定义，一层是提供示例模板，一层是在负面提示里明确禁止输出哪些冗余内容。三层强提示叠加上约束生成解码之后，系统连续跑了一周，输出格式的解析失败率降到了千分之一以内。
4.3 检索结果时效性与审计滞后性矛盾的处理
审计场景里有一个天然矛盾：数据一直在大量更新，而审计结论需要基于某个固定时间快照，否则结论无法复现。例如，同样是排查某个操作行为，如果数据在不断滚动更新，今天跑出来的结果和明天跑出来的就可能不一致。审计报告必须具备可复现性，结论必须经得起复查。
我的处理方式是在 Agent 的检索工具中强制增加快照时间参数。每次用户发起审计任务时，系统记录当前时间，后续所有检索动作都携带“数据截至该时间点”的条件。这样，即使底层数据源持续更新，审计结论引用的始终是同一份快照数据。
这里需要数据层支持的配合，底层查询引擎需要支持“AS OF 查询”，或者是通过业务表里的生效开始时间和生效结束时间来做限定。实测下来，这个设计虽然增加了一些底层实现的复杂度，但是换来的是审计结论的严肃性和可复查性，这对于审计系统来说是绝对的刚需。
4. 常见问题与排查技巧实录
4.4 结构化字段中的同义词和缩写问题
审计数据源来自多个系统，各个系统对同一个概念的叫法千差万别。比如内部系统里把“导出”叫“eport”，另一个系统里叫“下载”，制度文档里写的则是“数据外发”。如果 Agent 没有意识到这些是同义概念，在检索规划时就会漏掉其中一个数据源，导致审计结论不全面。
我处理这个问题的方法是构建领域同义词表，在 RAG 管道的查询阶段自动做扩展。当 Agent 要查询“数据导出”相关的记录时，系统自动生成一组等价查询词，并将它们一并纳入过滤条件。这属于一个小的工程细节，但对准确率的提升非常大。
注意事项：同义词表不需要一开始就做得很全，我建议在测试阶段通过对失败案例的分析持续迭代补充。一开始我试图通过让模型动态生成同义词，效果不如人意，模型的随机性太大；固定同义词表配合定期人工维护，在小语料场景下的效果会更值得依赖。
4.5 工具返回 Token 超长导致的分析遗漏
最后分享一个在小规模项目里隐藏很深的问题：工具返回结果的 Token 数超长。上面提到我会让工具返回结果做截断，但即使经过截断，一次有一定规模的检索返回结果仍然是很大的。如果系统不设置返回上限，Agent 在一次推理中能消耗的 Token 全部被工具返回结果占用了，留给后续分析推理的 Token 就非常少，输出质量急剧下滑。
我的解决方案除了在工具端做摘要和截断之外，还在 Agent 循环里增加了一个 Token 预算监控。当 Agent 的上下文使用量超过预算的一定比例时，系统会强制要求 Agent 进入总结模式，先把已经拿到的证据做一个临时总结，保留结论性信息，丢弃重复的细节，然后腾出空间给后续新的工具返回结果。
这个机制一开始觉得烦，多跑几个复杂案例之后才意识到它的关键价值。如果不做 Token 预算控制，Agent 处理复杂问题的时候会越来越“呆”，分析和思考能力会随着上下文的膨胀显著下降。
