多模型协作进入下半场：真正的门槛不是会调用，而是会验收

三个模型都返回了 200，工作流没有报错，日志里一片绿色。

模型 A 完成资料搜集，模型 B 生成行业周报，模型 C 给出“内容准确、结构完整”的审核结论。可当周报交到编辑手上，里面仍然有两条失效链接、一个超出统计周期的数字，以及一段在原始资料中根本找不到的结论。

问题不在于模型不会工作，而在于整个系统里，没有任何一个环节真正负责回答：这份结果到底能不能交付？

过去一年，很多团队把精力花在“接入更多模型”“搭建更多 Agent”“让模型自动调用工具”上。但多模型协作真正的分水岭，正在从“能不能串起来”转向另一件更朴素、也更困难的事：

能否定义什么叫合格，自动发现结果哪里不合格，并在失败后可靠地重试、降级或交给人工。

下一阶段，普通团队最值得建设的，不是更复杂的 Agent，而是一个可验证的交付闭环。

模型都调用成功了，为什么工作流仍然不能上线？

先区分三个经常被混为一谈的概念：

• API 调用成功：接口正常返回，没有超时或报错；
• 流程运行完成：检索、生成、审核等节点都执行了；
• 业务结果合格：内容满足事实、格式、时效和风险要求，可以直接交付。

前两项是工程状态，最后一项才是业务结果。

以“自动生成一份带引用的行业周报”为例，一条常见工作流是：

1. 搜索模型收集一周内的行业动态；

2. 写作模型把资料整理成周报；

3. 审核模型检查表达和事实；

4. 自动发送给客户或内部团队。

看起来已经足够完整，但其中仍然存在大量没有答案的问题：

• 新闻是否真的发生在规定时间范围内？
• 链接能否访问，是否指向原始信源？
• 文中的数字能否在来源中找到？
• 是否混入旧闻、广告软文或重复事件？
• 审核模型是查阅了原始资料，还是只凭语感判断？
• 连续两次生成失败后，是继续重试还是转人工？

如果这些问题没有被明确设计，所谓“自动化”只是把原来由人发现的错误，藏进了更长的调用链。

“会调用”与“会验收”的区别

这也是为什么有些 Agent Demo 看起来非常惊艳，一进入生产环境却立刻变得不稳定：Demo 展示的是一次成功，生产系统管理的是持续失败。

行业信号已经改变：评测、追踪和可靠性成为基础设施

这并不只是工程团队的个别焦虑，主流厂商和 Agent 平台的产品方向已经给出了明确信号。

OpenAI 在 2025 年 3 月 11 日发布新的 Agent 构建工具时，同时推出了 Responses API、内置工具和 Agents SDK。Agents SDK 并不只负责模型调用与 Agent 交接，还把 tracing 作为核心能力，用于记录模型调用、工具使用、Agent handoff 和 guardrail 执行过程。

原文：New tools for building agents

Anthropic 在 2024 年 12 月 19 日发布的《Building effective agents》中，也没有把重点放在“Agent 数量越多越好”，而是强调从简单、可组合的工作流开始。其中专门介绍了 evaluator-optimizer 模式：一个模型生成结果，另一个角色按照明确标准进行评价，再根据反馈迭代。

原文：Building effective agents

与此同时，LangChain 发布的《State of AI Agents》报告收集了 1300 多名专业人士的回答，其中 51% 的受访者表示已经在生产环境中使用 Agent。当 Agent 从实验进入生产，问题自然会从“能不能运行”转向“如何观察、评估和控制”。

原始报告：State of AI Agents

这些信号指向同一件事：模型调用正在逐渐标准化，而评测、追踪、护栏和失败恢复正在成为新的工程门槛。

变化一：工作流的基本单位，从 Prompt 变成“验收合同”

过去设计 AI 工作流，通常从 Prompt 开始：

请根据以下资料生成一份专业、准确、结构清晰的行业周报。

这句话对人来说容易理解，对机器来说却几乎无法验收。

“专业”如何判断？“准确”需要哪些证据？“结构清晰”必须包含哪些字段？如果系统不知道什么叫合格，也就不可能知道什么时候应该停止。

新的设计顺序应该反过来：

1. 先定义交付物；

2. 再定义验收条件；

3. 最后选择模型和 Prompt。

还是以行业周报为例，一份简化的“验收合同”可以包含：

硬性规则

• 输出必须符合指定的 JSON Schema；
• 每条新闻必须包含标题、摘要、日期和来源链接；
• 日期必须位于本周统计区间；
• 来源链接必须能够访问；
• 涉及数字的结论必须附带来源；
• 同一事件不得重复出现；
• 不得包含预先定义的禁用主题或敏感信息。

