企业官网建设流程全解析

1. 选模型这事，聪明真的不是第一诉求

1.1 我为什么开始纠结"敢不敢用"

过去三个月，我几乎每天都在回答同一个问题：给 Agent 选模型，到底看什么。你可能会说，看智力啊，哪个聪明选哪个。但真正跑过生产环境的人，多半会给你另一个答案——先别问哪个聪明，先问哪个你敢用。这里说的"敢用"，不是玄学，而是五个非常具体的维度：成本算得过来、延迟扛得住、输出稳定能校验、出错时兜得住、被质疑时还能复盘。

最早让我意识到这件事的，是一个客服 Agent 项目。当时团队里的第一反应也是"选能力天花板最高的那个"，于是把主力旗舰模型接了进来。结果业务方试用了一周，反馈非常统一：答得是挺聪明，但我们不敢让它在真实会话里跑。原因也很具体——单次会话的平均成本比原方案高了将近一个数量级，偶尔还会出现一本正经胡说八道的情况，客服主管甚至说"它要是敢给用户承诺退款，我是要负责任的"。

后来我们把评分第二梯队的模型换上去，配合一些工程手段，反而顺利全量上线了。这个反差让我开始认真思考一个问题：Agent 模型选型，本质上不是"选最强"，而是"选最敢用的"。能力强但不可控，等于埋雷；能力中等但可控、可测、可兜底，才是生产环境里真正能跑起来的东西。

1.2 一次事故：模型很聪明，但我不敢用它跑业务

具体说说那次"不敢用"的事故。那套客服 Agent 已经接好了知识库，检索召回都调通了，旗舰模型对正序问题的回答准确率确实漂亮，内部评测一度做到 92%。结果周末一上量，问题就来了。

第一类问题：模型把"缺货"的商品包装成"有货"推荐给用户。复查日志发现，知识库里某 SKU 的状态明明是"库存不足"，模型却在回复里写"库存充足，可以下单"。它并不是没有读到知识库条目，而是在生成时"自由发挥"了一段。第二类问题：用户问退货政策，模型直接给了自己编的"七天无理由"版本，和平台真实规则差了三条。业务方看完直接要求灰度停掉，理由是"再跑下去，客诉和退赔成本比模型费贵十倍"。

这件事让我彻底明白了一个道理：Agent 场景里的"聪明"，必须加上工程约束才有意义。不是模型不行，是我没有任何校验机制去拦住模型的错误断言。后来我们把方案改成了"回答必须附来源引用 + 低置信度强制转人工 + 敏感承诺词拦截"，才敢重新放量。模型没换，但"敢用程度"完全不同了。选型问题，从来不只是模型本身的物理指标问题，而是你为模型设计的整套防御体系问题。

2. 先拆需求，再谈选型

2.1 你的 Agent 是哪种形态：单轮、多轮还是自主决策

很多人在选型之前，其实没想清楚自己的 Agent 到底是什么形态。这直接决定了模型的选型优先级。

单轮问答型，就是用户问一句，模型回一句，中间不做工具调用、不查数据库。这种场景下，模型的语言能力、知识广度确实更重要，"聪明"占比高一些。典型代表是 FAQ 助手、文档解读、轻量客服。

多轮任务型，Agent 需要一边和用户对话，一边调用工具（查订单、改状态、查库存），然后根据工具返回结果继续生成。这种场景下，最容易卡住你的不是模型智商，而是工具调用准确率。模型如果总把参数传错、字段拼错、或者根本选错工具，任务成功率立刻跌到不能看。

自主决策型，比如数据分析 Agent、代码执行 Agent，模型要自己规划步骤、逐步执行、根据中间结果修正方向。这种场景对"可控性"和"可观测性"的要求几乎是第一位的，因为你不可能每一步都盯着它。总结一句：形态越复杂，"聪明"的权重就越低，"听话、稳定、好追踪"的权重越高。选型前先对号入座，后面才不至于跑偏。

2.2 给不同业务场景划一条"敢用边界"

"敢用"不是一个绝对概念，而是分层的。我给自己的项目做了一张风险分级表，每次选型之前先拿业务对号入座，再决定模型策略。

这张表最大的价值是帮你拒绝"一刀切"的冲动。同一个模型，在文案场景可能"敢用"，在金融建议场景就是"不敢用"。很多选型失败，不是模型不行，而是你没给场景设置对应的风险闸门。在低风险场景里，"聪明"占七成；在高风险场景里，"稳定、可验证、可回滚"占九成，智力反而不那么重要。这是整个选型框架的起点。

