1. 多智能体AI架构：不是“多个模型拼在一起”那么简单

你可能已经见过这样的场景：一个客服系统里，有负责理解用户问题的模块、有调用知识库检索答案的模块、有检查回复是否合规的模块、还有专门优化语言表达的润色模块——它们各自运行，又彼此协作，最终输出一条自然、准确、合规的回复。这不是单个大模型在“自言自语”，而是一支分工明确、能自主决策、可动态协调的小型AI团队。这就是**Multi-Agent AI Architecture（多智能体AI架构）**的核心图景。它早已不是论文里的概念玩具，而是正在被电商推荐引擎、金融风控中台、工业设备预测性维护平台、甚至教育个性化学习系统批量落地的工程现实。关键词“多智能体”“AI架构”“协作模式”“真实用例”不是空泛标签，而是指向一套具体的设计哲学：如何让AI能力从“单点突破”走向“系统级协同”。它解决的不是“能不能答对一个问题”，而是“在复杂约束下，如何组织多个AI能力单元，以最稳健、最可解释、最易维护的方式完成端到端任务”。适合谁看？如果你是技术负责人，正为大模型应用落地后的响应延迟、幻觉不可控、业务逻辑耦合过重而头疼；如果你是算法工程师，厌倦了把所有逻辑硬塞进一个Prompt里反复调试；如果你是产品经理，发现用户需要的不是“更聪明的聊天机器人”，而是“能跨系统调度资源、做判断、担责任的数字协作者”——那么，这篇文章就是为你写的。它不讲抽象理论，只拆解真实项目里怎么选型、怎么分层、怎么防崩、怎么迭代。

2. 架构设计底层逻辑：为什么必须放弃“单一大模型包打天下”的幻想

2.1 单体大模型的三大硬伤，直接催生多智能体需求

我带过三个不同行业的AI落地项目，从零开始搭建过五套生产级AI系统。每一次踩坑后都更确信一点：把所有功能压在一个大模型上，短期快，长期痛。这种痛不是性能差一点，而是结构性缺陷，无法通过调参或换更大模型来根治。

第一是 可靠性塌方风险 。单体架构下，模型一旦在某个环节出错（比如把“退款”误识别为“投诉”），整个流程就卡死或输出错误结果。我们曾在一个保险核保辅助系统中遇到过：大模型在解析用户上传的医疗报告时，将“轻度脂肪肝”错误归类为“重大既往症”，导致后续所有风控策略全盘失效。而换成多智能体后，我们让“医学文本解析Agent”只专注结构化提取关键指标（如ALT值、影像描述关键词），再由“核保规则引擎Agent”基于结构化数据做判断。前者出错，后者仍可结合其他字段（如体检报告、问卷）做兜底，系统整体可用性从82%提升到99.3%。这背后是 故障隔离 思想——每个Agent只承担单一职责，错误不会像病毒一样扩散。

第二是 可解释性与可审计性归零 。监管机构（尤其是金融、医疗领域）要求你能说清楚“为什么拒保”“为什么授信额度是5万”。单体大模型的决策链路是黑箱中的黑箱。而多智能体架构天然生成决策日志：Agent A提取了哪些事实，Agent B引用了哪条规则，Agent C做了什么权衡……每一步都可追溯、可回放。某银行在部署信贷初筛系统时，监管验收的关键一票，就是靠多智能体输出的完整决策流水线报告拿下的。这不是锦上添花，而是准入门槛。

第三是 演进成本指数级上升 。当业务需要新增“反欺诈交叉验证”能力时，单体方案意味着重写Prompt、重训微调数据、重新测试全部场景。而多智能体只需新增一个“反欺诈验证Agent”，定义好它和现有“申请信息解析Agent”“信用评分Agent”的输入输出协议，插进去即可。我们一个电商客户，上线6个月新增了4个业务Agent（价格比对、库存联动、物流时效预估、客服话术适配），核心架构代码零修改，仅新增配置文件和少量胶水代码。这种 模块化演进能力 ，是单体架构永远无法企及的工程优势。