软性标准

• 摘要是否忠于原文；
• 信源是否具有足够权威性；
• 是否覆盖本周最重要的行业变化；
• 观点与事实是否明确区分；
• 表达是否适合目标读者。

这里最重要的一点是：不要把所有检查都交给大模型。

JSON 字段是否完整、日期是否超出范围、URL 是否能访问，这些问题普通代码检查得更快、更稳定，也更便宜。模型更适合处理“摘要是否忠于来源”“这几条新闻是否属于同一事件”等带有语义判断的问题。

能用确定性代码判断的，就不要用概率模型猜。

一份可执行的验收标准，应该接近下面这样：

required_fields:
- title
- summary
- published_at
- source_url

hard_rules:
date_in_range: true
source_url_reachable: true
numeric_claim_has_citation: true
duplicate_event: false

review_rubric:
factuality: 0.4
source_quality: 0.3
completeness: 0.2
style: 0.1

这比“请认真检查内容是否准确”更有价值，因为它明确告诉系统：检查什么、怎么判断、失败后往哪里走。

变化二：多模型关系，从“流水线接力”变成“生成—复核—裁决”

早期多模型工作流更像流水线：

模型 A 搜索 → 模型 B 写作 → 模型 C 润色 → 输出

问题是，流水线中的每个模型都可能把上游错误包装得更加完整。错误一旦进入第一步，后面的模型未必会纠正，反而可能让它变得更像真的。

更可靠的结构应该是：

输入
↓
生成模型
↓
硬规则检查
↓
评审模型
├── 通过 → 保存并交付
├── 可修复 → 携带反馈重试
└── 高风险或连续失败 → 人工处理

生成者、评审者和裁决者需要承担不同职责。

三种常见架构怎么选？

让同一个模型“写完后再检查一遍”，当然比完全不检查好，但它并不等于可靠验收。

如果评审模型只看到生成结果，没有原始资料，也没有明确标准，那么它做的往往不是事实核查，而是“这段话读起来像不像真的”。

因此，评审环节至少应满足三个条件：

• 有清晰的 rubric，而不是模糊地要求“判断质量”；
• 能访问独立证据，例如原始网页、数据库记录或检索结果；
• 允许输出失败原因，而不只是一个孤立分数。

模型不是越多越可靠。三个模型共享同一份错误资料时，完全可能一起自信地犯错。

变化三：团队指标，从“调用成功率”转向“验收通过率与失败成本”

如果团队的工作流看板只有请求量、延迟、Token 和接口报错率，那么看到的只是系统有没有运行，看不到它有没有创造价值。

进入生产阶段后，至少应该补充以下指标：

• 一次验收通过率：无需重试即可合格的任务占比；
• 平均重试次数：每个合格结果经历了多少次生成；
• 人工介入率：多少任务最终需要人工处理；
• 错误逃逸率：已被系统判定合格、但人工抽检仍发现问题的比例；
• 每个合格结果的平均成本：模型调用、检索、重试和人工成本之和；
• 失败原因分布：格式、事实、来源、时效、合规等错误分别占多少。

这会改变团队对“便宜模型”的理解。

一个单次调用价格较低的模型，如果经常需要多轮返工，再加上人工抽检，最终未必便宜。反过来，一个单次成本更高、但一次通过率更稳定的模型，可能拥有更低的交付成本。

真正应该比较的不是单次价格，而是：

有效工作流价值 = 合格结果数量 ÷ 总调用成本与人工成本

失败后不能只有“再试一次”

不同错误需要不同的恢复路径：

• JSON 缺字段：使用代码修复，或要求模型定向补全；
• 链接失效：重新检索，不必重写整份周报；
• 数字缺少证据：回到原始资料，重新定位引用；
• 摘要与来源冲突：携带冲突证据重新生成；
• 高风险结论：切换更强模型复核，或进入人工队列；
• 连续多次失败：停止自动重试，避免成本失控。

一条可验收链路，代码并不复杂

下面是一段不绑定具体框架的 Python 伪代码：

result = generate(task)

hard_errors = validate_schema_and_sources(result)

if hard_errors:
result = retry_generate(
task,
feedback=hard_errors
)

review = evaluate(
result=result,
rubric={
"factuality": 0.4,
"source_quality": 0.3,
"completeness": 0.2,
"style": 0.1
}
)

if review.score >= 0.85:
save_as_accepted(result)

elif review.score >= 0.65:
retry_generate(
task,
feedback=review.feedback
)

else:
send_to_human(result, review)

需要特别提醒：代码里的 0.85 和 0.65 只是结构示例，不能凭感觉直接拿到生产环境使用。