2.3 别照抄别人的选型清单

前一阵有朋友问我，某个社区整理的"Agent 模型排行榜"能不能直接照着选。我的回答是：可以看，但千万别照抄。原因很简单，别人榜单上的测试集，和你业务里的真实数据完全是两码事。

比如某个榜单测的是"通用知识问答"，而你的业务是"商品售后工单分类"，两者需要的模型能力几乎没有交集。再比如，有些排行榜把上下文长度排得很高，但你的 Agent 实际场景里根本用不到长上下文，反而是"工具调用稳定性"更重要——这些差异，榜单根本体现不出来。

我建议的做法是：把别人的榜单当作初筛工具，先圈出候选池，然后立刻进入自己的业务用例评测。宁可多花一周做自有语料的评测，也不要省掉这一步直接抄答案。因为选模型不是买手机看跑分，而是给你的业务流程挑一个"器官"，它必须和你几十万条历史工单、你现有的工具生态、你的兜底机制严丝合缝地配合。

3. 七个"敢用"硬指标，比智商重要

3.1 工具调用与结构化输出：Agent 的命门

如果只能听我一句话，那就是重点盯工具调用能力。Agent 和普通聊天最大的区别在于，它需要按约定的结构去调用外部系统——查库存、下订单、生成报表。这意味着模型的输出必须是"机器可解析"的，而不是"语言通顺"的。

我遇到过最典型的问题：模型在回答里写了一句自然语言"好的，我帮你查一下订单"，然后紧跟一个 JSON 快照，但那个 JSON 不是标准的 JSON，它带了注释、多了一个逗号、甚至把字段名从 order_id 悄悄写成了 orderId。下游系统解析直接报错，Agent 流程当场中断。

评测工具调用能力时，我一般看三个细项：参数准确率（传进去的 key 和 value 是否正确）、工具选择准确率（到底调用了该调用的工具）、结构化输出合法率（返回的 JSON/代码是否可直接解析）。其中结构化输出合法率是很多团队最容易忽略的，它不影响你人工看着顺不顺眼，但直接影响自动化链路能不能跑通。实测下来，不同模型在这项上差别巨大，有的能到 99%，有的只有 85% 出头，而这十几个百分点的差距，就决定了你的 Agent 流程要写多少重试逻辑和修复代码。

3.2 成本模型：先算账，再谈聪明

"敢用"的第二个硬指标是钱。Agent 场景的 token 消耗和普通聊天完全不是一个量级。普通对话一次可能 2000~3000 token 就结束了，Agent 任务因为要多次传工具定义、多次调用模型、多次拼接工具返回结果，单次任务经常轻松到一万 token 以上。

我带过一个实际项目，Agent 每完成一次任务大约消耗 input 5000 token、output 750 token。假设每天一万次完整任务，跑 30 天，总消耗是：input 约 15 亿 token，output 约 2.25 亿 token。按一组参考定价来算（input 每百万 token 2 美元、output 每百万 token 8 美元），月成本大约是 4800 美元；如果换成一位更贵的旗舰选手（假设 input 每百万 token 15 美元、output 每百万 token 60 美元），就能飙到 36000 美元以上。这中间的差距，足够你再招一个工程师了。

所以选型时，必须建立自己的 cost per task（单任务成本）指标，而不是只看单次 API 报价。先拿 100 条真实 Agent 日志跑一遍，统计平均 token 量，再套进不同模型的报价体系里算总账。算完之后你会发现，很多纸面上"很强"的模型，在你的调用频率下压根不具备可运营性。

3.3 延迟与吞吐：用户等不起，自动化更等不起

第三个指标是延迟。Agent 场景的延迟不是单次模型回复的延迟，而是整个任务链路的端到端延迟。一次工具调用可能要经历模型推理、工具执行、再次推理多个来回，任何一个环节变慢，体验都会指数级恶化。

我习惯关注两个数字：首 token 延迟（TTFT）和每秒生成 token 数。TTFT 决定用户感知上"它到底有没有开始干活"，生成速度决定后续链路总时长。还有个容易踩的坑：并发一上去，模型的 P95 延迟会剧烈抖动。有的模型单发测试很快，到了 200 并发直接涨了 3 倍以上。所以我评测延迟时，从不看单发数据，一定要带并发压测。

