多智能体跑出100%满分：我们为何依然不敢上线？

多智能体架构图

在电商与末端物流配送中，大约 10% 的快件会遭遇异常情况：派送失败、地址缺失、包裹破损、客户拒收以及天气延误。

每一次配送失败都会带来二次上门的直接履约成本。更致命的是用户体验流失：调查显示，用户在经历 2 到 3 次派送失败后，很可能会直接放弃该平台。

目前多数物流企业的异常处理依然极度依赖人工。客服或运营人员在派送日志、骑手备注、用户画像和操作手册之间来回比对，手动做决策、发通知。这种模式处理流程僵硬。VIP 用户的生鲜件派送失败，与普通用户的普通包裹延误，往往走的是同一套低效的人工工单流。

针对这一痛点，德克萨斯大学奥斯汀分校麦姆斯商学院合作开展了一项课题研究：利用多智能体协作（Multi-Agent）系统，自动完成从异常识别、策略匹配到用户触达的全流程。

整套系统最终在基准测试中拿到了 100% 的任务完成率。但整套实验中最具价值的发现，恰恰隐藏在这份「满分答卷」背后。

一、技术选型与核心设计原则

项目采用模块化 Python 架构，核心依赖包括 LangGraph（智能体编排）、LangChain（模型交互）、Pydantic（输出结构化校验）、PyPDFLoader（制度文档解析）、SQLite（数据持久化）以及 LangSmith（调用链路追踪与监控）。

技术架构分解

在模型选型上，团队将内容生成与审核评估拆分为两层架构：

执行与生成层：采用高性价比的 gpt-4o-mini（temperature=0）
审核与评估层：采用更高推理能力的 gpt-4o（temperature=0）

from langchain_openai import ChatOpenAI
gen_llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
eval_llm = ChatOpenAI(model="gpt-4o", temperature=0)

确定性逻辑 vs 概率推理：把规则锁在代码里

智能体落地最常见的架构失误，是把每个决策都当成大模型的推理任务，而忽视了许多问题本质只是规则执行。

模糊场景理解、非结构化文本抽取、矛盾线索推导，适合交给大模型；而算术比较、阈值判断、硬性条件分支和风控拦截，交给普通代码更快、更便宜、更可预测，也更易审计。

系统被明确切分为四层结构：

LangGraph 拓扑结构

规则预处理器（无 LLM）：去重、日志合并、Prompt 注入防御、无异常噪点过滤。
确定性工具集（无 LLM）：自提柜容积匹配、人工升级规则引擎。
多智能体核心：包含决策智能体（Resolution Agent）与沟通智能体（Communication Agent），各自搭配独立的审核智能体（Critic）。
独立评测层：标准答案校验、一致性裁判、制度规范依从度裁判。

以智能自提柜匹配为例，柜机尺寸是否满足要求是纯算术逻辑：

@tool  
def check_locker_availability(zip_code: str, package_size: str) -> list[dict]:  
    """检查同区域可用自提柜规格与容量"""
    size_hierarchy = {"SMALL": 1, "MEDIUM": 2, "LARGE": 3}  
    pkg_level = size_hierarchy.get(package_size, 0)  
      
    for row in rows:  
        locker = dict(row)  
        locker_max = size_hierarchy.get(locker["max_package_size"], 0)  
        if locker_max < pkg_level:  
            locker["eligible"], locker["reason"] = False, "自提柜格口过小"  
        elif locker["capacity_status"] == "FULL":  
            locker["eligible"], locker["reason"] = False, "自提柜已满"  
        elif locker["capacity_status"] == "LIMITED" and package_size != "SMALL":  
            locker["eligible"], locker["reason"] = False, "自提柜饱和，仅限小件"  
        else:  
            locker["eligible"], locker["reason"] = True, "匹配成功"

人工升级判定同样采用确定性规则引擎，划分为强制升级（AUTOMATIC）与酌情升级（DISCRETIONARY）：

@tool  
def check_escalation_rules(customer_tier, exceptions_last_90d, attempt_number,  
                           package_type, status_code, status_description) -> dict:  
    triggers = []  
    if attempt_number >= 3:  
        triggers.append("AUTOMATIC: 第 3 次派送失败")  
    if customer_tier == "VIP" and exceptions_last_90d >= 3:  
        triggers.append("AUTOMATIC: VIP 客户 90 天内累计 3 次异常")  
    if status_code == "DAMAGED" and package_type == "PERISHABLE":  
        triggers.append("AUTOMATIC: 生鲜包裹破损")  
    if customer_tier == "STANDARD" and exceptions_last_90d > 5:  
        triggers.append("DISCRETIONARY: 普通客户 90 天内超过 5 次异常")

在完全不调用大模型的前提下，预处理层便自动排出了任务优先级队列。生鲜包裹被前置为最高优先级（P1），正常签收件直接秒级放行，全程不产生任何大模型 Token 开销。

确定性分流结果

二、核心工作流：Schema 约束与规则编排器

编排系统的核心原则是：编排器本身不应是大模型，而是一套状态机代码。

多智能体架构细节

LangGraph 中的节点转移由确定性代码驱动。每个节点处理完毕后，强制将控制权交还给调度器：

workflow = StateGraph(UnifiedAgentState)  
workflow.add_node("preprocessor", preprocessor_node)  
workflow.add_node("orchestrator", orchestrator_node)  
workflow.add_node("resolution_agent", resolution_agent_node)  
workflow.add_node("critic_resolution", critic_resolution_node)  
workflow.add_node("communication_agent", communication_agent_node)  
workflow.add_node("critic_communication", critic_communication_node)  
workflow.add_node("finalize", finalize_node)  

