企业官网建设流程全解析

聊聊我这几个月做的一件"折腾事"。

上个月，有个做智能客服的朋友把我拉进会议室，就为了一个选型问题：多模态大模型到底该选哪家？他手里的场景并不复杂——用户上传一张商品故障截图，客服Agent需要识别图片内容、结合历史工单、调用库存系统接口，最后给出换货或维修建议。可就是这么个看似标准的流程，让我在十几个候选模型面前犯了难：参数表上写得天花乱坠，真实跑起来却各有各的翻车姿势。

后来我想了个办法：既然模型选型最难的不是"谁跑分高"，而是"谁在某条真实任务链上不出错"，那不如把几个主流的多模态Agent架构当成面试候选人，我当面试官，用一套统一的考卷挨个过一遍。考卷覆盖感知理解、规划与任务分解、工具调用、记忆保持、边界压力测试五个环节，每一位候选人都在完全相同的任务输入上答题，现场记录表现、报错、退化过程和最终产出质量。

这篇内容就是整场"模拟面试"的完整记录，包括每个候选架构的典型实现思路、实测评分、翻车细节，以及我在面试结束后根据真实业务场景给出的选型建议。无论你是正在做Agent落地的开发者，还是只想搞懂"多模态大模型到底差在哪"的产品经理，这套横评方法都可以直接抄走。

1. 为什么把大模型拉来面试：横评实验的初衷与考卷设计

1.1 多模态Agent的核心能力模型拆解

先说我为什么不直接做基准测试。市面上现有的多模态评测集大多把任务切成"看图问答""图片描述""图表推理"这种孤立的题目，而真实的多模态Agent任务是一条链路：感知 → 理解 → 规划 → 行动 → 记忆反馈。任何一个环节出问题，整条链路都会断掉。比如一张模糊的商品图片，评测集里只问"图里是什么"，但真实场景要求Agent先认出来是"电源适配器"，再结合型号字段判断是否和订单匹配，最后决定调用哪个接口。这就是评测分数和实际体验差距巨大的根源。

所以我这次横评的核心思路是：不考单点能力，考"闭环能力"。每个候选架构都要走完"感知输入 → 内部推理 → 生成工具调用 → 拿到结果后继续推理"的完整循环，我在每个环节埋入不同的坑，观察它们怎么处理。

1.2 五位候选人的"简历"

为了避免商业品牌干扰判断，也为了让结果更聚焦在架构层面，我给所有参与面试的模型起了代号，按典型架构形态分成五类：

这五个架构并不对应任何一款具体商业产品，而是代表了市面上主流的工程实现路线。实际选型时，你往往会发现某款产品混合了多类架构特性，但搞清楚"主干是哪条路线"依然有决定意义。

1.3 考题设计原则：从感知到行动的任务链路

我设计考卷时给自己定了几条规矩：所有候选人必须使用完全相同的中文输入文本和图片素材；题目必须是"链式任务"，也就是一道题内包含多个依赖步骤；所有答案都要求输出可被程序解析的结构化结果，不接受"我觉得应该是"这种模棱两可的回复。

比如第一轮有一道这样的题：

面试官：这张图片里有一份手写采购单，上面有三行商品名，其中一行被红笔划掉。请你提取所有未划掉商品的名字和数量，并判断这些商品是否都属于"办公用品"类目，最后以JSON格式输出。

这道题表面考OCR，实际考的是图片布局理解（被划掉的行不能录入）、类目常识（文具属于办公用品吗）、结构化输出（JSON格式）。链路里任何一个环节出错，整道题就白做。我这轮总共准备了20道类似设计的题目，分布在图像、视频、混合输入三种素材类型上。

1.4 评分规则与我的打分习惯

每道题按0到5分打分：0分代表完全失败且没有补救机制，3分代表最终答案正确但过程中需要人工纠偏，5分代表无障碍完成且输出可解析。特别说明一点：如果候选人输出了错误答案但用自然语言明确表达了"我不确定"，我最多给2分，因为这个问题在自动化流程里就意味着静默失败。如果候选人答错了还信心满满，直接0分，因为在Agent场景里这种状态最危险。

