你在一个类似AI安全运维系统里问了下面一句给我封禁这个IP: xx.xx.xx.xx如果这还只是一个demo系统Agent可能很快按照一段漂亮流程执行识别用户意图 ↓ 选择block_ip工具 ↓ 执行封禁 ↓ 回复用户已处理看起来智能但若是一个真实的接入了生产的AI安全运维系统这个搞法有点吓人了。封禁IP这类敏感的写操作不是查天气也不是总结一段文本而是一个有副作用的动作它可能会改变外部系统状态可能影响真实用户、真实服务、真实业务。。所以在Agent调用block_ip之前最好还要想好下面这些地方都咋处理1、它凭什么能调用block_ip2、谁批的3、失败了怎么办4、事后怎么查证据链5、等问题不在block_ip而在少了中间关卡【识别用户意图》选择block_ip工具》执行封禁》回复用户已处理】这条流程最大的问题是模型刚说“我觉得应该封这个IP” 系统马上就真的去封了。这中间少了一步确认这个请求真的是封禁请求吗 block_ip这个工具适合当前请求吗 这个动作不需要人批准吗模型最多只能提出建议觉得这里应该调用block_ip参数大概是这些。但系统必须再检查一遍这次到底允不允许执行所以我们需要把一次工具调用拆开。不是模型决定 - 工具执行而是类似下面的流水线处理思路分类 - 规划 - 策略 - 审批 - 执行 - 错误处理 - 重试/降级 - 审计 - 回复我暂且把这个线路叫做【工具调用的治理流水线】乍一看节点线路是挺长也挺绕的但每一段都有明确作用。对应的Graph结构大概是这样读图时可以先不用纠结每条分支只记住一个大方向请求从分类、规划、策略、审批一路往下走能执行才进入execute_tool不能执行或已经被拒绝就直接进入审计。请求先经过分类节点问题问的是帮我封禁这个IP第一步先分类。在这个示例的安全运维工具执行系统里我们把动作粗略分成三类readonly只读查询这一类 high_risk_write高风险写操作这一类 unknown无法判断转人工的这一类而封禁IP显然不是只读查询它应该被分到high_risk_write这一步简单但关键因为后面的策略、审批、执行都是基于这个分类继续走的。然后进入规划节点分类之后才是规划规划节点负责把用户请求变成准备调用哪个工具 准备传什么参数对于“封禁这个IP”的这个问题规划结果可能是planned_tool: block_ip tool_args: ip: 192.0.2.10 reason: 用户请求封禁可疑来源到这里还依然只是形成了一个“准备执行的计划”planned_tool不是已经执行的工具。 tool_args也不是已经发送出去的参数。第一道真正的门策略检查分类节点可以知道你的问题类型是readonly还是high_risk_write还是unknown规划节点可以知道你的问题打算要用的是哪个工具使用啥参数有了分类也有了规划之后策略检查其实就问一个问题这个问题类型是否允许使用这个工具比如问题类型是readonly那它只应该使用只读工具类似下面这几个lookup_asset query_exposure check_ip_reputation再比如问题类型如果是high_risk_write它就应该仅使用支持的是写操作工具block_ip add_account_to_watchlist策略检查这个节点要做的就是1、readonly请求只能使用readonly工具。2、high_risk_write请求只能使用写操作工具。3、unknown请求不自动执行直接转人工。代码逻辑大概是def enforce_tool_policy(state): action_type state.get(action_type) planned_tool state.get(planned_tool) allowed_tools ALLOWED_TOOLS_BY_ACTION_TYPE.get(action_type, {}) if planned_tool in allowed_tools: return {tool_status: pending} return { tool_status: failed, tool_error: {type: tool_not_allowed}, }第二道门人工审批现在请求已经走到这里看一下当前的state分类high_risk_write 规划block_ip 策略允许进入下一关因为block_ip是高风险写操作所以还不能直接执行这个工具调用需要人工审批。readonly的工具调用一般情况下不需要人工审批这里的人工审批用LangGraph里的interrupt()让图停下来approval_result interrupt( { question: 这个高风险工具动作是否允许执行, planned_tool: state.get(planned_tool, ), tool_args: state.get(tool_args, {}), expected_resume_shape: { decision: approved 或 denied, operator: 审批人, reason: 审批原因, }, } )意思是图先停在这 把要执行的工具和参数展示给外部审批人 等外部用Command(resume...)把审批结果传回来倘若传回来的是{”decision”: ”approved”, ”operator”: ”alice”, ”reason”: ”已确认恶意来源”}图就继续往下走进入真正的工具执行节点了这一步把“模型建议调用工具”和“人批准执行工具”分开其实就是进入Human-in-the-loop了。批准之后工具才真正执行只有当审批结果是approved才会走到execute_tool才是真的调用block_ipblock_ip( ip192.0.2.10, reason用户请求封禁可疑来源 )至此完整主线是用户请求封禁IP ↓ 分类为high_risk_write ↓ 规划成block_ip ↓ 策略检查通过 ↓ interrupt暂停等待审批 ↓ 人工approved ↓ 执行block_ip ↓ 写入审计日志 ↓ 回复用户回看一下你会发现这已经和文章一开始那种【模型规划后直接执行】的“智能的流程”完全不是一回事了。如果人工拒绝呢再看同一个请求的另一条岔路还是帮我封禁这个IP。的这个问题分类、规划、策略检查都一样图依然会停在审批节点但这次审批人传回{”decision”: ”denied”, ”operator”: ”alice”, ”reason”: ”证据不足”}这时流程会直接进入审计不会进入execute_tool第1节给出的graph结构也是这个逻辑而audit_log里记录了下面这些说明危险动作确实被挡住了。approval: denied tool_status: denied如果规划错了呢换一个请求比如问的是请查询xxxx错误示例因为有“查询”这个关键字所以第一个节点的分类结果是readonly正常情况下readonly只能使用只读工具比如query_exposure、lookup_asset。但为了测试策略检查节点有没有用我们故意让规划节点犯错让它使用planned_tool: block_ip翻译过来就是用户明明是普通的查询只读类型 规划却给了一个封禁工具可写工具这时候策略节点会发现action_type: readonly planned_tool: block_ip allowed_tools: lookup_asset, query_exposure, check_ip_reputationblock_ip不在readonly允许工具集合里所以结果是tool_status: failed tool_error.type: tool_not_allowed然后流程直接进入审计不会进入工具执行。这个也证明了一件事就算规划错了策略节点也能在执行前拦住越权工具。如果工具自己失败了呢再看一个只读请求请查询unstable.example.com的暴露服务。分类结果是readonly规划结果是query_exposure策略检查也能通过只读动作不需要人工审批所以会直接进入工具执行。上面这些都没问题但这个工具执行时超时了errorexposure scanner timeout如果异常直接抛出去整张图就崩了。崩了后面没有重试没有人工工单没有审计更没有llm给你回复了所以execute_tool节点要捕获异常把它写回Statetry: result tool(**tool_args) return { tool_status: success, tool_result: result, tool_error: {}, } except Exception as exc: return { tool_status: failed, tool_error: { type: tool_runtime_error, message: str(exc), }, }Exception里的return要确保的是工具执行可以失败但图不能走不下去工具失败只是进入了一个可处理状态。接下来在retry_or_fallback节点里会判断如果没有触发最大重试次数就重试如果达到最大重试次数后仍然失败就创建人工处理工单tool_status: ticket_created manual_ticket: SEC-MANUAL-001这比直接报错要稳得多系统没有假装成功也没有无限重试更没有让整张图崩掉。最后一定要有audit_log前面看了几类测试路径审批通过执行工具 审批拒绝不执行工具 策略拦截执行前拒绝 工具失败重试后转人工这些路径最后都是要进入audit_log因为审计日志要回答的是用户请求是什么 系统怎么分类 规划了哪个工具 参数是什么 策略有没有放行 审批人是谁 审批结果是什么 工具有没有执行 结果是什么 失败后有没有重试 最后有没有转人工audit_log代表的是这次工具调用的证据链其重要性不需要过多解释。现在再看整条工具治理流水线分类 - 规划 - 策略 - 审批 - 执行 - 错误处理 - 重试/降级 - 审计 - 回复它其实是在回答一次工具调用里的几个现实问题1、分类这是什么类型的动作 2、规划准备调用哪个工具 3、策略这个类型允许用这个工具吗 4、审批危险动作有没有人批准 5、执行工具什么时候才真正被调用 6、错误处理失败后图会不会崩 7、重试/降级失败后怎么收场 8、审计事后怎么查 9、回复怎么把最终状态解释给用户上面这条流水线算是提供一种工具调用治理的思想说实话是比普通tool loop长的多但至少说明agent在工具调用治理方面我们能做也需要做的事儿还是挺多的。实验细节GitHub 仓库 https://github.com/yauld/ai-forge 完整实验文章 labs/langgraph/foundations/23 | LangGraph 工具调用治理让工具执行可控、可恢复、可审计.md 实验代码 labs/langgraph/foundations/experiments/23_tool_governance_console/学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