提示：别被“Agent”这个词迷惑。它不等于“另一个大模型”。一个Agent可以是轻量级规则引擎、一个微服务API、一段Python脚本，甚至是一个人工审核工单队列。它的本质是 一个具备目标导向、能自主感知环境、可执行动作并反馈结果的软件单元 。判断标准从来不是“用了多大参数量的模型”，而是“它是否在系统中承担了不可替代的决策或执行角色”。

2.2 三种主流架构模式：没有银弹，只有适配场景

市面上常提的“分层式”“环形”“树状”架构，本质上是对“协作关系”和“控制流”的不同建模。选错模式，后期改造成本远超初期省下的那点开发时间。

分层式（Layered）架构 ，是我给90%新项目首推的起点。它像工厂流水线：Input Layer（输入解析Agent）→ Processing Layer（核心处理Agent群，如意图识别、知识检索、逻辑推理）→ Output Layer（格式化、合规审查、多模态合成Agent）。优势极其明显：职责清晰、调试简单、监控粒度细。我们给一家连锁药店做的慢病管理助手，就采用此模式。当用户问“我血压高，能吃XX药吗？”，输入Agent先剥离出“用户身份（高血压患者）”“药品名（XX）”“核心诉求（用药安全性）”；处理层三个Agent并行工作——医学知识Agent查药品禁忌、用户档案Agent调取其肝肾功能指标、药物相互作用Agent扫描其正在服用的其他药品；输出Agent综合三路结果，生成带依据引用的通俗建议。每一层失败都有明确Fallback机制（如知识Agent超时，自动降级为调用结构化药品说明书数据库）。它的短板也很实在：不适合强交互、多轮深度协商的场景，因为层与层之间是单向依赖，缺乏动态反馈闭环。

环形（Ring）架构 ，专治“需要反复打磨、多轮博弈”的任务。典型如法律合同审查：起草Agent生成初稿 → 合规Agent标出风险条款 → 商务Agent评估商务条款合理性 → 起草Agent根据反馈修改 → 再次进入合规审查……如此循环，直到满足退出条件（如修改次数上限、风险项清零）。关键在于引入了 状态机（State Machine） 和 终止条件（Termination Criteria） 。我们帮一家律所做的并购尽调系统，就用此模式。环中每个Agent都带一个“置信度打分器”，当所有Agent对当前版本的综合置信度超过阈值，才允许进入下一阶段。这避免了无休止的低效修改。但代价是复杂度陡增——你需要精心设计状态流转逻辑和异常中断路径，否则极易陷入死循环。

树状（Tree）架构 ，则是应对“高度不确定、需动态分支”的终极方案。它没有预设流程，而是由一个“Orchestrator Agent”（编排Agent）作为大脑，根据实时输入和中间结果，动态决定下一步调用哪个子Agent。比如一个工业设备故障诊断系统：Orchestrator收到“电机异响”报警后，先调用“振动频谱分析Agent”；若分析出高频谐波，再调用“轴承健康评估Agent”；若评估显示轴承磨损，才触发“备件库存查询Agent”和“维修工单生成Agent”。整个决策树是运行时构建的，而非静态编码。它的威力在于极致灵活性，但对Orchestrator的决策能力要求极高——它本身就需要一个可靠的推理模型支撑。我们一个风电客户用此架构实现了故障根因定位准确率从68%提升到91%，但前期花了整整两个月训练和验证Orchestrator的决策逻辑。

注意：实际项目中，90%的“混合架构”都是分层式为主干，局部嵌入环形或树状逻辑。比如分层架构的Processing Layer内部，对关键决策节点采用环形迭代；或者Orchestrator Agent本身就是一个分层设计的复合体。不要追求理论完美，要盯住业务痛点。

3. 核心组件拆解：从“能跑起来”到“跑得稳、跑得明白”

3.1 Agent的四大构成要素：缺一不可的最小完备单元