打分标准提前公布在下面，后面所有分数都按这套规则来。

2. 第一轮面试：感知与理解，谁能真正"看懂"复杂世界

2.1 静态图像理解：高分辨率细节是分水岭

第一轮先测静态图像，我准备了四类素材：自然场景照片、UI界面截图、密集文字文档扫描件、带有小尺寸关键信息的"陷阱图"。

自然场景照片上，候选A和候选B都表现稳健，照片里的主体识别、场景描述、情绪判断基本准确。但进入UI截图后差距立刻出现。我给它一张包含底部弹窗的原生App截图，询问"当前页面有几种不同样式的按钮"。候选B把弹窗里的文字按钮和页面底部的图标按钮混在一起数，输出"7种"，实际只有4种。候选A能区分视觉层级，正确给出4种。这个差异背后其实是架构问题：候选B的视觉编码器输出的是固定数量的视觉Token，当页面信息密度超过Token容量时，细节会被强制压缩，小元素之间产生粘连。

密集文档扫描件上的表现更有意思。候选C因为带了专门的OCR前置流水线，在纯印刷体文字提取上接近满分，识别速度和准确率都碾压其他候选人。但它的问题在于OCR和语言模型之间的"语义对齐"依赖检索模块，一旦文档里出现手写批注、荧光笔标记这类OCR不擅长的内容，它就把批注当作正文一起输出，产生"信息污染"。而候选A虽然原生OCR能力不如专业流水线，但它能理解笔迹覆盖关系，知道"手写内容覆盖了印刷文字，应当以手写为准"。

2.2 视频与时序理解：多数模型败在"帧间逻辑"

视频理解是这轮拉分最狠的一题。我准备了一段15秒的监控画面：一个人走进房间，把桌上的文件拿走，然后离开。题目要求候选人描述"发生了什么，并判断文件是否还在桌上"。

候选D在这个任务上显然经过了专门优化，它把多帧视频编码成带有时间戳的Token序列，能明确输出"第7秒该人拿走文件，第12秒离开，桌上文件已不在"。候选A作为统一全模态模型也能完成，但代价是它先抽帧再按帧输入，15秒视频消耗了大量Token，响应时间拉长到接近半分钟，在实时性敏感的场景里基本不可用。

最惨的是候选B。它把视频按固定间隔抽帧后当作多张图片拼接处理，完全丢失了动作时序信息，输出的答案是："房间里有一人站着，桌上有一叠文件。"它压根没看出"拿走"这个动作。面试进行到这里我已经确定了一个结论：如果你的Agent核心场景是视频巡检、直播审核这类强时序任务，就不要指望通用视觉语言拼接架构，它的架构天花板就在这里。

2.3 混合输入：音频和视觉的协同理解测试

第三小轮测试多模态混合输入。我让候选人同时听一段语音指令和看一张表格图片。语音内容是："只保留华北区的数据，把其他区域删掉，然后对华北区按销量降序排列。"

候选A原生支持音频输入，能端到端理解语音和图像的关系。候选B到E都没有原生音频功能，我只能把语音先转成文字再作为文本输入，这属于外接ASR方案。测试结果里有个细节值得注意：候选B在拿到"文本版的语音指令+表格图片"后，理解完全正确；但候选E因为参数规模小，没有真正把"两个模态的命令"统一合并，给出了"把华北区删掉"这种与语音指令完全相反的操作。这就是轻量模型的能力边界：它并不是不懂语音，而是当两个模态的信息需要同时参与推理时，计算资源不够用了。

2.4 第一轮的意外：小目标检测导致的连环失败

整轮考试里最让我意外的是那道"陷阱图"。图片是一张仓储货架照片，角落处有一张巴掌大的提示牌，上面写着"注意：此区域商品需冷藏"。题目是"这张照片里有没有特殊存储要求？如果有，请说明。"

候选C因为OCR流水线只对文字区域感兴趣，而提示牌像素大小不够触发它的文字检测阈值，直接漏读，回答"没有特殊要求"。候选B虽然在图片描述时提到"远处有个牌子"，但无法识别牌子上的文字，属于"看见了却没看懂"。候选A识别出提示牌内容且准确回答了冷藏要求。候选E干脆输出了一个很长的免责声明，说"图片中信息较多，可能影响判断"。

