AI模型罗盘：从ReAct到Agent的工程化选型与评测方法

看到AI Models – Political Compass这个标题，我第一反应不是某个具体项目，而是一张坐标图。最近两年，AI 模型的讨论里确实流行用罗盘、象限图这类形式给模型做定位。热度高的讨论往往落在“这个模型在价值观上更接近哪一边”上，但对大多数做产品、做 Agent、做企业应用的工程师来说，真正该问的不是一个立场标签，而是：它在我需要的任务上，到底处在什么位置。

孤立地从标题看，我无法替这个项目确认它有没有完整榜单、官方结论或固定算法。我更愿意把它当作一个工程启发：AI 模型越来越多，靠记忆和排行榜已经无法做选型了，每个人都需要一套属于自己的模型坐标系。这篇文章不打算复述任何项目说明，只想聊聊如何把“模型罗盘”做成真有指导意义的工程方法。

1. 先搞清楚：AI 模型为什么需要一张“罗盘”

1.1 模型一多，选型就变成一道开放题

过去选模型很直接，你可能只需要在固定入口里挑一个表现最好的。今天的局面已经完全不同。通用对话模型、推理模型、函数调用模型、本地小模型、垂直生成模型，还有 AI 编程、AI 短剧、AI 广告视频、语音合成、歌声转换这些细分场景，每个名字背后都有自己的适用边界。

当模型数量超过人的日常关注范围，真正困难的不是知道某个模型存在，而是判断它该出现在哪条工作流里。

排行榜能回答“谁的综合分数高”，但回答不了“这个模型适不适合我的任务”。一个在通用问答榜上很高的模型，可能在多步工具调用里输出不稳定；一个在代码基准上靠前的模型，可能放到真实仓库上下文里表现平庸。这就是为什么需要坐标系：你只有在固定维度上反复比较，才能把选型从“感觉”变成“可复现”。

1.2 “罗盘”不是立场标签，而是工程坐标系

把 Political Compass 这个形式借过来，不等于要给模型贴立场标签。

立场标签存在两个工程问题：一是标签不稳定，换一种问法可能就变了；二是标签不能直接指导调用，就算你知道一个模型偏向某种表达风格，也不清楚应该把它放在 Agent 流程的哪一步。

我更愿意把这张图改造成多维工程坐标系。横轴可以是“推理能力”和“执行能力”，纵轴可以是“成本”和“稳定性”，旁边再挂上“上下文容量”“部署可控性”“安全边界”这些维度。所谓模型罗盘，不应该是为了给人贴标签，而是为了回答三个问题：

• 这个模型擅长哪些任务？
• 它会在哪些环节失效？
• 我的业务愿不愿意为它的缺点做补偿？

能回答这三个问题的坐标系，才是工程意义上的罗盘。

2. 从 ReAct 到 Agent：推理和行动正在成为关键轴

2.1 ReAct 不是“多一步思考”，而是把推理变成可执行的循环

谈论 AI Agent 时，很难避开 ReAct 这篇论文：ReAct: Synergizing Reasoning and Acting in Language Models。它的核心思想并不复杂：模型在生成回复时，不是一次性输出最终答案，而是交替执行“想、做、看”三步。

具体来说，模型先生成一个思考轨迹，决定下一步要调用什么工具；然后执行动作，比如查数据库、调 API、运行代码；拿到观察结果后，再继续思考，直到问题解决。相比单纯让模型“一步步思考”，ReAct 最大的变化是思考不再停留在文本内部，而是可以和外部环境发生交互。

这正好解释了为什么 Agent 类任务不能只用“问答能力”来评估模型。一个模型可以很会写答案，但如果不擅长把思考转成结构化动作，或者在拿到异常工具返回值后无法继续推理，它在 Agent 场景里依然不可用。

2.2 怎么判断一个模型适不适合当 Agent 底座

如果你正在做 AI Agent 开发，我建议从四个维度去测一个模型，而不是只看它的通用排行榜位置：