很多团队第一步就栽在“怎么定义一个Agent”上。他们以为只要封装一个API调用，起个名字叫“XXX Agent”，就算完成了。结果系统上线后，各Agent像一盘散沙，互相传错数据、等不到响应、失败后不知所措。根本原因在于，一个生产级Agent必须包含四个原子组件，缺一不可：

1. Role & Goal（角色与目标） ：这是Agent的“灵魂”。不能写“负责回答问题”，而要精确到“作为资深心血管医生，基于用户提供的近3个月血压记录、当前用药清单及最新体检报告，判断其服用XX降压药的安全性，并给出不超过3条具体调整建议”。目标必须可衡量（如“建议必须引用至少1条临床指南原文”）、有时限（如“响应延迟≤1.5秒”）、有边界（如“不提供用药剂量调整，仅提示需医生面诊”）。我们曾因一个Agent的目标描述模糊（“提升用户体验”），导致它过度优化语言流畅度而牺牲了医学准确性，被临床专家一票否决。

2. Memory（记忆） ：不是指大模型的上下文窗口，而是Agent自身的 状态存储与检索机制 。分为两类： Short-term Memory （短期记忆）用于单次会话内的上下文维持，比如记录用户刚提到的过敏史； Long-term Memory （长期记忆）则需对接外部向量数据库或关系型数据库，存储其专业领域的知识沉淀（如该Agent处理过的1000+类似病例的决策依据）。关键技巧：Memory的读写必须显式声明。我们强制要求每个Agent的输入输出Schema中，必须包含 memory_read_keys: [list] 和 memory_write_keys: [list] 字段。这样在系统集成时，编排层才能精准注入所需记忆，避免“该记得没记，不该记的乱记”。

3. Tools（工具） ：Agent的能力外延。一个纯LLM Agent就像一个只有大脑没有手脚的人。Tools是它的手和脚——可以是HTTP API（调用天气服务）、SQL查询（查用户订单历史）、Python函数（计算BMI指数）、甚至是一个人工审核接口（当置信度低于阈值时转人工）。重点在于 Tool Calling的可靠性保障 。我们规定：所有Tool调用必须自带 timeout 、 retry_policy （最多重试2次，间隔500ms）、 fallback_strategy （如API超时则返回缓存数据+标注“数据非实时”）。曾有一个金融Agent因未设超时，一次行情接口抖动导致整个交易审批流程阻塞17分钟，教训惨痛。

4. Protocol（协议） ：Agent间的“普通话”。定义清楚：输入是什么格式（JSON Schema）、输出必须包含哪些字段（ status: success/error 、 confidence_score: 0.0-1.0 、 trace_id: string ）、错误时返回什么结构（ error_code: "TOOL_UNAVAILABLE" 、 suggestion: "请检查网络连接" ）。我们用OpenAPI 3.0规范为每个Agent生成独立文档，并用Swagger UI集中管理。新加入的Agent，必须通过协议兼容性测试（Protocol Compatibility Test）才能接入主干网。这看似繁琐，却让我们在半年内接入12个第三方AI服务（含2个海外供应商）时，零协议冲突。

3.2 编排层（Orchestration Layer）：系统的“交响乐指挥家”

如果说Agent是乐手，编排层就是指挥家。它不演奏乐器，但决定谁何时奏响、音量多大、如何呼应。它的设计质量，直接决定整个系统的智商上限和稳定性下限。

核心能力一：动态路由（Dynamic Routing） 。不是简单的if-else。真正的动态路由基于实时信号：用户身份（VIP客户走绿色通道）、请求紧急度（“心脏骤停”报警优先于“预约挂号”）、系统负载（高并发时降级非核心Agent）。我们用一个轻量级决策树模型（XGBoost训练）做路由策略，输入是12个实时特征（如 request_latency_ms , user_tier , agent_health_score ），输出是目标Agent ID列表。这个模型每天用新日志自动重训，确保路由策略随业务变化而进化。