这个案例让我意识到一个共性问题：多数多模态大模型对小目标区域的文字识别能力远弱于大段文字。原因在于训练数据中"大段、清晰、居中"的文字占了绝对多数，模型天然倾向于忽略小尺寸视觉信息。做Agent场景的开发者一定要警惕：如果你的任务里存在"角落里的关键信息"，那就不能只依赖模型原生能力，要么在输入侧做图像分块放大，要么在前置流水线里补一个小目标检测模块。

3. 第二轮面试：规划与工具调用，Agent和聊天机器人的分界线

3.1 工具调用的格式稳定性：非法JSON是最隐蔽的杀手

通过感知层考试后，我进入第二轮，这一轮重点考察"能不能把事情做完"。第一道题是给定一个自然语言任务，要求候选人输出工具调用序列。任务："用户申请退款，但该商品已超过退货期，请查询该订单的物流状态，若物流显示已签收则拒绝退款并发送通知。"

这道题要求调用两次工具：第一次查询订单详情，第二次根据结果决定是否发送拒绝通知。五位候选人都知道要用工具，但格式稳定性差异巨大。候选A的响应格式严格匹配我预先定义的JSON Schema，参数名、类型完全正确：

{ "reasoning": "订单状态未知，需先查询物流以判断是否已签收", "tool_calls": [ { "tool_name": "query_order_logistics", "parameters": { "order_id": "SO-202406-078", "detail_level": "full" }, "next_on_success": "check_signature_status" } ] }

候选B则出现了典型的"模型式输出"问题：它在JSON之外添加了大段解释文字，又把reasoning字段和tool_calls字段的嵌套层级搞错，导致我的Agent框架第一次解析失败。我不得不加了一层"输出清洗器"，才把有效部分捞出来。这里有个很容易被忽视的坑：真实生产环境里，工具调用格式的稳定性比模型推理能力更影响整体成功率。一个每次都要清洗和重试的模型，即使最终结果正确，也会把端到端时延拉高好几倍。

3.2 多步任务分解质量：分得细不等于分得对

第二轮有一道经典的多步任务题，我让候选人处理这个请求："把本季度华东区所有销售额超过一万元的订单筛选出来，按金额降序排列，并生成一段给销售总监的摘要，摘要里必须包含最低金额订单的单号。"

候选E的分步逻辑最糟糕，它把任务拆成"筛选订单"和"排列订单"两步，但完全漏掉了"生成摘要"和"提取最低单号"这两个环节。更致命的是，它给出的筛选条件是"销售额大于一百"，单位错误，整个逻辑链条全部偏掉。候选D的视频架构在这类纯文本任务上暴露出短板，它擅长处理时序信息，但对结构化文本的抽数、排序、摘要这类"办公室工作"明显训练不足，中途试图调用一个不存在的"sort_sales"函数，这属于典型的工具推测幻觉。

候选A和候选C都完成了任务，但风格明显不同。候选C依靠检索增强模块先查了订单表结构，再执行筛选，过程更"程序化"，每一步都输出中间结果；候选A则是端到端推理，直接给出完整结果，中间过程不可见。从开发者角度，候选C的透明过程更容易调试，候选A的速度更快，但出错时排查成本更高。

3.3 一个完整实测：从PDF报表到Excel表格的链路

我拿一份真实脱敏的采购报表PDF做了个端到端测试，要求候选人："提取这份PDF中的所有采购记录，生成一张Excel表格，统计每个供应商的采购总金额，最后用一句话总结哪个供应商最值得注意。"

这是本次面试中链路最长的一道题，涉及OCR提取、表格结构还原、数据聚合、文本生成四个环节。候选C因为OCR流水线最强，提取和表格还原环节表现最好，但它把所有信息塞给语言模型后，统计环节出现了供应商名称合并错误，把"宏远电子"和"宏远电子上海分部"当成两个供应商。候选A在表格提取上弱于候选C，但它正确识别出这两个名称属于同一组织，并在总结里主动提到"建议先确认宏远电子的主体口径"。