如果你在做的是无人值守的自动化 Agent，延迟可能没那么敏感，但吞吐就变得很重要。批处理任务里，单位时间能处理的任务数直接决定了业务上限。这类场景下，我反而更愿意选轻量模型加并行方案，而不是指望一个慢悠悠的旗舰模型单线处理所有请求。

3.4 幻觉与误判率：出错能不能兜住

幻觉是 Agent 选型里永远绕不开的话题。但我想说的是，真正区分"敢用"和"不敢用"的，不是幻觉率本身，而是你针对幻觉的兜底能力。

不同模型在知识问答类的幻觉率确实有差异，但更大的差异在于：面对不确定问题时，它是倾向"胡说"还是倾向"承认不知道"。有的模型开了一个很不好的头——哪怕知识库里没有相关内容，它也要强行生成一个推理过程，最后给出一个貌似合理的答案。这种模型在 Agent 场景里极其危险，因为你不知道它哪句话是编的。

我的做法是三重防御：第一，选型时专门测"未知问题拒绝率"，把知识库里没有的问题丢给它，看它能不能老实说不知道；第二，要求模型在涉及关键事实时附带可验证的来源索引；第三，在业务层设置置信度阈值，低于阈值的答案直接转人工或触发二次核对。这三层下来，即使模型依然有幻觉，也不会直接穿透到用户端。

3.5 长上下文与记忆：多轮叠加的隐形陷阱

很多选型清单把"上下文长度"当作硬指标，动辄 128K、200K，觉得越长越厉害。实际在 Agent 场景里，长上下文带来的往往只是更贵的账单和更慢的响应，并不等于更好的表现。

Agent 任务有个显著特征：上下文会越滚越厚。第一轮你传了系统提示词、工具定义、用户问题；模型回复时提出需要某个数据，你调用工具查出结果，然后把工具返回拼进上下文；模型继续推理；又来一轮工具调用……几轮下来，早期塞进去的内容可能已经膨胀到两三万 token。这时候模型对长上下文的注意力能力就开始分化：有的模型还能准确提取最初那条关键信息，有的已经"忘记"了。

所以我的选型要求不是"上下文越长越好"，而是"在你要用的常见长度范围内保持稳定"。评测方法很简单：构造一段 8K、16K、32K 的上下文，在尾部插入一个需要引用上下文头部信息的问题，看它能不能答准。这个测试比单纯堆长度有价值得多，因为反映的是真实任务中的表现。

3.6 可控性与审计：出事的时候能不能复盘

"敢不敢用"还有一个经常被忽略的维度——出事以后，你能不能搞清楚到底发生了什么。

我见过一个线上事故处理现场：Agent 莫名其妙执行了一个错误操作，团队查日志发现，模型把某个字段名理解错了，生成了一个不合理的调用参数。但因为当时用的是外部 API 服务，缺省配置下日志留存不全，他们根本拿不到原始请求响应体，复盘都无从谈起。最后只能靠业务侧的痕迹倒推，非常被动。

如果你要把 Agent 用于自动化操作，选型时就一定要确认三件事：推理日志是否完整可导出、每次工具调用的输入输出是否留痕、链路追踪是否有唯一 ID 贯穿。有些模型平台只提供很粗糙的调用日志，有些则是默认关闭内容存储的——这些不是技术问题和合规问题，而是直接决定你敢不敢拿它跑自动化决策。

3.7 生态与运营：更新频率、社区和降级方案

最后一个指标很少有人一开始就想到，但它往往是后期最头疼的：模型生态与运营连续性。你选中的模型能不能稳定迭代？它的厂商更新策略怎样？社区有没有成熟的踩坑案例和最佳实践？万一它停服或者大幅涨价，你的降级方案是什么？

我在一个项目里吃过亏：选了一个当时表现惊艳的小众模型，用了两个月，对方突然升级了版本，结果工具调用的行为模式完全变了，线上 Agent 成功率骤降。更麻烦的是，由于模型太小众，社区里根本找不到可以参考的迁移案例，团队只能自己硬着头皮重新调。

现在我的做法是把"降级路径"写进选型评估表：至少要保证两个不同体系的候选模型都能跑通你的核心流程，并且把 Prompt 结构和工具定义写成模型无关的格式，这样切换成本才会可控。选模型不是一锤子买卖，你要的是长期可运营，而不是一次性惊艳。

4. 我的实操评测清单