核心能力二：容错熔断（Fault Tolerance & Circuit Breaking） 。必须内置“断路器”（Circuit Breaker）。当某个Agent连续5次超时或错误率超15%，编排层自动将其标记为“半开”状态：后续10%的请求试探性发送，其余请求走预设Fallback（如调用规则引擎、返回缓存结果、或降级为人工）。我们一个新闻摘要系统，曾因某第三方NLP服务突发故障，断路器在23秒内完成熔断，Fallback至本地关键词提取+模板填充，用户无感知。而未启用熔断的旧版，故障持续了47分钟。

核心能力三：可观测性埋点（Observability Instrumentation） 。编排层是全链路追踪的枢纽。我们强制要求每个Agent调用前后，编排层必须记录： span_id （唯一跟踪ID）、 agent_name 、 input_size_bytes 、 output_size_bytes 、 latency_ms 、 confidence_score 、 tool_calls_used: [list] 。这些日志统一接入ELK栈，配合Grafana看板，能秒级定位瓶颈——是某个Agent本身慢？还是它调用的Tool慢？或是网络抖动？某次线上事故，正是通过看板发现90%的延迟来自一个Agent频繁调用未加缓存的地理编码API，优化后P95延迟从3.2秒降至420毫秒。

实操心得：编排层代码必须与业务逻辑彻底解耦。我们用YAML配置文件定义所有路由规则、熔断阈值、Fallback策略。业务方（如风控经理）无需改代码，只需修改配置文件并提交PR，经CI/CD流水线自动验证后即可生效。这让我们平均每次业务策略调整的上线时间从3天缩短到22分钟。

4. 真实用例深挖：从电商客服到工业质检，看多智能体如何破局

4.1 案例一：跨境电商智能客服系统（分层式架构实战）

业务痛点 ：某头部跨境电商平台，日均咨询量超50万，覆盖200+国家，商品SKU超2000万。传统单体客服机器人面临三大死结：1）小语种支持差（机器翻译+大模型二次生成，错误率高）；2）跨境政策复杂（各国退换货规则、税务合规要求差异巨大）；3）多系统数据孤岛（订单系统、物流系统、海关清关系统互不联通）。

多智能体解法 ：采用强化版分层式架构，共5层12个Agent。

• Input Layer ：1个“多模态输入解析Agent”，不只处理文字，还能解析用户上传的包裹破损照片（调用CV模型）、语音留言（ASR转文本）、甚至截图中的订单号（OCR识别）。它输出结构化事件： {event_type: "package_damage", country: "DE", order_id: "ABC123", image_features: [vector]} 。

• Routing Layer （新增一层）：1个“智能路由Agent”，根据 country 和 event_type ，将请求分发到对应区域的处理集群。德国用户关于税务的咨询，绝不会路由到东南亚Agent池。

• Processing Layer ：按区域划分，每个区域集群包含：

  • “本地化政策Agent”：对接各国法规知识图谱（如德国《远程销售法》第12条），输出合规要点；
  • “订单履约Agent”：调用订单系统API，获取该订单的支付方式、发货仓、预计清关时间；
  • “物流状态Agent”：调用DHL/FedEx等物流商API，解析实时轨迹，识别异常节点（如“海关查验中”）；
  • “多语言生成Agent”：不依赖通用翻译模型，而是针对每个语种微调专用TTS/Text模型，确保德语回复符合当地敬语习惯（如对年长用户必用“Sie”而非“You”）。

• Output Layer ：1个“多通道合成Agent”，根据用户终端（WhatsApp/APP/Web）自动选择最优输出格式：WhatsApp发图文卡片+语音摘要；APP内嵌交互式进度条；Web端显示带时间轴的物流地图。

效果与细节 ：上线后，首次响应解决率（FCR）从41%提升至79%；德语区用户满意度（CSAT）达92%，较之前提升37个百分点；最关键的是，因政策解读错误导致的客诉，从月均2300起降至17起。 避坑经验 ：我们最初让“本地化政策Agent”直接调用大模型生成回复，结果它把波兰的增值税起征点算错了。后来改为：Agent只做结构化查询（ query: "Poland VAT threshold for cross-border sales" ），返回标准化JSON（ {"threshold": "10000 EUR", "effective_date": "2023-07-01"} ），再由“多语言生成Agent”填入模板。用“结构化数据+模板”代替“自由生成”，是保障合规性的铁律。