这个差异本质是"深度理解"与"表层模式匹配"的区别。候选C的检索增强系统擅长"找到信息"，但在"理解信息之间的实体关系"上依赖语言模型二次加工；候选A的统一架构在实体消解上天然占优。后续我在实际项目里也沿用了一个操作习惯：文档型Agent优先选检索增强架构，但凡是涉及实体归一化、关系推断的任务，都要加一道独立的实体对齐模块，不能只靠模型自己。

3.4 失败复盘：看似聪明实则不可执行的计划

第二轮的真正价值来自一次集体翻车。我让候选人制定一个跨部门审批流程的处理方案，任务里隐含了"必须在合规检查通过后才能发送合同"这个约束。候选B输出了一份非常漂亮的分步计划，看起来逻辑严谨，但实际执行时会发现，它计划的第三步是"调用send_contract工具"，而约束要求的前提条件在这个步骤之前根本没法满足。它不是不知道约束，而是把约束信息放进了"计划描述"而不是"工具调用条件"。

候选A犯了另一个方向的错误：它为了满足约束，虚构了一个"合规检查"工具，但这个工具在真实环境里根本不存在。这就是多任务规划中常见的"工具幻觉"——模型为了任务完整性会编造工具。我后来在日志里看到这类现象时总结出一条经验：给Agent做工具调用时，必须在系统提示里明确写出"只能使用工具列表中的工具，不得假设存在其他工具"，并且定期统计工具幻觉的频率，一旦超过某个阈值就要考虑换模型或加强约束。

4. 第三轮面试：记忆与长程一致性，AI的"断片"问题其实很严重

4.1 上下文窗口的虚与实

第三轮考察记忆能力。我先做了一个基础测试：在同一个会话里给每个候选人连续输入8张图片和对应的8条问题，中间穿插两轮无关对话，最后再回头问第一张图片里的细节。这是很基础的上下文保持测试，结果却意外地能区分架构。

候选A和候选B都能准确回述第一张图片的细节，但候选B在最终回述时多加了大量"根据我的理解""如果我没记错"之类的不确定修饰，说明它虽然记住了内容，但对记忆的置信度判断很模糊。候选E则直接丢失了第一张图片的信息，回答"您还没有发送过图片"。候选E的暴露窗口不是硬件限制，而是当输入序列变长时，它的注意力机制自动丢弃早期信息——这个问题在参数较小的模型里几乎是通病。

候选D在纯文本记忆测试中表现不错，但在视觉记忆测试里严重偏科：它能记住视频里的连续帧细节，却记不住静止图片之间的先后顺序，这也是时序建模架构的特性。

4.2 工作记忆与长期记忆的衔接

这一轮测试里我最看重的是"工作记忆与长期记忆的衔接"能力。我模拟了一个实际场景：候选人在第3轮对话中被告知"本项目的预算上限是八万元"，到第8轮对话时，新的任务要求在预算内选择方案。测试目标是看它能不能主动调用预算信息。

候选C在这个任务上表现最好，因为它外挂了向量库，预算信息被检索模块自动召回并向模型注入。候选A和候选B完全依靠上下文窗口，在上下文没有溢出前都能正确引用预算。但当我在第6轮故意插入一段长约5000字的不相关内容后，候选B开始把预算数字与插入内容里的数字混淆，错误地认为上限是"八十万"。这说明一个问题：上下文窗口再大，也不等于注意力不会被污染；外挂长期记忆的价值不只是在"存下来"，更在于"按需精准召回"，避免无关信息搞乱关键数值。

对于真实Agent项目，我的建议是两条腿走路：核心会话状态用短期记忆维护，业务实体数据进长期记忆库，同时定期做"记忆一致性校验"，把近期对话中的关键约束抽取出来定时回灌，避免被长对话稀释。

4.3 多轮对话中的用户偏好保持

