Agent 工程化系列 · 第 13 篇Agent 的安全与可靠性如何保障Agent 最危险的不是回答错而是执行错开篇定位前面我们已经讲过LLM 是能力核心Agent 是执行系统Function Call 让模型能够调用工具MCP 负责连接工具生态A2A 负责 Agent 之间协作Memory 让 Agent 具备连续上下文。到了这一篇要进入一个更现实的问题Agent 能不能安全、稳定地上线很多 Agent Demo 看起来很厉害会查资料、会写代码、会调用工具、会自动执行任务。但一旦进入真实业务环境问题马上变得复杂。因为 Agent 不只是回答问题它可能会读文件、写数据库、发邮件、调接口、改代码、下单、审批、甚至操作生产系统。所以这篇不是讲“如何让 Agent 更聪明”而是讲另一个工程问题如何让 Agent 在会做事的同时不乱做事目录01 为什么 Agent 比 Chatbot 更危险02 Agent 的风险来自哪里03 第一条防线权限最小化04 第二条防线工具调用前后校验05 第三条防线Human-in-the-loop06 可靠性不是安全但同样重要07 一个可落地的安全可靠性架构08 最后总结01 为什么 Agent 比 Chatbot 更危险普通聊天机器人回答错了最多是给了一段错误信息。但 Agent 不一样。Agent 通常连接了工具和外部系统一旦判断错可能真的会执行动作。比如用户只是想让它“整理一下文件”它可能误删目录。用户只是想让它“总结邮件”它可能把隐私内容转发出去。用户只是想让它“修复一个问题”它可能直接改动生产配置。这就是 Agent 和普通 LLM 应用最大的安全差异。一个核心判断安全风险不是从“回答”开始的而是从“行动”开始的。只要 Agent 能调用工具、访问文件、写数据库、发送消息、执行命令它就不再只是一个文本生成系统而是一个带执行能力的软件系统。02 Agent 的风险来自哪里Agent 的风险通常不是单点问题而是一条链路问题。一个用户输入、一段网页内容、一个工具返回结果、一次错误权限配置都可能影响 Agent 下一步动作。常见风险可以分成五类。第一类提示词注入提示词注入就是外部输入改变模型行为。它可能来自用户直接输入也可能藏在网页、邮件、PDF、图片、代码注释、工具返回结果里。这类风险对 Agent 特别危险因为 Agent 会把外部内容放进上下文再基于这些内容决定下一步动作。OWASP 对 Prompt Injection 的定义也强调攻击者可以通过输入改变 LLM 的行为或输出甚至影响关键决策、诱导未授权访问和连接系统中的命令执行。第二类权限过大很多 Agent 出问题不是因为模型太差而是因为系统给了它太大的权限。本来只需要读文件却给了读写删权限。本来只需要查数据库却给了更新和删除权限。本来只需要在测试环境执行却给了生产环境访问权限。这就是 OWASP 所说的 Excessive Agency功能过多、权限过大、自治程度过高都会让 LLM 系统执行破坏性动作。第三类工具污染工具返回的内容也不一定可信。比如搜索网页返回了一段隐藏提示词邮件内容里藏了“忽略前面的规则”MCP Server 返回了带指令的文本。如果 Agent 不区分“数据”和“指令”就可能把工具结果里的恶意文本当成新的系统命令。第四类敏感信息泄露Agent 经常需要访问用户文件、企业知识库、邮件、客户数据和系统日志。如果没有权限隔离、脱敏、输出检查它可能把不该展示的信息带到回答里或者传给不该调用的外部工具。第五类执行循环失控Agent 不是一次调用就结束它可能循环执行思考、调用工具、读取结果、再调用工具。如果没有终止条件、超时、预算和错误收敛机制就会出现无限循环、成本飙升、接口打爆、任务卡死。03 第一条防线权限最小化Agent 安全的第一原则不是“让模型更听话”而是不给它不该有的能力。工程上要先把能力拆开再按任务授权。比如文件工具不应该只有一个“操作文件”的大工具而应该拆成读取文件、列目录、写入新文件、修改文件、删除文件。其中读取可以低风险删除必须高风险审批。再比如数据库工具不应该让 Agent 直接拿一个高权限账号连接数据库。查询类任务只给 SELECT 权限更新类任务需要单独授权删除类任务最好不要直接暴露给 Agent。权限最小化的四个层次层次要控制什么工程做法工具最小化只暴露必要工具不需要的工具不注册给 Agent功能最小化工具只做一件事不用一个万能 Shell 代替专用工具权限最小化只给必要权限读写分离、按用户身份执行自治最小化高风险动作不自动执行删除、发送、付款、上线必须审批这几个原则听起来朴素但非常关键。因为一旦模型判断错真正决定损失大小的往往不是模型本身而是它能碰到什么系统、能做什么动作。04 第二条防线工具调用前后校验只做权限控制还不够。Agent 调工具之前要校验参数工具执行之后也要校验结果。OpenAI Agents SDK 的 Guardrails 文档把防护分成输入、输出和工具相关的校验。其中 Tool Guardrails 可以在函数工具执行前后运行执行前可以跳过、替换结果或触发中断执行后也可以替换输出或触发中断。这对 Agent 很重要。因为很多风险不是发生在最终回答而是发生在工具调用那一刻。工具调用前要检查什么第一参数格式是否合法。比如 city 是否是字符串amount 是否是正数file_path 是否在允许目录内。第二参数内容是否越权。比如用户只能访问自己的订单却请求查询别人的订单。第三动作风险等级是否过高。比如 delete、send、pay、deploy、update_permission 这类动作不能静默执行。第四是否存在注入风险。比如 Shell 命令、SQL 参数、URL、文件路径都要做白名单和转义处理。工具执行后要检查什么第一工具返回是否包含敏感信息。第二返回结果是否可信。第三是否包含新的恶意指令。第四是否需要摘要、脱敏、截断后再给模型。一个重要原则不要把所有安全责任都压到 Agent Prompt 里。Prompt 可以提醒模型不要越权但真正可靠的安全边界应该放在代码、权限、网关、沙箱和审批流程里。05 第三条防线Human-in-the-loopHuman-in-the-loop 不是为了降低自动化水平而是为了把高风险动作控制在可接受范围内。一个成熟 Agent 系统应该区分三类动作。第一类是低风险动作可以自动执行。比如读取公开资料、查询天气、生成草稿、总结文档。第二类是中风险动作可以自动准备但需要用户确认。比如修改文件、创建日程、发送内部消息。第三类是高风险动作必须强制审批。比如删除数据、外发邮件、付款、发布生产环境、修改权限、执行 Shell 命令。OpenAI 的 Guardrails and Human Review 文档中也描述了类似的审批生命周期工具调用需要审查时系统记录审批中断返回 interruptions 和可恢复 state应用批准或拒绝后再从同一 state 继续运行。这说明审批不是“重新开始一次对话”而是 Agent 执行链路中的一个状态暂停点。审批界面应该展示什么不要只给用户一个“是否同意”的按钮。审批界面至少要展示Agent 准备做什么动作使用了哪些参数会影响哪些对象是否可撤销如果不批准替代方案是什么这次动作由哪个用户、哪个任务、哪个工具触发只有这样用户才是在做有效审批而不是机械地点“同意”。06 可靠性不是安全但同样重要安全解决的是Agent 不要做危险的事。可靠性解决的是Agent 做事时不要卡死、乱重试、重复执行、失败不可恢复。这两者经常被混在一起但工程上要分开设计。Agent 可靠性的六个关键点第一超时每次模型调用、工具调用、外部 API 调用都要有超时。没有超时Agent 就可能一直等下去。第二重试重试只能用于临时失败比如网络抖动、限流、服务短暂不可用。不能对所有失败都盲目重试。比如参数错误、权限错误、业务规则不满足重试多少次都没用。第三幂等只要动作有副作用就要考虑幂等。比如创建订单、发送邮件、写数据库、触发流程如果 Agent 因为超时重试不能造成重复下单、重复发送、重复扣款。第四状态机复杂任务不要只存在模型上下文里。应该把任务拆成明确状态待开始、执行中、等待审批、已完成、失败、已回滚。这样任务失败后才能知道卡在哪一步。第五回滚不是所有动作都能回滚但至少要知道哪些动作可以撤销哪些动作不可撤销。不可撤销动作更应该强制审批。第六日志与追踪Agent 每一次计划、工具调用、审批、失败、重试、输出都应该留下日志。否则一旦出问题你很难回答三个问题它为什么这么做调用了什么工具影响了哪些数据07 一个可落地的安全可靠性架构如果把前面的内容落成架构可以拆成七层。第一层是输入边界负责输入清洗、风险识别、上下文来源标记。第二层是 Agent / Planner负责理解目标、制定计划、选择工具。第三层是 Policy Engine负责判断当前用户、当前任务、当前工具调用是否有权限。第四层是 Tool Gateway负责参数校验、工具白名单、限流、超时、重试、审计和审批触发。第五层是 Sandbox / External System负责把高风险动作限制在可控环境内。第六层是 Output Checker负责敏感信息过滤、格式校验、结果一致性检查。第七层是 Observability负责日志、指标、追踪、评估和告警。最小可落地版本如果你现在只是做一个早期 Agent 产品不一定要一次性做完所有能力。但至少应该先做到这五件事工具分级读、写、删、发、付、执行命令分开权限隔离按用户、项目、租户控制访问范围高危审批删除、外发、付款、上线必须暂停确认状态持久化复杂任务能暂停、恢复、重试日志审计每次工具调用都能追踪到用户、参数和结果这五件事做完Agent 才开始具备工程上线的基础。08 最后总结Agent 的安全与可靠性不是给模型多写几句“请谨慎操作”。真正的安全来自边界设计最小权限、工具校验、风险分级、人工审批、沙箱隔离、输出检查、日志审计。真正的可靠性来自执行设计超时、重试、幂等、状态机、checkpoint、回滚、可观测性。如果说前面几篇讲的是 Agent 如何获得能力那么这一篇讲的是能力必须被关进工程边界里Agent 才能从 Demo 走向生产。下一篇我们会继续讲一个和 Agent 落地密切相关的问题RAG 和 Agent 到底是什么关系。参考技术资料OpenAI Agents SDK - Guardrails输入、输出和工具级 Guardrails 的执行边界与触发机制。OpenAI API - Guardrails and Human Review高风险工具调用的审批中断、state 恢复和继续执行机制。OWASP Top 10 for LLM ApplicationsPrompt Injection、Insecure Output Handling、Excessive Agency 等 LLM 应用风险。OWASP LLM06:2025 Excessive Agency功能过多、权限过大、自治过高会导致破坏性动作。Anthropic - Claude Code Security权限系统、沙箱、网络请求审批、提示词注入防护和审计建议。Anthropic - Mitigating Prompt Injection in Browser Use浏览器 Agent 面临更大的不可信内容攻击面提示词注入仍不是已解决问题。