4.2 案例二：半导体晶圆厂AI质检平台（树状+环形混合架构）

业务痛点 ：某晶圆代工厂，28nm产线每片晶圆需检测超5000个die，传统AOI（自动光学检测）漏检率高达8.3%，尤其对微米级划痕、纳米级颗粒污染识别乏力。人工复检成本高昂，且专家经验难以复制。

多智能体解法 ：以“Orchestrator Agent”为根节点，构建动态决策树，关键节点嵌入环形精修。

• Root Orchestrator ：接收AOI初步标记的可疑区域图像（256x256像素块）。首先调用“粗筛Agent”（轻量CNN模型），快速过滤掉95%的伪阳性（如镜头污渍、光照不均）。剩余5%进入深度分析。

• 深度分析分支 ：Orchestrator根据粗筛结果的 defect_type_probabilities ，动态选择子树：

  • 若 scratch_prob > 0.7 ，调用“划痕形态学分析Agent”（调用OpenCV形态学操作+几何特征提取）；
  • 若 particle_prob > 0.7 ，调用“颗粒光谱分析Agent”（对接光谱仪数据，分析反射率曲线）；
  • 若 probabilities 均低于0.5，则启动“多模态融合Agent”，同步调用上述两个Agent，并融合其特征向量，输入一个小型集成分类器。

• 环形精修节点 ：在任一深度分析Agent输出后，Orchestrator不直接采纳，而是启动环形流程：

  1. “专家知识校验Agent”（规则引擎）检查结果是否符合已知物理规律（如“划痕长度不可能超过晶圆直径”）；
  2. 若校验失败，将原始图像+当前分析结果+校验失败原因，送入“对抗样本生成Agent”（GAN模型），生成若干相似但更易判别的变体图像；
  3. 将变体图像送回原深度分析Agent重新判断；
  4. 循环最多3次，或当校验通过/置信度提升超20%时退出。

效果与细节 ：系统将漏检率从8.3%降至0.9%，误报率从12.7%降至3.1%；更重要的是，它生成了每张缺陷图的完整“诊断报告”，包含：原始图像、各Agent分析步骤截图、特征热力图、物理规则校验过程、最终判定依据。这份报告成为培训新质检员的核心教材。 避坑经验 ：环形精修的“对抗样本生成”环节，我们最初用通用GAN，结果生成的图像失真严重。后来改为：用该产线过去3年积累的10万张真实缺陷图微调GAN，生成的变体图像纹理、噪声分布与真实产线数据高度一致，精修有效率从31%跃升至89%。

5. 落地避坑指南：那些文档里不会写的血泪教训

5.1 Agent间通信：别让“消息总线”变成“消息垃圾场”

很多团队一上来就选Kafka或RabbitMQ做Agent通信，觉得高大上。结果半年后，消息队列里堆积了数百万条格式混乱、无版本标识、无过期时间的消息，排查一个超时问题要翻三天日志。根本问题在于，把“通信基础设施”和“通信协议”混为一谈。

正确姿势 ：通信层（Transport Layer）只负责可靠投递，协议层（Protocol Layer）必须严格定义。我们强制推行“三明治消息格式”：

{
  "envelope": {
    "version": "1.2",
    "trace_id": "a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8",
    "timestamp": "2024-05-20T08:30:45.123Z",
    "ttl_seconds": 300,
    "sender": "order_parser_agent_v2",
    "receiver": "inventory_checker_agent_v1"
  },
  "payload": {
    // 这里才是业务数据，严格遵循OpenAPI定义的Schema
  },
  "signature": "sha256_hash_of_envelope_and_payload"
}