正确做法是准备一批经过人工标注的真实样本，比较模型评分与人工结论，再校准通过、重试和转人工的阈值。模型评分也不能完全替代硬规则与人工抽检。

否则，所谓“85 分合格”只是给不确定性套上了一个看起来精确的数字。

实测应该怎么做：不要只比较一次调用价格

为了避免编造测试结果，本文不提供缺少原始 Trace、固定样本和计价依据的“伪实测数字”。普通团队可以用同一批真实任务，完成一组可复现测试。

建议准备至少 20 条真实任务，比较四种方案：

1. 单模型直接生成；

2. 单模型生成后自检；

3. 一个模型生成、另一个模型复核；

4. 硬规则检查＋模型评审＋人工兜底。

模型组合测试表可以这样记录：

每次运行还应保留 Trace，至少记录：

任务 ID：weekly-report-007
生成模型：已脱敏记录
评审模型：已脱敏记录
生成耗时：由系统自动记录
输入/输出 Token：由接口返回值记录
硬规则结果：链接失效 1 条
评审结果：未通过
失败原因：数字缺少原始来源
处理路径：重新检索后重试
最终状态：通过 / 人工处理

发布评测文章时，最好附上一张脱敏后的真实 Trace 截图。没有原始记录，就不要用单个成功案例推导“某种架构提升了多少”。

普通团队的最小落地方案：先做一条可验收链路

很多团队看到这里，第一反应可能是：这套系统会不会太复杂？

其实，最小版本并不需要五六个 Agent。你甚至可以从一个 JSON 检查器开始。

第一步：选择容易判断的高频任务

优先选择：

• 输入范围比较稳定；
• 输出结构能够固定；
• 有明确事实来源；
• 当前存在重复人工返工。

行业周报、商品信息整理、客服工单分类、合同字段提取，都比“制定公司战略”更适合作为第一条链路。

第二步：建立单模型基线

先不要急着增加评审模型。让一个模型处理固定任务，并记录：

• 哪些错误最常见；
• 哪些错误可以用代码判断；
• 哪些错误必须依赖语义评审；
• 哪些错误需要人工负责。

没有基线，后续增加模型只是在增加复杂度。

第三步：拆出硬规则和软评审

硬规则交给代码，软判断交给模型。

例如，周报中的日期范围、字段完整性和链接状态由程序检查；摘要忠实度、信源质量和内容完整性由评审模型判断。

第四步：设置三个出口

每次验收后，只允许进入三种状态：

• 通过：保存、发布或进入下一业务环节；
• 重试：携带具体错误反馈重新生成；
• 人工：高风险、低置信度或连续失败时进入人工队列。

不要无限重试。无限重试不是自动化，而是自动烧钱。

第五步：最后再比较模型组合

当验收标准和测试集基本稳定后，再比较不同模型在生成、评审和重试环节的表现。

此时你比较的不再是谁写得“看起来更好”，而是谁能以更低的综合成本，稳定产出更多合格结果。

如果你准备验证自己的第一条“可验收 AI 工作流”，可以从同一个任务、同一份验收标准开始，通过 api.884819.xyz 统一调用可用模型，记录输出、耗时和成本，再计算每个合格结果的平均成本。

8848AI 平台使用用户名和密码即可注册，无需邮箱验证；平台内置 AI 对话功能，注册后可以直接使用。国产模型如 Deepseek、千问等完全免费，没有月租和订阅，其他模型按量付费。

AI 的下一场竞争，是交付能力竞争

未来普通团队与 AI 的差距，可能不在于谁更早接入新模型，而在于谁更早建立了一套系统，能够回答三个问题：

1. 什么是正确的结果？

2. 系统如何发现哪里错了？

3. 发现错误之后应该怎么办？

多模型协作不是让几个模型在同一个聊天框里讨论，也不是把调用链画得越来越复杂。它真正的价值，是把生成、检查、修复和人工责任连接成一个可观察的闭环。

模型会继续更新，价格也会继续变化。但一套经过真实任务校准的验收标准、失败路由和评测数据，不会随着某个模型版本下线而失效。

不过，新的问题也随之出现：如果负责验收的模型本身会误判，谁来验收“验收者”？

下一篇，我们将拆解 AI 工作流中最容易被忽视的一层——如何建立评审模型、人工抽检与黄金测试集之间的校准机制，避免多个模型只是一起自信地犯错。

下一篇建议阅读：《谁来验收AI验收员？普通团队搭建模型评测集的四个常见误区》

#AI工作流 #AIAgent #模型评测 #多模型协作 #人工智能 #AI教程 #8848AI