智能体自主决策的审批与审计：构建可控自动化流程

1. 从“工具”到“同事”智能体自主决策的边界在哪里过去两年我经手过不少智能体项目从最早的规则引擎到后来的大模型驱动有一个感受越来越强烈智能体真正难的地方不是它能不能干活而是它能不能“自己拿主意”之后你还敢不敢让它继续干下去。这个标题——“智能体开始自己拿主意可审批、可审计的自动化”——说的正是这个转折点。以前我们做自动化本质上是写死流程A 触发 BB 执行 CC 返回结果。智能体出现之后流程变成了“目标驱动”你告诉它要达成什么它自己规划路径、调用工具、判断结果。效率确实上来了但问题也跟着来了——它凭什么做这个决定做错了谁负责出了问题怎么回溯我见过太多团队在 Demo 阶段兴奋得不行一上生产就怂了。原因很简单没有审批不敢放权没有审计不敢背锅。所以这篇文章想聊的不是怎么让智能体更聪明而是怎么让它的“聪明”变得可控、可查、可解释。适合正在做智能体落地、自动化流程改造、或者被“AI 自主决策”这件事卡住的开发和产品同学。2. 为什么“自己拿主意”这件事让工程团队睡不着觉2.1 自主决策带来的三个真实风险先说清楚风险才能理解后面为什么要设计审批和审计。我总结下来智能体自主决策主要带来三类问题。第一类是越权操作。比如一个客服智能体本来只应该查询订单状态结果它为了“更好地解决问题”自己调用了退款接口。这不是段子是我在真实项目里遇到过的。大模型在规划路径时会倾向于选择“能达成目标的最短路径”但它对权限边界的理解往往不如人类清晰。第二类是错误累积。传统自动化的错误是线性的一步错一步停。智能体的错误是链式的它调用了一个工具拿到一个不太对的结果然后基于这个结果继续推理最后输出一个看起来合理但完全错误的结论。等你发现的时候中间已经跑了七八步。第三类是不可复现。同一个输入今天跑和明天跑结果可能不一样。温度参数、上下文长度、工具返回的微小差异都会导致决策路径分叉。出了问题想复现发现根本回不去。注意这三点不是智能体的缺陷而是自主性的必然代价。你要做的不是消灭它们而是给它们装上“刹车”和“行车记录仪”。2.2 审批和审计到底在解决什么问题审批解决的是“事前控制”。智能体在做出关键决策之前必须停下来把它的意图、依据、预期结果提交给人或者另一个可信系统确认。确认通过继续执行不通过回退或者转人工。审计解决的是“事后追溯”。智能体每一步决策、每一次工具调用、每一个中间结果都要留下结构化记录。出了问题你能像查日志一样查清楚它在第几步、基于什么信息、做了什么判断。这两个机制合在一起才构成一个完整的“可控自主”闭环。少了审批你不敢放权少了审计你放权之后睡不着觉。2.3 哪些场景必须上审批哪些可以全自动不是所有智能体都需要审批。我的经验是按“影响面”和“可逆性”两个维度来分。场景类型影响面可逆性建议策略信息查询、内容摘要低高全自动仅审计内部工单流转、数据同步中高抽样审批全量审计对外发送消息、修改配置中高中关键节点审批全量审计资金操作、权限变更、删除数据高低强制审批全量审计告警这张表是我自己在项目里用的简化版。核心逻辑就一句话越不可逆、影响面越大的操作审批层级越高审计粒度越细。3. 可审批给智能体装上“请示汇报”的机制3.1 审批节点的设计原则审批节点不是越多越好。我见过一个项目智能体每调一个工具都要审批结果人比机器还累最后大家直接把审批关了。这就失去了意义。我的设计原则是三条第一只在“决策分叉点”设审批。什么叫决策分叉点就是智能体面临多个可选路径且不同路径后果差异很大的时候。比如“是直接回复用户还是转人工”这就是一个分叉点。而“用哪个搜索工具查资料”这种就不需要审批。第二审批信息要“可判断”。你不能只告诉审批人“智能体想执行退款”你得告诉它为什么退款、退多少、依据是什么、不退款会怎样。审批人需要足够的信息才能做判断否则审批就变成了橡皮图章。第三审批要有超时策略。智能体停下来等人审批人不在怎么办我的做法是分级超时低风险操作超时自动通过中风险操作超时转下一审批人高风险操作超时自动拒绝并告警。3.2 审批流的三种实现模式在实际工程里审批流有三种常见实现方式各有适用场景。第一种是同步阻塞式。智能体执行到审批节点挂起等待审批结果返回后再继续。这种方式最简单但缺点是智能体被阻塞如果审批时间长整个流程就卡住了。适合审批人就在线、响应快的场景。第二种是异步回调式。智能体把审批请求发出去自己先去做别的等审批结果回来再继续。这种方式对智能体框架要求高一些需要支持状态保存和恢复。适合审批链路长、审批人不在线的场景。第三种是预授权式。提前给智能体划定一个“安全操作空间”在这个空间内的操作不需要实时审批但超出空间就必须审批。比如“单笔退款不超过 100 元可以自动执行超过就必须审批”。这种方式效率最高但需要你对业务边界有清晰的量化。实操心得我一般会混合使用。高频低风险操作走预授权低频高风险操作走同步阻塞中间地带走异步回调。这样既不会把人累死也不会把风险放出去。3.3 审批信息的结构化设计审批能不能做好关键看审批信息给得够不够。我通常要求智能体在发起审批时必须提交以下结构化信息{ agent_id: customer-service-001, task_id: task-20260115-8842, approval_type: refund_request, decision_point: step_7_of_12, intent: 为用户订单 #12345 发起退款, reasoning: 用户反馈商品破损上传图片经视觉模型判定为运输损坏符合退款政策第 3.2 条, evidence: [ {type: user_upload, url: ...}, {type: policy_match, rule_id: refund-policy-3.2}, {type: order_info, amount: 299.00} ], expected_outcome: 退款 299 元至原支付渠道, risk_level: medium, alternative: 若审批不通过将转人工客服处理 }这份结构里reasoning 和 evidence 是最关键的。审批人不需要看智能体的完整思考过程但需要看到它做这个判断的核心依据。这样审批人才能在几秒钟内做出判断而不是去翻聊天记录。3.4 审批人怎么选人、规则还是另一个智能体审批人不一定是人。我的经验是分层规则审批适用于边界清晰、可量化的场景。比如金额阈值、频率限制、黑名单匹配。规则审批速度快、成本低但只能处理已知情况。智能体审批适用于需要一定判断力但风险可控的场景。比如“这条回复的语气是否合适”可以用一个专门训练的审核智能体来判断。但要注意审核智能体本身也需要审计。人工审批适用于高风险、高不确定性、或者规则和智能体都拿不准的场景。人工审批最慢但兜底能力最强。实际项目里我通常让这三层形成漏斗规则先筛一遍智能体再审一遍最后剩下的才给人。这样能把人工审批量压到最低同时不牺牲安全性。4. 可审计让智能体的每一步都有据可查4.1 审计日志应该记什么审计日志不是普通的运行日志。普通日志记的是“发生了什么”审计日志记的是“为什么发生”和“谁让它发生的”。我要求的审计日志至少包含以下字段字段说明是否必填trace_id全链路追踪 ID必填agent_id智能体标识必填step_index当前步骤序号必填timestamp精确到毫秒必填action_type决策/工具调用/审批/输出必填input_summary输入摘要必填reasoning决策依据决策类必填tool_name调用的工具名工具类必填tool_params工具参数工具类必填tool_result工具返回摘要工具类必填approval_status审批状态审批类必填model_version模型版本必填token_usagetoken 消耗建议填这张表看着多但真正落地的时候大部分字段可以由框架自动采集只有 reasoning 需要智能体主动输出。这也是为什么我在设计智能体的时候会强制要求它在每个决策点输出结构化的 reasoning。4.2 审计数据的存储与检索审计数据的特点是写入量大、查询频率低、但查询时要求快。我一般用“热冷分离”的策略。热数据放在 Elasticsearch 或者类似的搜索引擎里保留最近 7 到 30 天支持全文检索和聚合分析。出了问题先查热数据快速定位。冷数据归档到对象存储按天分区保留半年到一年。冷数据查询慢但成本低适合合规审计和长期回溯。注意审计数据里可能包含用户隐私信息存储和检索都要做脱敏。我通常的做法是原始数据加密存储检索时只返回脱敏后的摘要需要看原文的走单独的审批流程。4.3 审计的可视化让非技术人员也能看懂审计日志给开发看没问题但给业务方或者合规方看就需要可视化。我做过一个简单的审计时间线视图效果不错。核心思路是把智能体的执行过程画成一条时间线每个节点标注动作类型、耗时、结果状态。点击节点展开详细信息和 reasoning。审批节点用不同颜色标出一眼就能看出哪里卡住了、哪里被拒绝了。这个视图不需要多复杂但能极大降低沟通成本。业务方一看就明白智能体干了什么合规方一看就知道有没有越界。4.4 审计与告警的联动审计不只是事后查还可以事前防。我通常会在审计管道里加一层实时规则引擎对审计流做实时扫描。比如同一个智能体在 5 分钟内发起了 3 次以上退款审批 → 告警智能体调用了未授权的工具 → 立即阻断并告警审批通过率异常偏高或偏低 → 提示检查审批规则这些规则不需要很复杂但能帮你提前发现异常。我踩过的坑是等出了问题再去查审计往往已经晚了。实时告警能把响应时间从小时级压到分钟级。5. 落地实操从零搭一套可审批可审计的智能体流程5.1 整体架构设计我以最常见的“客服退款智能体”为例讲一下完整落地过程。整体架构分四层第一层是智能体执行层。负责理解用户意图、规划步骤、调用工具。这一层可以用 Coze、Dify 这类平台搭建也可以用 Python 自己写。平台搭建的好处是快坏处是审批和审计的定制能力有限。自己写的好处是灵活坏处是什么都要自己来。第二层是审批网关。所有需要审批的操作都先经过这一层。审批网关负责判断是否需要审批、生成审批请求、路由到审批人、收集审批结果、回传给智能体。第三层是审计管道。智能体每一步执行都往审计管道发一条结构化事件。审计管道负责格式化、脱敏、写入热存储、触发实时规则。第四层是管理与可视化。给管理员看的审批队列、审计时间线、告警面板。这四层里审批网关和审计管道是核心。智能体执行层可以换但这两层建议做厚一点因为它们是“可控”的根基。5.2 审批网关的关键实现审批网关的核心是一个状态机。我用 Python 写过一个简化版核心逻辑大概是这样class ApprovalGateway: def __init__(self, rules, approvers): self.rules rules self.approvers approvers self.pending {} def check(self, action): risk self.rules.evaluate(action) if risk.level low: return ApprovalResult(auto_approvedTrue) if risk.level medium: approver self.approvers.pick(medium) req_id self.pending.create(action, approver) return ApprovalResult(pendingTrue, request_idreq_id) if risk.level high: approver self.approvers.pick(high) req_id self.pending.create(action, approver) self.alert(action) return ApprovalResult(pendingTrue, request_idreq_id) def resolve(self, request_id, approved, comment): req self.pending.pop(request_id) self.audit.log(req, approved, comment) return req.agent_callback(approved)这段代码的关键点在于规则引擎决定风险等级风险等级决定审批路径审批结果通过回调返回给智能体。实际生产里还要加超时、重试、幂等这些但核心逻辑就是这个。5.3 审计管道的搭建审计管道我一般用“生产者-队列-消费者”模式。智能体是生产者往消息队列里发事件消费者从队列里取事件做格式化、脱敏、写入。用消息队列的好处是解耦。智能体不需要关心审计存储是什么只管发事件。审计存储换了智能体不用改。消费者这边我通常做三件事格式化把智能体发来的原始事件转成统一的审计 schema。脱敏识别并替换敏感字段比如手机号、身份证号、银行卡号。分流一份写热存储一份写冷存储一份发给实时规则引擎。实操心得脱敏这一步千万别省。我见过一个项目审计日志里直接存了用户完整聊天记录后来做合规检查的时候被要求全部重做。脱敏规则最好做成可配置的不同业务线用不同规则。5.4 智能体侧的改造要点智能体本身也需要做一些改造才能配合审批和审计。第一决策点要显式化。不要让智能体“默默”做决定。每个关键决策都要输出结构化的决策信息。这需要在 prompt 里明确要求或者在代码里强制拦截。第二工具调用要包装。不要让智能体直接调工具而是通过一个包装层。包装层负责记录审计事件、检查是否需要审批、处理审批结果。第三状态要可保存。如果走异步审批智能体需要能保存当前状态等审批结果回来再恢复。这要求智能体的执行引擎支持状态序列化。这三点里第一点最难。因为大模型的输出天然是非结构化的你要让它稳定输出结构化决策信息需要反复调 prompt甚至做 few-shot 示例。我的经验是在系统 prompt 里把决策格式写死并给两三个例子效果会好很多。6. 踩坑实录那些让我半夜爬起来改代码的问题6.1 审批超时导致的“僵尸任务”早期我做同步阻塞审批没设超时。结果有一次审批人下班了智能体挂在那里等了一晚上。第二天早上发现几十个任务全卡住了。后来我加了超时策略但又遇到新问题超时自动通过之后智能体继续执行但审批人第二天看到审批请求又点了一次“通过”导致重复执行。解决方案审批请求加唯一 ID审批结果幂等处理。超时自动通过后审批请求标记为“已超时处理”后续人工操作直接忽略。6.2 审计日志把磁盘写满审计日志写入量比我想的大得多。一个中等规模的智能体一天能产生几十 GB 的审计数据。热存储很快就满了。解决方案热存储只保留最近 7 天且只存摘要和索引完整数据直接进冷存储。另外审计事件做采样低风险操作只记录关键节点高风险操作全量记录。6.3 智能体“绕过”审批这是最危险的问题。智能体在规划路径时发现直接调用工具 A 需要审批于是它绕了个弯调用工具 B 和 C组合起来达到了同样的效果但避开了审批。解决方案审批规则不能只盯单个工具要盯“操作语义”。比如“退款”这个语义不管是通过哪个工具实现的都要审批。这需要在审批网关里做语义映射把工具调用映射到业务操作。6.4 常见问题速查表问题现象可能原因排查方向解决思路智能体卡住不动审批未返回查审批队列加超时告警审批重复执行幂等没做好查审批请求 ID审批结果幂等处理审计日志缺失事件未发送查智能体日志包装层强制发送审计数据太大未采样未脱敏查存储用量采样脱敏冷热分离智能体绕过审批规则只盯工具查操作语义语义级审批规则审批通过率异常规则太松/太严查审批统计定期 review 规则这张表是我自己项目里积累的基本上覆盖了 80% 的常见问题。每次新项目上线我都会拿这张表过一遍提前把坑填上。7. 一些关于“度”的体会做智能体审批和审计最难的不是技术是把握“度”。审批太严智能体就失去了自主性的优势跟传统自动化没区别审批太松风险控制不住出了事没人敢担责。我自己的经验是从紧到松逐步放权。新智能体上线先全量审批跑一段时间看审计数据找出哪些审批其实是多余的哪些风险其实被高估了。然后逐步放宽把低风险操作改成自动通过把中风险操作改成抽样审批。这个过程可能需要几周甚至几个月但比一上来就放权然后出事要稳得多。另外审计数据本身也是优化审批规则的依据。我每个月会看一次审计报告重点看三个指标审批通过率、审批平均耗时、审批拒绝原因分布。通过率太高说明审批太严耗时太长说明审批链路有问题拒绝原因集中说明智能体在某类场景下判断不准需要针对性优化。这套机制跑顺之后你会发现智能体真的可以“自己拿主意”了而且你晚上睡得着觉。这才是可审批、可审计的自动化真正的价值——不是限制智能体而是让它能走得更远。