• ttl_seconds （Time-To-Live）是救命稻草。任何消息超过5分钟未被消费，自动丢弃并告警。避免陈旧消息干扰实时决策。
• version 字段必须存在。当 inventory_checker_agent 升级到v2，它只处理 version: "1.2" 的消息，老版本消息由v1消费，实现灰度发布。
• signature 保证消息不被篡改。曾有一次，因网络中间件bug，消息体被截断，签名校验失败，系统立即拒绝处理并告警，避免了错误库存数据写入。

注意：别迷信“异步”。对强事务性场景（如支付扣款），我们坚持用同步HTTP+重试，配合Saga模式补偿。异步只用于通知类、分析类、非关键路径。混淆两者，是分布式系统崩溃的头号诱因。

5.2 状态管理：共享内存不是万能解药，小心“状态雪崩”

看到“Agent需要共享状态”，很多团队第一反应是上Redis或PostgreSQL。结果很快发现：10个Agent同时读写一个 user_session_state 键，出现竞态条件，用户看到的库存数量忽高忽低。根源在于，把“状态存储”当成了“状态管理”。

正确姿势 ：区分三种状态，用不同方案：

• 瞬时会话状态（Ephemeral Session State） ：如用户当前对话的上下文。用内存型Key-Value（如Go的 sync.Map 或Python的 concurrent.futures.ThreadPoolExecutor + dict ），生命周期绑定会话ID，会话结束自动GC。绝不落盘。

• 业务实体状态（Business Entity State） ：如“订单状态”“库存数量”。必须走业务系统主数据库，Agent只读不写。写操作由业务系统自身完成，Agent通过CDC（Change Data Capture）监听变更。我们用Debezium监听MySQL binlog，实时更新Agent的本地缓存。

• 决策共识状态（Consensus State） ：如多个Agent对某笔交易的风险评级达成一致。这时才用分布式一致性协议（如Raft），但我们只在极少数场景（如金融联合风控）使用，且封装成独立的“共识服务”，Agent只调用其API。

血泪教训 ：我们曾在一个物流路径规划系统中，让10个Agent共享一个 available_trucks 内存列表。高峰期，Agent A刚读取到“卡车#123可用”，Agent B同时读取并锁定，A再写回时覆盖了B的锁定状态，导致两单货物同时派给同一辆车。解决方案：将“卡车可用性”视为业务实体，所有调度请求必须调用 truck_scheduler_service 的 reserve_truck(truck_id, order_id) 接口，该服务内部用数据库行锁保证原子性。

5.3 监控告警：别只盯着“CPU 100%”，要看“决策衰减”

传统运维监控CPU、内存、QPS，这对多智能体系统远远不够。真正致命的是“决策质量衰减”——模型漂移、数据偏移、规则过时，系统还在高速运行，但输出越来越不准。

必须建立三层监控体系 ：

• 基础设施层 ：CPU/内存/网络（基础，但不够）。
• 服务层 ：各Agent的 p95_latency_ms 、 error_rate_% 、 tool_call_success_rate_% （如调用物流API的成功率）。
• 业务层（最关键） ： decision_confidence_drift （决策置信度漂移率）、 fallback_rate_% （降级到规则引擎的比例）、 human_review_rate_% （需人工复核的比例）。

我们用Prometheus采集所有指标，但告警规则是业务驱动的：

• 当 decision_confidence_drift 7日均值下降超15%，触发“模型健康度告警”，自动启动模型重训流水线；
• 当 fallback_rate 连续2小时 > 5%，触发“规则引擎压力告警”，提示业务方检查规则是否过时；
• 当 human_review_rate 单日突增300%，触发“高危决策告警”，暂停该Agent所有自动决策，强制人工审核。

实操心得 ：在每个Agent的输出中，必须强制包含 confidence_score 。这个分数不能是模型自己输出的logits，而要经过校准（Calibration）。我们用Platt Scaling对每个Agent的输出概率进行校准，确保 confidence_score=0.85 时，实际准确率确实在84%-86%之间。未经校准的置信度，比没有还危险。

