做企业级 AI 智能体和写一个 Python 脚本调大模型完全是两码事。脚本只要自己跑通就算成功但企业级意味着要面对多人使用、权限隔离、数据合规、高并发、可观测、可回滚甚至要能清楚解释它为什么这么回答。这个项目我从立项到灰度上线一共花了三个多月过程中切了 RAG、接上了 MCP、最终用多智能体架构做任务编排踩了不少坑也沉淀出来一套可以复用的工程化流程。这篇文章把整个交付过程拆开来讲从需求拆解到架构选型从 RAG 调优到 MCP 集成再到多智能体的协作调度最后落到可观测性和成本治理。适合正在从能跑迈向能交付的 AI 应用开发者也适合那些被老板一句话做个 AI 助手砸中、需要真正落地系统的技术负责人。项目背景先交代清楚目标是给企业内部做一个统一的智能助手覆盖知识问答、数据分析、工单处理三类核心场景。不是做一个通用聊天机器人而是要把散落在内部 Wiki、技术文档、客服话术库、运维工单里的信息打通同时还要能调用现有系统去查数据、操作流程。这意味着纯靠大模型记忆根本不可能必须接外部知识于是有了 RAG必须有工具调用的标准化通道于是选了 MCP而场景之间的复杂性又要求系统能自己拆解任务、分发给不同的专家模块于是上了多智能体架构。1. 整体架构设计与技术选型的底层逻辑1.1 为什么是 RAG MCP 多智能体的组合先想明白一个问题企业智能体真正难在哪不是模型回答问题能力不够而是它不懂你公司的内部情况。大模型训练时没见过你的 Wiki、你的工单格式、你的业务流程所以纯靠提示词的方案很快会碰到天花板。RAG 就是解决这个问题的把企业内部知识先做切片、向量化用户提问时先检索再生成让大模型基于检索到的材料来回答问题而不是靠猜测。那 MCP 又是干什么的企业的智能体不能只会说话还得会做事。比如查工单状态、创建审批、拉取报表数据这些动作需要调用内部系统接口。在没有统一标准之前每个系统都要单独写一套工具封装格式千奇百怪MCPModel Context Protocol相当于给工具调用定了一套标准协议模型通过统一的 MCP 客户端去连接各个 MCP Server每个 Server 暴露自己的工具能力这样新接一个系统就变成部署一个 MCP Server的活儿不用再改主流程代码。多智能体则是应对任务复杂度的。我一开始想用一个大模型 Prompt 包打天下结果发现知识问答、数据分析、工单处理三个场景的提示词和要求互相打架。你想要的回答风格不一样调用的工具不一样容错要求也不一样。硬揉在一起就变成一段几千字的巨型 Prompt改起来头痛调试更头痛。后来拆成三个子智能体各管一个场景再由一个主控智能体做意图识别和任务分发调度链路反而清晰了。1.2 总体架构的分层设计交付后的架构可以画成四层。最上层是接入层给企业微信、Web 门户、内部系统统一提供接口会话统一走同一个网关。往下是编排层多智能体协调器在这里做意图识别、任务拆分、结果合并这是全系统的大脑。再往下是能力层包括 RAG 引擎、工具调用模块以及三个场景子智能体。最底下是数据和基础设施层包括向量数据库、对象存储、日志系统、模型网关等。这个分层的核心好处是每一层都能独立扩展和替换。比如模型网关层今天用厂商 A 的模型明天想换厂商 B 的只需要改网关配置不需要动业务代码今天想把 RAG 的知识库从文档扩展为包含表格和图片也只需要在能力层做扩展编排层完全不受影响。这些事在单体 Prompt 方案里根本无法想象。选型方面还有几个具体决策。向量数据库用开源方案因为企业内部数据不能出内网。服务端框架选异步模型因为 RAG 检索和工具调用都有网络 I/O同步阻塞的模型在大并发下会浪费大量线程资源。模型层面则是大小模型混合意图识别走轻量模型生成回答走强模型子智能体里一些简单的抽取任务也分配给小模型成本和延迟能显著下降。1.3 选型的取舍与踩坑预判任何架构都是取舍的结果。选 MCP 而不是自己定义一套 JSON-RPC 工具协议是因为 MCP 已经形成社区生态官方 SDK 维护积极未来接第三方工具也方便。但 MCP 有个现实问题规范本身在快速演进不少版本之间的接口变动不兼容一旦锁定版本就不能随便升。多智能体方案也有代价最大的代价就是调试复杂度上升。原来一个 Prompt 出了问题改一段话就行现在可能是调度逻辑、子智能体 Prompt、工具返回解析这三个环节各自的问题。为了应对这个我一开始就定了严格的日志规范每次请求必须能串起从用户输入到主控决策、子智能体执行、工具调用、最终生成的全链路 trace否则出了问题根本没法查。我特意没有上全自动规划型多智能体框架比如让它自己随意调工具和自由规划所有步骤原因很简单企业内部场景最重要的是可控。自由规划能力强意味着不可预测性大生产环境出事代价很高。我宁可把流程拆成半固定模式主控只做意图分类和场景路由具体步骤由各子智能体按照自己的流程执行这样既保留智能化的调度能力又不至于失控。2. RAG 落地的关键工程细节2.1 文档接入与清洗最脏最累但决定上限的环节团队里有人一开始就想调 Embedding 模型和调参但我的经验是RAG 的上限由文档质量决定Embedding 模型只是帮忙保住这个上限。内部知识库里格式五花八门有散落十几个人的个人 Wiki、有导出成 PDF 的研发文档、有客服历史工单的 CSV、还有一堆从来没整理过的 Markdown 草稿。这些直接灌进向量库就是灾难。我的做法是先做了接入管线的分级处理。严格格式化的 Markdown 文档直接进入 ParserPDF 用文本抽取工具先转成纯文本再用规则把标题层级、列表结构还原成 Markdown历史工单这种结构化数据则走独立的字段拼接模板把工单标题、问题描述、解决方案、标签拼成一段语义连贯的文本之后再切片。清洗规则里有几条特别值得说。第一去重是硬需求同一份文档经常以不同名字存在于多个 Wiki 页面里我把标题归一化加上正文 MinHash 去重发现重复率有接近 20%。第二版权和敏感词过滤有些文档带涉密标记这必须从源头上切掉不能等到检索阶段再过滤。第三语言归一化内部文档里中英文混杂严重产品名有时候中文有时候英文我把这些术语做了统一映射否则检索的时候同一个意思的分词结果完全不同召回率很难看。2.2 切片策略chunk_size 和 overlap 的最优组合切片这事看起来简单实际上对效果影响非常大而且没有放之四海而皆准的参数。我试验过的组合从 256 token 到 1500 token 都跑过。最终线上用的方案是基础文档 800 token、overlap 100表格和代码块单独切片、不跨块合并FAQ 类短文本则逐条独立成片不切片。为什么是 800 而不是更大或者更小我拿内部的问答测试集跑过对比。512 token 的切片召回率不错但上下文太碎答出来的内容经常只有半截缺乏整体论述1200 token 的切片语义完整性好一些但检索噪声明显上升无关内容被带进来幻觉比例增加。800 是平衡点。overlap 取 100 是为了照顾那些跨越切片边界的长段落让边界信息在相邻切片里各出现一次匹配概率更高。还有一个细节切片要保留父子结构信息。我存的向量不是孤立的文本块而是带元数据标签的——它属于哪个文档、哪个一级标题、哪个二级标题、在文档中的顺序位置。这样检索召回之后可以做两件事按文档来源分组去重以及把命中的切片连同它的上层标题一起塞给生成模型。模型看到这段话归属于《某某系统操作手册》的权限配置章节回答时会更有上下文感也更容易带上引用来源。2.3 混合检索与重排序向量不是万能的只靠向量相似度做检索很快会碰到几个实际问题。一是精确术语匹配用户问SLB 健康检查失败向量可能把SLB扩写成负载均衡导致匹配到一堆不相关内容但关键词检索能精确命中。二是 ID 类和代码块检索类似错误码 50032这种向量空间里找得好不如直接字符串匹配准。所以线上实际跑的是混合检索向量召回 Top 50 关键词召回 Top 50合并去重之后再进重排序模型由重排序模型给出最终 Top 10。重排序这一步非常关键别省。向量检索的阶段只是找可能相关重排序才是精确挑最有用。我试过不加 reranker最终回答准确率大概下降八个百分点。新增的开销是重排序模型的一次推理大概几十毫秒在语义上换来的收益完全值。重排在实现上有个小技巧把新鲜度和文档权重作为分数因子和模型得分做加权融合。内部知识里操作手册类文档权重最高过期草稿权重调低同样的内容版本日期更近的排前面。这个加权逻辑很朴素但在企业知识库场景极其有效因为知识迭代速度决定了旧文档常常有误导性。2.4 RAG 评测没有测试集就是在裸奔RAG 系统上线前我做了一个 500 条问题的评测集覆盖三个子场景并且每一条都人工标注了标准答案来源和预期回答要点。这套评测集是整个项目的隐形基础设施。评测分两部分检索效果和生成效果。检索效果用 RecallK看正确答案来源是否出现在前 K 个召回结果里生成效果我不用复杂指标直接采用要点命中率 幻觉率的人工评估模板。每一轮改动之后跑一遍评测集对比这两个数字。数据是最有说服力的我自己引以为傲的一个切片参数优化上线前跑评测发现幻觉率上升了 2%差点带病上线。评测集需要持续维护。上线后我每周从真实用户反馈里抽 20 条典型的坏案例翻成评测用例补进去。三个月下来评测集从 500 条涨到 900 条系统的每个迭代都变得有据可依。3. MCP 层工具能力的标准化接入3.1 为什么不用内置函数而是引入 MCP最开始我也图省事直接在代码里写了一个查询工单状态的函数注册给模型调用。接一个两个还行等到第四个系统来找你接接口的时候就难受了每个系统的认证方式不一样、参数风格不一样、错误返回格式也不一样主服务的代码越来越臃肿而且加一个新工具需要发一次主服务版本这在企业环境里效率很低。引入 MCP 之后思路转变了。主服务只需要做一个 MCP Client剩下的全部按 MCP Server 的方式外挂出去。MCP Server 是一个独立进程内部自带认证逻辑、工具定义和调用实现。主服务通过标准协议发现这个 Server 提供了哪些工具、工具的参数 Schema 是什么然后只负责把模型的决定转发过去拿到结果再转回来。这个架构的直接好处是新增一个系统接入本质上是新写一个 MCP Server主服务代码一行都不用改。我接过的典型例子包括运维监控系统的告警查询工具、内部 CRM 系统的客户信息工具、甚至一个遗留老系统的只读数据接口。每个 Server 上线时做好注册测试环境联调通过后生产环境直接挂载。3.2 MCP Server 的工程实现要点每个 MCP Server 在实现上大致要做四件事定义工具清单、实现参数校验、实现调用逻辑、封装返回结果。工具清单是模型能看到的东西一定要写清楚描述。描述含糊的后果是模型不知道什么时候该用、传什么参数。我踩过的坑是在获取客户详情的工具描述里没写清楚仅接受客户编码不接受客户姓名模型就总把姓名直接传进来参数校验挂了才想起来做纠偏。后来规定所有工具描述必须包含功能、适用场景、参数格式示例、典型错误情况。写起来很啰嗦但真的能显著减少模型误调用。参数校验和错误返回这块要特别注意 MCP 的错误处理设计。工具执行失败时返回的不是一个中断信号而是一个错误结果仍然要回到模型手里。模型要能根据错误信息调整策略比如工具说参数不存在模型应该能转而去问用户要正确参数或者尝试另一种工具。所以 Server 返回错误的时候要尽量给模型可行动的反馈千万别只抛一句调用失败。我实现过的最复杂的一个 Server 是数据分析类的它提供的不只是查数据而是一条链路校验表名 - 查元数据 - 生成查询语句 - 执行查询 - 返回数据集摘要。每一步都可能出错所以错误分支非常多。但这正是在企业场景里做 Agent 的价值——工具够具体模型才能真正做有用的事。3.3 MCP 的安全与权限治理MCP 把工具调用标准化之后安全权限反而更好做了因为有了统一的拦截点。我在 MCP Client 层做了一个全局的工具权限表每个用户会话从认证系统拿到的身份信息会在调用工具时作为附加参数传入权限校验模块。校验通过才真正执行不通过则返回无权限的标准错误。这个看起来不起眼的层避免了 90% 的越权风险。还有一个同样重要的点是高危工具确认。企业内部有些工具是不可逆的比如删除数据、修改配置。我的方案是把它们标记为高危MCP Client 拦截这类工具的调用请求回复模型一句话该操作需要用户确认请先向用户展示具体操作内容并取得明确确认。要让模型去跟用户做二次确认而不是直接执行。这事做起来不复杂但很多团队忽略上线之后真的发生过一次模型误调用测试环境删除接口的事故还好拦截层兜住了。3.4 工具调用的观测与排查MCP 层的日志是最容易偷懒的地方但这恰恰是排查问题的金矿。每个工具调用的日志我要求至少包含这几项用户标识、会话 ID、调用的工具名、入参、出参、错误码、耗时。格式统一成 JSON 结构化日志直接进日志系统。有个实际的排查体验某天用户反馈智能体回答这个数据我查不到。查日志发现工具调用是成功的但模型因为返回结果太大直接截断后认为数据异常进而回答失败。如果没有结构化日志这种问题排查几乎只能靠猜。我后来的处理是给 MCP 返回结果加了体积上限和摘要机制超大结果自动做统计摘要再回传给模型。这类问题都在日志里看得清清楚楚。4. 多智能体的协作模式与任务编排4.1 从单体到多智能体怎么切而不乱从单体 Prompt 切到多智能体那段时间最大的阻力来自效果反复。单体虽然笨但改起来快多智能体切分的第一个版本效果反而下降了因为任务路由不准、上下文割裂。我的经验是不要一上来就设计一大堆智能体先把三个最核心的场景拆成三个子智能体主控只做分类不做复杂规划先跑通再迭代。三个子智能体的划分依据是场景的专业性知识问答子智能体专注于 RAG 检索和引用回答它的内部流程不涉及工具调用但要求回答结构严谨数据分析子智能体专注于写查询、调用数据工具、生成结论它对数据的正确性要求远高于话术的圆滑工单处理子智能体则专注于理解工单内容、查状态、推动流程它需要更主动地询问用户让信息补全。每个子智能体的系统提示词都围绕自己的场景来写里面包含检索指令、工具选择逻辑、回答格式约束、以及不知道就明说不编造的底线。这样每个 Prompt 都短小清晰容易调试和维护。4.2 Orchestrator-Workers 模式的具体实现我采用的是经典的 Orchestrator-Workers 模式主控智能体负责理解用户意图、选择路由、合并结果三个子智能体各司其职。没有采用更复杂的智能体之间自由对话原因在前面说过可控性优先。主控智能体的关键不是多聪明而是稳。它不需要自己回答任何业务问题只需要做意图分类。我把输入和输出都约束得很死输入是用户原始文本 上下文摘要输出是一个固定 JSON 结构包含场景路由结果问答 / 数据分析 / 工单 / 闲聊 / 无法分类、需要抽取的关键实体、以及一个简单的推理说明。用轻量模型跑就够成本和延迟都低。实际跑的过程中发现路由不准的典型场景是复合意图。用户问帮我查一下本月工单量趋势顺便说明当前有哪些高优故障——这既有数据分析又有知识问答。我的处理是允许主控输出多路由结果再拆成两个并行子任务分别执行最后在主控层做合并输出。合并时要有顺序逻辑一个明确的主报告另一个作为补充。否则模型会把两者揉在一起哪个都没说透。4.3 任务状态的共享与管理多智能体系统最容易被低估的问题是状态管理。我第一版直接在每个子智能体内部各自记录状态结果主控想要当前整个任务进行到哪一步的时候根本拿不到全局信息。重新整理后的方案是引入一个轻量级任务上下文对象。每次用户会话对应一个上下文里面包含会话基本信息、历史消息列表截断后的摘要、当前活跃路由、各子任务状态待执行 / 执行中 / 已完成 / 失败、工具调用历史。这个对象由编排层统一管理子智能体只能读取和写入自己负责的那一段。其实这就是把分布式系统里的状态集中管理思路用在了智能体编排里。这样做还有个额外好处断线重连的时候用户重新进入会话系统能把上下文读出来继续执行而不是让用户从头开始再讲一遍需求。这在企业办公场景里非常关键因为用户经常会问一个复杂问题然后开会去了半小时后回来说刚才那个继续。4.4 异常处理与兜底策略多智能体链路长了之后任何一个环节都可能出问题检索失败、工具超时、子智能体生成格式错误、甚至大模型 API 超时。之前单体方案里一个环节出问题影响面可控多智能体里如果异常不兜底用户感受到的就是这个 AI 又抽风了。我做了三层兜底。第一层是超时控制子智能体的每个环节都有超时时间比如 RAG 检索 5 秒、工具调用 15 秒超时就直接标记该子任务失败不等它。第二层是降级策略如果数据分析子智能体失败降级成直接调用知识问答子智能体让它基于检索到的历史报表文档做一个文字性说明至少给用户一个非空的回答。第三层是显式兜底所有失败都会在主控层汇总成一句诚实的说明比如数据分析模块暂时不可用这是根据历史文档整理的相关内容不允许系统假装成功。这些策略合在一起系统上线后可用性从第一周的 90% 提升到了 99% 以上。异常兜底的价值在真实生产里比任何花哨的模型效果优化都更显著。5. 从 Demo 到交付生产环境不可回避的工程问题5.1 可观测性给智能体装上仪表盘很多 AI 项目在 Demo 阶段跑得飞起一上生产就抓瞎核心原因就是看不见。传统接口只要看状态码和耗时就行但智能体的回答质量、工具选择是否合理、检索是否命中关键信息这些都没有标准状态码可看。我做了一套完整的可观测体系分三个层次。技术指标层请求量、延迟分布、Token 消耗、缓存命中率、工具调用成功率这些用标准监控就能搞定。业务指标层各子场景使用占比、RAG 命中率、工具误调用率、用户点赞点踩比例、会话平均轮数这些是评估系统真实价值的核心。链路追踪层所有环节的事件都带 trace_id 串联打开链路面板能看到一次回答的完整生命历程。链路追踪层的价值上线第二天就体现出来了。用户反馈有次回答特别慢我点开链路一看发现模型在第一轮意图识别阶段就反复调用了一个本不该用的工具白白浪费了十几秒。如果没有链路追踪这种问题根本定位不了。5.2 会话管理与上下文工程企业级智能体的会话不是聊完就走的。用户可能一周后回来继续上周的话题也可能在一个会话里穿插提问不同场景的问题。我的处理是三层会话结构持久会话 ID、时间衰减的上下文摘要、长期用户画像。持久会话 ID 每次都一样用于跨天追踪上下文摘要是对前文对话的压缩摘要超过一定轮数就触发一次摘要重写避免把全部历史消息塞给模型用户画像则记录用户高频关注的主题和常用工具用于个性化输出。上下文工程里有个经验不要把原始对话历史一股脑全塞进模型上下文那不仅浪费 Token而且噪声太大。我实际测过超过十轮对话后摘要上下文的效果系统性超过完整历史。5.3 安全、权限与合规红线企业级智能体最大的红线是数据安全。我把整个系统的数据流分成两类一类走内网隔离包含所有知识库检索和工具调用一类走模型网关只把必要的文本片段发送给模型服务。敏感信息过滤层放在模型网关前面对出站的每一条消息做规则检测命中敏感词的文本会自动脱敏。用户权限隔离是另一条必须做死的线。两个人用同一个智能体问同一个问题得到的结果可能必须不同因为员工 A 有权限看某系统的数据员工 B 没有。我把权限逻辑同时压在三个地方RAG 检索阶段按用户角色过滤文档源、MCP 工具调用阶段做操作级鉴权、生成阶段再校验回答中引用的内容是否有权限。三层都过才能回给用户。这个设计的坏处是稍微复杂了一点好处是基本杜绝了越权回答。5.4 成本控制Token 不是无限量的企业里做 AI 项目老板一定会问一年要花多少钱。Token 成本必须从一开始就纳入设计。我做的主要优化有三类。响应缓存高频问题比如怎么提交报销的检索结果和回答结果直接缓存用户再问的时候不走模型直接从缓存返回。这大概省了 15% 的 Token。语义缓存更进一步不只是文本完全匹配的缓存而是通过嵌入向量相似度判断问题语义相同命中就直接复用上次答案这又覆盖了很多换个说法重问的场景。模型分级是成本控制的另一大头。意图识别、实体抽取这类简单任务走小模型只有最终生成回答才走强模型。我还做了一个模型路由模块根据问题的复杂度动态决定是否调用强模型简单问题用中档模型回答复杂问题才升级到强模型。实际跑下来Token 成本降低了差不多四成而且用户几乎感知不到差别。6. 团队协作与项目管理经验6.1 模块划分决定协作效率智能体项目的前期大家特别容易陷入各调各的 Prompt各测各的效果的混沌状态。后来我把项目按能力和接口严格划分一个人负责 RAG 管线一个人负责 MCP Server 开发一个人负责编排层逻辑一个人负责评测集管理与质量评估。每人都有一个明确的对外接口和效果评判标准。这个划分让并行开发效率显著提升。RAG 管线的改动不会阻塞 MCP Server 开发因为接口早就定好了编排层的逻辑调整只需要依赖评测集跑回归不用每次都找所有人来开会评审效果。6.2 评测驱动的开发方式之前做 AI 项目习惯改完看几条效果感觉行就上。但这个项目的教训告诉我没有评测集多智能体的每轮改动都是在赌。我把评测集跑分作为代码合并的前置条件每个新改动必须在评测集上达到不低于旧版本的效果分数才能合并。一开始团队觉得繁琐后来发现有效——很多自以为在优化的改动跑分一看反而下降省了大量线上回滚的麻烦。评测集的质量比数量重要。500 条质量高的、覆盖边界情况的用例比 2000 条堆数量的用例更有价值。我定期从真实用户反馈里挑坏案例加进去让评测集和真实场景保持同步演化。6.3 灰度发布与快速回滚通道企业级系统不能全量上线再等反馈必须有灰度机制。我的做法是把用户按部门维度分批放开第一批是内部测试团队 20 人第二批是试点部门 200 人第三批才全量。每一批都收集反馈、观测指标、处理问题之后才放开下一批。灰度期间最有用的工具是一键回滚开关把模型请求的流量分成两组默认走新版配置开关一拉就全量切回旧版。这个开关的显著价值在于反馈变差时可以立刻回滚到稳定版本然后慢慢排查问题不用把用户晾在一个坏版本上受罪。7. 常见问题速查与避坑清单7.1 高频问题排查实录从上线到现在我整理了一张常见问题表特别适合那些刚开始做企业级智能体的团队对照排查。问题现象根本原因解决方案回答不准确且引用混乱切片太大导致检索噪声调小 chunk_size加强 reranker工具频繁误调用工具描述不清晰、无场景说明重写工具描述加入参数示例回答超时严重链路串行调用太多并行化独立子任务加缓存用户反馈你回答得太泛了没有检索到关键文档检查文档接入覆盖率和切片粒度相同问题回答不稳定模型温度和 top_p 设置过高降低 temperature启用固定种子新系统接入周期长没有标准化 MCP 封装流程建立 MCP Server 模板复用认证和日志7.2 我踩过的几个大坑第一个坑是低估了文档清洗的工作量。最开始以为知识库接入就是个数据导入的事结果文档格式混乱、命名不一致、敏感内容混在一起的现实让 RAG 效果迟迟上不去。后来单独排了两周专门做数据治理效果才质变。第二个坑是想在一开始就把通用智能体做好。目标是做成什么都能问的超级助手结果什么都做不好。后来痛定思痛砍到三个核心场景重点突破先把每个场景的准确率做到合格再横向扩展。第三个坑是忽视了模型会变这件事。开发期间用的模型版本上线前厂商更新了版本回答风格和工具调用格式习惯都变了一些。后来我固化模型版本并把模型升级作为一次完整的上线变更来做不再偷偷升。7.3 给后来者的几点实操建议如果你现在正要启动一个企业级智能体项目我的建议是说简单也简单、说难也难的几条。第一先建评测集再写代码。哪怕只有 50 条用例也能在关键时刻拦住你走向错误的方向。第二宁可聪明地少做不要愚蠢地求全。把场景收窄到你能在这个迭代内做到 90 分的范围比摊子铺得很大但什么都 70 分强得多。第三全链路日志从第一天就做好否则出了问题你只能对着黑盒祈祷。第四不要被新框架带着走。MCP 再火、多智能体再热如果和你的场景不匹配就不要硬上。架构永远服务于业务。从 0 到 1 交付一个企业级 AI 智能体技术只是其中一半。另一半是工程化思维设计可观测的链路、建立可回归的评测、明确可控制的灰度策略、沉淀可复用的工具接入规范。这些看起来不那么性感却决定了系统能走多远。每个新场景接入时我会先问三个问题知识源在哪、需要调什么工具、谁来为结果负责。想清楚这三件事剩下的基本都是工程执行的问题了。如果你正在做类似的项目希望这篇拆解能帮你少走几步弯路。 
长河君 · 2026/10/17 12:57:22 · 阅读 1.2k 企业级AI智能体交付实战：RAG、MCP与多智能体架构拆解
做企业级 AI 智能体和写一个 Python 脚本调大模型完全是两码事。脚本只要自己跑通就算成功但企业级意味着要面对多人使用、权限隔离、数据合规、高并发、可观测、可回滚甚至要能清楚解释它为什么这么回答。这个项目我从立项到灰度上线一共花了三个多月过程中切了 RAG、接上了 MCP、最终用多智能体架构做任务编排踩了不少坑也沉淀出来一套可以复用的工程化流程。这篇文章把整个交付过程拆开来讲从需求拆解到架构选型从 RAG 调优到 MCP 集成再到多智能体的协作调度最后落到可观测性和成本治理。适合正在从能跑迈向能交付的 AI 应用开发者也适合那些被老板一句话做个 AI 助手砸中、需要真正落地系统的技术负责人。项目背景先交代清楚目标是给企业内部做一个统一的智能助手覆盖知识问答、数据分析、工单处理三类核心场景。不是做一个通用聊天机器人而是要把散落在内部 Wiki、技术文档、客服话术库、运维工单里的信息打通同时还要能调用现有系统去查数据、操作流程。这意味着纯靠大模型记忆根本不可能必须接外部知识于是有了 RAG必须有工具调用的标准化通道于是选了 MCP而场景之间的复杂性又要求系统能自己拆解任务、分发给不同的专家模块于是上了多智能体架构。1. 整体架构设计与技术选型的底层逻辑1.1 为什么是 RAG MCP 多智能体的组合先想明白一个问题企业智能体真正难在哪不是模型回答问题能力不够而是它不懂你公司的内部情况。大模型训练时没见过你的 Wiki、你的工单格式、你的业务流程所以纯靠提示词的方案很快会碰到天花板。RAG 就是解决这个问题的把企业内部知识先做切片、向量化用户提问时先检索再生成让大模型基于检索到的材料来回答问题而不是靠猜测。那 MCP 又是干什么的企业的智能体不能只会说话还得会做事。比如查工单状态、创建审批、拉取报表数据这些动作需要调用内部系统接口。在没有统一标准之前每个系统都要单独写一套工具封装格式千奇百怪MCPModel Context Protocol相当于给工具调用定了一套标准协议模型通过统一的 MCP 客户端去连接各个 MCP Server每个 Server 暴露自己的工具能力这样新接一个系统就变成部署一个 MCP Server的活儿不用再改主流程代码。多智能体则是应对任务复杂度的。我一开始想用一个大模型 Prompt 包打天下结果发现知识问答、数据分析、工单处理三个场景的提示词和要求互相打架。你想要的回答风格不一样调用的工具不一样容错要求也不一样。硬揉在一起就变成一段几千字的巨型 Prompt改起来头痛调试更头痛。后来拆成三个子智能体各管一个场景再由一个主控智能体做意图识别和任务分发调度链路反而清晰了。1.2 总体架构的分层设计交付后的架构可以画成四层。最上层是接入层给企业微信、Web 门户、内部系统统一提供接口会话统一走同一个网关。往下是编排层多智能体协调器在这里做意图识别、任务拆分、结果合并这是全系统的大脑。再往下是能力层包括 RAG 引擎、工具调用模块以及三个场景子智能体。最底下是数据和基础设施层包括向量数据库、对象存储、日志系统、模型网关等。这个分层的核心好处是每一层都能独立扩展和替换。比如模型网关层今天用厂商 A 的模型明天想换厂商 B 的只需要改网关配置不需要动业务代码今天想把 RAG 的知识库从文档扩展为包含表格和图片也只需要在能力层做扩展编排层完全不受影响。这些事在单体 Prompt 方案里根本无法想象。选型方面还有几个具体决策。向量数据库用开源方案因为企业内部数据不能出内网。服务端框架选异步模型因为 RAG 检索和工具调用都有网络 I/O同步阻塞的模型在大并发下会浪费大量线程资源。模型层面则是大小模型混合意图识别走轻量模型生成回答走强模型子智能体里一些简单的抽取任务也分配给小模型成本和延迟能显著下降。1.3 选型的取舍与踩坑预判任何架构都是取舍的结果。选 MCP 而不是自己定义一套 JSON-RPC 工具协议是因为 MCP 已经形成社区生态官方 SDK 维护积极未来接第三方工具也方便。但 MCP 有个现实问题规范本身在快速演进不少版本之间的接口变动不兼容一旦锁定版本就不能随便升。多智能体方案也有代价最大的代价就是调试复杂度上升。原来一个 Prompt 出了问题改一段话就行现在可能是调度逻辑、子智能体 Prompt、工具返回解析这三个环节各自的问题。为了应对这个我一开始就定了严格的日志规范每次请求必须能串起从用户输入到主控决策、子智能体执行、工具调用、最终生成的全链路 trace否则出了问题根本没法查。我特意没有上全自动规划型多智能体框架比如让它自己随意调工具和自由规划所有步骤原因很简单企业内部场景最重要的是可控。自由规划能力强意味着不可预测性大生产环境出事代价很高。我宁可把流程拆成半固定模式主控只做意图分类和场景路由具体步骤由各子智能体按照自己的流程执行这样既保留智能化的调度能力又不至于失控。2. RAG 落地的关键工程细节2.1 文档接入与清洗最脏最累但决定上限的环节团队里有人一开始就想调 Embedding 模型和调参但我的经验是RAG 的上限由文档质量决定Embedding 模型只是帮忙保住这个上限。内部知识库里格式五花八门有散落十几个人的个人 Wiki、有导出成 PDF 的研发文档、有客服历史工单的 CSV、还有一堆从来没整理过的 Markdown 草稿。这些直接灌进向量库就是灾难。我的做法是先做了接入管线的分级处理。严格格式化的 Markdown 文档直接进入 ParserPDF 用文本抽取工具先转成纯文本再用规则把标题层级、列表结构还原成 Markdown历史工单这种结构化数据则走独立的字段拼接模板把工单标题、问题描述、解决方案、标签拼成一段语义连贯的文本之后再切片。清洗规则里有几条特别值得说。第一去重是硬需求同一份文档经常以不同名字存在于多个 Wiki 页面里我把标题归一化加上正文 MinHash 去重发现重复率有接近 20%。第二版权和敏感词过滤有些文档带涉密标记这必须从源头上切掉不能等到检索阶段再过滤。第三语言归一化内部文档里中英文混杂严重产品名有时候中文有时候英文我把这些术语做了统一映射否则检索的时候同一个意思的分词结果完全不同召回率很难看。2.2 切片策略chunk_size 和 overlap 的最优组合切片这事看起来简单实际上对效果影响非常大而且没有放之四海而皆准的参数。我试验过的组合从 256 token 到 1500 token 都跑过。最终线上用的方案是基础文档 800 token、overlap 100表格和代码块单独切片、不跨块合并FAQ 类短文本则逐条独立成片不切片。为什么是 800 而不是更大或者更小我拿内部的问答测试集跑过对比。512 token 的切片召回率不错但上下文太碎答出来的内容经常只有半截缺乏整体论述1200 token 的切片语义完整性好一些但检索噪声明显上升无关内容被带进来幻觉比例增加。800 是平衡点。overlap 取 100 是为了照顾那些跨越切片边界的长段落让边界信息在相邻切片里各出现一次匹配概率更高。还有一个细节切片要保留父子结构信息。我存的向量不是孤立的文本块而是带元数据标签的——它属于哪个文档、哪个一级标题、哪个二级标题、在文档中的顺序位置。这样检索召回之后可以做两件事按文档来源分组去重以及把命中的切片连同它的上层标题一起塞给生成模型。模型看到这段话归属于《某某系统操作手册》的权限配置章节回答时会更有上下文感也更容易带上引用来源。2.3 混合检索与重排序向量不是万能的只靠向量相似度做检索很快会碰到几个实际问题。一是精确术语匹配用户问SLB 健康检查失败向量可能把SLB扩写成负载均衡导致匹配到一堆不相关内容但关键词检索能精确命中。二是 ID 类和代码块检索类似错误码 50032这种向量空间里找得好不如直接字符串匹配准。所以线上实际跑的是混合检索向量召回 Top 50 关键词召回 Top 50合并去重之后再进重排序模型由重排序模型给出最终 Top 10。重排序这一步非常关键别省。向量检索的阶段只是找可能相关重排序才是精确挑最有用。我试过不加 reranker最终回答准确率大概下降八个百分点。新增的开销是重排序模型的一次推理大概几十毫秒在语义上换来的收益完全值。重排在实现上有个小技巧把新鲜度和文档权重作为分数因子和模型得分做加权融合。内部知识里操作手册类文档权重最高过期草稿权重调低同样的内容版本日期更近的排前面。这个加权逻辑很朴素但在企业知识库场景极其有效因为知识迭代速度决定了旧文档常常有误导性。2.4 RAG 评测没有测试集就是在裸奔RAG 系统上线前我做了一个 500 条问题的评测集覆盖三个子场景并且每一条都人工标注了标准答案来源和预期回答要点。这套评测集是整个项目的隐形基础设施。评测分两部分检索效果和生成效果。检索效果用 RecallK看正确答案来源是否出现在前 K 个召回结果里生成效果我不用复杂指标直接采用要点命中率 幻觉率的人工评估模板。每一轮改动之后跑一遍评测集对比这两个数字。数据是最有说服力的我自己引以为傲的一个切片参数优化上线前跑评测发现幻觉率上升了 2%差点带病上线。评测集需要持续维护。上线后我每周从真实用户反馈里抽 20 条典型的坏案例翻成评测用例补进去。三个月下来评测集从 500 条涨到 900 条系统的每个迭代都变得有据可依。3. MCP 层工具能力的标准化接入3.1 为什么不用内置函数而是引入 MCP最开始我也图省事直接在代码里写了一个查询工单状态的函数注册给模型调用。接一个两个还行等到第四个系统来找你接接口的时候就难受了每个系统的认证方式不一样、参数风格不一样、错误返回格式也不一样主服务的代码越来越臃肿而且加一个新工具需要发一次主服务版本这在企业环境里效率很低。引入 MCP 之后思路转变了。主服务只需要做一个 MCP Client剩下的全部按 MCP Server 的方式外挂出去。MCP Server 是一个独立进程内部自带认证逻辑、工具定义和调用实现。主服务通过标准协议发现这个 Server 提供了哪些工具、工具的参数 Schema 是什么然后只负责把模型的决定转发过去拿到结果再转回来。这个架构的直接好处是新增一个系统接入本质上是新写一个 MCP Server主服务代码一行都不用改。我接过的典型例子包括运维监控系统的告警查询工具、内部 CRM 系统的客户信息工具、甚至一个遗留老系统的只读数据接口。每个 Server 上线时做好注册测试环境联调通过后生产环境直接挂载。3.2 MCP Server 的工程实现要点每个 MCP Server 在实现上大致要做四件事定义工具清单、实现参数校验、实现调用逻辑、封装返回结果。工具清单是模型能看到的东西一定要写清楚描述。描述含糊的后果是模型不知道什么时候该用、传什么参数。我踩过的坑是在获取客户详情的工具描述里没写清楚仅接受客户编码不接受客户姓名模型就总把姓名直接传进来参数校验挂了才想起来做纠偏。后来规定所有工具描述必须包含功能、适用场景、参数格式示例、典型错误情况。写起来很啰嗦但真的能显著减少模型误调用。参数校验和错误返回这块要特别注意 MCP 的错误处理设计。工具执行失败时返回的不是一个中断信号而是一个错误结果仍然要回到模型手里。模型要能根据错误信息调整策略比如工具说参数不存在模型应该能转而去问用户要正确参数或者尝试另一种工具。所以 Server 返回错误的时候要尽量给模型可行动的反馈千万别只抛一句调用失败。我实现过的最复杂的一个 Server 是数据分析类的它提供的不只是查数据而是一条链路校验表名 - 查元数据 - 生成查询语句 - 执行查询 - 返回数据集摘要。每一步都可能出错所以错误分支非常多。但这正是在企业场景里做 Agent 的价值——工具够具体模型才能真正做有用的事。3.3 MCP 的安全与权限治理MCP 把工具调用标准化之后安全权限反而更好做了因为有了统一的拦截点。我在 MCP Client 层做了一个全局的工具权限表每个用户会话从认证系统拿到的身份信息会在调用工具时作为附加参数传入权限校验模块。校验通过才真正执行不通过则返回无权限的标准错误。这个看起来不起眼的层避免了 90% 的越权风险。还有一个同样重要的点是高危工具确认。企业内部有些工具是不可逆的比如删除数据、修改配置。我的方案是把它们标记为高危MCP Client 拦截这类工具的调用请求回复模型一句话该操作需要用户确认请先向用户展示具体操作内容并取得明确确认。要让模型去跟用户做二次确认而不是直接执行。这事做起来不复杂但很多团队忽略上线之后真的发生过一次模型误调用测试环境删除接口的事故还好拦截层兜住了。3.4 工具调用的观测与排查MCP 层的日志是最容易偷懒的地方但这恰恰是排查问题的金矿。每个工具调用的日志我要求至少包含这几项用户标识、会话 ID、调用的工具名、入参、出参、错误码、耗时。格式统一成 JSON 结构化日志直接进日志系统。有个实际的排查体验某天用户反馈智能体回答这个数据我查不到。查日志发现工具调用是成功的但模型因为返回结果太大直接截断后认为数据异常进而回答失败。如果没有结构化日志这种问题排查几乎只能靠猜。我后来的处理是给 MCP 返回结果加了体积上限和摘要机制超大结果自动做统计摘要再回传给模型。这类问题都在日志里看得清清楚楚。4. 多智能体的协作模式与任务编排4.1 从单体到多智能体怎么切而不乱从单体 Prompt 切到多智能体那段时间最大的阻力来自效果反复。单体虽然笨但改起来快多智能体切分的第一个版本效果反而下降了因为任务路由不准、上下文割裂。我的经验是不要一上来就设计一大堆智能体先把三个最核心的场景拆成三个子智能体主控只做分类不做复杂规划先跑通再迭代。三个子智能体的划分依据是场景的专业性知识问答子智能体专注于 RAG 检索和引用回答它的内部流程不涉及工具调用但要求回答结构严谨数据分析子智能体专注于写查询、调用数据工具、生成结论它对数据的正确性要求远高于话术的圆滑工单处理子智能体则专注于理解工单内容、查状态、推动流程它需要更主动地询问用户让信息补全。每个子智能体的系统提示词都围绕自己的场景来写里面包含检索指令、工具选择逻辑、回答格式约束、以及不知道就明说不编造的底线。这样每个 Prompt 都短小清晰容易调试和维护。4.2 Orchestrator-Workers 模式的具体实现我采用的是经典的 Orchestrator-Workers 模式主控智能体负责理解用户意图、选择路由、合并结果三个子智能体各司其职。没有采用更复杂的智能体之间自由对话原因在前面说过可控性优先。主控智能体的关键不是多聪明而是稳。它不需要自己回答任何业务问题只需要做意图分类。我把输入和输出都约束得很死输入是用户原始文本 上下文摘要输出是一个固定 JSON 结构包含场景路由结果问答 / 数据分析 / 工单 / 闲聊 / 无法分类、需要抽取的关键实体、以及一个简单的推理说明。用轻量模型跑就够成本和延迟都低。实际跑的过程中发现路由不准的典型场景是复合意图。用户问帮我查一下本月工单量趋势顺便说明当前有哪些高优故障——这既有数据分析又有知识问答。我的处理是允许主控输出多路由结果再拆成两个并行子任务分别执行最后在主控层做合并输出。合并时要有顺序逻辑一个明确的主报告另一个作为补充。否则模型会把两者揉在一起哪个都没说透。4.3 任务状态的共享与管理多智能体系统最容易被低估的问题是状态管理。我第一版直接在每个子智能体内部各自记录状态结果主控想要当前整个任务进行到哪一步的时候根本拿不到全局信息。重新整理后的方案是引入一个轻量级任务上下文对象。每次用户会话对应一个上下文里面包含会话基本信息、历史消息列表截断后的摘要、当前活跃路由、各子任务状态待执行 / 执行中 / 已完成 / 失败、工具调用历史。这个对象由编排层统一管理子智能体只能读取和写入自己负责的那一段。其实这就是把分布式系统里的状态集中管理思路用在了智能体编排里。这样做还有个额外好处断线重连的时候用户重新进入会话系统能把上下文读出来继续执行而不是让用户从头开始再讲一遍需求。这在企业办公场景里非常关键因为用户经常会问一个复杂问题然后开会去了半小时后回来说刚才那个继续。4.4 异常处理与兜底策略多智能体链路长了之后任何一个环节都可能出问题检索失败、工具超时、子智能体生成格式错误、甚至大模型 API 超时。之前单体方案里一个环节出问题影响面可控多智能体里如果异常不兜底用户感受到的就是这个 AI 又抽风了。我做了三层兜底。第一层是超时控制子智能体的每个环节都有超时时间比如 RAG 检索 5 秒、工具调用 15 秒超时就直接标记该子任务失败不等它。第二层是降级策略如果数据分析子智能体失败降级成直接调用知识问答子智能体让它基于检索到的历史报表文档做一个文字性说明至少给用户一个非空的回答。第三层是显式兜底所有失败都会在主控层汇总成一句诚实的说明比如数据分析模块暂时不可用这是根据历史文档整理的相关内容不允许系统假装成功。这些策略合在一起系统上线后可用性从第一周的 90% 提升到了 99% 以上。异常兜底的价值在真实生产里比任何花哨的模型效果优化都更显著。5. 从 Demo 到交付生产环境不可回避的工程问题5.1 可观测性给智能体装上仪表盘很多 AI 项目在 Demo 阶段跑得飞起一上生产就抓瞎核心原因就是看不见。传统接口只要看状态码和耗时就行但智能体的回答质量、工具选择是否合理、检索是否命中关键信息这些都没有标准状态码可看。我做了一套完整的可观测体系分三个层次。技术指标层请求量、延迟分布、Token 消耗、缓存命中率、工具调用成功率这些用标准监控就能搞定。业务指标层各子场景使用占比、RAG 命中率、工具误调用率、用户点赞点踩比例、会话平均轮数这些是评估系统真实价值的核心。链路追踪层所有环节的事件都带 trace_id 串联打开链路面板能看到一次回答的完整生命历程。链路追踪层的价值上线第二天就体现出来了。用户反馈有次回答特别慢我点开链路一看发现模型在第一轮意图识别阶段就反复调用了一个本不该用的工具白白浪费了十几秒。如果没有链路追踪这种问题根本定位不了。5.2 会话管理与上下文工程企业级智能体的会话不是聊完就走的。用户可能一周后回来继续上周的话题也可能在一个会话里穿插提问不同场景的问题。我的处理是三层会话结构持久会话 ID、时间衰减的上下文摘要、长期用户画像。持久会话 ID 每次都一样用于跨天追踪上下文摘要是对前文对话的压缩摘要超过一定轮数就触发一次摘要重写避免把全部历史消息塞给模型用户画像则记录用户高频关注的主题和常用工具用于个性化输出。上下文工程里有个经验不要把原始对话历史一股脑全塞进模型上下文那不仅浪费 Token而且噪声太大。我实际测过超过十轮对话后摘要上下文的效果系统性超过完整历史。5.3 安全、权限与合规红线企业级智能体最大的红线是数据安全。我把整个系统的数据流分成两类一类走内网隔离包含所有知识库检索和工具调用一类走模型网关只把必要的文本片段发送给模型服务。敏感信息过滤层放在模型网关前面对出站的每一条消息做规则检测命中敏感词的文本会自动脱敏。用户权限隔离是另一条必须做死的线。两个人用同一个智能体问同一个问题得到的结果可能必须不同因为员工 A 有权限看某系统的数据员工 B 没有。我把权限逻辑同时压在三个地方RAG 检索阶段按用户角色过滤文档源、MCP 工具调用阶段做操作级鉴权、生成阶段再校验回答中引用的内容是否有权限。三层都过才能回给用户。这个设计的坏处是稍微复杂了一点好处是基本杜绝了越权回答。5.4 成本控制Token 不是无限量的企业里做 AI 项目老板一定会问一年要花多少钱。Token 成本必须从一开始就纳入设计。我做的主要优化有三类。响应缓存高频问题比如怎么提交报销的检索结果和回答结果直接缓存用户再问的时候不走模型直接从缓存返回。这大概省了 15% 的 Token。语义缓存更进一步不只是文本完全匹配的缓存而是通过嵌入向量相似度判断问题语义相同命中就直接复用上次答案这又覆盖了很多换个说法重问的场景。模型分级是成本控制的另一大头。意图识别、实体抽取这类简单任务走小模型只有最终生成回答才走强模型。我还做了一个模型路由模块根据问题的复杂度动态决定是否调用强模型简单问题用中档模型回答复杂问题才升级到强模型。实际跑下来Token 成本降低了差不多四成而且用户几乎感知不到差别。6. 团队协作与项目管理经验6.1 模块划分决定协作效率智能体项目的前期大家特别容易陷入各调各的 Prompt各测各的效果的混沌状态。后来我把项目按能力和接口严格划分一个人负责 RAG 管线一个人负责 MCP Server 开发一个人负责编排层逻辑一个人负责评测集管理与质量评估。每人都有一个明确的对外接口和效果评判标准。这个划分让并行开发效率显著提升。RAG 管线的改动不会阻塞 MCP Server 开发因为接口早就定好了编排层的逻辑调整只需要依赖评测集跑回归不用每次都找所有人来开会评审效果。6.2 评测驱动的开发方式之前做 AI 项目习惯改完看几条效果感觉行就上。但这个项目的教训告诉我没有评测集多智能体的每轮改动都是在赌。我把评测集跑分作为代码合并的前置条件每个新改动必须在评测集上达到不低于旧版本的效果分数才能合并。一开始团队觉得繁琐后来发现有效——很多自以为在优化的改动跑分一看反而下降省了大量线上回滚的麻烦。评测集的质量比数量重要。500 条质量高的、覆盖边界情况的用例比 2000 条堆数量的用例更有价值。我定期从真实用户反馈里挑坏案例加进去让评测集和真实场景保持同步演化。6.3 灰度发布与快速回滚通道企业级系统不能全量上线再等反馈必须有灰度机制。我的做法是把用户按部门维度分批放开第一批是内部测试团队 20 人第二批是试点部门 200 人第三批才全量。每一批都收集反馈、观测指标、处理问题之后才放开下一批。灰度期间最有用的工具是一键回滚开关把模型请求的流量分成两组默认走新版配置开关一拉就全量切回旧版。这个开关的显著价值在于反馈变差时可以立刻回滚到稳定版本然后慢慢排查问题不用把用户晾在一个坏版本上受罪。7. 常见问题速查与避坑清单7.1 高频问题排查实录从上线到现在我整理了一张常见问题表特别适合那些刚开始做企业级智能体的团队对照排查。问题现象根本原因解决方案回答不准确且引用混乱切片太大导致检索噪声调小 chunk_size加强 reranker工具频繁误调用工具描述不清晰、无场景说明重写工具描述加入参数示例回答超时严重链路串行调用太多并行化独立子任务加缓存用户反馈你回答得太泛了没有检索到关键文档检查文档接入覆盖率和切片粒度相同问题回答不稳定模型温度和 top_p 设置过高降低 temperature启用固定种子新系统接入周期长没有标准化 MCP 封装流程建立 MCP Server 模板复用认证和日志7.2 我踩过的几个大坑第一个坑是低估了文档清洗的工作量。最开始以为知识库接入就是个数据导入的事结果文档格式混乱、命名不一致、敏感内容混在一起的现实让 RAG 效果迟迟上不去。后来单独排了两周专门做数据治理效果才质变。第二个坑是想在一开始就把通用智能体做好。目标是做成什么都能问的超级助手结果什么都做不好。后来痛定思痛砍到三个核心场景重点突破先把每个场景的准确率做到合格再横向扩展。第三个坑是忽视了模型会变这件事。开发期间用的模型版本上线前厂商更新了版本回答风格和工具调用格式习惯都变了一些。后来我固化模型版本并把模型升级作为一次完整的上线变更来做不再偷偷升。7.3 给后来者的几点实操建议如果你现在正要启动一个企业级智能体项目我的建议是说简单也简单、说难也难的几条。第一先建评测集再写代码。哪怕只有 50 条用例也能在关键时刻拦住你走向错误的方向。第二宁可聪明地少做不要愚蠢地求全。把场景收窄到你能在这个迭代内做到 90 分的范围比摊子铺得很大但什么都 70 分强得多。第三全链路日志从第一天就做好否则出了问题你只能对着黑盒祈祷。第四不要被新框架带着走。MCP 再火、多智能体再热如果和你的场景不匹配就不要硬上。架构永远服务于业务。从 0 到 1 交付一个企业级 AI 智能体技术只是其中一半。另一半是工程化思维设计可观测的链路、建立可回归的评测、明确可控制的灰度策略、沉淀可复用的工具接入规范。这些看起来不那么性感却决定了系统能走多远。每个新场景接入时我会先问三个问题知识源在哪、需要调什么工具、谁来为结果负责。想清楚这三件事剩下的基本都是工程执行的问题了。如果你正在做类似的项目希望这篇拆解能帮你少走几步弯路。