# 业务 AI 工程分析 这个维度考察的不是纯技术能力，而是**你能不能把业务问题翻译成 AI 工程方案**。面试官会给一个具体业务场景，看你怎么拆需求、选方案、评估效果——是「懂业务的 AI 工程师」和「只会调 API」的分水岭。 --- ## 方案选型与决策 ### Q：时间紧张，“快速上线规则方案”和“训练一个更智能的 AI 方案”之间怎么选？ > 来源：网易 AI Agent 开发实习 **新手答**：“先上规则方案，后面再换 AI。” **高手答**： 方向没错，但决策框架不能只有“先上再说”。需要从三个维度判断： **1. 问题的确定性** | 确定性 | 特征 | 推荐方案 | |--------|------|---------| | 高确定性 | 规则可穷举、边界清晰、异常少 | 规则引擎，AI 是过度设计 | | 中确定性 | 大部分可枚举，少量长尾 case | 规则 + AI 兜底（混合方案） | | 低确定性 | 输入多变、无法穷举、需要泛化 | 必须上 AI，规则撑不住 | **2. 数据就绪度** 没有训练数据或标注数据，AI 方案就是空中楼阁。这时候先上规则不是妥协，是**唯一选择**——同时用规则方案跑线上积累数据，为后续 AI 方案准备训练集。 **3. 切换成本** 架构设计时预留 AI 接入口： ```text 用户请求 → 路由层 → 规则引擎（当前） → AI 模型（预留接口，AB 测试切换） ``` 如果一开始就把规则逻辑写死在业务代码里，后面换 AI 的改造成本会很高。好的做法是把决策逻辑抽象成**策略接口**，规则和 AI 只是两种实现。 **核心认知**：这道题考的不是“AI 还是规则”的二选一，而是你有没有**渐进式落地**的工程思维——先用确定性方案兜底，同时积累数据和信任，再逐步引入 AI。90% 的生产系统都是这么演进的。 **差距在哪**：新手的“先上规则后面换”缺乏判断框架。高手从问题确定性、数据就绪度、切换成本三个维度给出决策依据，且在架构上预留了演进空间。面试官考的是你对 AI 落地的务实认知——不是“AI 万能”，而是“什么时候该用什么”。 --- ### Q：设计一个能根据用户行为自适应调整策略的 AI 系统，从技术架构上怎么做？ > 来源：网易 AI Agent 开发实习（原题：设计进化 BOSS 战 AI） **新手答**：“用强化学习，让 AI 从用户行为中学习。” **高手答**： “自适应”听起来需要复杂的在线学习，但生产系统里通常分成**离线学习 + 在线切换**两层，而不是让模型实时训练： **整体架构**： **三层设计**： | 层级 | 职责 | 技术选型 | |------|------|---------| | **离线层** | 从历史行为中挖掘用户策略模式，训练/更新策略库 | 聚类分析、行为序列建模、离线 RL | | **在线层** | 实时识别当前用户的行为模式，匹配最佳策略 | 轻量分类器、规则路由、特征匹配 | | **反馈层** | 收集策略执行效果，回流到离线层 | 埋点 + 效果指标计算 | **为什么不直接在线学习？** - **延迟**：在线训练/推理延迟不可控，业务场景通常要求毫秒级响应 - **安全**：在线学习可能学到不该学的模式（作弊行为、极端 case），没有人工审核就更新策略很危险 - **可回滚**：离线训练的策略可以 AB 测试、灰度发布、一键回滚；在线学习的模型状态很难精确回退 **关键工程细节**：策略切换不能太突然。用户上一秒还在面对策略 A，下一秒突然变成策略 B，体验会很割裂。需要**渐进式过渡**——在几轮交互中逐步调整策略权重，而非硬切。 **差距在哪**：新手直觉是“强化学习”，但没考虑在线学习的延迟、安全和可控性问题。高手把“自适应”拆成离线学习 + 在线匹配两层，既保留了适应能力，又保证了工程可控性。面试官考的是你能不能把一个看似需要前沿技术的需求，翻译成可落地的工程方案。 --- ## 效果评估与排查 ### Q：如何验证 AI 方案确实提升了业务指标，而不是带来了副作用？ > 来源：网易 AI Agent 开发实习（原题：验证 AI 提升游戏体验而非难度） **新手答**：“看准确率提升了就行。” **高手答**： 模型指标（准确率、F1）提升不等于业务指标提升——这是 AI 落地最常踩的坑。验证体系要分三层： **第一层：定义正确的业务指标** AI 方案的目标不是“模型更准”，是“业务更好”。两者经常不一致： ```text 模型准确率 92% → 但推荐的内容用户不点 回答正确率 95% → 但用户满意度反而下降（回答太机械、缺乏温度） 意图识别 F1 0.9 → 但转化率没变（识别对了但后续流程有问题） ``` 正确做法：**从业务目标倒推评估指标**。如果目标是提升用户留存，就看留存率而非模型准确率。 **第二层：AB 测试隔离变量** ```text 对照组：原方案（规则/旧模型） 实验组：新 AI 方案 流量分配：5% → 20% → 50%（渐进放量） 观测周期：至少 2 周（排除新奇效应） ``` 关键是**只改一个变量**。如果同时上了新模型和新 UI，效果变化归因不清。 **第三层：监控副作用指标** 除了目标指标，必须同时监控**护栏指标**（guardrail metrics）——那些“绝对不能变差”的指标： | 目标指标 | 护栏指标 | |---------|---------| | 推荐点击率提升 | 用户投诉率不能上升 | | 客服响应速度提升 | 回答准确率不能下降 | | 任务完成率提升 | 用户流失率不能上升 | 如果目标指标提升了但护栏指标恶化，这个方案就不能上线——AI“提升”的部分可能是以牺牲用户体验为代价的。 **差距在哪**：新手只看模型指标。高手从业务指标定义、AB 测试设计、护栏指标监控三层构建了完整的验证体系。面试官考的是你对“AI 效果”的理解是“模型更准”还是“业务更好”。 --- ### Q：业务方反馈“AI 效果差”，你怎么系统性定位问题？ > 来源：网易 AI Agent 开发实习（原题：玩家反馈 AI 很蠢如何定位） **新手答**：“看看 bad case，调调 Prompt。” **高手答**： “效果差”是一个模糊反馈，第一步是**把主观评价转化为可量化的问题**。排查框架分四层： **第一层：复现与分类** ```text 收集 bad case → 标注失败类型 → 统计分布 ``` 失败类型通常落在几个桶里： | 失败类型 | 占比（示例） | 排查方向 | |---------|------------|---------| | 理解错误（意图识别偏了） | 35% | Prompt / 意图分类模型 | | 检索错误（召回了不相关内容） | 25% | RAG 管线 / 知识库质量 | | 生成错误（理解对了但回答错了） | 20% | 模型能力 / 输出约束 | | 体验问题（答案对但感觉差） | 15% | 语气 / 格式 / 响应速度 | | 数据问题（知识库本身有错） | 5% | 数据源清洗 | **关键认知：不分类就优化，等于蒙眼治病。** 如果 35% 的问题出在意图识别，你去调生成 Prompt 是浪费时间。 **第二层：定位瓶颈环节** Agent 系统是一条管线，每个环节都可能出问题： 方法：拿 bad case 逐环节回放——意图识别对不对？检索召回了什么？模型看到的上下文是什么？输出前有没有被截断或格式化出错？通常 80% 的问题集中在 1-2 个环节。 **第三层：区分“能力问题”和“数据问题”** - **能力问题**：模型/算法本身不行 → 需要换模型、调架构、加微调 - **数据问题**：输入数据质量差（知识库过时、标注有错、用户输入太模糊）→ 需要修数据、加预处理 大部分“AI 效果差”最终定位下来是**数据问题**，不是模型问题。先查数据再查模型，能节省大量排查时间。 **第四层：建立持续监控** 修完当前 bad case 不够，要建**自动化质量监控**： - 定期从线上抽样做自动评测（LLM-as-Judge 或规则校验） - 关键指标（意图识别准确率、检索相关度、用户满意度）设告警阈值 - 新版本上线后自动跑回归测试集 **差距在哪**：新手直接看 bad case 调 Prompt——这是在“碰运气”。高手先分类统计找到主要失败类型，再逐环节定位瓶颈，最后区分能力问题和数据问题。面试官考的是你有没有系统性的排查方法论，而不是“哪里不对改哪里”。 --- ## 智能客服与 AI 系统落地 ### Q：面向客户的 Multi-Agent 客服系统，怎么保证用户体验良好？ > 来源：币安 AI大模型实习一面 **新手答**：“让多个 Agent 各自负责不同问题就行。” **高手答**： 核心原则：**用户感知到的是一个客服，背后是多个 Agent 协作**。Multi-Agent 的拆分是内部架构优化，不能让用户察觉到“被转接给了不同的机器人”。 **体验设计五原则**： 1. **统一对话界面**：用户始终在一个对话窗口中，Agent 切换对用户透明。Orchestrator 管理路由，用户只和它对话 2. **Handoff 时传结论不传过程**：Agent A 转给 Agent B 时，传结构化摘要（用户需求 + 已确认信息 + 待处理事项），不传原始对话历史。避免 B 重复问用户已经说过的信息 3. **追问策略**：不让用户做填空题，让用户做选择题。“您是想查物流还是申请退款？”而不是“请问您有什么需求？” 4. **状态感知**：每个 Agent 接手时，先用一句话确认已知信息——“我看到您要退货的是订单 XXX，对吗？”让用户觉得“它记得我说过的话” 5. **降级兜底**：Agent 连续 2 次无法理解用户 → 自动升级到人工，附带完整上下文摘要，让人工客服无缝接续 **常见体验灾难及防治**： | 体验灾难 | 根因 | 防治方案 | |---------|------|---------| | 用户被反复追问相同信息 | Handoff 时信息丢失 | 标准化交接摘要协议 | | 回答风格突变（突然变得很机械） | Agent 切换后 Prompt 风格不一致 | 统一语气指南写入所有 Agent 的 System Prompt | | 用户说了半天对方没任何反应 | LLM 推理延迟 + 无流式反馈 | 打字指示器 + 流式输出 + 预设过渡语 | | “我帮您转接同事”频繁出现 | 路由频繁切换 Agent | 对用户隐藏路由行为，切换时不通知 | **差距在哪**：新手把 Multi-Agent 等同于“拆分问题类型”，没考虑用户体验。高手从用户感知出发设计——统一界面、无感切换、结论传递、主动确认、降级兜底。面试官考的是你能不能从技术架构的视角切换到用户体验的视角——多 Agent 是为了“系统更好管”，但不能让用户为此买单。 --- ### Q：知识库 RAG 和智能客服 Agent 系统的成熟方案有哪些？标准方案的优点和局限性？ > 来源：币安 AI大模型实习一面 **新手答**：“用 RAG 检索知识库，然后 LLM 回答。” **高手答**： 智能客服 Agent 的方案选型不是“用不用 RAG”的问题，而是**用什么级别的架构**。按成熟度和复杂度分四档： | 方案 | 代表产品 | 优点 | 局限性 | |------|---------|------|--------| | 纯 RAG 问答 | 大多数企业知识库 | 简单、可追溯、成本低 | 不能处理多轮复杂任务、无法执行操作 | | RAG + Agent | Coze、Dify、FastGPT | 既能查知识又能调工具执行操作 | 工具调用准确率不稳定、调试困难 | | Multi-Agent 客服 | 蚂蚁/阿里内部方案 | 专业分工、可扩展、体验好 | 架构复杂、通信成本高、需大量领域数据 | | 知识图谱 + RAG | GraphRAG 方案 | 多跳推理强、实体消歧好 | 图构建成本高、维护复杂 | **标准方案架构**： **标准方案的四大核心局限**： 1. **知识库覆盖度**：用户问了知识库没有的问题 → 模型要么幻觉要么拒答，体验都不好。解法：知识库覆盖度监控 + 未命中 query 自动收集 + 定期补充 2. **多轮上下文管理**：标准 RAG 是单轮检索，多轮对话中上下文漂移导致检索偏离。解法：对话状态追踪 + query 改写融合历史 3. **个性化不足**：同一个问题对不同用户应该有不同回答（VIP vs 普通用户）。解法：用户画像注入检索条件和 Prompt 4. **实时性**：知识库更新有延迟，新政策/新产品上线后用户马上来问，知识库还没入库。解法：热更新机制 + 兜底到在线搜索 **选型决策框架**： ```text 问题确定性高 + 无需操作 → 纯 RAG 问题多变 + 需要执行操作 → RAG + Agent 用户量大 + 场景复杂 + 有团队维护 → Multi-Agent 实体关系复杂 + 多跳推理需求 → GraphRAG ``` **差距在哪**：新手只知道“RAG + LLM”一种方案。高手对比了四档方案的适用场景和局限性，且分析了标准方案的四大核心问题和对应解法。面试官考的是你对智能客服系统的全局认知——不只是“能做”，而是知道每种方案“做到什么程度、卡在哪里”。 --- ## Q：设计订单客服 Agent 时，如何处理转人工和意图识别调优？ > 来源：某 Java/Agent 岗面经（2026-08-12） **新手答**：“分类用户意图，查订单后回答；模型不会就转人工。” **高手答**： 订单客服应采用“意图路由 + 确定性工作流 + LLM 交互”的混合架构。查物流、取消订单、退款等操作由带权限和幂等保护的业务工作流执行；LLM 负责理解表达、补槽位、解释结果和安抚情绪，不能自行编造订单状态或赔付规则。 转人工是一个显式状态，而不是失败后的兜底字符串。触发条件包括：用户主动要求；连续两轮未解决或重复表达；低置信度/多意图冲突；高风险退款、投诉和账号安全；工具连续失败；情绪升级。交接包要包含用户目标、订单号、已验证身份、已执行动作、工具结果、失败原因和最近关键对话，避免人工重新问一遍。 意图调优使用线上闭环： 1. 从“转人工后人工选择的真实原因”、用户纠正、重复提问和失败 Trace 中采集 hard cases。 2. 建分层标签体系，先区分咨询/操作/投诉，再细分业务意图；同时保留 `unknown` 和多标签能力。 3. 先做规则、Prompt、few-shot 和 query rewrite；若错误集中且样本稳定，再训练分类器或 SFT。 4. 用 macro-F1、关键意图召回率、误路由率、澄清率、转人工率和任务成功率共同评估；不能为了压低转人工率把高风险请求强留给 Agent。 **差距在哪**：新手把客服 Agent 视为问答机器人。高手把意图、业务动作、风险门禁、人工交接和数据回流组成闭环，并知道转人工率不是越低越好。 --- ## Q：Agent 项目如何从 Demo 进行企业级落地？从原型到生产需要补全哪些工程能力？ > 来源：哆咔互娱 Agent开发实习一面 **新手答**：“把 Demo 代码优化一下，加个前端界面，部署到服务器上就行了。” **高手答**： Demo 到生产的鸿沟不在于功能实现，而在于**可靠性、可观测性、可维护性**三个维度的系统性补全： 具体需要补全的工程能力： **1. 容错与稳定性** - Demo 里工具调用失败直接报错；生产需要重试策略、超时熔断、降级路径 - Demo 的状态全在内存；生产需要 Checkpoint 持久化 + 断点续跑 - Demo 单用户；生产需要并发控制、资源隔离、排队机制 **2. 可观测性** - 全链路 Trace：每步推理耗时、工具调用结果、token 消耗都要可追溯 - Bad Case 收集闭环：线上失败 case 自动入库，定期回流到评测集 - 成本监控：按用户/任务/工具维度统计 token 开销，做成本归因 **3. 评测与迭代** - Demo 靠人看输出质量；生产需要自动化评测集（按任务类型分层） - Prompt 和 Skill 的变更需要回归测试，不能改一处全线崩 - 灰度发布：新策略先对 5% 流量生效，观察指标再全量 **4. 安全合规** - 工具权限分级：高风险操作（删除、支付）走 Human-in-the-Loop - 输出安全护栏：敏感词拦截、幻觉检测、PII 脱敏 - 审计日志：谁触发了什么操作，完整记录不可篡改 **5. 运维与交付** - CI/CD：评测集跑通才能合并，不能靠“手动试了一下没问题” - 文档与 Onboarding：新人接手不需要读五千行 Prompt 才能开始改 - SLA 定义：响应时间、成功率、可用性的承诺和降级策略 **差距在哪**：面试官考的是你对“工程成熟度”的认知。Demo 证明“能做”，生产证明“做得稳”。能列出从可靠性、可观测性到安全合规的系统清单，说明你有真实的落地思维而不只是跑通 Happy Path。 --- ## Q：什么时候接入 MCP 是合理设计，什么时候属于过度设计？ > 来源：拼多多 AI Agent 提前批二面（2026-08-12） **新手答**：“MCP 是标准协议，接上后扩展性更好，所以有工具就应该用 MCP。” **高手答**： MCP 的价值是**跨 Host 复用、动态发现和协议标准化**，不是让一次普通函数调用变得更“Agent”。判断是否值得接入，要看四个问题： 1. 能力是否要被多个 Agent/IDE/团队复用？只有单体应用内部使用，直接函数或稳定 REST 接口更简单。 2. 工具是否需要独立部署、版本演进和权限边界？如果生命周期和主应用完全一致，拆 Server 只增加运维面。 3. 是否真正需要 resources、prompts、tools、能力协商或远程发现？只调用一个固定 API，薄适配层已经够用。 4. 标准化收益能否覆盖成本？MCP 会增加 transport、连接管理、鉴权、Schema 维护、超时重试、可观测性和供应链风险。 可以用一个简化决策： ```text 单应用 + 固定能力 + 同一团队维护 -> 本地函数/内部接口 跨服务 + 明确契约 + 传统系统消费者 -> REST/gRPC 多 Host 复用 + 动态工具生态 + Agent 消费 -> MCP ``` 最稳妥的演进方式是先把领域能力做成与协议无关的 service，再按真实消费者需求加 REST/MCP adapter。这样不会为了展示技术栈，把业务逻辑锁死在 MCP Server 里。 **差距在哪**：新手把“用了新协议”当架构能力。高手能计算复用收益、治理需求和新增复杂度，并给出渐进演进路径。面试官是在验证项目里的 MCP 是解决真实问题，还是简历装饰。 --- ## Q：设计一个群聊 Agent，如何同时处理权限、上下文和并行请求？ > 来源：小红书数据库智能化日常实习一面（2026-08-10） **新手答**：“监听群里的 @ 消息，把群聊历史发给模型，并发调用就行。” **高手答**： 群聊 Agent 不是单用户 Bot 的简单放大，必须把每次运行绑定到 `tenant_id + group_id + thread_id + requester_id`，并在进入模型前完成身份和权限计算。 **权限**：读取群消息不等于有权读取每个成员的私有资料，也不等于能以群成员身份执行写操作。工具授权取发起人权限、群策略和 Agent 自身权限的交集；转账、删数据、发外部消息等操作要二次确认或管理员审批。 **上下文**：默认只取当前 thread、最近相关消息、被引用消息和群级公开知识；私聊记忆与其他群记忆严格隔离。对每条消息保留作者、时间和可见范围，模型输出引用事实时能回溯证据。长群聊使用主题分段和检索，不能把整群历史直接塞进窗口。 **并发**：事件先用 message id 幂等去重。同一 thread 的状态变更按版本号或队列串行，不同 thread 可并行；无依赖的只读工具可以 fan-out，有副作用的工具按业务键加锁并使用幂等键。回复前检查 `state_version`，发现期间出现新消息就重规划或标注基于哪个快照回答。 **差距在哪**：新手只看到“群消息更多”。高手意识到群聊引入了多主体权限、上下文可见性和状态竞争，能用隔离键、版本控制和幂等把概率模型放进可控系统。 --- ## Q：长文本内容安全审核如何区分“引用有害内容”与“表达有害立场”？ > 来源：中国电信风控 Agent 二面（2026-08-22） **新手答**：“不能只看关键词，要把全文交给大模型判断语义。” **高手答**： 先把文本切成带重叠和章节结构的片段，提取“内容是什么、谁在说、对谁说、用于支持还是反驳、是否要求执行”的语用信息。局部分类器负责高召回发现风险片段，文档级模型结合标题、前后论证和引用边界判断立场；规则层继续处理明确违法、高风险实体和业务硬约束。不能把未经信任的长文本直接拼进系统 Prompt，以免形成间接提示注入。 评测集要成对构造：相同有害句子分别出现在赞同、批判、新闻引用、学术讨论和操作指令中，比较片段召回、文档级精确率及严重级别。高风险但上下文不确定时保留证据跨度、置信度并转人工；改写只能在不改变用户合法诉求的前提下消除风险内容。 **差距在哪**：新手把关键词换成一个大模型，高手分离局部召回、全文立场、规则硬约束和对抗评测。面试官考的是安全系统能否理解语境且不被被审文本反向控制。 --- ## Q：如何设计会议转写 Agent 的端到端链路并评估质量？ > 来源：字节 TikTok AI Agent 开发一面（2026-08-13） **新手答**：“音频调用 ASR，再让大模型总结会议。” **高手答**：媒体接入后依次做降噪/VAD、分段、流式 ASR、说话人分离、标点与热词纠错，再生成带时间戳的转写、摘要、决策和待办。评测除 WER/CER 外，还看关键实体加权错误、说话人混淆、时间戳、稳定前缀延迟及摘要/待办准确率；必须回放同一批音频验证下游指标，不能用 WER 单独决定上线。 **差距在哪**：新手只串两个模型，高手把流式语音、结构化会议结果和端到端指标连起来。 --- ## Q：音视频 Agent 如何保护隐私并提供可验证删除？ > 来源：字节 TikTok AI Agent 开发一面（2026-08-13） **新手答**：“传输和存储加密，用户删除时删数据库。” **高手答**：采集前取得明确同意，原始音视频、转写、声纹、摘要和向量按敏感等级使用独立权限、密钥和保留期。删除请求沿数据血缘清理对象存储副本、缓存、索引、离线样本和派生结果，并记录任务状态与证明；不可立即修改的备份通过密钥销毁和恢复后重放删除日志处理。日志只保留脱敏元数据，第三方模型调用还要限制地域与二次使用。 **差距在哪**：新手只删主表，高手覆盖派生数据、备份和可审计证明。 --- ## Q：医疗 Skill 如何与 HIS 系统协同，同时满足权限和审计要求？ > 来源：百川智能医疗大模型后训练一面（2026-08-22） **新手答**：“通过 MCP/API 查询患者数据，模型给出建议，医生确认。” **高手答**：HIS 是权威事实源，Skill 只按患者、角色和场景取得最小字段，使用短时授权且不把凭据放进模型。查询、建议和写回分开；诊断/医嘱只生成带证据和置信度的草稿，由规则校验和医务人员签署后写回。全链记录模型、知识版本、输入来源、人工修改和最终责任人，支持撤回、纠错和患者数据删除。 **差距在哪**：新手完成接口连接，高手明确临床责任、最小权限和不可绕过的人工签署。 --- ## Q：20K 流式长文本安全审核如何兼顾增量响应与全文语义？ > 来源：中国电信风控 Agent 二面（2026-08-22） **新手答**：“分块审核，最后再做一次全文汇总。” **高手答**：流式层对每个窗口做高召回风险检测，维护实体、引用边界、立场和未决上下文状态；只有明确高风险才早停，依赖后文消歧的内容标记 pending。段落/章节结束做局部合并，全文结束再判断立场、跨段指代和组合风险。结果事件带版本和证据跨度，后续修正不能静默覆盖；评测同时看首告警延迟、全文准确率和修订率。 **差距在哪**：新手把独立块投票，高手维护跨块状态并允许可审计修订。 --- ## Q：面向 C 端的 Agent 应用应该包含哪些架构和模块？ > 来源：百度大模型研发工程师二面（2026-08-21） **新手答**：“前端接一个大模型，后端提供 RAG、Memory 和 Tools。” **高手答**： C 端 Agent 要同时回答“用户如何持续使用”和“任务如何可靠完成”。产品接入层包含账号、会话、流式交互、多模态输入、历史记录和反馈；Agent Runtime 负责 Context 装配、规划、工具循环、暂停恢复和预算；能力层提供搜索、RAG、Memory、业务 API 与 Sandbox；治理层负责权限、内容安全、隐私、审计、Eval、成本和灰度。 与内部 Agent 相比，C 端还要处理弱网重连、跨设备会话、首屏/首 Token 延迟、用户插话和取消、工具操作确认、未成年人或敏感数据保护。高风险动作必须展示将执行什么、影响什么，并让用户确认；模型生成文本成功不等于业务任务成功，最终状态要以权威业务系统为准。 指标也要分层：产品层看留存、任务完成率和投诉；Agent 层看步骤数、澄清率、工具正确率；系统层看 TTFT、P99、失败恢复和单任务成本。架构选择由目标任务决定，通用助手、办公 Agent 和 Coding Agent 不应复用同一套默认工具与权限。 **差距在哪**：新手只列模型组件，高手把产品交互、Runtime、业务能力和治理连成完整闭环，并能指出 C 端特有的体验与安全约束。 --- ## Q：设计一个“输入网站、输出宣发内容”的 Agent，完整链路是什么？ > 来源：百度大模型研发工程师二面（2026-08-21） **新手答**：“爬取网站正文，拼接 Prompt，让模型生成标题和文案。” **高手答**： 链路可以拆成采集、理解、生成、验证和发布。采集前校验 URL、DNS 和重定向，防 SSRF；按授权范围抓取 HTML 或使用浏览器渲染，提取正文、产品事实、图片和更新时间。理解层把事实转成带来源位置的结构化 Brief，并结合品牌语气、平台、受众、字数和禁用词约束选择模板。 生成层针对不同渠道产出多版本标题、正文、CTA 和标签，但不能让模型补造价格、效果和资质。验证层检查 JSON Schema、事实是否能回指网站证据、敏感词、版权、链接有效性和平台限制；低置信事实、高风险行业与正式发布都进入人工审批。发布工具使用最小权限、幂等键和草稿模式，保留内容版本与审计记录。 评测不能只看文案“好不好”：离线看事实一致性、约束通过率、品牌风格和人工偏好，线上看审核通过率、点击/转化、撤回率和投诉，并和人工基线做分层 A/B。网站内容变化时按内容摘要增量重建 Brief，避免每次全站抓取和上下文膨胀。 **差距在哪**：新手只会爬取加生成，高手覆盖了抓取安全、证据约束、人工审批、幂等发布和业务效果闭环。 --- ## 这类题的答题模式 业务 AI 工程分析题的核心是**从业务出发，回到业务**： ```text 1. 先理解业务目标——不是"用 AI 做什么"，是"业务要解决什么问题" 2. 再判断 AI 是否是最优解——不是所有问题都需要 AI，规则引擎可能更稳 3. 选方案时考虑 ROI——不是最先进的方案最好，是性价比最高的方案最好 4. 效果评估回到业务指标——不是模型准确率，是业务转化率/效率提升/成本降低 ``` 面试官听到「用 RAG + Agent」就知道你在套方案。听到「这个场景的核心瓶颈是 X，所以我选 Y 方案，预期提升 Z 指标」，才会觉得你有业务 sense。 --- ## 推荐阅读 - [架构选型：ReAct、Plan-and-Execute 与 ToT 怎么选](../01-architecture-design/index.html) - [评估与全局观：怎么量化 Agent 好坏、落地最大挑战](../05-eval-and-vision/index.html) - [工程化踩坑：死循环、状态丢失与成本控制](../07-engineering-pitfalls/index.html)