再往下是一道模拟真实客服的题。我首先跟候选人确认"用户希望所有回复都控制在50字以内，不要使用任何数字编号"，之后经过三轮内容完全无关的闲聊，最后抛出一个需要列点回复的问题。候选A记住了字数约束，回复控制在49字；候选B记住了字数但忘记禁用编号，输出里出现了1、2、3；候选C用检索模块辅助决策，但检索结果覆盖了原始的对话内偏好，回复里出现了"根据系统知识库，建议您……"这样不符合客服风格的措辞。

最有意思的是候选E，它既没记住字数也没记住编号，但它的工具调用序列里出现了一个"get_user_preferences"方法探查用户偏好。这说明端侧小模型选择用"动作弥补记忆"的方式，既然记不住，就每次重新查。对于端侧Agent来说这不失为一种务实策略，代价是每次交互多一次工具调用，在隐私敏感场景反而显得合理。

4.4 记忆丢失导致的任务失败案例

三轮记忆测试后我专门做了一次压力测试：在一个长会话末尾让所有候选人执行"创建采购订单"任务，而订单所需的供应商编号在第2轮对话里就出现过。候选C因为检索模块准确召回，一气呵成完成。候选A和候选B虽然处于上下文窗口边缘，但都能找到编号。候选D在这个纯文本记忆任务上最让我意外：它从第4轮开始就把较早对话中的供应商编号替换成了一个"可能正确的编号"，结果订单创建到了错误供应商名下，而且没有任何置信度提示。

这个案例值得单独拿出来说：在Agent环境里，最危险的不是"记不住"，而是"记住了一个错的版本还继续执行"。我在设计Agent应用时的经验是——凡是涉及资金、合同、身份等关键字段的自助决策，必须在执行前增加"关键信息确认"环节，让模型先把记忆中的关键字段复述出来再提交。这个环节能拦截大量记忆错误造成的业务事故。

5. 边界与安全：能力边界测试，比能力测试更重要

5.1 幻觉、置信度与拒绝机制

第四轮是边界压力测试。我准备了一批"模型最容易翻车"的输入，包括：故意包含微小冲突信息的文档、完全超出训练数据范围的垂类问题、以及需要承认"不知道"才能正确完成的题目。

候选B暴露了最典型的过度自信问题。我问它一张X光片是否显示骨折，它给出非常笃定的诊断结论，而同样的X光片在另一个角度拍摄的图片中都看不出明显骨折线。多模态模型的医学影像理解本身就容易幻觉，在Agent场景中让这样的模型直接产出诊断建议，风险极高。相比之下候选E因为没有足够能力给出"像样的"答案，反而触发了它的保护机制，输出"该问题超出我的能力范围，建议咨询专业人员"。这让我意识到一个反直觉的现象：有时候能力弱的模型反而更安全，因为它训练数据不足，对未知内容形成了一定的"免疫反应"。

候选C的拒绝机制最稳定，它内置了置信度阈值，当检索结果与问题相关性不足时会主动返回"未找到可靠答案"。但这也有代价：我给出了一道它其实可以合理回答的常识题，它因为检索模块没找到直接匹配而拒绝回答，产生了"过度拒绝"。对于实际业务来说，过度拒绝虽然不污染数据，但会降低用户体验，需要在工程层面做降级处理。

5.2 多模态输入中的对抗扰动与内容安全

第二轮边界测试，我在图片里添加了肉眼几乎不可见的对抗性水印，水印文字是一段与图片内容矛盾的指令。候选B完全忽视了水印，按原图内容输出；候选C因为检索模块会逐段匹配文字，反而对水印产生了"额外注意"，输出出现了部分误导。候选A识别出水印与图片内容的冲突，主动提示"图片内存在冲突信息，以主体内容为准"。这种冲突感知能力可能来自大规模数据训练时遇到的图文不一致样本，但它在真实Agent中非常有价值。

信息安全角度我很注意，所有测试都使用了完全脱敏的虚构数据，不涉及任何真实个体的可识别信息。在内容安全方面，五类架构都对暴力、色情、违法犯罪类指令表现出了有效拒绝，候选D因为视频语境理解更强，在面对一段"用文字描述画面中动作"的对抗性任务时，比纯图片模型更容易识别出恶意意图。我的结论是：不要只看模型供应商给的安全报告，一定要在自己业务的实际输入分布上做对抗测试，尤其是那些"看似无害但结合业务上下文存在风险"的边缘输入。

