公司选什么工具、选什么模型，背后是一套决策模型

做企业 AI 落地，我几乎每周都会被问同一个问题：「我们用哪个模型好？」「那个工具是不是很厉害？」

这两个问题，问错了。

因为「哪个模型好」是个没有标准答案的问题。同一个模型，在查价格这种简单活上可能够用，在写复杂的合同分析上可能就不行；反过来，贵的模型在简单活上纯属浪费。选模型、选工具，真正该问的是另一件事：我的任务需要什么，我的预算能承受什么——这背后是一套决策模型。

这篇文章把企业选型的决策框架讲清楚，不是给你一个答案，是给你一套思路。

一、第一步：按任务分级，而不是按「模型排行榜」选

先把你们的任务分个级，这是整个选型的地基：

• 高频、简单、重复的任务（查价、查舱、自动回个标准邮件）：要的是快、便宜、量大。这种活用顶级模型是浪费——一个顶十个的算力，干的是一块钱的活。
• 低频、复杂、需要深度推理的任务（合同分析、异常处理、复杂投诉）：要的是准。这种活值得用贵一点的模型，因为错一次的代价远超省下的模型钱。
• 中间地带：大多数日常任务都在这里，选一个「性价比」平衡的模型当默认，多数场景够用。

一句话：日常用便宜的、难活用贵的。 不是所有任务都配得上最贵模型，也不是所有任务都该省那点钱。

二、第二步：按场景匹配工具，不只看模型

模型只是 Agent 的一部分。工具能力经常被忽视，但它决定了 Agent 能不能真正干活：

• 你们的 Agent 需要读 PDF 吗？需要自动查网站吗？
• 需要跟公司系统对接（ERP、CRM、运价表）吗？
• 需要记忆吗——能不能记住上次跟这个客户怎么谈的？
• 需要画图、做表格、生成图片吗？

选型的时候，把这些需求列出来，跟模型的工具支持对比。模型再聪明，工具不匹配，Agent 也干不了活。 比如你们要做一个自动查舱 Agent，模型再强，如果接不上船期数据源，就是空中楼阁。

三、工具按角色分工：开发维护类 vs 承载运行类

工具除了「跟业务系统对接」这一层，还有一层更基础的分工常被忽略：有些工具是用来改 Agent 的，有些工具是用来跑 Agent 的。 把这层想清楚，工具选型才不会乱。

开发维护类工具：用来升级 Agent

这类工具的主要工作是「改 Agent」——改它的提示词（Prompt）、改它的配置文件（MD 文件）、改它的规则和工具清单。你见过的那种「命令行里跟 AI 对话，让它写代码、改文件」的工具，就是这一类。

典型例子：Claude Code、Codex。它们擅长的是把「想改什么」变成「实际改好的文件」：告诉它「把询价 Agent 的提示词改得更简洁」，它帮你改完、还能帮你检查有没有改错。

中小企业的用法：拿这类工具当「改 Agent 的入口」——提示词要调、规则要改、新工具要接，都用它来动手。它解决的是「怎么改」，不是「改完在哪跑」。

承载运行类工具：用来跑 Agent

这类工具是 Agent 的「宿主」：Agent 写好之后，在它上面跑起来。它提供 Agent 运行需要的底层能力——记忆（记住跟这个客户上次怎么谈的）、会话管理（一个 Agent 多个对话不乱）、调度（到点干活）、接入 IM 工具（在企业微信/微信里收发消息）等。

典型例子：OpenClaw、Hermes 这类运行时/宿主工具。你不需要自己写一套记忆和会话管理，用它提供的就行。

一条更省事的路：开发维护工具本身就能跑 Agent

还有第三个思路：直接用 Claude Code 这类开发工具的能力本身来当 Agent 宿主——让它按照你的提示词干活、记住上下文、一步步完成任务，这样就不用自研底层记忆和会话管理了。

这条路适合中小企业的场景：人少、不想维护底层系统，先把 Agent 跑起来、看效果，比什么都重要。缺点也很明显：开发和运行混在一个工具里，规模大了之后，版本管理、多人协作、长时间稳定运行这些事会开始吃力。

怎么选：先分清三个问题

别一上来就比工具参数，先回答三个问题：

1. 你的 Agent 现在主要是「被开发」还是「被运行」？ 刚开始大概率是边改边跑，一个开发维护类工具就够起步。
2. 要不要接入 IM（企业微信/微信）？ 要的话，承载运行类工具是必需——Agent 要在聊天工具里跟人协作，就得有宿主提供消息接入。
3. 团队有没有人愿意维护底层？ 没有就选「开发工具当宿主」的省事路线；有专门的人，再考虑拆成开发维护 + 承载运行两套。

先跑起来，再分角色。 起步阶段一个工具干两件事很正常；等 Agent 多了、要长期稳定跑了，再拆成「改 Agent 的」和「跑 Agent 的」两拨工具。

四、第三步：算整体成本，不是算单个模型的钱

中小企业最容易踩的坑：算成本只看「一次调用多少钱」。

但实际成本是另一笔账：

• 一个高频任务，一天跑几千次，每次省几毛钱，一年省下的是几万块
• 一个任务用便宜的模型准确率差 5%，多出来的错误要多少人去复核
• 贵的模型跑得慢，客户等报价多等十秒，丢不丢单

所以选型要看整体成本，而不是单价：

• 高频任务优先压低单价——选便宜的模型、精简提示词、减少不必要的调用
• 低频关键任务优先保证准确——贵一点没关系，错一次更贵
• 多 Agent 组合：别指望一个模型打天下，让便宜的干粗活、贵的干细活，组合起来整体成本最低

五、第四步：先跑试点验证，再定选型

决策模型再完善，纸上谈兵也不行。选型的最终裁判是试点：

• 拿真实的业务数据，让候选模型各跑一遍
• 比的不只是准确率，还有速度、成本、出错模式
• 让业务同事实际用几天，看他们愿意用哪个

选型不是一次性的，业务变了、新模型出来了、成本结构变了，都要重新评估。把选型当成一个持续的过程，而不是一次拍板。

六、一套可复用的决策思路

把上面四步收成一张「选型决策卡」，以后遇到任何工具/模型选择，按这个走：

1. 分级：这个任务是什么级别？高频简单还是低频复杂？
2. 匹配：需要的工具能力（对接系统、读文件、记忆等）是什么？
3. 算账：整体成本怎么算？高频压单价、关键保准确、组合降总成本？
4. 验证：拿真实数据试点，看实际表现而不是参数表

这套思路不针对任何具体产品——它是给「选择」这件事本身用的方法论。工具会换代、模型会升级，但这四个问题永远成立。

七、适用边界

这套框架适合已经有明确任务、准备正式选型的团队。如果任务本身还没想清楚，先别选型——先定义清楚「这个 Agent 要干什么」，见给 AI 定岗：先写岗位说明书。

我还没完全解决的问题：不同供应商的模型在实际业务里的表现差异，光看官方 benchmark 往往不准，需要一套更系统、更贴近自家数据的评测方法。目前靠「拿真实业务跑试点」兜底，但样本还不够多。

继续读：AI 员工值不值？用「省下的人力 / 花的钱」算一笔账；工作流接入后怎么持续评估？；搭一个 AI 员工，不用写代码。