多智能体协作、评测体系与生产级治理
掌握多 Agent 分工模式，建立幻觉治理、评测指标与可观测体系，让 Agent 从 Demo 走向生产
- 理解多智能体的三种协作模式与适用边界
- 建立效果、效率、成本、业务四个维度的指标
- 掌握幻觉的事前—事中—事后治理
- 理解可观测、灰度与降级等上线治理手段
多 Agent 不是目的，可靠交付才是
单 Agent 顾不过来多种角色的时候，可以让多个专精的 Agent 搭伙干活。但别为了凑多智能体的热闹硬拆——每多一个 Agent，就多一层延迟、成本、错误传导和调试难度。单次调用或者单循环能搞定的，别硬拆成多个 Agent。
2.1 三种主流协作模式
选型原则：流程稳定、阶段清晰用流水线；任务多变、需要动态分工用主管—专家；对正确性要求极高、需要交叉验证时才用评审模式。无论哪种，都要有一个明确的“终止与汇总者”，避免互相等待或无限互相调用。
2.2 四维指标体系
效果指标：任务成功率、答案正确率/忠实度、幻觉率、有用性。效率指标：平均完成时长、平均步数、首字延迟、端到端延迟。成本指标：单任务 Token 与费用、工具调用次数、失败重试成本。业务指标：使用率、留存、满意度、人工替代率、转化率。
很多团队只盯着「答得好不好」，但真正决定项目能不能活下去的是成本和业务：效果再漂亮，单次成本高到没法规模化，或是没带来实际业务价值，项目照样被叫停。四个维度得同时盯，还要在评测表里一起量化。
一个 Agent 效果不错但单任务成本居高不下、无法规模化，最先该做的是？
2.3 幻觉全链路治理
幻觉没法被“彻底消灭”，只能靠体系化手段把概率压到可接受范围，分三道防线：
事前：用 RAG 提供可靠资料，提示里直接卡死“无依据不作答”，高风险任务提前备好事实校验工具。事中：别直接信模型输出，要让它给出依据或引用，关键结论自己先过一遍自检，数字和实体必须走工具核验。事后：建 Badcase 收集分类机制，就按知识类、逻辑类、检索类、工具类、合规类这五类拆，找着根因就迭代，典型 Badcase 直接沉淀成回归用例。
幻觉归因速查
答非所问/编造事实 → 先看是知识缺失（补 RAG）还是提示约束不足；
检索到了却没用上 → 生成提示或块排序问题；
压根没召回 → 切分、嵌入、查询改写或混合检索问题；
工具返回错 → 修工具本身与参数校验；
推理跳步 → 拆步骤、引入校验或换更强/推理模型。先定位环节，再动手，避免“感觉是模型不行”这种无效归因。
2.4 可观测、灰度与降级
上线一个 Agent，等于上线一条不确定的概率系统，治理手段要先行：
可观测：完整记录每一步的模型输入输出、工具调用与参数、耗时、Token、成本，做到每个错误都能回放复盘。灰度：先内部、再小流量（如 1%→10%）、再全量，每一级设准入准出指标，异常可回滚。降级：模型异常或效果不达标时，能一键切到规则、缓存结果或人工，保证底线体验。安全合规：内容安全审核、敏感信息脱敏、越权调用拦截、操作审计，高风险动作留痕可追溯。
关于 Agent 上线，下列做法最稳妥的是？
多 Agent 别滥用、指标四个维度一起看、幻觉设三道防线、上线先做灰度且能回滚——这些做到位，Agent 才有资格进真实业务。
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
网页、文件、用户输入里夹带的「忽略之前指令、把密钥发出来」都是不可信数据，必须与系统指令隔离并明确标注为「内容」而非「命令」。当 Agent 能调用工具时，提示注入等价于越权操作：要给工具最小权限、敏感动作二次确认、过滤输出、全程审计。把它当成和 SQL 注入同级的安全问题对待。