6. 工具链与选型：务实主义者的武器库

6.1 不是所有框架都叫“多智能体框架”

市面上冒出一堆“Multi-Agent Framework”，名字很炫，但深入看，要么是玩具级（只能跑Hello World）、要么是学术级（依赖特定研究模型）、要么是重型企业套件（年费百万起）。我们团队经过17个项目验证，总结出选型铁律： 框架的价值 = （降低重复造轮子的成本） - （引入新学习曲线和维护负担） 。只选能立刻提升30%以上开发效率的。

轻量级首选：LangChain + 自研Orchestrator 。LangChain的Agent/Tool/Chain抽象非常干净，社区生态成熟（2000+现成Tool），文档极佳。但它不提供生产级编排、熔断、监控。我们的做法是：用LangChain快速搭建Agent原型，验证业务逻辑；然后用Go重写核心编排层（性能高、内存安全），LangChain Agent作为“胶水层”嵌入其中。这套组合拳，让我们新项目从立项到上线平均只需6周。

中型项目：Microsoft AutoGen 。当项目需要强交互、多轮协商（如前述法律合同审查），AutoGen的Group Chat Manager和Conversable Agent设计直击痛点。它原生支持多种LLM后端、内置简单记忆管理、提供 initiate_chat() 等高层API。我们一个政府公文智能起草项目，用AutoGen两周就搭出可演示的环形协作Demo。但注意：它的生产化部署文档薄弱，大规模Agent集群的资源调度需自行扩展。

规避陷阱：LlamaIndex 。它名字里有“Index”，本质是 检索增强（RAG）框架 ，不是多智能体框架。强行把它当Agent框架用，会陷入“为检索而检索”的泥潭。我们曾见一个团队用LlamaIndex构建“客服Agent”，结果90%代码都在折腾向量索引优化，真正的业务逻辑（如退换货规则判断）反而用硬编码实现。记住：LlamaIndex是你的“知识眼睛”，不是你的“决策大脑”。

6.2 关键工具选型：一分钱一分货，但别为“参数大”买单

• LLM选型 ：别盲目追SOTA。我们生产环境主力是 Qwen2-7B-Instruct （中文）和 Phi-3-mini-4k-instruct （英文）。理由硬核：7B模型在A10 GPU上P95延迟<800ms，满足实时交互；指令微调充分，Few-shot效果稳定；最重要的是，它足够小，我们可以为每个Agent定制专属微调（Domain-Specific Fine-tuning），比如“医疗Agent”用10万条医患对话微调，“法律Agent”用5万份判决书微调。而70B模型，即使量化后，在单卡上延迟也常超3秒，用户早关页面了。

• 向量数据库 ： Qdrant 是我们近三年的坚定选择。它原生支持Payload过滤（如 filter: {"source": "medical_guidelines", "year": ">2023"} ），这对多智能体按需检索至关重要；Rust编写，性能碾压同类；开源版功能已足够生产。曾对比Weaviate，发现其复杂过滤语法在高并发下性能抖动严重，Qdrant则稳如磐石。

• 工作流引擎 ： Temporal 。当你的Agent需要跨天、跨系统、带人工干预的长周期任务（如“处理一个复杂的保险理赔，涉及医院材料收集、第三方评估、财务审核”），传统短生命周期的HTTP调用完全不够。Temporal提供真正的“持久化工作流”，状态自动保存，故障自动恢复，时间跳过（Timer）精准到毫秒。我们一个车险理赔系统，用Temporal编排平均耗时3.2天的全流程，成功率99.997%。

最后分享一个小技巧：所有Agent的Prompt，我们不用纯文本管理，而是用Jinja2模板。模板中可嵌入变量（如 {{ user_profile.risk_tolerance }} ）、条件逻辑（ {% if country == 'CN' %}...{% endif %} ）、甚至调用Python函数（ {{ calculate_tax(amount, country) }} ）。这样，同一个Agent，通过注入不同上下文变量，就能服务全球不同市场，维护成本直线下降。