1. 从Demo到生产Agent落地为什么总在同一个地方翻车我见过太多团队在Agent项目上经历同一种过山车周五下午的Demo演示惊艳全场老板拍板加资源三个月后上线却变成客服工单的重灾区。问题不是模型不够聪明而是Demo环境和生产环境之间隔着四道工程鸿沟每一道都能让一个看起来完美的Agent系统彻底失效。先说一个我亲身经历的场景。去年帮一家做企业知识管理的团队做Agent架构评审他们的Demo是这样的用户问上季度华东区的销售数据Agent自动调用数据库查询工具返回结果再调用图表工具生成可视化全程流畅。演示时用的是一条预置的、干净的查询路径。上线后第一周真实用户问了帮我对比一下去年和今年华东区的销售趋势顺便看看哪些产品线拖了后腿Agent直接卡死——它不知道该先查哪张表工具调用参数拼错了三次最后返回了一个格式完全不对的JSON前端解析崩溃。这不是模型能力问题。这是工程问题。Demo阶段你只需要证明这条路能走通生产阶段你需要保证一万条不同的路都不会塌。这两件事的难度差了两个数量级。Agent生产落地的核心矛盾在于LLM的概率性输出和工程系统的确定性要求之间的冲突。你不可能让一个每次输出都可能不一样的东西直接去操作生产数据库、发送真实邮件、修改用户权限。所以必须在这两者之间插入一层工程化的护栏和编排。这篇文章我会把Agent从Demo到生产要跨的四道坎拆开讲工具调用的可靠性、权限安全的边界控制、可观测性的建设、以及并发与成本的实际约束。每一道坎我都会给出具体的工程解法不是理论是我在实际项目中验证过的方案。适合正在做Agent项目、或者准备把Agent从POC推向生产的同学参考。2. 第一道坎工具调用的可靠性——为什么你的Agent总在调错工具和传错参数2.1 工具调用失败的三种典型模式工具调用是Agent区别于普通聊天机器人的核心能力也是生产环境里最容易出问题的地方。我观察下来工具调用失败基本逃不出这三种模式第一种选错工具。用户问帮我查一下这个订单的物流状态Agent却调用了查询订单详情的工具因为这两个工具的描述在语义上太接近了。LLM在选工具时本质上是在做语义匹配如果你的工具描述写得模糊它就会在相似的选项之间随机游走。第二种参数格式错误。这是最高频的问题。比如你的工具要求日期格式是YYYY-MM-DD但LLM输出了2024年3月15日或者你的工具要求order_id是字符串LLM传了个整数。这类错误在Demo里很少出现因为Demo的测试用例是你精心设计的但生产环境的用户输入千奇百怪LLM的参数生成就会跟着漂移。第三种工具链断裂。多步任务中前一个工具的输出需要作为后一个工具的输入但LLM在中间步骤丢失了上下文或者对前一个工具返回的结果理解错误导致后续调用全部失败。比如查询数据库返回了一个嵌套的JSONLLM没有正确提取其中的字段直接把整个JSON塞给了下一个工具。2.2 用Schema约束把参数错误率压到1%以下解决参数格式问题最直接的手段是强Schema约束。不要指望LLM理解你的参数要求要用机器可验证的格式告诉它。具体做法是在工具定义中使用JSON Schema并且把约束写到最细。比如{ name: query_order_logistics, description: 查询指定订单的物流状态。仅在用户明确询问物流相关问题时使用。, parameters: { type: object, properties: { order_id: { type: string, pattern: ^ORD-[0-9]{10}$, description: 订单编号格式为ORD-加10位数字例如ORD-2024031501 }, query_type: { type: string, enum: [latest_status, full_trace], description: 查询类型latest_status只返回最新状态full_trace返回完整物流轨迹 } }, required: [order_id] } }注意几个关键点pattern字段用正则表达式锁死了订单号的格式enum限制了查询类型的可选值description里给了具体示例。这些约束会在LLM生成参数时被框架用来做校验不符合格式的直接拒绝让LLM重新生成。实测下来加了严格的Schema约束之后参数格式错误率能从15%左右降到1%以下。但这里有个坑约束太严会导致LLM频繁触发重试如果重试次数没有上限一个简单的查询可能循环十几次都过不了校验。我的经验是设置最大重试次数为3超过之后直接返回兜底话术同时记录日志供后续分析。2.3 工具描述怎么写才能让LLM不选错工具描述的质量直接决定了LLM选工具的准确率。我见过很多团队把工具描述写成查询订单信息这种描述在工具有十几个的时候LLM根本分不清该用哪个。好的工具描述应该包含四个要素功能边界、使用场景、不适用场景、输出示例。举个例子工具名称query_order_detail 功能根据订单号查询订单的详细信息包括商品列表、金额、下单时间、支付状态。 使用场景当用户询问某个具体订单的详情、金额、商品内容时使用。 不适用场景不要用于查询物流状态用query_order_logistics、不要用于查询用户信息用query_user_profile。 输出示例{order_id: ORD-2024031501, items: [...], total_amount: 299.00, status: paid}不适用场景这一条特别重要。LLM在选工具时如果有两个工具的功能描述有重叠它就会犹豫。明确告诉它这个工具不干什么能大幅降低误选率。另外一个小技巧给工具名加上领域前缀。比如order_query_detail、user_query_profile、logistics_query_status。这样即使LLM没有仔细读描述光看工具名也能做出更准确的判断。2.4 工具链断裂的修复中间结果的结构化传递多步工具调用中最容易出问题的是中间结果的传递。我的做法是强制所有工具的输出都走结构化格式并且在编排层做一次显式的字段映射。具体来说每个工具的输出都定义为一个Schema编排层在调用下一个工具之前先从上一个工具的输出中提取需要的字段拼成下一个工具的输入。这个过程不依赖LLM的理解而是用代码写死的映射关系。比如查询订单返回了{order_id: ..., logistics_id: ...}下一个工具需要logistics_id编排层直接取output.logistics_id而不是让LLM去看懂这个JSON再决定传什么。这样做的好处是即使LLM在中间步骤产生了幻觉也不会影响工具之间的数据传递。注意结构化传递的前提是你的工具输出本身就是结构化的。如果某个工具返回的是自然语言文本那就在工具层加一个解析步骤把它转成结构化数据再往下传。不要让自然语言在工具链中间流转。3. 第二道坎权限安全——Agent能做什么不能做什么必须由代码说了算3.1 Agent权限失控的两种真实事故Agent的权限问题比传统应用更棘手因为Agent的行为是动态生成的你很难在开发阶段穷举它可能执行的所有操作。我听说过两个真实事故。第一个是某公司的内部Agent被员工用一句帮我整理一下所有客户的联系方式诱导直接导出了整个客户数据库的Excel。Agent本身有查询权限但它没有判断这个查询是否合理的能力。第二个是某运维Agent在执行清理临时文件任务时因为LLM对临时文件的理解偏差删掉了一个正在使用的日志目录导致线上服务中断。这两个事故的共同点是Agent的执行权限没有被工程系统约束而是依赖LLM的判断力。这是极其危险的。LLM的判断力在对抗性输入面前非常脆弱你不能把安全边界建立在它的自觉上。3.2 三层权限模型工具级、参数级、会话级我的方案是建立三层权限控制每一层都用代码而非Prompt来实现。第一层工具级权限。每个Agent实例在初始化时明确声明它能访问哪些工具。这个声明是一个白名单不在白名单里的工具Agent根本看不到。比如客服Agent只能访问query_order、query_logistics、create_ticket三个工具它连delete_order这个工具的存在都不知道。第二层参数级权限。即使工具在白名单里参数也要受约束。比如query_order工具客服Agent只能查询当前会话关联的订单不能查询任意订单。这个约束在工具的实现层做不在Prompt里写。具体做法是工具函数接收一个context参数里面包含当前用户的身份和会话信息工具内部根据context来限制查询范围。def query_order(order_id: str, context: dict): # 客服只能查当前会话关联的订单 if context[role] customer_service: if order_id not in context[session_orders]: raise PermissionError(无权查询该订单) # 管理员可以查任意订单 elif context[role] admin: pass else: raise PermissionError(未知角色) # 执行查询...第三层会话级权限。每个会话有一个权限令牌令牌里包含了这个会话允许执行的操作类型和资源范围。Agent在执行任何操作之前都要用这个令牌做一次鉴权。令牌是有时效的过期自动失效。这三层加起来即使LLM被诱导生成了恶意调用也会在工具层被拦截。安全边界必须在代码里不能在Prompt里。3.3 危险操作的二次确认机制怎么设计有些操作即使有权限也应该加一道人工确认。比如删除数据、发送邮件、修改配置。我的做法是给这些操作打上requires_confirmation标记Agent在执行前会暂停把操作详情展示给用户等用户确认后再继续。这里的关键是确认信息要足够具体。不要只显示即将执行删除操作要显示即将删除订单ORD-2024031501该订单包含3件商品总金额299元。用户看到具体信息才能做出准确判断。另外确认机制要有超时。如果用户5分钟没有响应操作自动取消避免Agent一直挂在那里等。3.4 审计日志每一笔工具调用都要能追溯到人审计日志是权限安全的最后一道防线。每一笔工具调用都要记录谁发起的用户ID、什么时间、调用了什么工具、传了什么参数、返回了什么结果、是否成功。这些日志要写到独立的存储里Agent本身没有权限修改或删除。我通常用追加写的日志文件或者专门的审计表确保日志的完整性。审计日志的价值不仅在于事后追责更在于实时监控。你可以设置规则如果某个Agent在短时间内频繁调用敏感工具或者调用了从未调用过的工具就触发告警。这种异常检测能在事故扩大之前就发现问题。4. 第三道坎可观测性——Agent的黑盒怎么打开4.1 为什么传统APM工具看不透Agent传统的APM工具是为确定性系统设计的一个请求进来经过几个服务每个服务的耗时和状态都能追踪。但Agent的执行路径是动态生成的同一个用户问题Agent可能走三条完全不同的工具调用链。传统APM只能告诉你这个请求花了3秒但没法告诉你这3秒里Agent想了什么、为什么选了这条路径。Agent的可观测性需要三个层面的数据决策层LLM为什么选了这个工具、执行层工具调用的输入输出和耗时、结果层最终返回给用户的内容是否满足预期。4.2 决策链追踪把LLM的思考过程记录下来决策链追踪的核心是记录每一次LLM调用的完整上下文输入Prompt、输出内容、选择的工具、生成的参数。这些数据要关联到同一个会话ID下形成一条完整的决策链。我通常用这样的结构来存储{ session_id: sess_20240315_001, turn: 3, timestamp: 2024-03-15T10:23:45Z, llm_input: { messages: [...], available_tools: [query_order, query_logistics] }, llm_output: { thought: 用户询问物流状态应该使用query_logistics工具, tool_call: { name: query_logistics, arguments: {order_id: ORD-2024031501, query_type: latest_status} } }, tool_result: { status: success, data: {...}, latency_ms: 230 } }有了这条决策链当用户投诉Agent答非所问时你可以直接回放整个决策过程看到底是哪一步出了问题是LLM选错了工具还是工具返回了错误数据还是LLM对工具结果的理解有偏差。4.3 关键指标工具调用成功率、平均步数、异常中断率可观测性不能只看日志还要有聚合指标。我重点关注三个指标工具调用成功率。按工具维度统计每个工具的调用成功率和失败原因分布。如果某个工具的失败率突然上升可能是Schema变了或者上游数据源出了问题。平均步数。一个用户请求平均需要多少步工具调用才能完成。这个指标突然上升通常意味着LLM在某个环节卡住了反复重试。比如正常情况平均3步完成突然变成8步那就要去查是不是某个工具的描述变得模糊了。异常中断率。Agent执行过程中因为错误而中断的比例。这个指标要按错误类型细分是LLM输出格式错误、工具调用超时、还是权限被拒绝。不同原因对应不同的修复策略。4.4 用LLM-as-Judge做输出质量的自动评估传统的监控只能告诉你系统有没有报错但没法告诉你Agent的回答质量好不好。这时候可以用LLM-as-Judge用一个独立的LLM来评估Agent的输出是否满足预期。具体做法是从生产流量中抽样把用户问题、Agent的完整决策链、最终输出一起送给评估LLM让它从准确性、完整性、相关性三个维度打分。分数低于阈值的样本自动进入人工复核队列。这个方案的成本可控因为只需要抽样评估不需要全量。我通常按5%的比例抽样每天评估几百条足够发现系统性的质量问题。注意LLM-as-Judge本身也有偏差不要完全依赖它的打分。我的做法是把它当作一个异常发现器它标记出来的低分样本人工复核后再决定是否真的有问题。5. 第四道坎并发与成本——Agent扛不住流量时的工程取舍5.1 Agent的并发瓶颈到底在哪里很多人以为Agent的并发瓶颈在LLM的推理速度其实不是。LLM的推理确实慢但它是可以水平扩展的。真正的瓶颈在工具调用的串行依赖和会话状态的维护。一个多步Agent任务工具调用是串行的查订单→查物流→生成回复。每一步都要等上一步完成。如果每个工具调用平均200毫秒三步就是600毫秒再加上LLM的推理时间一个请求轻松超过3秒。当并发量上来时这些串行等待会迅速耗尽线程池。会话状态的维护是另一个瓶颈。Agent需要记住对话历史、工具调用结果、当前任务状态。如果这些状态存在内存里就没法水平扩展如果存在数据库里每次读写都有延迟。5.2 会话状态的外置与恢复我的方案是把会话状态完全外置到Redis里Agent实例本身无状态。每个请求进来先从Redis加载会话状态执行完后写回。这样Agent实例可以随意增减不受状态约束。状态的结构要设计得紧凑只存必要的信息对话历史最近N轮、当前任务状态、已调用的工具和结果。不要存整个LLM的上下文那个太大了。我通常只存最近5轮对话和当前任务的中间结果更早的历史做摘要压缩。恢复机制也很重要。如果Agent实例在执行过程中崩溃了下一个请求进来时要能从Redis里恢复状态继续执行。这要求状态写入是原子的不能出现写了一半的情况。5.3 工具调用的并行化改造串行工具调用是延迟的主要来源。能并行的调用一定要并行。比如查询订单详情和查询物流状态这两个操作没有依赖关系可以同时发起。改造的方法是在编排层识别出没有依赖关系的工具调用用asyncio.gather或者类似的并行机制同时执行。这能把多步任务的延迟从步数×单步延迟降到最长单步延迟。但并行化有个前提工具调用必须是幂等的。如果某个工具调用有副作用比如创建订单就不能随便并行否则可能重复创建。我的做法是给每个工具打上idempotent标记只有标记为幂等的工具才允许并行调用。5.4 成本控制Token消耗的监控与优化Agent的Token消耗比普通对话高得多因为每次工具调用都要把完整的工具定义和对话历史塞进Prompt。一个多步任务下来Token消耗可能是普通对话的10倍以上。控制成本的第一招是精简工具定义。只把当前任务可能用到的工具放进Prompt不要把所有工具都塞进去。比如用户问的是订单问题就只放订单相关的工具物流和用户管理的工具先不放。第二招是对话历史的摘要压缩。超过5轮的历史对话用LLM做一次摘要只保留关键信息。这样能大幅减少Prompt长度。第三招是缓存高频查询。有些查询是重复的比如我的订单状态同一个订单在短时间内可能被查多次。把结果缓存起来设置合理的过期时间能省下不少Token。我通常会监控每个会话的Token消耗设置一个上限。超过上限的会话触发告警人工介入分析是不是有异常调用。6. 把四道坎串起来一个可落地的Agent生产架构6.1 架构分层与职责划分把前面四道坎的解法串起来一个可落地的Agent生产架构大概长这样接入层负责接收用户请求做身份认证和限流。这一层不涉及Agent逻辑就是标准的Web服务。编排层是核心负责加载会话状态、调用LLM做决策、执行工具调用、管理重试和确认流程。这一层要无状态状态全部外置。工具层是实际执行操作的地方每个工具都是一个独立的函数或服务有自己的权限校验和审计日志。可观测层贯穿所有层收集决策链日志、工具调用指标、Token消耗数据。存储层包括会话状态存储Redis、审计日志存储追加写文件或专用表、缓存存储。6.2 关键配置参数与调优建议几个我实际调过的参数供参考参数建议值说明LLM最大重试次数3超过后返回兜底话术工具调用超时5秒超时后标记失败触发重试或降级会话状态TTL30分钟超过后会话过期需重新开始对话历史保留轮数5轮超过后做摘要压缩并行工具调用上限5个避免同时发起过多请求Token消耗告警阈值单会话5000超过后触发人工复核这些值不是固定的要根据你的实际流量和成本预算调整。比如Token预算充足的话可以把历史保留轮数调大提升对话连贯性。6.3 上线前的检查清单在把Agent推向生产之前我通常会过一遍这个清单所有工具都有明确的Schema定义和描述权限校验在工具层实现不依赖Prompt危险操作有二次确认机制审计日志覆盖所有工具调用决策链日志能完整回放关键指标有监控和告警会话状态外置Agent实例无状态幂等工具支持并行调用Token消耗有监控和上限有兜底话术处理所有异常情况这个清单看起来长但每一条都是踩过坑之后加上的。少一条上线后就多一个半夜被叫起来修bug的理由。6.4 从上线到迭代持续优化的闭环Agent上线不是终点而是起点。生产环境会暴露你在Demo阶段永远想不到的问题。我的做法是建立一个持续优化的闭环每天看异常日志找出Top 3的失败模式针对性修复。每周看LLM-as-Judge的评估结果找出质量下降的样本分析原因。每月做一次全量的工具调用分析看看有没有可以合并或废弃的工具。这个闭环跑起来之后Agent的成功率会从上线初期的70%左右逐步提升到95%以上。但这个过程需要耐心不是一蹴而就的。我个人在实际项目中的体会是Agent生产落地最难的不是技术而是心态的转变从证明它能行转变到保证它不出事。Demo阶段你可以容忍失败生产阶段每一个失败都是真实的用户影响。这四道坎本质上都是在做同一件事把Agent的不确定性关进工程确定性的笼子里。笼子扎得越紧Agent在生产环境里就越稳。
Agent从Demo到生产：四道工程鸿沟与落地架构实战
1. 从Demo到生产Agent落地为什么总在同一个地方翻车我见过太多团队在Agent项目上经历同一种过山车周五下午的Demo演示惊艳全场老板拍板加资源三个月后上线却变成客服工单的重灾区。问题不是模型不够聪明而是Demo环境和生产环境之间隔着四道工程鸿沟每一道都能让一个看起来完美的Agent系统彻底失效。先说一个我亲身经历的场景。去年帮一家做企业知识管理的团队做Agent架构评审他们的Demo是这样的用户问上季度华东区的销售数据Agent自动调用数据库查询工具返回结果再调用图表工具生成可视化全程流畅。演示时用的是一条预置的、干净的查询路径。上线后第一周真实用户问了帮我对比一下去年和今年华东区的销售趋势顺便看看哪些产品线拖了后腿Agent直接卡死——它不知道该先查哪张表工具调用参数拼错了三次最后返回了一个格式完全不对的JSON前端解析崩溃。这不是模型能力问题。这是工程问题。Demo阶段你只需要证明这条路能走通生产阶段你需要保证一万条不同的路都不会塌。这两件事的难度差了两个数量级。Agent生产落地的核心矛盾在于LLM的概率性输出和工程系统的确定性要求之间的冲突。你不可能让一个每次输出都可能不一样的东西直接去操作生产数据库、发送真实邮件、修改用户权限。所以必须在这两者之间插入一层工程化的护栏和编排。这篇文章我会把Agent从Demo到生产要跨的四道坎拆开讲工具调用的可靠性、权限安全的边界控制、可观测性的建设、以及并发与成本的实际约束。每一道坎我都会给出具体的工程解法不是理论是我在实际项目中验证过的方案。适合正在做Agent项目、或者准备把Agent从POC推向生产的同学参考。2. 第一道坎工具调用的可靠性——为什么你的Agent总在调错工具和传错参数2.1 工具调用失败的三种典型模式工具调用是Agent区别于普通聊天机器人的核心能力也是生产环境里最容易出问题的地方。我观察下来工具调用失败基本逃不出这三种模式第一种选错工具。用户问帮我查一下这个订单的物流状态Agent却调用了查询订单详情的工具因为这两个工具的描述在语义上太接近了。LLM在选工具时本质上是在做语义匹配如果你的工具描述写得模糊它就会在相似的选项之间随机游走。第二种参数格式错误。这是最高频的问题。比如你的工具要求日期格式是YYYY-MM-DD但LLM输出了2024年3月15日或者你的工具要求order_id是字符串LLM传了个整数。这类错误在Demo里很少出现因为Demo的测试用例是你精心设计的但生产环境的用户输入千奇百怪LLM的参数生成就会跟着漂移。第三种工具链断裂。多步任务中前一个工具的输出需要作为后一个工具的输入但LLM在中间步骤丢失了上下文或者对前一个工具返回的结果理解错误导致后续调用全部失败。比如查询数据库返回了一个嵌套的JSONLLM没有正确提取其中的字段直接把整个JSON塞给了下一个工具。2.2 用Schema约束把参数错误率压到1%以下解决参数格式问题最直接的手段是强Schema约束。不要指望LLM理解你的参数要求要用机器可验证的格式告诉它。具体做法是在工具定义中使用JSON Schema并且把约束写到最细。比如{ name: query_order_logistics, description: 查询指定订单的物流状态。仅在用户明确询问物流相关问题时使用。, parameters: { type: object, properties: { order_id: { type: string, pattern: ^ORD-[0-9]{10}$, description: 订单编号格式为ORD-加10位数字例如ORD-2024031501 }, query_type: { type: string, enum: [latest_status, full_trace], description: 查询类型latest_status只返回最新状态full_trace返回完整物流轨迹 } }, required: [order_id] } }注意几个关键点pattern字段用正则表达式锁死了订单号的格式enum限制了查询类型的可选值description里给了具体示例。这些约束会在LLM生成参数时被框架用来做校验不符合格式的直接拒绝让LLM重新生成。实测下来加了严格的Schema约束之后参数格式错误率能从15%左右降到1%以下。但这里有个坑约束太严会导致LLM频繁触发重试如果重试次数没有上限一个简单的查询可能循环十几次都过不了校验。我的经验是设置最大重试次数为3超过之后直接返回兜底话术同时记录日志供后续分析。2.3 工具描述怎么写才能让LLM不选错工具描述的质量直接决定了LLM选工具的准确率。我见过很多团队把工具描述写成查询订单信息这种描述在工具有十几个的时候LLM根本分不清该用哪个。好的工具描述应该包含四个要素功能边界、使用场景、不适用场景、输出示例。举个例子工具名称query_order_detail 功能根据订单号查询订单的详细信息包括商品列表、金额、下单时间、支付状态。 使用场景当用户询问某个具体订单的详情、金额、商品内容时使用。 不适用场景不要用于查询物流状态用query_order_logistics、不要用于查询用户信息用query_user_profile。 输出示例{order_id: ORD-2024031501, items: [...], total_amount: 299.00, status: paid}不适用场景这一条特别重要。LLM在选工具时如果有两个工具的功能描述有重叠它就会犹豫。明确告诉它这个工具不干什么能大幅降低误选率。另外一个小技巧给工具名加上领域前缀。比如order_query_detail、user_query_profile、logistics_query_status。这样即使LLM没有仔细读描述光看工具名也能做出更准确的判断。2.4 工具链断裂的修复中间结果的结构化传递多步工具调用中最容易出问题的是中间结果的传递。我的做法是强制所有工具的输出都走结构化格式并且在编排层做一次显式的字段映射。具体来说每个工具的输出都定义为一个Schema编排层在调用下一个工具之前先从上一个工具的输出中提取需要的字段拼成下一个工具的输入。这个过程不依赖LLM的理解而是用代码写死的映射关系。比如查询订单返回了{order_id: ..., logistics_id: ...}下一个工具需要logistics_id编排层直接取output.logistics_id而不是让LLM去看懂这个JSON再决定传什么。这样做的好处是即使LLM在中间步骤产生了幻觉也不会影响工具之间的数据传递。注意结构化传递的前提是你的工具输出本身就是结构化的。如果某个工具返回的是自然语言文本那就在工具层加一个解析步骤把它转成结构化数据再往下传。不要让自然语言在工具链中间流转。3. 第二道坎权限安全——Agent能做什么不能做什么必须由代码说了算3.1 Agent权限失控的两种真实事故Agent的权限问题比传统应用更棘手因为Agent的行为是动态生成的你很难在开发阶段穷举它可能执行的所有操作。我听说过两个真实事故。第一个是某公司的内部Agent被员工用一句帮我整理一下所有客户的联系方式诱导直接导出了整个客户数据库的Excel。Agent本身有查询权限但它没有判断这个查询是否合理的能力。第二个是某运维Agent在执行清理临时文件任务时因为LLM对临时文件的理解偏差删掉了一个正在使用的日志目录导致线上服务中断。这两个事故的共同点是Agent的执行权限没有被工程系统约束而是依赖LLM的判断力。这是极其危险的。LLM的判断力在对抗性输入面前非常脆弱你不能把安全边界建立在它的自觉上。3.2 三层权限模型工具级、参数级、会话级我的方案是建立三层权限控制每一层都用代码而非Prompt来实现。第一层工具级权限。每个Agent实例在初始化时明确声明它能访问哪些工具。这个声明是一个白名单不在白名单里的工具Agent根本看不到。比如客服Agent只能访问query_order、query_logistics、create_ticket三个工具它连delete_order这个工具的存在都不知道。第二层参数级权限。即使工具在白名单里参数也要受约束。比如query_order工具客服Agent只能查询当前会话关联的订单不能查询任意订单。这个约束在工具的实现层做不在Prompt里写。具体做法是工具函数接收一个context参数里面包含当前用户的身份和会话信息工具内部根据context来限制查询范围。def query_order(order_id: str, context: dict): # 客服只能查当前会话关联的订单 if context[role] customer_service: if order_id not in context[session_orders]: raise PermissionError(无权查询该订单) # 管理员可以查任意订单 elif context[role] admin: pass else: raise PermissionError(未知角色) # 执行查询...第三层会话级权限。每个会话有一个权限令牌令牌里包含了这个会话允许执行的操作类型和资源范围。Agent在执行任何操作之前都要用这个令牌做一次鉴权。令牌是有时效的过期自动失效。这三层加起来即使LLM被诱导生成了恶意调用也会在工具层被拦截。安全边界必须在代码里不能在Prompt里。3.3 危险操作的二次确认机制怎么设计有些操作即使有权限也应该加一道人工确认。比如删除数据、发送邮件、修改配置。我的做法是给这些操作打上requires_confirmation标记Agent在执行前会暂停把操作详情展示给用户等用户确认后再继续。这里的关键是确认信息要足够具体。不要只显示即将执行删除操作要显示即将删除订单ORD-2024031501该订单包含3件商品总金额299元。用户看到具体信息才能做出准确判断。另外确认机制要有超时。如果用户5分钟没有响应操作自动取消避免Agent一直挂在那里等。3.4 审计日志每一笔工具调用都要能追溯到人审计日志是权限安全的最后一道防线。每一笔工具调用都要记录谁发起的用户ID、什么时间、调用了什么工具、传了什么参数、返回了什么结果、是否成功。这些日志要写到独立的存储里Agent本身没有权限修改或删除。我通常用追加写的日志文件或者专门的审计表确保日志的完整性。审计日志的价值不仅在于事后追责更在于实时监控。你可以设置规则如果某个Agent在短时间内频繁调用敏感工具或者调用了从未调用过的工具就触发告警。这种异常检测能在事故扩大之前就发现问题。4. 第三道坎可观测性——Agent的黑盒怎么打开4.1 为什么传统APM工具看不透Agent传统的APM工具是为确定性系统设计的一个请求进来经过几个服务每个服务的耗时和状态都能追踪。但Agent的执行路径是动态生成的同一个用户问题Agent可能走三条完全不同的工具调用链。传统APM只能告诉你这个请求花了3秒但没法告诉你这3秒里Agent想了什么、为什么选了这条路径。Agent的可观测性需要三个层面的数据决策层LLM为什么选了这个工具、执行层工具调用的输入输出和耗时、结果层最终返回给用户的内容是否满足预期。4.2 决策链追踪把LLM的思考过程记录下来决策链追踪的核心是记录每一次LLM调用的完整上下文输入Prompt、输出内容、选择的工具、生成的参数。这些数据要关联到同一个会话ID下形成一条完整的决策链。我通常用这样的结构来存储{ session_id: sess_20240315_001, turn: 3, timestamp: 2024-03-15T10:23:45Z, llm_input: { messages: [...], available_tools: [query_order, query_logistics] }, llm_output: { thought: 用户询问物流状态应该使用query_logistics工具, tool_call: { name: query_logistics, arguments: {order_id: ORD-2024031501, query_type: latest_status} } }, tool_result: { status: success, data: {...}, latency_ms: 230 } }有了这条决策链当用户投诉Agent答非所问时你可以直接回放整个决策过程看到底是哪一步出了问题是LLM选错了工具还是工具返回了错误数据还是LLM对工具结果的理解有偏差。4.3 关键指标工具调用成功率、平均步数、异常中断率可观测性不能只看日志还要有聚合指标。我重点关注三个指标工具调用成功率。按工具维度统计每个工具的调用成功率和失败原因分布。如果某个工具的失败率突然上升可能是Schema变了或者上游数据源出了问题。平均步数。一个用户请求平均需要多少步工具调用才能完成。这个指标突然上升通常意味着LLM在某个环节卡住了反复重试。比如正常情况平均3步完成突然变成8步那就要去查是不是某个工具的描述变得模糊了。异常中断率。Agent执行过程中因为错误而中断的比例。这个指标要按错误类型细分是LLM输出格式错误、工具调用超时、还是权限被拒绝。不同原因对应不同的修复策略。4.4 用LLM-as-Judge做输出质量的自动评估传统的监控只能告诉你系统有没有报错但没法告诉你Agent的回答质量好不好。这时候可以用LLM-as-Judge用一个独立的LLM来评估Agent的输出是否满足预期。具体做法是从生产流量中抽样把用户问题、Agent的完整决策链、最终输出一起送给评估LLM让它从准确性、完整性、相关性三个维度打分。分数低于阈值的样本自动进入人工复核队列。这个方案的成本可控因为只需要抽样评估不需要全量。我通常按5%的比例抽样每天评估几百条足够发现系统性的质量问题。注意LLM-as-Judge本身也有偏差不要完全依赖它的打分。我的做法是把它当作一个异常发现器它标记出来的低分样本人工复核后再决定是否真的有问题。5. 第四道坎并发与成本——Agent扛不住流量时的工程取舍5.1 Agent的并发瓶颈到底在哪里很多人以为Agent的并发瓶颈在LLM的推理速度其实不是。LLM的推理确实慢但它是可以水平扩展的。真正的瓶颈在工具调用的串行依赖和会话状态的维护。一个多步Agent任务工具调用是串行的查订单→查物流→生成回复。每一步都要等上一步完成。如果每个工具调用平均200毫秒三步就是600毫秒再加上LLM的推理时间一个请求轻松超过3秒。当并发量上来时这些串行等待会迅速耗尽线程池。会话状态的维护是另一个瓶颈。Agent需要记住对话历史、工具调用结果、当前任务状态。如果这些状态存在内存里就没法水平扩展如果存在数据库里每次读写都有延迟。5.2 会话状态的外置与恢复我的方案是把会话状态完全外置到Redis里Agent实例本身无状态。每个请求进来先从Redis加载会话状态执行完后写回。这样Agent实例可以随意增减不受状态约束。状态的结构要设计得紧凑只存必要的信息对话历史最近N轮、当前任务状态、已调用的工具和结果。不要存整个LLM的上下文那个太大了。我通常只存最近5轮对话和当前任务的中间结果更早的历史做摘要压缩。恢复机制也很重要。如果Agent实例在执行过程中崩溃了下一个请求进来时要能从Redis里恢复状态继续执行。这要求状态写入是原子的不能出现写了一半的情况。5.3 工具调用的并行化改造串行工具调用是延迟的主要来源。能并行的调用一定要并行。比如查询订单详情和查询物流状态这两个操作没有依赖关系可以同时发起。改造的方法是在编排层识别出没有依赖关系的工具调用用asyncio.gather或者类似的并行机制同时执行。这能把多步任务的延迟从步数×单步延迟降到最长单步延迟。但并行化有个前提工具调用必须是幂等的。如果某个工具调用有副作用比如创建订单就不能随便并行否则可能重复创建。我的做法是给每个工具打上idempotent标记只有标记为幂等的工具才允许并行调用。5.4 成本控制Token消耗的监控与优化Agent的Token消耗比普通对话高得多因为每次工具调用都要把完整的工具定义和对话历史塞进Prompt。一个多步任务下来Token消耗可能是普通对话的10倍以上。控制成本的第一招是精简工具定义。只把当前任务可能用到的工具放进Prompt不要把所有工具都塞进去。比如用户问的是订单问题就只放订单相关的工具物流和用户管理的工具先不放。第二招是对话历史的摘要压缩。超过5轮的历史对话用LLM做一次摘要只保留关键信息。这样能大幅减少Prompt长度。第三招是缓存高频查询。有些查询是重复的比如我的订单状态同一个订单在短时间内可能被查多次。把结果缓存起来设置合理的过期时间能省下不少Token。我通常会监控每个会话的Token消耗设置一个上限。超过上限的会话触发告警人工介入分析是不是有异常调用。6. 把四道坎串起来一个可落地的Agent生产架构6.1 架构分层与职责划分把前面四道坎的解法串起来一个可落地的Agent生产架构大概长这样接入层负责接收用户请求做身份认证和限流。这一层不涉及Agent逻辑就是标准的Web服务。编排层是核心负责加载会话状态、调用LLM做决策、执行工具调用、管理重试和确认流程。这一层要无状态状态全部外置。工具层是实际执行操作的地方每个工具都是一个独立的函数或服务有自己的权限校验和审计日志。可观测层贯穿所有层收集决策链日志、工具调用指标、Token消耗数据。存储层包括会话状态存储Redis、审计日志存储追加写文件或专用表、缓存存储。6.2 关键配置参数与调优建议几个我实际调过的参数供参考参数建议值说明LLM最大重试次数3超过后返回兜底话术工具调用超时5秒超时后标记失败触发重试或降级会话状态TTL30分钟超过后会话过期需重新开始对话历史保留轮数5轮超过后做摘要压缩并行工具调用上限5个避免同时发起过多请求Token消耗告警阈值单会话5000超过后触发人工复核这些值不是固定的要根据你的实际流量和成本预算调整。比如Token预算充足的话可以把历史保留轮数调大提升对话连贯性。6.3 上线前的检查清单在把Agent推向生产之前我通常会过一遍这个清单所有工具都有明确的Schema定义和描述权限校验在工具层实现不依赖Prompt危险操作有二次确认机制审计日志覆盖所有工具调用决策链日志能完整回放关键指标有监控和告警会话状态外置Agent实例无状态幂等工具支持并行调用Token消耗有监控和上限有兜底话术处理所有异常情况这个清单看起来长但每一条都是踩过坑之后加上的。少一条上线后就多一个半夜被叫起来修bug的理由。6.4 从上线到迭代持续优化的闭环Agent上线不是终点而是起点。生产环境会暴露你在Demo阶段永远想不到的问题。我的做法是建立一个持续优化的闭环每天看异常日志找出Top 3的失败模式针对性修复。每周看LLM-as-Judge的评估结果找出质量下降的样本分析原因。每月做一次全量的工具调用分析看看有没有可以合并或废弃的工具。这个闭环跑起来之后Agent的成功率会从上线初期的70%左右逐步提升到95%以上。但这个过程需要耐心不是一蹴而就的。我个人在实际项目中的体会是Agent生产落地最难的不是技术而是心态的转变从证明它能行转变到保证它不出事。Demo阶段你可以容忍失败生产阶段每一个失败都是真实的用户影响。这四道坎本质上都是在做同一件事把Agent的不确定性关进工程确定性的笼子里。笼子扎得越紧Agent在生产环境里就越稳。