4.1 用业务用例，别用通用榜单

很多人问我，评测到底该用什么样的测试集。我的答案非常朴素：拿你自己真实的业务流量样本，其他都是辅助。

通用榜单测的是模型平均能力，但你要的不是平均值，而是它在你的领域、你的工具链、你的用户语气下的表现。我每次选型都做这么一件事：从生产环境随机抽 300~500 条真实会话记录，脱敏后整理成一条标准评测集。里面包含正常问答、少见的边角情况、以前模型翻过车的典型坑。再用这段评测集跑候选模型，看谁的表现最稳。

这一步非常花时间，但绝对值得。因为评测集的质量直接决定选型的准确性。别再拿网上别人贴的几十条示例测试题当依据了，那些测出来的是"跑分"，你真正需要的是"业务通过率"。

4.2 离线评审跑分表：一张表框住七个指标

结合前面讲的七个硬指标，我做成了一张离线评审表，每个候选模型进来先过一遍这张表。你可以直接抄去改一版，注意结合自己的场景调整权重。

这套表做完之后，我给每个候选模型打分，然后四舍五入得到一个"敢用指数"。我对团队的要求是：敢用指数没到 75 分，再聪明也先缓一缓。分数达标了，再进入灰度环节。

4.3 在线灰度与成本监控：离线过了不算数

离线评测只是入场券，真正决定"敢不敢全量"的，是在线灰度。

我会先放 10% 的流量给候选模型，观察至少 3 个业务日。监控不是只看准确率，而是看一组复合指标：任务完成率、平均重试次数、人工介入率、单任务成本、P95 延迟、用户负面反馈率。其中"人工介入率"是我最看重的，它直接反映模型在真实噪音环境里的"省心程度"。

灰度期间还一定要盯成本曲线。因为离线测试的 token 量是基于理想路径算的，真实用户会走各种奇怪分支，工具调用次数、上下文长度都可能翻倍。我会在灰度期设一个成本红线，比如单任务成本超过预期的 1.5 倍就立即暂停，查清楚原因再继续。不要等月底账单出来才发现预算爆了，那时候已经晚了。

4.4 一套可以直接抄的选型步骤

最后分享一个我觉得适用于大部分团队的操作流程，五步走：

第一步，定义自己的评测集，至少 300 条真实业务样本，包含工具调用场景。第二步，圈出 3~5 个候选模型，先跑一遍离线跑分表，筛选出前两位。第三步，对前两位做成本模拟，按灰度流量水平折算"如果全量上线月成本是多少"。第四步，小流量灰度 3~5 天，监控任务完成率和人工介入率，守住成本红线。第五步，灰度通过后再规划降级方案，把另一个候选模型也接入备用通道。

这套流程看起来走得慢，实际上比"直接上旗舰模型，翻车后花两周救火"快得多。模型选型本身不是一次性决策，而是一个持续评估的工程环节，跑顺了以后，每次有新的好模型出来，你都可以用同一套漏斗快速判断要不要换。

5. 常见翻车现场与排查技巧

5.1 上下文爆炸：工具结果把 context 堆满了

这是 Agent 场景里我最常遇到的翻车。一次任务里，Agent 连续调了三次工具，每次工具返回都是一大段 JSON 表格，十几轮对话下来上下文直接冲到了 30K token。结果就是从某一轮开始，模型回复质量明显下降，因为它已经分不清哪些是早期关键信息了。

针对这个问题，我总结了一组组合拳：第一，每轮工具结果不要全部塞进后续上下文，抽取关键字段压缩成摘要；第二，历史对话超过一定长度后做滚动摘要，只保留用户原始诉求和未完成任务的关键状态；第三，给系统提示词加规则，明确要求模型"只参考最近一次工具结果"，减少无关信息干扰。这几个措施实测可以把 Agent 在长任务里的上下文消耗砍掉 40% 以上，同时保住任务成功率。

5.2 输出格式不稳定：JSON 里永远有惊喜

模型输出结构化数据时，偶尔会带点"人类习惯"：多了个注释、结尾多了个逗号、字段名大小写不一致、甚至突然用 Markdown 代码块把 JSON 包起来。每次格式错误，Agent 流程就得重试一次，重试次数一多，成本和延迟双双恶化。