5.3 成本、延迟与规模化约束

最后一项不是模型能力，而是部署经济性。我把五位候选人在相同硬件条件、相同并发压力下的表现做了一个汇总，结果很能说明选型问题：

这里有个很多人容易忽略的细节：候选A在输入"单张高分辨率图片+长段落文本"时，时延会从800ms飙升到3000ms以上，因为同一上下文窗口里图片Token和文本Token互相挤占，遇到这种混合输入场景需要做排队降级处理。候选C的时延完全被检索模块主导，如果知识库庞大且未做分层索引，想控制在400ms以内很难，必须在检索层做向量聚类剪枝。

6. 面试成绩单与选型建议：没有最好的模型，只有最合适的闭环

6.1 综合评分明细

面试全部结束后，我把五个候选人在五个维度的得分汇总成一张成绩单：

这张表说明的事情比单一总分丰富得多。比如候选E总分最低，但它的经济性和端侧响应能力在特定场景里无可替代；候选A总分最高，但它在规模化上的低分意味着电商大流量场景直接上它会把预算拉爆。不存在"最强模型"，只有"最强匹配"。

6.2 按业务场景做的定向推荐

根据成绩单，我后续给不同场景的朋友做选型建议时基本遵循以下逻辑：

智能客服与工单处理这类"图片+文本+单据"混合场景，我推荐候选C做文档主链路、候选A做兜底增强，因为C的检索能力能保证历史工单被正确引用，A的实体归一化能力能修正C产生的供应商/客户ID混淆。

视频巡检、直播审查这类强时序任务，唯一合理的选择是候选D，因为它虽然通用能力薄弱，但跨帧事件识别能力是其他架构无法替代的。如果预算允许，也可以考虑把候选D作为前置视频预处理模块，把关键帧抽取出来再交给候选A做深度分析，这样能节省大量Token成本。

端侧离线助手这类对延迟和隐私极度敏感的场景，候选E是唯一可行选项。实测下来，它的单次响应速度可以控制在100ms级别，完全不需要联网。代价是复杂任务的成功率偏低，需要在应用层拆步骤并配合规则引擎兜底。

如果做通用型办公Agent且预算宽裕，候远A综合体验最顺滑，尤其是在实体关系判断、冲突信息识别这类"需要整合全局理解"的任务上，优势明显。但务必提前估算Token成本，并为高分辨率图片输入设置延迟熔断。

完整服务推荐逐步接入。

6.3 我在这轮面试后沉淀下来的几个判断

整场面试做完，我最强烈的感受是：参数表和跑分榜单在选型决策里的参考价值比想象中还低。真实Agent场景的决定性因素，是模型在你自己的任务链上"翻车之后能不能自我修正"，以及"翻车时有没有给出风险提示"。再强的模型，在关键字段上静默出错一次，可能就抵消掉它一千次正确回答积累的信任。

所以我后来给自己定了几条硬规则：所有进入生产环境的多模态Agent，必须在工具调用层做格式强校验，输出不规范就拦截重试而不是直接污染下游；所有涉及资金、合同、个人敏感信息的决策，执行前强制增加关键信息确认环节；所有长期运行的Agent，每N轮对话后做一次记忆一致性校验，把关键约束重新回灌到上下文里。

还有一点让我印象很深：在多个候选架构表现接近的时候，透明度和可调试性往往比性能分更值得优先考虑。候选C虽然有些环节弱于候选A，但它的每一步都有中间结果可查，这在实际项目里意味着半夜线上出问题时能快速定位到是"检索没召回"还是"模型理解偏了"，而不是整个Agent像一个黑盒一样拒绝透露内部状态。

最后分享一个小技巧。如果你没有条件像我这样搭一整套面试题，也至少可以在选型阶段做一件事：把你业务里最常见的三个真实任务原样输入给候选模型，观察五件事——首答正确率、错误提示率、工具输出格式非法率、上下文拉长后的遗忘率、以及毫无根据的自信回复次数。这五个数字，比任何公开排行都更能说明那个模型在你手里的真实段位。