• 指令遵循稳定性：模型能否稳定输出你要求的 JSON 或固定格式？
• 工具调用可靠性：函数的参数名、参数类型、必填字段是否经常出错？
• 错误恢复能力：工具返回报错后，模型是重新调整计划，还是直接开始编答案？
• 多步成本：一个任务平均要调用几次模型？延迟和 token 消耗是否在可接受范围？

这四个维度里，工具调用可靠性和错误恢复能力最容易被忽略。实际落地时，模型把工具参数传错，比回答错一道题更麻烦，因为它会直接打断整条自动化链路。

2.3 从“模型能力”到“Agent 工程”的思维切换

过去写 Prompt，核心是让模型输出更好的文本。现在做 Agent，核心是让模型在循环中保持状态、调用工具、处理异常。

一个常见误区是：用选择题式的数据集评测模型，然后直接上 Agent。真实 Agent 任务里，模型不仅要选对答案，还要在拿到异常 observation 后不崩溃。比如 AI 编程场景，普通模型能写一两个文件，但真实仓库里可能要读取多个文件、执行测试、根据报错修复。这个场景更像 ReAct 循环，而不是单轮问答。

所以我在做模型选型时，会更倾向于把“任务完成率”而不是“回答正确率”作为第一指标。任务完成率包括是否在限定步数内完成、是否调用正确工具、是否在失败后成功恢复。这个指标更接近线上体验。

3. 建一张自己的模型定位图：六个维度比一个总榜更可靠

3.1 六维评测坐标

如果要把模型放进一张“罗盘”里，我建议至少使用六个维度。维度不是越多越好，但要能覆盖大多数业务选型需求。

这六个维度并不一定要同时用于所有项目。如果是快速验证，优先看推理质量、工具调用、速度成本；如果要进入生产，再把上下文容量、稳定与安全、部署可控性补上。

3.2 四类典型模型的位置

不同类型的模型，在坐标系里往往落在不同区域。我自己习惯把模型粗略分成四类：

这里要强调一点：这不是绝对分类。模型的能力位置来自你实测，而不是模型名字里带不带 Agent。一个主打通用对话的模型，经过系统提示词和工具定义调优后，也可能胜任部分 Agent 工作；一个垂直语音模型，如果非要让它做文本推理，结果大概率不理想。

3.3 一个可复用的记录结构

评测结果一定要结构化留档。不要只记一句“这个模型还行”，否则两个月后新模型出来时，你根本没有可比数据。

我自己会把每次评测记录成 JSONL 格式，类似这样：

{ "date": "2025-05-20", "model": "example-model", "task_type": "tool_call", "prompt": "帮我查一下杭州今天的温度，并转换成华氏度", "expected": "调用天气 API，完成单位转换", "output": { "action": "weather_api", "params": { "city": "杭州", "unit": "fahrenheit" } }, "pass": true, "latency_ms": 1850, "cost_usd": 0.0031, "notes": "首次请求漏传日期，重试后正常" }

每一次请求的提示词、参数、输出、是否通过、耗时、成本都留下。后期换模型时，直接用同一批历史样本跑一遍，比凭记忆判断要可靠得多。

注意：用于对比的请求参数要尽量一致，比如 temperature、max_tokens、top_p。参数不一致时，结果差异可能来自参数，而不是模型本身。

4. 从榜单到落地：模型选型应该跑完这条链路

4.1 先搭最小评测集，不要急着搭评测平台

很多人一开始就搭一个评测平台，结果被平台建设拖住，模型选型反而没推进。我更建议先做一个最小评测集。

具体做法是从真实业务里挑 20 到 50 个样本，覆盖三类情况：典型任务、边界输入、工具调用。典型任务用来判断日常效果，边界输入用来暴露模型弱点，工具调用用来验证 Agent 场景。

然后给每个样本定义通过标准。这个标准不一定要复杂，可以是“输出格式正确且关键信息完整”“调用了正确工具且参数无缺失”“拒绝回答时给出了合规理由”。前几次先人工判读，后面再逐步自动化。

这个流程不复杂，但能绕开两个常见问题：一是直接用公开基准题，结果和线上业务脱节；二是只测单轮问答，无法暴露工具调用和异常处理问题。

4.2 按照“单任务 → 小批量 → 灰度”的顺序推进