workflow.add_edge("preprocessor", "orchestrator")  
ROUTES = ["resolution_agent", "critic_resolution", "communication_agent",  
          "critic_communication", "finalize"]  
workflow.add_conditional_edges("orchestrator", lambda s: s["next_agent"],  
                               {r: r for r in ROUTES})  
for worker in ["resolution_agent", "critic_resolution",  
               "communication_agent", "critic_communication"]:  
    workflow.add_edge(worker, "orchestrator")  
workflow.add_edge("finalize", END)

所有 Agent 的输出都通过 Pydantic 严格约束。若输出出现逻辑自相矛盾，直接在反序列化阶段报错抛出：

class ResolutionOutput(BaseModel):  
    is_exception: Literal["YES", "NO"]  
    resolution: Literal["RESCHEDULE", "REROUTE_TO_LOCKER", "REPLACE",  
                           "RETURN_TO_SENDER", "N/A"]  
    rationale: str

    @model_validator(mode="after")  
    def validate_consistency(self):
        if self.is_exception == "YES" and self.resolution == "N/A":  
            raise ValueError("存在异常时，决断动作不能为 N/A")  
        if self.is_exception == "NO" and self.resolution != "N/A":  
            raise ValueError("不存在异常时，决断动作必须为 N/A")  
        return self

三、三次迭代过程

在模型权重未做任何微调的前提下，通过对 Schema、系统提示词以及评估逻辑的调整，系统经历了三轮快速迭代。

三轮迭代结果对比

迭代 1：智能体「自创」动作导致测试失败

在 v1 版本中，Prompt Schema 中包含了一个动作 HOLD_AT_DEPOT（网点暂存）。智能体在处理地址不详和多次失败包裹时选择了该动作。然而对比评测集的标准答案，标准动作库只有四种，导致两例判定失败，完成率仅为 8/10。

团队当时尝试把标准答案的标签修改为 HOLD_AT_DEPOT，得分瞬间变成了 10/10。这种现象在工程开发中极为普遍：当你修改评测标准去附和系统的行为时，系统总能拿到满分。 但这是一种自欺欺人的评测幻觉。

迭代 2：收紧 Schema 契约，保留原始标签

v2 版本删除了 HOLD_AT_DEPOT 选项，严格限制在四种标准操作内。任务完成率重回 10/10。但升级准确率却意外下滑至 88%（7/8）。

SHP-003 号订单的异常排查：
决策智能体建议 RESCHEDULE（重新预约），这是正确答案。但审核智能体（Critic）检索到业务规范中写着「应在网点暂存并联系客户核实地址」，因此连续两次打回重审。在重试过程中，模型返回了非法的 N/A，被 Pydantic 拦截。在达到三次重试上限后，流水线触发兜底防线：强制设定为 RESCHEDULE 并转人工升级。

这一单耗时飙升至 18.91 秒。最终结果虽然阴差阳错猜对了，但产生了多余的人工升级，暴露出 Prompt 契约与审核标准之间的逻辑打架。

迭代 3：重构 Prompt 契约，显式暴露冲突

v3 版本明确在 Prompt 中告知决策与审核智能体：「网点暂存并联系客户」属于 RESCHEDULE 的前置履约动作，而不是独立的决策类别。

同时升级了重试报错机制，模型重试时会被明确告知上一次格式错在何处。v3 版本的平均响应延迟从 7.76 秒降至 7.19 秒，SHP-003 处理耗时从 18.91 秒压缩到 7.89 秒，升级准确率回到 100%。

v3 运行指标与耗时下降

耗时大幅度缩短

四、顿悟时刻：标准答案与制度规范的脱节

表面上看，v3 的评测报告无可挑剔：

任务完成率：100%
升级准确率：100%
工具调用准确率：100%
语义连贯性：5.0 / 5.0

然而，当引入**制度规范依从度裁判（Playbook Adherence Judge）**独立比对决策结果与业务手册原文时，真相浮出水面。

标准答案通过但制度审查冲突

在 8 个异常包裹样本中，有 2 个包裹完全契合标注的标准答案，却与企业官方手册的规定直接冲突。

骑手日志与手册政策的冲突

SHP-002 案：骑手备注用户无法联系，标准答案给出退回发件人。但业务手册明确规定，只有在经历两次以上尝试或明确拒收后才允许退件。
SHP-005 案：快件第三次派送失败且附近自提柜已满，标准答案设定为转自提柜，但现实中自提柜已无可用容量。

智能体做出了最贴近真实业务逻辑的操作，却在初筛中被传统标准答案判错；或者智能体猜对了标准答案，却违背了业务手册的实际规定。

Anthropic 在近期研究《Demystifying evals for AI agents》中指出：前沿模型在复杂环境中经常能突破静态评估的局限。在某些评测集上，智能体看似未能命中预设答案，实际上却找出了更合理的业务解法。

静态的标准答案本身就可能存在过时或漏洞。多智能体评测的深层价值，不仅在于测试 AI 是否做出了正确动作，更在于帮企业反向检验现行制度是否完备。

五、核心实践启示

LangSmith 监控链路演进

确定性逻辑进代码，概率性推理给模型
系统中的安全护栏、容量校验和刚性升级触发器，全都由常规代码实现。5 起关键人工升级完全由规则驱动触发，未耗费任何 LLM 算力。
警惕被迎合的标准答案
当评测集为了适应模型的生成结果而频繁调整标签时，数据指标会虚高。必须保留原始测试集，并引入不直接接触答案标签的独立裁判机制。
将模型分歧作为人工复核的路由信号
当执行智能体与审核智能体产生冲突时，不必强求模型自主达成共识。这种分歧往往意味着业务场景遇到了制度盲区，将分歧点打包为待办工单交由人工处理，是系统在生产环境中最稳妥的容错路径。