1. 为什么“谁让 Agent 做了什么”突然成了头号难题我接手维护一个内部 Agent 平台的时候其实一开始没人提“审计”两个字。大家关心的是意图识别准不准、工具调用对不对、回复要不要人工审核。直到某天合规那边递过来一个问题这个动作到底是谁让 Agent 去做的是用户明确发起的还是 Agent 自己“灵机一动”补的当时所有人都愣住了——没人答得上来因为系统里根本没有记录这条因果链。这其实是 AI Agent 大规模落地后必然会撞上的墙。传统软件审计很简单某个用户账号登录了系统点了某个按钮系统执行了某个操作记录下日志就行。但 Agent 不是这么工作的。用户可能只说了句“帮我把上周的数据整理一下发邮件”Agent 自己拆解任务、自己决定要调用报表服务、自己组织邮件内容、自己发出请求。中间每一步都不是用户手点的而是模型根据上下文“推断”出来的。出事的时候合规要的不是“它干了什么”而是“谁让它干的、它凭什么这么干、干之前它看到了什么”。这一连串问题传统操作日志根本回答不了。还有一个被严重低估的问题Agent 的行为有概率性。同样的输入模型版本不同、温度参数不同甚至同一版本在不同时刻都可能做出不同的工具调用决策。如果没有把模型版本、提示词快照、完整推理链路记录下来一旦线上行为发生漂移你根本分不清是业务代码改了还是模型悄悄变了。这类问题排查起来痛不欲生而审计链路恰恰是唯一的定位手段。所以做 Agent 审计本质上不是“加个日志模块”而是把一次 Agent 行为变成一个可回放的证据链谁发起的、在什么会话上下文里、模型基于哪些信息做了决策、决策调用了哪些工具、传入了什么参数、返回了什么结果、对业务数据产生了什么影响。这个证据链才是审计和合规真正想要的“可追溯链路”。顺便提醒一句不要等出事再做审计。我见过太多团队Agent 都上线半年了才被合规要求补交审计方案结果要么日志里只有最终结果没有过程要么关键字段根本没人埋点最后只能靠模型产出一堆不可验证的“解释”。到那一步基本等于重做。审计链路应该和 Agent 主流程一起设计而不是事后打补丁。2. 先别急着写日志审计数据模型才是地基聊实现之前我建议先把“记什么”想清楚。很多人一上来就想着接日志系统结果埋点埋到一半发现字段不够用、链路拼不起来、上下文丢了又要返工。审计和普通日志最大的区别在于普通日志是给工程师排障用的字段少了能忍审计日志是要拿去回答“谁、何时、基于什么、做了什么、产生了什么影响”这五个问题的缺一个字段整条证据链就不成立。2.1 一个审计事件至少要有哪几类字段我把审计事件拆成六类每类都对应合规审查里经常被问到的具体问题分类字段示例解决什么问题发起方actor_type, actor_id, session_id, user_auth_method回答“谁让 Agent 做的”执行方agent_id, agent_version, model_id, model_version, temperature回答“是哪个 Agent、哪个模型版本做的”上下文input_excerpt, input_prompt_hash, conversation_history_ref, retrieved_documents_ref回答“Agent 当时看到了什么”决策与行为intent_snapshot, tool_calls, tool_parameters, tool_results_digest回答“Agent 做了什么、怎么做的”影响resource_access, changed_records, email_recipients, external_api_targets回答“产生了什么影响”合规元数据policy_version, human_review_status, risk_level, retention_until回答“这个操作按哪版合规策略评估过”这里我特别想强调上下文类的字段。很多人只记录工具调用参数觉得“Agent 调了什么 API、传了什么参数”就够了。但合规真正棘手的是“Agent 为什么这么调”。比如用户说“帮我处理掉异常订单”Agent 如果直接调用了退款接口你得能证明它确实是根据用户这句话做的判断而不是拿着别的会话里的上下文串了。所以输入内容的截断快照、检索到的文档引用、会话历史的引用 ID都必须跟着审计事件走。出于隐私和成本考虑上下文可以不全量存但至少要有摘要和引用 ID保证审计人员能按图索骥找到原始证据。2.2 用 Trace 把一次任务变成一棵因果树单条审计事件看起来像一条 JSON 记录但审计链路的价值在于“串起来”。用户的一次请求往往会被 Agent 拆成多个子任务先查数据库再调外部服务然后生成结果回复。每一步都是一个独立的审计事件它们之间必须有父子关系。这里我直接复用链路追踪的思想一次任务是一个 Trace任务里的每个步骤是一个 Span每个 Span 记录自己的 audit_event_id同时通过 trace_id 和 parent_span_id 关联到父级。这样整个任务的因果结构就变成了一棵树。审计人员查问题时可以先定位到根事件然后顺着树往下展开看到它的每一个分支决策。举个实际例子下面是一次简单任务的结构化记录{ audit_id: evt_01H9Z8Z4KZHW0Y7A0P2T, trace_id: trace_001e4f1a9c3b, parent_span_id: null, span_id: span_000001, timestamp: 2025-06-12T15:33:21.482Z, actor: { type: human_user, id: user_1024, auth_method: sso_ticket }, agent: { agent_id: data_ops_assistant, agent_version: v2.3.1, model_id: internal-llm-7b, model_version: 2025-06-01 }, input: { excerpt: 处理掉异常订单, input_hash: sha256:af9c... }, decision: { intent: bulk_refund_orders, risk_level: high, tool_calls: [ { tool: refund_api, params: {order_ids: [A1001, A1002], reason: user_requested_cleanup} } ] }, policy_version: p_v14, human_review_status: pending }注意每个字段都不是随手拍的。actor 里为什么要带 auth_method因为“这个人是谁”和“这个人怎么被验证的”是两回事审计时必须能证明身份来源可信。decision 里为什么要单独放 intent“工具调用了退款”和“Agent 认为用户要求退款”是两个层面的行为都要记录否则事后说不清。2.3 原文全文、意图哈希与截断快照的平衡“记录上下文”最容易踩的坑是走极端要么只存个哈希后面查证据时什么都看不到要么整段原文存进去隐私和成本双双爆表。我的做法是三层搭配第一层意图摘要。模型在决策阶段通常会产出结构化的意图快照比如“bulk_refund_orders”这个必须原样存这是最核心的证据。第二层输入原文的脱敏截断。只保留前一定长度比如 2000 字符并且过一遍脱敏规则把手机号、身份证、密钥这类敏感信息替换掉。第三层完整原文的引用哈希。完整内容存到受控的原始数据存储中审计链路里只放哈希和引用 ID需要核验时再走专门流程解封。这样设计的考量很实际审计链路本身会被同步到多套系统存太多敏感原文等于扩大了暴露面。而哈希可以保证“这条记录确实对应于这一次原始输入”防止事后被篡改或抵赖。对大部分合规场景有摘要加引用 ID 已经足够还原现场。3. 可追溯链路的工程落地埋点、管道与存储数据模型设计完后下一个问题是在哪里记、怎么传、怎么存才能保证可靠。这一节我只聊工程实现里真正影响审计质量的几个决定埋点位置、链路协议和存储选型。别小看这三件事做错了整个链路就会变成“看起来有、实际上查不了”的花架子。3.1 埋点放在 Agent SDK 调度层而不是散落在业务代码里我见过最不推荐的埋点方式是在每个工具函数里手动写日志。看着灵活实际上因为 Agent 的工具调用是动态路由的工具函数可能被各种场景复用手动埋点不仅容易漏还容易把业务日志和审计日志混在一起。审计事件的粒度、字段、时序全靠开发者自觉基本等于没有。正确的做法是把埋点下沉到 Agent 执行框架的调度层。通常一个 Agent 框架会有这么几个必经环节接收用户输入、模型推理生成决策、执行工具调用、生成最终输出。在调度层统一拦截这四个环节每个环节自动生成一条审计事件业务代码完全无感。比如我在封装工具执行时会在调用前后分别记录两条事件class AuditedToolExecutor: def execute(self, tool_name: str, params: dict, context: AuditContext): # 调用前记录“准备调用什么” audit.send({ event_type: tool_invocation_started, trace_id: context.trace_id, span_id: generate_span_id(), tool_name: tool_name, params_digest: hash_json(params), policy_check: check_policy(tool_name, params) }) result self._invoke_tool(tool_name, params) # 调用后记录“实际结果是什么” audit.send({ event_type: tool_invocation_completed, trace_id: context.trace_id, span_id: previous_span_id, result_summary: summarize_result(result), result_hash: hash_json(result) }) return result关键点是“调用前”和“调用后”各记一条。只记调用后的话如果工具执行中途崩溃或者超时你根本不知道 Agent 到底有没有发起过这个调用。两条事件合在一起才能完整覆盖“尝试调用”和“调用成功/失败”两个事实。还要提一点埋点代码必须和 Agent 核心流程同生命周期。有些团队把审计上报做成了异步任务请求处理结束了再慢慢补发结果进程一退出或者队列一堆积审计事件就丢了。我现在的做法是先同步写入本地可靠缓冲WAL再异步批量转发到审计管道。同步写保证不丢异步转保证不阻塞主流程。3.2 复用 OpenTelemetry 的 Trace 语义而不是另造一套链路很多团队一听到“可追溯链路”第一反应是自己设计一套 trace 系统。我的建议是能复用 OpenTelemetry 的语义就复用理由很实在大家都要记录 trace_id、span_id 和父子关系完全没必要重复造轮子。OpenTelemetry 的 Span 天然支持分层嵌套并且有现成的跨语言 SDKAgent 平台里无论组件用的是 Python、Java 还是 Go都能往同一个链路模型里挂数据。有人会问OpenTelemetry 不是主要干性能监控的吗拿来做审计会不会不搭说实话会有一些不搭所以要自己在这个底座上做扩展。我会把审计专用的字段塞进 span 的 attributes 里比如 actor 信息、input_hash、policy_version同时自定义一个独立的 audit event exporter把链路和详情分别送往不同目的地链路拓扑进可观测系统审计详情进合规专用存储。这样两边的诉求都满足又不用重写链路逻辑。审计场景里我还给 OTel span 增加了一个扩展属性audit.retention_days。为什么加这个因为审计数据的保留周期和普通 trace 不一样。普通 trace 一周后就无所谓了审计事件可能要留 180 天甚至更久。给每个 span 打上保留周期标签后续冷热归档和到期清理可以直接按这个字段执行不用再逐条判断。3.3 存储选型审计日志不能只丢进 Elasticsearch讨论存储选型前建议先想清楚一个事情审计链路的数据是只增不改、强顺序、高价值而且必须防丢失。这意味着它不是一般意义上的“日志”不能随随便便进一个共享日志集群就完事。我试过把审计事件和普通业务日志混在同一个 Elasticsearch 索引里后果是因为禁止修改和删除审计事件必须进独立索引因为查询模式不同要支持按 trace_id 遍历整棵树而不是简单关键字检索。混在一起后索引策略、生命周期管理全都冲突。我现在采用的方案是分层存储。审计事件先进入消息队列Kafka 或同类产品然后分两条路径一条写入对象存储做不可变归档按 trace_id 做分区文件另一条写入检索型存储比如 ClickHouse 或专门的审计索引支撑日常按用户、按时间、按工具检索。对象存储解决“如何永久保住原始证据”的问题检索存储解决“怎么快速找到某个事件”的问题。选型对比我整理了一个表方案优势劣势适用场景Elasticsearch 单集群上手快、全文检索方便数据不便于长期冻结、权限控制粒度一般小团队、审计量不大对象存储 检索倒排不可变、成本低、容量几乎无限需要自己维护两级索引一致性生产级审计链路强烈推荐传统关系型数据库事务强、字段约束严格写入扩展性差、海量事件性能受限审计量小且有强事务需求专用审计即服务产品省心、自带合规模板数据出境/自托管约束、价格高业务量小、不想自建我特别想说一下消息队列的选择。审计事件不能直接同步写对象存储因为 Agent 是高频调用的同步写会把性能拖垮。让事件先落队列再由消费者批量写归档是最稳妥的架构。队列本身必须开启持久化并且确认审计消费者成功写入后才 ack宁可消费慢一点绝不丢事件。3.4 链路完整性校验间歇性丢事件是个隐形雷审计链路最让人头疼的问题不是设计不好而是事件在传输过程中偶尔丢失。单看一天的丢失率可能不到 0.1%但合规审计要求的是“零丢失”证据链。你没法保证每条日志都检查一遍有没有缺失所以必须设计自动校验机制。我的做法是两套校验并行。第一套是序列号校验每个 actor 会话内审计事件按自然序号递增存储端做周期性扫描发现序号断档就告警并触发补采。第二套是心跳校验Agent 在长时间任务中如果超过 N 分钟没有产生任何审计事件调度层要主动发一条“心跳事件”表明 Agent 仍在运行但无决策发生防止“静默丢事件”和“真没做事”被混淆。有了这两套机制审计链路的完整性才是可证明的而不是靠运气。4. 身份与不可篡改审计链路最容易翻车的两处审计链路有两个环节如果不认真设计整条链路的可信度直接归零。一个是“发起人身份”怎么确定一个是“事件内容”怎么防篡改。前者决定你能不能回答“谁让 Agent 做的”后者决定你记录的证据能不能被采信。这俩翻车了前面做再多工作都白搭。4.1 actor 认证粒度别只认一个“登录用户”Agent 场景里一次任务的发起方不一定只有人类。它可能是用户在前端触发的可能是另一个 Agent 在编排流程时触发的还可能是定时调度系统批量触发的。如果审计日志里只记录“system”或者一个笼统的账号那合规问起来的时候你仍然说不清是谁。我在审计链路里把 actor_type 明确分为三类human_user、service_account、agent_identity。每一类用不同的字段组合记录身份。human_user 要记录登录凭证类型和会话 IDservice_account 要记录业务系统名、请求方 IP 和鉴权凭证指纹agent_identity 要记录父 Agent 的 audit_id因为 Agent 不是凭空产生的它一定来自另一个可追溯的发起链路。这里容易忽略一个细节用户在前端操作时后端服务可能已经换了身份。比如用户通过网关发起请求网关再以服务账号身份调用 Agent API。如果你只记录网关的服务账号就丢了真正的发起人。所以我要求 Agent 平台在接收请求时强制要求上游透传原始的 actor headers包含原用户 ID 和鉴权上下文服务账号身份只作为调用链路里的中间层记录。宁可多记录一条“以什么身份代理调用”也不能把发起人用一个笼统的 system 糊弄过去。4.2 防篡改哈希链与定期签名快照审计事件的存储端虽然是不可变对象存储但合规还关心另一个问题存储上层的检索索引或者运维同学有权限的数据库有没有可能被悄悄改掉为了对抗这种风险我做了两层保护。第一层是哈希链每条审计事件在写入归档时带上一个 hash 字段其值是上一条审计事件的摘要加本条事件内容后计算出来的摘要。这样任意一条事件被修改都会导致后续所有事件的哈希校验不通过。通俗点说每条事件都像一页账本页码和上一页的结算数锈死在一起撕掉任何一页都会露出破绽。第二层是定期签名快照每隔一段时间把截至当前的全量检索生成一份签名摘要用内部公钥基础设施的私钥签名后单独存到分离开的通道里。日常审查不需要比对所有事件只需要定期抽查签名快照是否一致就能低成本发现篡改迹象。注意这些机制不是为了防黑客而是为了防“内部修改后被抵赖”。做审计最尴尬的事情是审计记录被管理员改掉了然后你说不是自己干的。哈希链和签名快照能让这种情况在技术上就不可能。哪怕运维权限再大也改不了已经被签名固化过的历史批次。4.3 脱敏与隐私边界日志里不能裸奔敏感数据审计日志记录得太详细本身就是一把双刃剑。你要记录“Agent 看到了什么”才能还原现场但用户对话里可能带着手机号、地址、身份证、工单里的机密内容。如果这些内容以明文形式穿过整个审计管道审计系统本身就会变成一个新的数据泄露面。我的脱敏做法分两级。第一级在源头做模板识别加 NER 识别把符合手机号、邮箱、身份证格式的字段以及人名、组织名这类实体先替换为掩码再进行哈希最后才进入审计事件。第二级在检索存储里再挂一层动态脱敏权限只有带特定角色的人才能查看原文摘要普通审计员看的是掩码版本需要看原始字段时必须走解密申请流程并且解密操作本身也要记审计日志。这里特别提醒脱敏规则一定要在审计链路的最开始执行不要在存储端做。因为存储端脱敏意味着原始数据已经完整落盘了风险早已存在。在源头脱敏虽然增加了一点计算成本但可行。5. 从“记录”到“能用”让合规检查真正落地审计链路建好之后最容易出现的新问题是“数据有了但没人用”。记录是手段能支持合规检查才是目的。合规同学要的不是一张全量导出表而是“这个高危操作有没有经过审批、那个用户有没有超权限访问、上个月的所有退款请求有没有遗漏的人工复核”。这要求审计系统提供的不只是查询接口而是一套可操作的合规检查能力。5.1 事前、事中、事后三层策略我的做法是把它分成三层事前策略、事中拦截、事后扫描。事前策略指 Agent 启动任务之前审计框架会先检查这个 actor 有没有权限执行这个意图没有权限直接拒绝并且拒绝本身也要记录为一条审计事件。事中拦截指工具调用正要发生时实时检查目标接口的权限范围和频率限制发现超限调用立即中止并触发告警。事后扫描指每天或每周跑一次全量链路分析找出那些形式上符合权限、但行为上可疑的模式比如某个用户短时间内多次让 Agent 读取同一批客户数据或者 Agent 自主调用了评分策略之外的接口。我自己是强烈建议三层都有的因为单靠某一层都有漏洞。事前策略挡不住“有权限但滥用”的行为事中拦截挡不住分布式慢速绕过事后扫描又太迟无法阻止即时风险。三层配合才能覆盖“该拦的拦掉、该审的审出来”。5.2 定期生成可读的审计报告而不是丢一堆 JSON 出去给合规部门看的东西绝对不能是 JSON 原文。我踩过这个坑一开始我把审计查询接口给合规同学用他们看了一眼就关掉了反馈是“看不懂”。后来我改成自动化生成周报形式的审计报告效果一下子好了很多。报告里包含几个固定板块高危操作清单、未完成人工复核事件列表、按 actor 维度的操作汇总、异常行为模式与建议处理方案、以及保留策略执行状态。生成报告的功夫其实不值钱真正值钱的是每一块背后的聚合逻辑。比如“高危操作”的定义必须和业务一起确定哪些工具调用算高危是退款接口、是删除数据接口、还是外发邮件接口这个清单不是技术团队拍脑袋定的而是和业务负责人过一遍每季度重估一次。有了这个清单事后扫描和报告生成才有统一的标尺。5.3 不要依赖模型输出的“解释”还有一点我必须专门提Agent 的推理过程不能只依赖模型在回复里写的解释。LLM 会解释但解释可能幻觉化、简略化、甚至美化自己的行为。举例来说模型可能在回复里写“我已经整理了所有需要的订单”但实际上它只调用了过滤条件不当的查询。如果审计只存模型输出文本那你拿到的是一条美化过的故事而不是真实行为。要让“解释”可以用必须把它结构化为决策快照。模型的原始输出可以作为参考信息挂在审计事件里但真正用于合规判断的是结构化 intent、实际调用的工具列表和工具参数。如果模型声称做了某件事但代码审计链路里没有对应工具调用记录那这条声称就不可信。这套“声明必须与行为记录匹配”的原则是 Agent 审计里最核心的判定逻辑。6. 上线半年踩过的坑和现在沉淀下来的做法最后的章节我想分享一些真实上线过程中踩过的坑。很多问题是我在测试环境完全不会遇到的只有把 Agent 放进真实流量里跑起来才会暴露出来。希望这些内容能帮你绕过一些弯路。6.1 坑一异步上报时序错乱链路树都拼不起来最初我图省事把审计上报做成了纯异步业务线程处理完之后就把事件丢进一个内存队列由后台线程批量上报。结果高峰期一跑同一 trace 下的子任务事件比父任务事件还先到存储端链路树直接乱了。定位问题很简单但修复很麻烦——得重新梳理上报顺序和缓冲策略。后来我换了方案单个 trace 内的所有事件在写入审计管道前先经过一个局部分区排序器再批量上报。保证同一个 trace 内事件顺序稳定跨 trace 就不那么关心顺序了。这个容忍度要分清链路内的顺序是审计正确性的关键全局顺序不是。6.2 坑二只记工具调用的参数没记模型的原始决策输出有一回出了个事故Agent 回复客户说“已为你自动续费”但实际工具参数传错了价格档位。系统日志里查得到工具调用参数也查得到最终回复文本唯独找不到模型在决策时拿到的上下文快照和它当时的推理摘要。结果怎么都说不清是哪一步出的错。从那以后我把“模型决策时看到的输入摘要”和“模型选定的意图快照”强制加进了审计事件表。这个字段带来的存储成本不小但相比一次说不清的事故这点成本太值了。6.3 坑三没规划保留周期半年后归档数据一塌糊涂一开始我把所有审计数据都留满 365 天结果发现成本极速膨胀而且不少历史数据根本不会被翻到。后来我和业务方重新梳理了分级保留策略普通操作日志保留 180 天高危操作日志和涉及争议的会话保留 3 年且高危操作做年度归档。这件事要提前设计字段不能事后补否则你会被大量历史事件拖到归档流程里动弹不得。6.4 坑四敏感字段差点直接写进审计日志我至今记得有一次做安全复查发现审计日志里完整记录了用户对话中的一串银行卡号。当时虽然没有造成泄露但合规直接给我亮了黄牌。后来我意识到脱敏不能靠写代码时“记得”去做而要靠审计事件组装时的强约束所有输入必须经过同一个上下文净化器再入日志净化器本身批量识别敏感数据格式。你可以在测试阶段用造数工具批量灌入模拟敏感数据验证净化率这样能提前发现规则漏洞。6.5 现在沉淀下来的核心做法经过这大半年的反复调整我现在做 Agent 平台的第一原则变成了在画系统架构图的同时就把审计链路画出来。具体沉淀下来大概四句话——所有决策和工具调用必须有结构化审计事件所有事件必须能串成 trace 树所有事件必须以不可篡改的方式落盘所有审计能力都要同时支持在线查询和定期报告。这套方法可能不适用所有团队但如果你正在为“谁让 Agent 做了什么”发愁照着这个框架走至少能保证回答得出合规的一连串追问。回到开头那个问题。当年合规问我“这个动作到底是谁让 Agent 做的”现在我能直接拉出完整链路用户在某时某刻、通过什么认证方式、在哪个会话里、输入了什么内容、Agent 的哪个版本基于该输入生成了什么意图、调用了哪些工具、传了什么参数、拿到了什么结果。这个链路比任何解释都硬核也让 Agent 系统从“越用越黑盒”变成了“每一步都有据可查”。我相信这也是所有想让 Agent 真正走进生产环境的人迟早要补上的一课。
1. 为什么“谁让 Agent 做了什么”突然成了头号难题我接手维护一个内部 Agent 平台的时候其实一开始没人提“审计”两个字。大家关心的是意图识别准不准、工具调用对不对、回复要不要人工审核。直到某天合规那边递过来一个问题这个动作到底是谁让 Agent 去做的是用户明确发起的还是 Agent 自己“灵机一动”补的当时所有人都愣住了——没人答得上来因为系统里根本没有记录这条因果链。这其实是 AI Agent 大规模落地后必然会撞上的墙。传统软件审计很简单某个用户账号登录了系统点了某个按钮系统执行了某个操作记录下日志就行。但 Agent 不是这么工作的。用户可能只说了句“帮我把上周的数据整理一下发邮件”Agent 自己拆解任务、自己决定要调用报表服务、自己组织邮件内容、自己发出请求。中间每一步都不是用户手点的而是模型根据上下文“推断”出来的。出事的时候合规要的不是“它干了什么”而是“谁让它干的、它凭什么这么干、干之前它看到了什么”。这一连串问题传统操作日志根本回答不了。还有一个被严重低估的问题Agent 的行为有概率性。同样的输入模型版本不同、温度参数不同甚至同一版本在不同时刻都可能做出不同的工具调用决策。如果没有把模型版本、提示词快照、完整推理链路记录下来一旦线上行为发生漂移你根本分不清是业务代码改了还是模型悄悄变了。这类问题排查起来痛不欲生而审计链路恰恰是唯一的定位手段。所以做 Agent 审计本质上不是“加个日志模块”而是把一次 Agent 行为变成一个可回放的证据链谁发起的、在什么会话上下文里、模型基于哪些信息做了决策、决策调用了哪些工具、传入了什么参数、返回了什么结果、对业务数据产生了什么影响。这个证据链才是审计和合规真正想要的“可追溯链路”。顺便提醒一句不要等出事再做审计。我见过太多团队Agent 都上线半年了才被合规要求补交审计方案结果要么日志里只有最终结果没有过程要么关键字段根本没人埋点最后只能靠模型产出一堆不可验证的“解释”。到那一步基本等于重做。审计链路应该和 Agent 主流程一起设计而不是事后打补丁。2. 先别急着写日志审计数据模型才是地基聊实现之前我建议先把“记什么”想清楚。很多人一上来就想着接日志系统结果埋点埋到一半发现字段不够用、链路拼不起来、上下文丢了又要返工。审计和普通日志最大的区别在于普通日志是给工程师排障用的字段少了能忍审计日志是要拿去回答“谁、何时、基于什么、做了什么、产生了什么影响”这五个问题的缺一个字段整条证据链就不成立。2.1 一个审计事件至少要有哪几类字段我把审计事件拆成六类每类都对应合规审查里经常被问到的具体问题分类字段示例解决什么问题发起方actor_type, actor_id, session_id, user_auth_method回答“谁让 Agent 做的”执行方agent_id, agent_version, model_id, model_version, temperature回答“是哪个 Agent、哪个模型版本做的”上下文input_excerpt, input_prompt_hash, conversation_history_ref, retrieved_documents_ref回答“Agent 当时看到了什么”决策与行为intent_snapshot, tool_calls, tool_parameters, tool_results_digest回答“Agent 做了什么、怎么做的”影响resource_access, changed_records, email_recipients, external_api_targets回答“产生了什么影响”合规元数据policy_version, human_review_status, risk_level, retention_until回答“这个操作按哪版合规策略评估过”这里我特别想强调上下文类的字段。很多人只记录工具调用参数觉得“Agent 调了什么 API、传了什么参数”就够了。但合规真正棘手的是“Agent 为什么这么调”。比如用户说“帮我处理掉异常订单”Agent 如果直接调用了退款接口你得能证明它确实是根据用户这句话做的判断而不是拿着别的会话里的上下文串了。所以输入内容的截断快照、检索到的文档引用、会话历史的引用 ID都必须跟着审计事件走。出于隐私和成本考虑上下文可以不全量存但至少要有摘要和引用 ID保证审计人员能按图索骥找到原始证据。2.2 用 Trace 把一次任务变成一棵因果树单条审计事件看起来像一条 JSON 记录但审计链路的价值在于“串起来”。用户的一次请求往往会被 Agent 拆成多个子任务先查数据库再调外部服务然后生成结果回复。每一步都是一个独立的审计事件它们之间必须有父子关系。这里我直接复用链路追踪的思想一次任务是一个 Trace任务里的每个步骤是一个 Span每个 Span 记录自己的 audit_event_id同时通过 trace_id 和 parent_span_id 关联到父级。这样整个任务的因果结构就变成了一棵树。审计人员查问题时可以先定位到根事件然后顺着树往下展开看到它的每一个分支决策。举个实际例子下面是一次简单任务的结构化记录{ audit_id: evt_01H9Z8Z4KZHW0Y7A0P2T, trace_id: trace_001e4f1a9c3b, parent_span_id: null, span_id: span_000001, timestamp: 2025-06-12T15:33:21.482Z, actor: { type: human_user, id: user_1024, auth_method: sso_ticket }, agent: { agent_id: data_ops_assistant, agent_version: v2.3.1, model_id: internal-llm-7b, model_version: 2025-06-01 }, input: { excerpt: 处理掉异常订单, input_hash: sha256:af9c... }, decision: { intent: bulk_refund_orders, risk_level: high, tool_calls: [ { tool: refund_api, params: {order_ids: [A1001, A1002], reason: user_requested_cleanup} } ] }, policy_version: p_v14, human_review_status: pending }注意每个字段都不是随手拍的。actor 里为什么要带 auth_method因为“这个人是谁”和“这个人怎么被验证的”是两回事审计时必须能证明身份来源可信。decision 里为什么要单独放 intent“工具调用了退款”和“Agent 认为用户要求退款”是两个层面的行为都要记录否则事后说不清。2.3 原文全文、意图哈希与截断快照的平衡“记录上下文”最容易踩的坑是走极端要么只存个哈希后面查证据时什么都看不到要么整段原文存进去隐私和成本双双爆表。我的做法是三层搭配第一层意图摘要。模型在决策阶段通常会产出结构化的意图快照比如“bulk_refund_orders”这个必须原样存这是最核心的证据。第二层输入原文的脱敏截断。只保留前一定长度比如 2000 字符并且过一遍脱敏规则把手机号、身份证、密钥这类敏感信息替换掉。第三层完整原文的引用哈希。完整内容存到受控的原始数据存储中审计链路里只放哈希和引用 ID需要核验时再走专门流程解封。这样设计的考量很实际审计链路本身会被同步到多套系统存太多敏感原文等于扩大了暴露面。而哈希可以保证“这条记录确实对应于这一次原始输入”防止事后被篡改或抵赖。对大部分合规场景有摘要加引用 ID 已经足够还原现场。3. 可追溯链路的工程落地埋点、管道与存储数据模型设计完后下一个问题是在哪里记、怎么传、怎么存才能保证可靠。这一节我只聊工程实现里真正影响审计质量的几个决定埋点位置、链路协议和存储选型。别小看这三件事做错了整个链路就会变成“看起来有、实际上查不了”的花架子。3.1 埋点放在 Agent SDK 调度层而不是散落在业务代码里我见过最不推荐的埋点方式是在每个工具函数里手动写日志。看着灵活实际上因为 Agent 的工具调用是动态路由的工具函数可能被各种场景复用手动埋点不仅容易漏还容易把业务日志和审计日志混在一起。审计事件的粒度、字段、时序全靠开发者自觉基本等于没有。正确的做法是把埋点下沉到 Agent 执行框架的调度层。通常一个 Agent 框架会有这么几个必经环节接收用户输入、模型推理生成决策、执行工具调用、生成最终输出。在调度层统一拦截这四个环节每个环节自动生成一条审计事件业务代码完全无感。比如我在封装工具执行时会在调用前后分别记录两条事件class AuditedToolExecutor: def execute(self, tool_name: str, params: dict, context: AuditContext): # 调用前记录“准备调用什么” audit.send({ event_type: tool_invocation_started, trace_id: context.trace_id, span_id: generate_span_id(), tool_name: tool_name, params_digest: hash_json(params), policy_check: check_policy(tool_name, params) }) result self._invoke_tool(tool_name, params) # 调用后记录“实际结果是什么” audit.send({ event_type: tool_invocation_completed, trace_id: context.trace_id, span_id: previous_span_id, result_summary: summarize_result(result), result_hash: hash_json(result) }) return result关键点是“调用前”和“调用后”各记一条。只记调用后的话如果工具执行中途崩溃或者超时你根本不知道 Agent 到底有没有发起过这个调用。两条事件合在一起才能完整覆盖“尝试调用”和“调用成功/失败”两个事实。还要提一点埋点代码必须和 Agent 核心流程同生命周期。有些团队把审计上报做成了异步任务请求处理结束了再慢慢补发结果进程一退出或者队列一堆积审计事件就丢了。我现在的做法是先同步写入本地可靠缓冲WAL再异步批量转发到审计管道。同步写保证不丢异步转保证不阻塞主流程。3.2 复用 OpenTelemetry 的 Trace 语义而不是另造一套链路很多团队一听到“可追溯链路”第一反应是自己设计一套 trace 系统。我的建议是能复用 OpenTelemetry 的语义就复用理由很实在大家都要记录 trace_id、span_id 和父子关系完全没必要重复造轮子。OpenTelemetry 的 Span 天然支持分层嵌套并且有现成的跨语言 SDKAgent 平台里无论组件用的是 Python、Java 还是 Go都能往同一个链路模型里挂数据。有人会问OpenTelemetry 不是主要干性能监控的吗拿来做审计会不会不搭说实话会有一些不搭所以要自己在这个底座上做扩展。我会把审计专用的字段塞进 span 的 attributes 里比如 actor 信息、input_hash、policy_version同时自定义一个独立的 audit event exporter把链路和详情分别送往不同目的地链路拓扑进可观测系统审计详情进合规专用存储。这样两边的诉求都满足又不用重写链路逻辑。审计场景里我还给 OTel span 增加了一个扩展属性audit.retention_days。为什么加这个因为审计数据的保留周期和普通 trace 不一样。普通 trace 一周后就无所谓了审计事件可能要留 180 天甚至更久。给每个 span 打上保留周期标签后续冷热归档和到期清理可以直接按这个字段执行不用再逐条判断。3.3 存储选型审计日志不能只丢进 Elasticsearch讨论存储选型前建议先想清楚一个事情审计链路的数据是只增不改、强顺序、高价值而且必须防丢失。这意味着它不是一般意义上的“日志”不能随随便便进一个共享日志集群就完事。我试过把审计事件和普通业务日志混在同一个 Elasticsearch 索引里后果是因为禁止修改和删除审计事件必须进独立索引因为查询模式不同要支持按 trace_id 遍历整棵树而不是简单关键字检索。混在一起后索引策略、生命周期管理全都冲突。我现在采用的方案是分层存储。审计事件先进入消息队列Kafka 或同类产品然后分两条路径一条写入对象存储做不可变归档按 trace_id 做分区文件另一条写入检索型存储比如 ClickHouse 或专门的审计索引支撑日常按用户、按时间、按工具检索。对象存储解决“如何永久保住原始证据”的问题检索存储解决“怎么快速找到某个事件”的问题。选型对比我整理了一个表方案优势劣势适用场景Elasticsearch 单集群上手快、全文检索方便数据不便于长期冻结、权限控制粒度一般小团队、审计量不大对象存储 检索倒排不可变、成本低、容量几乎无限需要自己维护两级索引一致性生产级审计链路强烈推荐传统关系型数据库事务强、字段约束严格写入扩展性差、海量事件性能受限审计量小且有强事务需求专用审计即服务产品省心、自带合规模板数据出境/自托管约束、价格高业务量小、不想自建我特别想说一下消息队列的选择。审计事件不能直接同步写对象存储因为 Agent 是高频调用的同步写会把性能拖垮。让事件先落队列再由消费者批量写归档是最稳妥的架构。队列本身必须开启持久化并且确认审计消费者成功写入后才 ack宁可消费慢一点绝不丢事件。3.4 链路完整性校验间歇性丢事件是个隐形雷审计链路最让人头疼的问题不是设计不好而是事件在传输过程中偶尔丢失。单看一天的丢失率可能不到 0.1%但合规审计要求的是“零丢失”证据链。你没法保证每条日志都检查一遍有没有缺失所以必须设计自动校验机制。我的做法是两套校验并行。第一套是序列号校验每个 actor 会话内审计事件按自然序号递增存储端做周期性扫描发现序号断档就告警并触发补采。第二套是心跳校验Agent 在长时间任务中如果超过 N 分钟没有产生任何审计事件调度层要主动发一条“心跳事件”表明 Agent 仍在运行但无决策发生防止“静默丢事件”和“真没做事”被混淆。有了这两套机制审计链路的完整性才是可证明的而不是靠运气。4. 身份与不可篡改审计链路最容易翻车的两处审计链路有两个环节如果不认真设计整条链路的可信度直接归零。一个是“发起人身份”怎么确定一个是“事件内容”怎么防篡改。前者决定你能不能回答“谁让 Agent 做的”后者决定你记录的证据能不能被采信。这俩翻车了前面做再多工作都白搭。4.1 actor 认证粒度别只认一个“登录用户”Agent 场景里一次任务的发起方不一定只有人类。它可能是用户在前端触发的可能是另一个 Agent 在编排流程时触发的还可能是定时调度系统批量触发的。如果审计日志里只记录“system”或者一个笼统的账号那合规问起来的时候你仍然说不清是谁。我在审计链路里把 actor_type 明确分为三类human_user、service_account、agent_identity。每一类用不同的字段组合记录身份。human_user 要记录登录凭证类型和会话 IDservice_account 要记录业务系统名、请求方 IP 和鉴权凭证指纹agent_identity 要记录父 Agent 的 audit_id因为 Agent 不是凭空产生的它一定来自另一个可追溯的发起链路。这里容易忽略一个细节用户在前端操作时后端服务可能已经换了身份。比如用户通过网关发起请求网关再以服务账号身份调用 Agent API。如果你只记录网关的服务账号就丢了真正的发起人。所以我要求 Agent 平台在接收请求时强制要求上游透传原始的 actor headers包含原用户 ID 和鉴权上下文服务账号身份只作为调用链路里的中间层记录。宁可多记录一条“以什么身份代理调用”也不能把发起人用一个笼统的 system 糊弄过去。4.2 防篡改哈希链与定期签名快照审计事件的存储端虽然是不可变对象存储但合规还关心另一个问题存储上层的检索索引或者运维同学有权限的数据库有没有可能被悄悄改掉为了对抗这种风险我做了两层保护。第一层是哈希链每条审计事件在写入归档时带上一个 hash 字段其值是上一条审计事件的摘要加本条事件内容后计算出来的摘要。这样任意一条事件被修改都会导致后续所有事件的哈希校验不通过。通俗点说每条事件都像一页账本页码和上一页的结算数锈死在一起撕掉任何一页都会露出破绽。第二层是定期签名快照每隔一段时间把截至当前的全量检索生成一份签名摘要用内部公钥基础设施的私钥签名后单独存到分离开的通道里。日常审查不需要比对所有事件只需要定期抽查签名快照是否一致就能低成本发现篡改迹象。注意这些机制不是为了防黑客而是为了防“内部修改后被抵赖”。做审计最尴尬的事情是审计记录被管理员改掉了然后你说不是自己干的。哈希链和签名快照能让这种情况在技术上就不可能。哪怕运维权限再大也改不了已经被签名固化过的历史批次。4.3 脱敏与隐私边界日志里不能裸奔敏感数据审计日志记录得太详细本身就是一把双刃剑。你要记录“Agent 看到了什么”才能还原现场但用户对话里可能带着手机号、地址、身份证、工单里的机密内容。如果这些内容以明文形式穿过整个审计管道审计系统本身就会变成一个新的数据泄露面。我的脱敏做法分两级。第一级在源头做模板识别加 NER 识别把符合手机号、邮箱、身份证格式的字段以及人名、组织名这类实体先替换为掩码再进行哈希最后才进入审计事件。第二级在检索存储里再挂一层动态脱敏权限只有带特定角色的人才能查看原文摘要普通审计员看的是掩码版本需要看原始字段时必须走解密申请流程并且解密操作本身也要记审计日志。这里特别提醒脱敏规则一定要在审计链路的最开始执行不要在存储端做。因为存储端脱敏意味着原始数据已经完整落盘了风险早已存在。在源头脱敏虽然增加了一点计算成本但可行。5. 从“记录”到“能用”让合规检查真正落地审计链路建好之后最容易出现的新问题是“数据有了但没人用”。记录是手段能支持合规检查才是目的。合规同学要的不是一张全量导出表而是“这个高危操作有没有经过审批、那个用户有没有超权限访问、上个月的所有退款请求有没有遗漏的人工复核”。这要求审计系统提供的不只是查询接口而是一套可操作的合规检查能力。5.1 事前、事中、事后三层策略我的做法是把它分成三层事前策略、事中拦截、事后扫描。事前策略指 Agent 启动任务之前审计框架会先检查这个 actor 有没有权限执行这个意图没有权限直接拒绝并且拒绝本身也要记录为一条审计事件。事中拦截指工具调用正要发生时实时检查目标接口的权限范围和频率限制发现超限调用立即中止并触发告警。事后扫描指每天或每周跑一次全量链路分析找出那些形式上符合权限、但行为上可疑的模式比如某个用户短时间内多次让 Agent 读取同一批客户数据或者 Agent 自主调用了评分策略之外的接口。我自己是强烈建议三层都有的因为单靠某一层都有漏洞。事前策略挡不住“有权限但滥用”的行为事中拦截挡不住分布式慢速绕过事后扫描又太迟无法阻止即时风险。三层配合才能覆盖“该拦的拦掉、该审的审出来”。5.2 定期生成可读的审计报告而不是丢一堆 JSON 出去给合规部门看的东西绝对不能是 JSON 原文。我踩过这个坑一开始我把审计查询接口给合规同学用他们看了一眼就关掉了反馈是“看不懂”。后来我改成自动化生成周报形式的审计报告效果一下子好了很多。报告里包含几个固定板块高危操作清单、未完成人工复核事件列表、按 actor 维度的操作汇总、异常行为模式与建议处理方案、以及保留策略执行状态。生成报告的功夫其实不值钱真正值钱的是每一块背后的聚合逻辑。比如“高危操作”的定义必须和业务一起确定哪些工具调用算高危是退款接口、是删除数据接口、还是外发邮件接口这个清单不是技术团队拍脑袋定的而是和业务负责人过一遍每季度重估一次。有了这个清单事后扫描和报告生成才有统一的标尺。5.3 不要依赖模型输出的“解释”还有一点我必须专门提Agent 的推理过程不能只依赖模型在回复里写的解释。LLM 会解释但解释可能幻觉化、简略化、甚至美化自己的行为。举例来说模型可能在回复里写“我已经整理了所有需要的订单”但实际上它只调用了过滤条件不当的查询。如果审计只存模型输出文本那你拿到的是一条美化过的故事而不是真实行为。要让“解释”可以用必须把它结构化为决策快照。模型的原始输出可以作为参考信息挂在审计事件里但真正用于合规判断的是结构化 intent、实际调用的工具列表和工具参数。如果模型声称做了某件事但代码审计链路里没有对应工具调用记录那这条声称就不可信。这套“声明必须与行为记录匹配”的原则是 Agent 审计里最核心的判定逻辑。6. 上线半年踩过的坑和现在沉淀下来的做法最后的章节我想分享一些真实上线过程中踩过的坑。很多问题是我在测试环境完全不会遇到的只有把 Agent 放进真实流量里跑起来才会暴露出来。希望这些内容能帮你绕过一些弯路。6.1 坑一异步上报时序错乱链路树都拼不起来最初我图省事把审计上报做成了纯异步业务线程处理完之后就把事件丢进一个内存队列由后台线程批量上报。结果高峰期一跑同一 trace 下的子任务事件比父任务事件还先到存储端链路树直接乱了。定位问题很简单但修复很麻烦——得重新梳理上报顺序和缓冲策略。后来我换了方案单个 trace 内的所有事件在写入审计管道前先经过一个局部分区排序器再批量上报。保证同一个 trace 内事件顺序稳定跨 trace 就不那么关心顺序了。这个容忍度要分清链路内的顺序是审计正确性的关键全局顺序不是。6.2 坑二只记工具调用的参数没记模型的原始决策输出有一回出了个事故Agent 回复客户说“已为你自动续费”但实际工具参数传错了价格档位。系统日志里查得到工具调用参数也查得到最终回复文本唯独找不到模型在决策时拿到的上下文快照和它当时的推理摘要。结果怎么都说不清是哪一步出的错。从那以后我把“模型决策时看到的输入摘要”和“模型选定的意图快照”强制加进了审计事件表。这个字段带来的存储成本不小但相比一次说不清的事故这点成本太值了。6.3 坑三没规划保留周期半年后归档数据一塌糊涂一开始我把所有审计数据都留满 365 天结果发现成本极速膨胀而且不少历史数据根本不会被翻到。后来我和业务方重新梳理了分级保留策略普通操作日志保留 180 天高危操作日志和涉及争议的会话保留 3 年且高危操作做年度归档。这件事要提前设计字段不能事后补否则你会被大量历史事件拖到归档流程里动弹不得。6.4 坑四敏感字段差点直接写进审计日志我至今记得有一次做安全复查发现审计日志里完整记录了用户对话中的一串银行卡号。当时虽然没有造成泄露但合规直接给我亮了黄牌。后来我意识到脱敏不能靠写代码时“记得”去做而要靠审计事件组装时的强约束所有输入必须经过同一个上下文净化器再入日志净化器本身批量识别敏感数据格式。你可以在测试阶段用造数工具批量灌入模拟敏感数据验证净化率这样能提前发现规则漏洞。6.5 现在沉淀下来的核心做法经过这大半年的反复调整我现在做 Agent 平台的第一原则变成了在画系统架构图的同时就把审计链路画出来。具体沉淀下来大概四句话——所有决策和工具调用必须有结构化审计事件所有事件必须能串成 trace 树所有事件必须以不可篡改的方式落盘所有审计能力都要同时支持在线查询和定期报告。这套方法可能不适用所有团队但如果你正在为“谁让 Agent 做了什么”发愁照着这个框架走至少能保证回答得出合规的一连串追问。回到开头那个问题。当年合规问我“这个动作到底是谁让 Agent 做的”现在我能直接拉出完整链路用户在某时某刻、通过什么认证方式、在哪个会话里、输入了什么内容、Agent 的哪个版本基于该输入生成了什么意图、调用了哪些工具、传了什么参数、拿到了什么结果。这个链路比任何解释都硬核也让 Agent 系统从“越用越黑盒”变成了“每一步都有据可查”。我相信这也是所有想让 Agent 真正走进生产环境的人迟早要补上的一课。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
