上周我和一个在律所做技术负责人的朋友吃饭他聊起最近团队正在搞的“AI Agent项目”说每天站会听得他头大。不是“RAG接口又超时了”就是“MCP服务观测数据对不上”还有“客户给的合同PDFAgent解析出来的条款上下文对不上法务差点炸了”。这让我想起一个现象现在网上关于AI Agent、RAG、MCP的教程和概念文章铺天盖地但大多停留在“Hello World”级别。告诉你一个工具链怎么搭起来跑通一个Demo然后就说“搞定”。但真到了企业级开发尤其是像律所这种对准确性、稳定性和流程有严苛要求的场景你会发现从“跑通”到“能用”再到“敢用”和“好用”中间隔着十万八千里。今天我就借这个“律所AI Agent项目”的日常拆解一下真实的企业级AI应用开发到底在忙些什么。你会发现核心矛盾从来不是某个算法多先进而是如何把前沿的、不稳定的AI能力封装成一个稳定、可靠、可观测、可维护的工程系统。这其中的关键往往是一些听起来很“工程”、很“枯燥”的细节。1. 从“玩具”到“工具”企业级AI Agent的核心不是智能是可靠性很多人对AI Agent的想象还停留在“一个超级智能的虚拟员工能理解一切自主完成复杂任务”。但在企业级场景尤其是法律、金融、医疗等领域首要需求恰恰相反不是要它多“智能”而是要它多“可靠”。一个能回答80%问题但偶尔会“幻觉”出错误答案的Agent其破坏力远大于一个只能回答50%问题但答案100%准确的系统。因为前者会带来巨大的信任崩塌和潜在风险。律所的合同审阅、法律咨询错一个字、漏一个条款都可能意味着巨额赔偿。所以这个律所项目组每天开会讨论最多的不是“我们怎么让Agent更聪明”而是稳定性服务会不会挂响应时间是否稳定准确性RAG召回的内容是否精准有没有被无关信息污染可解释性Agent给出的结论依据是什么能追溯到原文的哪一段吗边界控制什么问题Agent能答什么问题必须转人工这个边界怎么定义和监控这就引出了他们日常工作的第一个重头戏RAG检索增强生成系统的“对接”与“打磨”。这里的“对接”远不是调个API那么简单。1.1 RAG对接不是调用接口是定义数据契约在Demo里RAG可能就是一段代码用户提问 - 向量化 - 检索向量数据库 - 返回Top K文档 - 拼接到Prompt里 - 交给大模型生成答案。干净利落。但在企业里尤其是律所数据源是复杂的内部知识库历年案例汇编、法律法规库、内部办案指引Word、PDF、Markdown。动态数据源客户管理系统中的案件基本信息、日程安排。第三方数据裁判文书网、企业信息查询平台等需要合规接入。非结构化文档客户发来的合同、证据材料扫描件格式五花八门。“对接”RAG首先要解决的是数据接入与清洗的标准化。他们需要为每一种数据源编写特定的“解析器”和“加载器”PDF解析器不能只用通用的PyPDF2或pdfplumber因为法律文书有固定结构标题、条款、附录。他们需要能识别“第X条”、“双方约定”等法律文本结构的解析器确保条款不被切碎。文档分块策略法律文档分块不能简单按字数或段落。一个完整的“违约责任”条款可能跨越好几页必须保证其完整性。他们采用了基于语义和规则的分块策略比如结合NLP识别出的“条款边界”进行分块。元数据注入为每一块文本注入丰富的元数据例如文档来源、文档类型合同/法条/案例、生效日期、相关案号、所属客户。这些元数据在后续检索和结果过滤中至关重要。他们为此专门建立了一套数据预处理流水线所有外部文档必须经过这条流水线的清洗、解析、分块、向量化才能进入核心的向量数据库。每天的站会都会有类似“XX客户的新版投资协议PDF解析后第8条和第9条合并了导致检索不准”这样的问题讨论。1.2 检索质量精准率 vs. 召回率的永恒博弈即使数据准备好了检索本身也是个大坑。简单使用余弦相似度去向量库找最像的文本在法律场景下很容易出问题。问题一语义相似但主题无关。比如用户问“劳动合同中试用期最长多久”向量检索可能返回一堆讲“试用期工资”的段落因为它们都有“试用期”这个词语义相近。但用户要的是“时长”。解决方案他们引入了混合检索Hybrid Search。结合密集向量检索捕捉深层语义。稀疏向量检索如BM25捕捉关键词匹配。比如“最长”、“多久”这些关键词能有效过滤掉只讨论工资的文档。元数据过滤在检索前先根据问题类型是问法条还是问合同范本用元数据过滤一遍候选集缩小范围。问题二长尾问题与冷启动。一些非常专业、冷僻的法律概念在有限的内部知识库中可能没有直接对应的向量表示。解决方案建立查询重写Query Rewriting和扩展Query Expansion层。利用大模型本身的能力将用户的原始问题重写或扩展成多个从不同角度切入、或更接近知识库表述方式的查询语句分别进行检索再合并结果。例如将“试用期最长多久”扩展为“《劳动合同法》关于试用期期限的规定”、“试用期的最长法定期限”。这些策略的调优需要大量的测试和评估。他们构建了一个测试集包含历史上律师常问的几百个问题及其标准答案每天跑一遍监控检索模块的精准率、召回率等指标。这才是“RAG对接”的日常。2. “超时熔断”给不确定的AI能力装上保险丝如果说RAG对接是解决“输入”的可靠性问题那么“超时熔断”就是解决“过程”和“输出”的可靠性问题。大模型API无论是云端还是本地部署不是百分之百稳定的。网络抖动、服务端负载过高、遇到复杂问题导致生成时间过长……任何意外都可能导致请求挂起进而拖垮整个Agent服务甚至引发连锁反应。在律所的项目里Agent可能被集成到内部OA系统、律师工作台甚至客户门户。一个前端页面因为Agent接口超时而一直转圈用户体验是毁灭性的。因此“熔断”机制不是可选项是必选项。2.1 超时控制每一层都要有“守门人”他们的超时控制是分层级的客户端超时前端或调用方设置的超时比如10秒。超过就显示“请求超时请稍后再试”。网关/API网关超时在请求到达具体Agent服务前网关层面设置一个稍短于客户端的超时如8秒用于保护后端服务不被慢请求拖累。服务内部超时这是最精细的一层。一个完整的Agent处理流程可能包含多个步骤意图识别超时2秒。RAG检索超时3秒。大模型调用这是大头也是最不稳定的。他们根据任务类型设定了不同超时简单QA超时5秒。复杂合同条款分析超时15秒。批量文档摘要超时30秒并采用异步任务。后处理格式化、日志记录等超时2秒。任何一个步骤超时整个流程不会傻等而是会触发降级策略。例如RAG检索超时 - 跳过检索直接让大模型基于通用知识回答并在答案前提示“本次回答未参考您提供的资料”。大模型生成超时 - 返回一个预设的友好提示如“问题较为复杂分析中…已记录您的问题稍后由专业律师为您解答”并将任务转入人工处理队列。2.2 熔断机制防止雪崩超时是针对单次请求的防护熔断是针对连续故障的防护。他们使用了类似“断路器Circuit Breaker”的模式来封装对大模型API的调用。关闭状态正常调用。打开状态当一段时间内如10秒失败率超时、服务不可用等超过阈值如50%断路器“跳闸”进入打开状态。此时所有新请求立即失败快速失败不再尝试调用不稳定的下游服务。半开状态断路器打开一段时间后如30秒会进入半开状态允许少量试探请求通过。如果试探成功则关闭断路器恢复常态如果失败则继续保持打开。这样当大模型服务出现区域性故障或自身负载极高时Agent服务能快速隔离故障避免线程池被占满、资源耗尽导致整个服务不可用。站会上经常听到“昨晚XX云的大模型服务波动我们的熔断器触发了好几次前端大部分请求都走了降级策略没出大乱子。”3. MCP观测看见AI的“思考过程”MCPModel Context Protocol是一个新兴的协议它允许外部工具如计算器、代码解释器、搜索引擎以一种标准化的方式被大模型调用。在这个律所项目里他们利用MCP协议让Agent可以调用内部的法律法规查询工具、案例检索工具甚至是一个简单的法律条款冲突检查工具。但引入MCP带来了新的挑战可观测性Observability。当Agent只是单纯问答时输入和输出是清晰的。但当Agent开始通过MCP调用各种工具时它的“思考过程”就变成了一个黑盒它为什么决定调用这个工具调用时传了什么参数工具返回了什么结果这个结果如何影响了最终的输出对于需要审计和追责的法律应用这是不可接受的。律师需要知道Agent给出的“根据《XX法》第Y条本条款无效”这个结论到底是检索了哪一年的法条具体是哪一款。3.1 构建MCP调用的全景观测因此他们投入了大量精力构建MCP的观测体系结构化日志每一次MCP工具调用都必须记录下完整的“轨迹Trace”。trace_id: 本次用户会话的唯一标识。tool_name: 被调用的工具名称如search_legal_clause。tool_input: 调用参数如{“law_name”: “劳动合同法”, “keyword”: “试用期”}。tool_output: 工具返回的原始结果。timestamp: 调用时间。duration: 调用耗时。链路追踪将一次用户问答中可能发生的多次LLM调用、多次RAG检索、多次MCP工具调用通过trace_id串联起来形成一个完整的“执行图谱”。这样任何一个最终答案都可以回溯到其所有的中间步骤和依据。指标监控监控每个MCP工具的成功率、平均响应时间、错误类型。例如发现calculate_damages计算损失赔偿工具最近错误率飙升可能是因为输入参数格式变了或者依赖的某个内部API挂了。3.2 观测数据驱动优化这些观测数据反过来成了优化Agent的宝贵资源。工具使用分析他们发现Agent在回答“合同审查”类问题时调用“条款冲突检查”工具的频率很低。经过分析不是不需要而是Prompt里没有明确指引Agent去调用。于是他们优化了系统Prompt加入了更明确的工具调用建议。错误根因分析当用户反馈一个答案不准确时他们可以通过trace_id快速定位。发现是RAG检索阶段某个关键词权重设置不合理导致召回了一篇过时的司法解释。于是去调整检索器的权重配置。成本与性能优化观测发现对于简单的定义查询Agent有时也会走一遍完整的RAGLLM流程耗时又费钱。他们据此引入了一个更轻量级的路由Router机制先通过一个快速的分类模型或规则判断问题类型如果是简单事实性问题直接走基于关键词的精准文档查找甚至缓存绕过重型RAG和LLM。站会上关于MCP的讨论常常是“昨天trace_idabc123的那个咨询Agent调了三次案例检索工具但最终答案却没引用最后一次检索到的最相关案例得查查是不是结果融合逻辑有问题。”4. 真实开发日常在确定性与不确定性之间走钢丝梳理下来你会发现这个律所AI Agent团队的日常充满了与“不确定性”的斗争数据的不确定性客户给的文档格式不确定、质量不确定。模型的不确定性大模型的输出有随机性偶尔会“幻觉”。服务的不确定性依赖的外部API、自身基础设施可能出问题。需求的不确定性律师们使用后会提出各种意想不到的用法和边界情况。而他们的工作就是用工程化的确定性手段去封装和约束这些不确定性。日常一数据运维与迭代。每天都有新文档入库需要跑预处理流水线监控解析错误率定期更新向量库索引。同时要根据律师们的反馈持续优化分块策略和检索算法。日常二监控与告警响应。盯着仪表盘大模型API的P99延迟是否突增R检索的召回率是否下降MCP工具调用失败率是否异常一旦告警立刻排查。日常三Prompt工程与测试。这可能是最像“AI”的工作但目的极其工程化如何设计System Prompt能让Agent更稳定地使用工具如何通过Few-shot示例减少错误格式的输出他们建立了庞大的测试用例库每次Prompt调整都必须通过回归测试。日常四流程与边界定义。和业务部门律师们开会明确哪些问题Agent可以自主回答哪些必须提示“建议咨询专业律师”哪些应该直接转人工工单。将这些边界规则写成代码里的判断逻辑。所以回到开头的问题真实的企业级AI Agent开发在忙什么他们忙的不是炫酷的算法而是管道、护栏、仪表盘和流程。是把那个能力强大但性格跳脱的“天才实习生”大模型训练成一个遵守流程、记录在案、有明确职责边界、且关键时刻知道求助的“可靠助理”。这个过程百分之八十是软件工程百分之十五是数据工程可能只有百分之五是纯粹的AI算法研究。如果你也想从“玩具”走向“工具”那么在你设计下一个Agent的架构时不妨先问问自己这四个问题我的数据管道足够健壮吗能处理各种脏数据、怪格式吗检索结果真的准吗我的服务有熔断和降级吗上游挂了我的系统会一起挂掉吗我能看见Agent的“思考过程”吗出现错误答案我能在5分钟内定位到是哪个环节出了问题吗我有清晰的边界和流程吗用户知道什么能问、什么不能问吗出了问题有兜底方案吗想清楚这些你的Agent项目才算真正上了路。