模型选型不是一次测试定生死，我更建议按三个阶梯推进。

第一步是单任务验证。先用一条真实请求跑通整个链路，看模型原始输出、日志、工具调用结果，确认流程没有断。这里不要急着调参数，先把输入输出都看明白。

第二步是小批量评估。用 20 到 50 个样本跑一轮，记录通过率、平均延迟、失败原因。如果失败集中在某个特定类型，说明模型在这个场景有明确短板。此时可以针对性地改提示词或换模型。

第三步是线上灰度。小批量通过后，用低流量真实请求验证。重点看业务指标变化，比如用户重试率、客服转人工率、任务完成率、响应超时率。如果业务指标没有恶化，再逐步放大流量。

注意：不要在小批量通过几天后就立刻全量切换。线上环境有超时、并发、重试、网络抖动等小批量测试覆盖不到的问题，灰度期至少要覆盖一个完整业务周期。

4.3 本地部署把资源边界也算进去

如果方案要求本地部署，选型时要额外增加一组约束。

本地部署不是简单把模型权重下载下来就能跑。你可能要考虑模型格式、量化级别、显存占用、吞吐、批处理能力、不同推理框架的算子差异。一个模型在 A 框架下表现正常，在 B 框架下可能因为算子不支持而变慢甚至失败。

这类问题不完全只属于大语言模型。垂直生成模型也一样，比如语音合成、歌声转换这类任务，模型权重拿到手之后，还要看采样率、音色一致性、推理速度、批处理能力。如果只追求生成效果，忽略了推理资源，很容易在规模化时卡住。

所以，我在做模型选型时会把“资源上限”当成评测条件之一：只允许用多大的 GPU、要跑多快的吞吐、最多能接受多少延迟。把这些条件写进评测记录，选出来的模型才是可落地的。

5. 选型误区与长期维护：地图只是起点

5.1 五类最常见的模型选型误判

模型选型最常见的错误，不是选错了模型，而是用错了比较方式。我总结了五个常见误判：

1. 只看综合排行榜，不看任务分布。综合分数高，不代表所有子任务都强。
2. 用单轮问答数据评估 Agent 模型。Agent 真正的关键是多轮工具调用和错误恢复。
3. 把提示词差异当成模型差异。两个模型用了不同 Prompt，结果差距根本不是模型本身造成的。
4. 忽略上下文窗口的实际可用性。模型宣称支持超长上下文，但长文本中间的信息可能记不住。
5. 没有安全边界验证。面对异常输入时，模型可能直接输出错误内容，而不是拒绝或修正。

前两个是选型阶段最容易犯的，后三个往往是上线后才会暴露的。如果能在一开始就把它们放进评测集，会省掉很多返工。

5.2 把评测沉淀成团队资产

模型更新速度快，今天的评测结果三个月后可能就不准确。所以评测不能是一次性动作，而要变成持续维护的资产。

我建议维护一张模型卡，包含候选模型、评测集版本、评测日期、统计结果、成本数据、决策结论和风险备注。每次新模型出来，先用同一套样本跑一遍，再讨论要不要切换。如果没有历史记录，任何新模型的“感觉更好”都很难验证。

这里还要提醒一句：不要只记录通过率。失败样本、失败原因、工具调用错误类型、成本变化、异常输入表现，这些信息比一个分数更有价值。因为它们能告诉你，如果要用这个模型，需要额外增加哪些规则、提示词或兜底逻辑。

5.3 边界意识：它适合你，不等于适合你的场景

最后想说的是边界意识。

没有万能模型。每个模型的适用边界由数据、训练目标、部署方式和成本共同决定。一个在客服场景好用的模型，可能在长文档理解上并不理想；一个在创意写作上出色的模型，可能不适合做严谨的工具调用。边界意识不是保守，而是为了减少不可控风险。

回到AI Models – Political Compass这个标题。如果让我提炼一个判断，那就是：罗盘的意义不在于告诉你哪一边是正确答案，而在于帮你建立方向感。模型世界还会继续膨胀，今天的最优解，三个月后可能就不再成立。真正有价值的东西，是你手里那套可复现的评测方法、边界意识和持续记录的习惯。