我现在的处理分为两层：第一层是在 Prompt 里做强约束，但窗口期命中率还不够稳，必须配合第二层——解析层兜底。我通常会给输出格式做"约束解码"式的校验，或者写一个小工具：先用正则把外围说明文字剥离，再尝试解析 JSON，解析失败时自动修复，比如去掉尾部逗号、补齐缺失引号。这几个自动化修复规则就能把格式通过率从 90% 拉到 99%，别小看这几个点，在每天上万次调用下，它直接决定你要不要半夜爬起来处理告警。

5.3 工具选择错乱：模型开始"自由发挥"

模型明明该调"查询库存"工具，却去调了"创建订单"；该把参数 order_id 填进去，却填成了 sku 码。这类工具选择错乱在 Agent 场景里是要特别注意的，因为它不是格式错误，而是逻辑错误，不会报错，但会造成业务链路的连锁问题。

我的排查经验是：先看工具定义是否足够精确。很多时候模型选错工具，是因为工具描述写得太模糊，或者工具之间功能边界不清。我会把每个工具的描述改成"什么时候该用、什么时候不该用、输入字段的确切含义"，再加上一两个 few-shot 示例。改完以后正确率通常能涨一截。如果还不够，就在 Prompt 层面加一道"任务仲裁"指令：先让模型分析当前意图，再明确选择工具，再判断是否需要请求用户澄清。一步拆成三步，可以明显减少模型"猜"的冲动。

5.4 成本失控：一天烧掉一周预算

还有一个高频事故：灰度期表现正常，全量一放开，成本立刻爆炸。核心原因通常是真实流量里的"长尾对话"远超预期——有些用户的问题特别绕，Agent 被反复触发工具调用，一次会话可能跑出几十次模型请求，token 消耗直接翻几个数量级。

我给团队定的规矩是：全量上线前必须建立单会话成本告警。用"单任务平均 token 数 × 定价"设一个阈值，比如超过均值三倍就触发邮件提醒；同时给 Agent 设置最大工具调用轮数，超过 10 轮强制结束并转人工。这两个硬上限看起来有点粗暴，但在 Agent 场景里非常必要，它保证了最坏情况下的成本可控。没有这些护栏，再便宜的单次调用，也扛不住失控的调用次数。

5.5 生产环境降级策略：别让模型把你架在火上烤

最后一个常见问题不是模型跑了，而是模型挂了。Agent 业务对可用性的要求高于普通问答，一旦主模型在高峰期限流或者平台故障，你的 Agent 会立刻罢工。所以生产环境一定要有降级策略。

我的做法是主备双模型：主用模型负责常态流量，备用模型平时跑少量影子流量做健康监测，一旦主用模型告警，网关自动把流量切到备用模型。切换的时候业务可能短暂降智，但至少不会整体挂掉。另外，在 Prompt 和工具定义层面，我要保证两个模型之间可以无缝切换：所有工具 schema 用统一格式，系统提示词不要写死某个模型的专属表达。这样一来，"备用模型"就不会只是纸面的保险，而是真正随时能顶上来的后手。

还有一点经验：降级方案一定要演练过才算数。之前我们有个项目配置了备份模型，结果从来没真切过，真到故障那天才发现备份模型的工具调用格式和主模型不一致，切过去反而引发更多报错。后来我们改成每周自动跑一次切换演练，再遇到故障就能真正无缝接上了。演练的价值，只有踩过坑的人才能体会。

6. 一点个人体会，写在最后

做了这么多次 Agent 模型选型，我的核心感触是：模型的能力争议会一直被讨论，但生产环境真正在意的是"谁能稳定地把活干完"。聪明是一种潜力，敢用才是一种能力。再聪明的模型，如果成本算不过来、输出不可解析、出错之后无法复盘，你在生产现场就永远不敢把关键流程交给它。

我个人建议，每个团队都尽快沉淀一份自己的"敢用清单"——不用多，三五页纸就够，涵盖刚才说的成本、延迟、结构化输出、工具调用、兜底机制、降级路径。把它变成每次选型的固定动作。你会发现，这套方法论不仅能帮你选出真正能上线的模型，还能倒逼你把 Agent 的工程质量往上拉一大截。因为很多时候，不是模型配不上业务，而是整个链路里少了一环让你"敢"的保障。

最后再分享一个小技巧：选型完成后最好每季度重新测评一轮。模型迭代太快，今天的"不敢用"可能三个月后就变成"很敢用"，别让刻板印象拦住更好的方案。选型不是一个终点，而是一套持续运转的评估机制。