CHAPTER 5 · EP 26

他们会这样考你 · Agent 设计模式

第 5 章 · 第 26 讲 · 15:34

时长 15:34音色 云健 · 男声章节 5

同步字幕

章节导航(点击跳转)

0:00开场 · 这一集解决什么问题1:15
1:15第一层 · 预定义流程还是模型自主决策1:45
3:01第二层 · 复杂度阶梯1:21
4:22第三层 · 五种编排模式之一,提示链与路由1:28
5:50第四层 · 五种编排模式之二,并行、编排与评估1:52
7:43第五层 · 从写提示词到管上下文1:39
9:22第六层 · 高效上下文的三个原则1:33
10:55第七层 · 上下文的三板斧3:08
14:04可带走的判断清单1:28
解读全文

ep26 · Agent 设计模式 · 从 Prompt 工程到上下文工程

本内容改编自小山学堂《学 AI 产品,从入门到精通》,为二次演绎配音版。
来源 xueai.miyang.cn(小山学堂 · 洛小山)

本集定位

这一集回答两个连在一起的问题。第一,你要的到底是预定义流程还是模型自主决策。第二,当系统变复杂之后,怎么管理每一轮推理送给模型的全部词元。

核心判断只有一句,复杂度是成本,不是功能。每多引入一层编排,就要多付一层延迟、调用费用和调试难度。这一篇把口播里的复杂度阶梯、五种编排模式、上下文三原则和三板斧展开成可以直接拿去做评审的材料。


一、能力地图

主题核心问题判断规则关键结论
预定义流程控制权在谁手里开发者写死执行顺序确定性、可预测、成本可控、调试容易
智能体控制权在谁手里模型每步动态决定自主性、动态决策、成本不确定、难复现
复杂度阶梯要不要上复杂度单次调用 → 检索增强 → 预定义流程 → 智能体每上一级都要问收益值不值
提示链任务能否拆成固定步骤上一步输出作下一步输入,中间可插质量门用准确度换延迟
路由输入类型是否多样先分类再导向专门分支关注点分离,兼顾成本优化
并行化子任务有无依赖拆分并行或多次投票提速与提升置信度
编排者工人子任务能否预知运行时动态拆解分配最接近智能体的预定义流程
评估优化有无明确质量标准生成与评判双角色迭代循环到满意或达上限
上下文工程窗口里放什么上下文衰减、注意力预算、平方复杂度目标是最小高信号词元集合
三板斧长任务怎么不失忆压缩、结构化笔记、子智能体可组合使用

二、预定义流程还是智能体

预定义流程:模型和工具通过写好的代码路径编排,开发者在写代码时决定执行顺序。关键词是确定性、可预测、开发者控制流程。

智能体:模型动态决定自己的执行流程和工具使用,每一步自主判断下一步做什么、要不要调用工具、什么时候结束。关键词是自主性、动态决策、模型控制流程。

差异对比

维度预定义流程智能体
控制权开发者,代码路径固定模型,每步动态决定
可预测性高,输入确定则路径确定低,同样输入可能走不同路径
适用场景任务拆解明确、步骤固定任务开放、需要灵活决策
成本可控,调用次数固定不确定,循环次数未知
调试难度低,路径确定容易复现高,行为不确定难以复现

什么时候不要用智能体。大多数情况下你不需要它。对大多数应用场景,优化单次调用配合检索增强就够了。常见的过度设计是,用一个框架去做本质上一次提问加一次搜索就能解决的事。

一个可操作的判断信号:你能不能把这件事的步骤提前写下来。写得清楚,说明流程确定,用预定义流程就够了;写不清楚,每一步都得看上一步的结果才知道下一步是什么,才轮到智能体登场。


三、复杂度阶梯

  1. 单次调用:优化提问,加少样本示例,调温度参数
  2. 加检索增强:让它能访问外部知识
  3. 上预定义流程:把任务拆成多步,用代码控制流程
  4. 才上智能体:让模型自主规划执行

每上一级都要问一句,这一级的复杂度带来的收益,值不值得额外的延迟、成本和调试难度。行业里有句话值得背下来,最成功的实现往往不是用复杂框架搭出来的,而是用简单可组合的模式搭出来的。

阶梯的第二个用法是复盘。已经上线的功能效果不好,先别急着加东西,往下退一级看看。很多时候问题不在能力不够,而在层级选错了。


四、五种编排模式

模式一 提示链

把一个大任务拆成多个顺序步骤,上一步的输出直接作为下一步的输入。每一步都是一次独立调用,专注做好一件事。步骤之间可以插入质量门,只有通过检查才进入下一步。

适用:任务能自然拆解为固定步骤、需要在中间做质量检查、愿意用准确度换延迟。

实例:生成营销文案 → 翻译为目标语言 → 格式化为特定平台样式。中间门检查是否包含品牌关键信息。

模式二 路由

先分类输入,再导向不同的专门处理分支。每个分支可以有独立的提示词、模型甚至工具配置。核心价值是关注点分离。

适用:输入类型多样、不同类型需要完全不同的处理逻辑、需要成本优化。

实例:客服系统里简单常见问题用又快又便宜的小模型,退款相关用强模型加订单工具,技术故障用强模型加日志查询。

模式三 并行化

让多次调用同时执行再聚合结果,两种子模式。

  • 拆分并行:拆成独立子任务并行处理后合并。代码审查里一个查安全漏洞、一个查性能问题、一个查代码风格,最后汇总。
  • 多次投票:同一任务用相同提示词跑多次,取多数或最佳。内容审核里三个判断取多数意见。

适用:子任务无依赖、需要提速、需要提升置信度。

模式四 编排者加工人

由中心模型动态拆解任务并分配给多个工人模型。与并行化的区别是子任务在运行时动态决定,代码里没有预先定义,最接近智能体。

适用:子任务不能提前预知、涉及对多个文件或资源的并行操作。

实例:给项目加国际化支持,编排者分析代码库后动态决定改哪些组件、创建哪些文件。

模式五 评估加优化

一个负责生成,另一个负责评判,形成迭代循环,直到评判者满意或达到迭代上限。

适用:有明确的质量评估标准、迭代能显著提升质量、单次生成很难达标。

实例:文学翻译,初步翻译后检查信达雅和风格一致性并给出修改建议,循环两三次出终稿。

收口:从最简单的提示链开始,只在确认简单方案不够用时才升级。

五种模式速查

模式核心思想典型场景复杂度
提示链顺序串联,逐步处理文案生成管道低
路由分类导向,专门处理智能客服分流低
并行化并行处理,聚合结果多维度代码审查中
编排者工人动态拆分,分布执行跨文件代码修改中高
评估优化生成评判,迭代改进高质量翻译中

选模式时要同时看三件事,任务能不能提前拆、子任务之间有没有依赖、有没有明确的质量标准。三件事都答不上来,多半说明还没到需要编排的程度。


五、从提示词工程到上下文工程

过去的提示词工程关注怎么写指令,措辞、结构、少样本示例。现在的上下文工程关注模型的输入窗口里放什么、怎么放、放多少。

上下文窗口里通常有五类内容,系统提示词(角色定义、规则、约束)、工具定义(名称、参数、描述)、对话历史、检索数据、用户状态。这些加在一起可能占满大半个窗口。

为什么重要,三条理由

  1. 上下文衰减:上下文越长,模型对信息的检索准确率越低,关键信息被淹没
  2. 注意力预算有限:无关词元占位等于有用信息被稀释
  3. 平方级复杂度:词元数量翻倍,计算量变成四倍。从五万扩到十万,注意力计算量变成原来的四倍

推论:有些团队把窗口加大之后反而觉得模型变笨了。窗口变大,塞进去的噪音也变多,有效信息密度反而下降。解决方向不是继续加窗口,而是做减法。


六、高效上下文的三个原则

一,系统提示词找合适的高度。 太模糊,模型缺乏方向感,输出泛泛而谈;太具体,模型被过度约束,遇到新情况无法灵活处理。最佳实践是给出明确的角色定位和核心原则,五到十条,然后信任模型在此框架下自主判断。像好的管理者一样,给方向,不给每一步的指令。

二,工具集要精简。 生产实践验证过一句,如果人类都分不清该用哪个工具,模型也分不清。给十个功能相似但描述模糊的工具,不如给五个职责清晰、命名精准的。每个工具的描述要像好的接口文档,让调用者一看就知道什么时候用、怎么用。

三,少样本示例精选不堆砌。 正确做法是精选两三个最能代表目标行为的典型例子,覆盖最常见的输入模式。错误做法是堆砌十几个边界案例,既浪费词元,又让模型过度关注异常而忽略主线。

像编辑精修文章一样精修你的上下文,每一个多余的词都是噪音。


七、上下文的三板斧

长任务的根本挑战:开新窗口会失忆,继续在旧窗口工作注意力会被稀释。

第一板斧 压缩。 对话快要触达上限时,用一次调用对已有对话做摘要,保留关键信息,丢弃冗余细节,然后继续工作。

低风险操作:清理旧的工具调用结果,如文件列表、搜索输出。

高风险操作:丢弃架构决策的推理过程、未解决的缺陷描述,丢了就会重蹈覆辙。

实践建议:摘要要结构化,用已完成、未完成、关键决策、已知问题分栏,自由文本很难快速定位。

第二板斧 结构化笔记。 执行过程中主动把关键信息写到外部文件,上下文重置后读回恢复记忆。核心是把短期记忆外化为长期记忆。

关键设计:笔记格式要固定且结构化,不能是自由散文,否则读回来还要额外花词元去理解笔记本身。

与压缩的区别:压缩是压完继续用,笔记是存到外面以后取用。后者适合可能被中断、需跨会话延续的场景。

第三板斧 子智能体架构。 主智能体把需深入探索的子任务委派出去,子智能体在独立上下文窗口工作,可能消耗数万词元,最终只返回一千到两千词元的精炼摘要。核心价值是关注点分离加上下文隔离。

配套选择:预加载还是按需获取。 预加载在对话开始就塞入项目约定、核心规则、用户偏好,即时可用但每次占词元;按需获取只在需要时检索,上下文精简但多一次调用延迟。最佳实践是混合,高频信息预加载,长尾信息按需获取,类比浏览器缓存,热数据放内存,冷数据放磁盘。


提示1 · 先用最简方案,再谈升级

复杂度阶梯从单次调用起步,依次是检索增强、预定义流程、智能体。每爬一级都要问收益值不值得代价。大多数场景,一次提问加一次搜索就够了。这套阶梯还能用来复盘,效果不好先往下退一级。

提示2 · 能不能提前写下步骤,是分水岭

写得出步骤说明流程确定,用预定义流程;写不出步骤、每步都要看上一步的结果,才轮到智能体。这个信号比任何技术对比都好用在评审会上。

提示3 · 五种模式从提示链开始选

需要中间质检用提示链,输入多样用路由,子任务无依赖用并行,子任务无法预知用编排者加工人,有明确质量标准用评估加优化。不要一上来选最复杂的那个。

提示4 · 把上下文当稀缺资源

系统提示词找中间的合适高度,工具集宁少勿滥,示例精选两三个。窗口加大不等于效果变好,有效信息密度才是关键,方向是做减法不是做加法。

提示5 · 长任务先定策略

连续不会被中断的用压缩,可能被中断或要跨会话的用结构化笔记,需要深度探索又不想污染主上下文的用子智能体。三者可以组合,混合使用预加载与按需获取。


八、落地节奏建议

如果要把这一集的方法真正用起来,可以按三步推进。第一步是盘点,把现有功能按复杂度阶梯归位,标出哪些明显停在了过高的层级。第二步是降级实验,挑一到两个功能往下退一级,对比效果、延迟和成本三项指标,用数据验证复杂度是否真的必要。第三步才是规范化,把五种模式的选择依据、系统提示词的原则条数、工具集的准入标准写成团队规范,让下一个需求不再靠个人感觉决定层级。

这里有一个很容易被忽略的配套动作,规范里必须写清「谁有权决定升级」。复杂度升级往往需要研发和设计共同推动,如果没有明确的决策人,团队会默认往复杂走,因为加东西在心理上比砍东西更容易被接受。


九、审查清单

  1. 这个需求能不能提前写下完整步骤?能的话为什么还要上智能体?
  2. 复杂度阶梯上,我们当前停在哪一级?有没有往下退一级的可能?
  3. 五种模式选了哪一种?选它的理由是不是「因为别人都这么用」?
  4. 预定义流程的中间有没有质量门?门不过时怎么兜底?
  5. 路由分支的模型档位有没有按难度区分?
  6. 系统提示词是太模糊还是太具体?原则条目在五到十条之间吗?
  7. 工具集有多少个?人类能不能一眼分清该用哪个?
  8. 少样本示例是不是堆了十几个边界案例?
  9. 长任务是压缩、笔记还是子智能体?中断之后能不能恢复?
  10. 哪些信息预加载、哪些按需获取?命中率有没有观测?

十、常见误区

误区一,框架越复杂产品越高级。 复杂度是成本不是功能。最成功的实现往往用的是最朴素的组合模式。

误区二,智能体一定比预定义流程好。 两者解决的是不同问题,判断标准是控制权该在谁手里,而不是哪个更先进。

误区三,上了智能体就不用管流程了。 恰恰相反,动态决策带来的是更高的调试难度和更不可控的成本。

误区四,上下文窗口越大越好。 窗口变大的同时噪音也变多,有效信息密度下降,方向是做减法。

误区五,工具越多能力越强。 如果人类都分不清该用哪个,模型也分不清。

误区六,压缩就是把所有内容都摘要一遍。 压缩的关键决策是保留什么、丢弃什么,架构决策和未解决缺陷不能丢。


十一、约束说明

  • 本集只讨论编排模式与上下文管理的判断框架,不提供任何具体框架或库的使用方式。
  • 五种模式的分类来自行业公开总结,实际落地时常组合使用,不要机械套用单一模式。
  • 复杂度阶梯的收益判断依赖具体场景,成本、延迟、调试难度三项必须结合自身数据评估。
  • 上下文相关的量级数据(如窗口扩大带来的计算量变化)为原理性说明,实际开销随模型实现而异。
  • 压缩与笔记策略都存在信息丢失风险,涉及关键决策的信息应单独持久化,不可只依赖摘要。

十二、可带走的判断清单

  1. 先用最简方案,复杂度阶梯从单次调用起步,每上一级都要问收益值不值。
  2. 分清控制权在谁手里,要确定性选预定义流程,要灵活决策才考虑智能体。
  3. 五种模式从提示链开始选,不要一上来选最复杂的那个。
  4. 把上下文当稀缺资源,系统提示词找合适高度,工具集宁少勿滥,示例精选两三个。
  5. 长任务先定策略再动手,压缩、笔记、子智能体三者可以组合。

来源 xueai.miyang.cn(小山学堂 · 洛小山《学 AI 产品,从入门到精通》)

自测卡 · 实战 · 从 Demo 到产品 · 30 道灵魂拷问 · 共 30 题 · 不进入音频

自测卡 1 · 实战 · 从 Demo 到产品 · 30 道灵魂拷问

他们会这样考你

实战 · 从 Demo 到产品 · 30 道灵魂拷问

动手实战篇学完了,你已经知道 Demo 和产品之间隔着什么。这 30 个问题来自三个真实场景,先自己开口回答,再看框架。

一句话速览

每题附考察意图、答题框架与加分点:Demo 到上线的差距 / Agent 卡死 / 上下文压缩 / 记忆设计 / 多 Agent / MCP / 成本账单

怎么用这一页

每道题都标注了提问者。他们问同一块知识,想听的东西却不一样。

🎙 面试官 想验证你是真做过,还是只看过 Demo

👔 老板 要的是解释、方案和一个能兑现的承诺

🛠 技术同事 在试探你会画多大的饼、懂多少代价

每题给出三层: 对方在考察什么 → 答题框架 → 加分点 。答不上来的环节,点末尾的课程页回去补。

Q1 面试官

「假设你们团队一天就调通了生图 API,Demo 演示效果很好。你觉得离真正上线还差多远?差在哪?」

🎯 对方在考察什么

这是判断你 有没有真的把 AI 功能推上线过 的分水岭题。只玩过 Demo 的人会说「再打磨一下就能上」;上过线的人知道,调通 API 只是 10%,剩下 90% 全是产品化工作,能一条条数出来。

🧭 答题框架

先给结论: 调通 API 只是 10%。真实案例里从调通到上线花了三个月,差的东西可以按四个维度盘点。

体验层: 生成进度反馈、失败一键重试、多张结果供选择、历史记录可回看。Demo 里用户干等 30 秒没人管,产品里不行。

质量层与工程层: 质量靠 Prompt 优化(用 LLM 把用户的人话翻译成生图模型能懂的描述)加角色一致性锚定;工程靠多模型降级链、超时重试、成本限额、结果持久化。模型一定会挂,挂了之后的体验才是产品。

安全层: 输入输出双重内容审核、版权风险、用户参考图的隐私策略。Demo 可以裸奔,产品裸奔会出事故。

⭐ 加分点 点一句这张清单的通用性:换成任何 AI 功能,从 Demo 到 Production 都是体验、质量、工程、安全四个维度。面试官听到你有方法论,比听到你背清单印象深得多。

用这些课程页组织答案 →

生图的产品化清单

用 AI 给 AI 写 Prompt

模型会挂,然后呢?

Q2 老板

「用户反馈说 Agent 转了半个小时还没停,最后啥也没给出来。怎么回事?你打算怎么让这种事以后别再发生?」

🎯 对方在考察什么

老板要的是 根因解释加防护承诺 ,两样都要。只会说「模型抽风了」的人露馅:说明你既讲不清卡死的模式,也拿不出让它自己停下来的机制。答「我让技术加个超时」也只算半分,那只是最粗的一层。

🧭 答题框架

先解释根因: 生产环境的 Agent 卡死有四种典型模式:同参数死循环(反复用相同参数调同一工具)、收益递减(跑了 50 轮全是边缘动作)、文本复读(上下文过长后开始车轱辘话)、工具连续失败雪崩(一个工具挂了拖垮整条链路)。先定位这次是哪种。

给防护方案: 防呆是三层网。硬限制兜底:迭代上限、总超时、单工具调用次数上限,无条件刹车。检测预警:同参数检测、同工具名检测、收益递减检测,发现异常模式就上报。

降级续命: 检测到异常先温柔纠正,注入一条「你已经重复了 3 次,请换一种方法」的提示、暂时禁用故障工具、强制总结当前进度带着半成品返回。对用户来说,带着半成品回来比空手而归好得多。

补体验层承诺: 就算 Agent 在跑长任务,用户也要看到进度感,展示当前在做什么,可以随时手动停止。用户骂的其实是「等了半小时还不知道它在干嘛」。

⭐ 加分点 补一句「用户从来不会报告 Agent 死循环了,他只会说这 AI 怎么这么慢、这么蠢」。能把技术故障翻译成用户视角,老板会觉得你是能兜住这件事的人。

用这些课程页组织答案 →

为什么 Agent 会卡死

防呆设计:怎么让循环自己停下来

流式体验:别让用户干等

Q3 面试官

「你们的 AI 助手对话越长越贵、越长越笨。上下文压缩你会怎么设计?什么能删、什么绝对能不动?」

🎯 对方在考察什么

考你 有没有一套压缩的决策框架 ,以及知不知道那条红线。答「找个模型做摘要就行」的人露馅了:既没算过摘要本身的成本,也没意识到删错东西的后果是用户当场发现「我明明说过,你怎么忘了」。

🧭 答题框架

先说为什么必须压: 每一轮对话都要把全部历史重新发给模型。对话越长,费用越高、注意力越分散、离窗口上限越近,三个问题逼着你管理上下文。

给分级框架: 可以删的:旧的工具调用结果、已处理完的中间步骤。可以压缩的:AI 的长篇回复、搜索结果,压成一句摘要。绝对能不动的:用户的原始消息、System Prompt、关键偏好设定。

点出红线: 用户的话是圣物。宁可删 AI 自己说的 1000 字,也别动用户说的 10 个字。压缩优先级从高到低:工具输出、AI 回复、用户消息永不触碰。

说清手段的成本: 本地压缩(截断、规则替换)零成本但粗糙,LLM 摘要精准但本身要花钱。正确顺序是先免费后花钱:先用本地手段砍掉明显的废话,剩下的再考虑 LLM 摘要。

⭐ 加分点 主动提用户体感:压缩做得好用户毫无感知,做得差用户会觉得 AI「失忆」了。把压缩当成一个体验指标去做评测,超越纯粹的省钱视角,这个角度很少有人给。

用这些课程页组织答案 →

对话越长越贵、越长越笨

压缩是一门取舍的艺术

用户说的话能不能删?

本地压缩 vs LLM 压缩

Q4 面试官

「产品要做『让 AI 记住用户』。你打算怎么设计这套记忆系统?所有对话都存下来吗?用户改了主意怎么办?」

🎯 对方在考察什么

连环三问,考你对记忆系统的 完整设计能力 :存什么、怎么更新、怎么用。把「记忆」和「上下文」混为一谈的人第一句就露馅;说「全存下来慢慢查」的人,在成本和噪声这关也过不去。

🧭 答题框架

先分清两套系统: 上下文窗口是白板,写满就擦、对话结束就清空;长期记忆是笔记本,写下的东西下次打开还在。做记忆功能的前提是承认白板靠不住。

设计守门员: 用户每天几十上百条消息,「嗯」「好的」「哈哈」占大半,值得记的偏好和事实只有几条。写入前要有一层筛选逻辑,判断这条信息有没有长期价值。

处理记忆冲突: 用户上月说喜欢咖啡、这月说改喝茶了,四种策略按场景选:明确替换就覆盖更新;信息互补就合并扩展;无法确定谁对就标记冲突待确认;临时状态(最近太累总睡懒觉)直接跳过不存。

算注入的账: 记了 1000 条,每次全塞进 System Prompt 简单但贵且噪声多,按需检索省钱但可能漏。要按记忆规模和场景选注入策略,这是个成本决策。

⭐ 加分点 点出「记忆系统的核心能力是更新,光会追加的记忆系统用两个月就变成谣言库」。大部分人只设计了写入,没设计过期和纠错。

用这些课程页组织答案 →

上下文 ≠ 记忆

什么值得记、什么不值得记

记忆冲突:用户改了主意怎么办

记忆注入的成本问题

Q5 技术同事

「你 PRD 里写了要上多 Agent 协作,还画了个挺酷的架构图。咱们真需要这么多 Agent 吗?一个搞不定吗?」

🎯 对方在考察什么

技术同事在试探你是 真想清楚了还是在追热点 。多 Agent 意味着更多协调成本、更多出错可能,他们要为这些复杂度买单。答不出「为什么一个 Agent 做不到」,这个需求大概率会被打回来。

🧭 答题框架

先认账: 默认立场就是一个 Agent 够用,很多所谓需要多 Agent 的场景,其实是 Prompt 没写好。加第二个 Agent 之前要过三问:一个真做不到吗?复杂度值得吗?有没有更简单的方案(比如工具并行调用)?

给三种真需要的场景: 并行加速,5 个来源同时搜比串行快 5 倍;角色分工,Writer 写、Reviewer 审,角色隔离让审查真正有效;风险隔离,子 Agent 解析 PDF 失败了只汇报「这个文件有问题」,主任务不受影响。

对号入座: 回到 PRD 里的具体场景,说清它命中的是哪一种。命中了就保留,没命中就当场砍掉,这比守着架构图硬辩好看得多。

展示并发常识: 就算上了多 Agent,也要懂「看」可以并行、「改」必须排队。判断一个操作能否并发,关键就一条:它是只读的吗?

⭐ 加分点 主动说「如果这三种场景一个都不命中,我就改回单 Agent」。技术同事最怕的是为 PPT 架构买单的 PM,你先把退路说出来,信任立刻就建立了。

用这些课程页组织答案 →

什么时候需要多个 Agent

并发的代价:谁能同时跑

脑暴:让多个 AI 吵架

Q6 面试官

「MCP 现在很火,你说说它和普通的 API 调用有什么区别?对你们产品来说意味着什么?」

🎯 对方在考察什么

考你对 MCP 的理解 停在哪一层 。只答「让 AI 调外部工具的协议」的人,和看了一篇科普文的人没区别。真正理解的人会讲双向:你的产品既能消费别人的能力,也能把自己变成别人的工具。

🧭 答题框架

先给一层理解: 作为 Client,产品通过 MCP 消费外部能力:日历、邮件、数据库、浏览器,接入一个协议就能用一片生态,省掉逐个对接 API 的成本。

再给关键的第二层: MCP 是双向的。产品也能作为 Server 把自身能力暴露出去,让 Cursor、Claude Desktop、自动化脚本来调用你。单向集成只是工具调用,双向意味着你的 AI 能成为别人的工具。

说产品含义: 当多个 Agent 能互相调用,生态就自然形成了。这是从工具到平台的关键跨越,也是产品定位层面的决策,得由 PM 来拍。

补工程常识: 接了 10 个 MCP 服务,启动时全连一遍?3 个挂了启动就卡住。注册和连接要分开,用到再连(懒连接)。更进一步,Agent 运行时发现缺工具,可以自己发现并配置新的 MCP 连接。

⭐ 加分点 用一句话收尾:「MCP 对 AI 产品的意义,类似当年开放平台对移动互联网的意义,先想清楚自己是接入方还是被接入方。」把协议问题抬到生态站位问题,面试官会记住你。

用这些课程页组织答案 →

MCP 不只是「调工具」

懒连接:不用别连

AI 自己加工具

Q7 老板

「这个月 API 账单比上个月翻了三倍,用户量才涨了 20%。钱都烧哪去了?下个月能降下来吗?」

🎯 对方在考察什么

考你 懂不懂 Agent 产品的成本结构 。以为成本和消息条数成正比的人,解释不了账单为什么跑得比用户量快。能把账单拆到轮次和上下文长度这一层的人,才有资格谈怎么降。

🧭 答题框架

先纠正计量单位: 用户发一句话,底层可能跑 10+ 轮循环、几十条 API 消息,而且每一轮都要重发全部历史。成本跟任务复杂度挂钩,随复杂度指数增长,所以账单跑得比用户量快是正常现象,失控才是问题。

排查典型的成本刺客: 定时任务复用旧会话,上下文越滚越长,一个选择就能让月账单差 10 倍;卡死的循环空转烧钱;长对话没做压缩,每轮都在为陈年历史付费。

给降本组合拳: 定时任务改成每次新建会话;上线循环防呆掐掉空转;上下文压缩砍掉不该重发的 token;按用户和时段设成本限额,监控异常调用。

给量化承诺方式: 建立单次任务平均成本的监控看板,把「下个月能不能降」转化成「单任务成本降到多少、异常调用清零」,按周汇报。

⭐ 加分点 补一句「涨价的另一面是省着用会变笨,压缩过头体验会掉」,主动把成本和体验的权衡摆到桌面上,说明你在做产品决策,没有单纯当会计。

用这些课程页组织答案 →

一条消息背后的真实成本

定时任务的成本陷阱

对话越长越贵、越长越笨

Q8 面试官

「我们产品要加生图功能。文生图和垫图你打算怎么选?别说都试试,给我几个具体场景。」

🎯 对方在考察什么

考你知不知道 这是生图产品的第一个分岔口 。文生图和垫图是两种完全不同的产品策略,答「哪个效果好用哪个」的人,说明没在真实产品里做过生图决策。

🧭 答题框架

先讲核心区别: 文生图是从无到有,模型每次对角色的想象都不一样;垫图是拿参考图当锚,外貌锁死,只变场景和动作。

给场景对照: 纯背景图、食物物品特写、创意发散,用文生图,自由度高还便宜;角色出镜、角色换装(脸不变衣服变)、多场景系列图,必须垫图,否则用户会发现「怎么每张长得都不一样」。

给判断口径: 就问一句「这张图有没有『必须还是同一个人』的约束」。有,走垫图;没有,文生图更灵活。

补产品含义: 选垫图意味着要先建标准参考图这套素材资产,这是排期里要算进去的产品侧工作量。

⭐ 加分点 点破「有没有参考图,决定的是两条完全不同的产品策略」,差的不只是出图效果,是整条素材管线和成本结构。

用这些课程页组织答案 →

文生图 vs 垫图

角色一致性

Q9 面试官

「用户输入『画个夕阳下的猫』,直接把这句话发给生图模型不行吗?为什么你们中间还要过一道 LLM,多花一次钱?」

🎯 对方在考察什么

考你理不理解生图产品的 核心架构:Prompt 二次翻译层 。这一层看起来多余,其实是出图质量的命门。答不出「为什么必须翻译」的人,做出来的生图功能就是抽卡机。

🧭 答题框架

先给结论: 用户想的和生图模型需要的是两种语言,中间必须有一层 LLM 做翻译,把一句话扩写成几百 token 的精确视觉描述。

给三个理由: 用户不会写生图 Prompt,没人会主动打出 golden hour lighting 这种词;模型理解不了模糊意图,「发呆」对它来说根本没画面;每个生图模型方言还不同,Midjourney、DALL-E、Stable Diffusion 偏好各异,得按目标模型定制。

举个例子: 「Alice 在阳台发呆」经过翻译层,会变成站姿、神态、灯光、发型、标志性项链、构图俱全的英文长描述,出图才稳定。

给架构定位: 这层翻译写进生图的产品化清单里,是固定架构,省掉它省的是小钱,赔的是出图质量。

⭐ 加分点 补一句:翻译层还是统一注入角色特征(发型、项链这些锚点)的地方,它和角色一致性策略天然长在一起。

用这些课程页组织答案 →

用 AI 给 AI 写 Prompt

生图的产品化清单

Q10 技术同事

「你提的这个 bug『IP 形象每次生成都长得不一样』,我调调温度、固定一下种子就行了吧?没多大事。」

🎯 对方在考察什么

技术在试探你是把角色一致性当 调参问题还是产品设计问题 。你要是点头说好,过两周这个 bug 会原样回来,还多了一句「参数已经调过了」。

🧭 答题框架

先定性: 这是生图产品最难的问题之一,调参数解决不了。纯文字描述连续生成四次,脸型、发型、体态、画风全在漂,文字锁不住视觉身份。

给方案: 为 IP 制作标准化角色参考表(Character Reference Sheet),每次生图把参考图一起发给模型,让模型「看着画」,用垫图锚定。

说锚定什么: 脸型体型(五官比例、身材轮廓)、表情风格(预先备好多种表情变体)、穿搭(标志性服装,换装场景只换衣服不换脸)。

补边界: 降级链里有的备选模型不支持垫图,切过去会退化成纯文生图,一致性会掉,这个损失要在降级方案里预先声明,别到时候当事故处理。

⭐ 加分点 主动认领产品侧工作量:参考图资产的制作和维护是 PM 要推动的事,别让技术觉得你只会提要求。

用这些课程页组织答案 →

角色一致性

文生图 vs 垫图

模型会挂,然后呢

Q11 面试官

「你们生图依赖第三方模型。哪天 Gemini 超时了、Seedream 又限流了,你的产品怎么办?讲讲你的降级设计。」

🎯 对方在考察什么

考你有没有 「模型一定会挂」的工程兜底思维 。答「等它恢复」或者「弹个错误提示」的人,没被凌晨的告警电话叫醒过。

🧭 答题框架

先走一遍链路: 模型 A 超时 15 秒触发熔断,自动切模型 B;B 限流,继续切 C;C 成功出图。全程用户只看到「正在画」,感知不到后面换了三个模型。

给三个机制: 优先级加白名单,角色出镜用一致性最好的模型,纯背景用便宜快的;探活,定时检测各模型健康状态,确认宕机的直接跳过,恢复了自动回来;垫图降级,备选模型不支持垫图就退化成文生图,质量降一档但图能出。

给全挂兜底: 所有模型都挂时,给友好文案「服务繁忙,已加入队列,完成后通知你」,永远不给冷冰冰的报错页。

收一句原则: 用户不关心哪个模型挂了,只关心图能不能出来。降级设计的目标是把故障翻译成体验损耗最小的等待。

⭐ 加分点 说降级链的验收标准是「最差体验」:设计得好,最差也只是多等几秒或收到一句友好提示,这才叫产品化。

用这些课程页组织答案 →

模型会挂,然后呢

生图的产品化清单

Q12 面试官

「你简历上写熟悉 Agent。那你说说 Agent 循环呗,就是『想、做、看』三步转圈,对吧?」

🎯 对方在考察什么

这是道陷阱题,考你 是背过教科书还是见过生产环境 。顺着点头说「对」的人直接掉坑里,面试官等的是你把教科书省略的部分讲出来。

🧭 答题框架

先接住: 教科书的 ReAct 确实是 Think、Act、Observe 三步,这是骨架,没错但远远不全。

再展开: 生产环境里一轮循环实际要跑 11 步左右,多出来的包括上下文裁剪和 token 预算检查、系统指令注入、权限校验和参数合规、并发调度、超时监控和错误兜底、结果回写、安全审计日志。

点本质: 多出来的这些步骤才是工程量大头,Agent 能不能稳定、安全、可用,靠的正是教科书里没有的部分。

举一个说透: 权限校验这一步决定这个工具当前用户能不能调、参数合不合法,缺了它,Agent 上线第一天就是安全事故。

⭐ 加分点 补一句排期视角:真实 Agent 每转一圈要做的事比教科书多 5 倍,评估工作量时要按 11 步算,按 3 步算的排期一定爆。

用这些课程页组织答案 →

教科书的 3 步 vs 真实的 N 步

防呆设计

Q13 面试官

「一个工具调用要在后台跑 30 秒。这 30 秒,用户屏幕上应该有什么?给我讲讲你的方案。」

🎯 对方在考察什么

考你的 AI 产品交互功底 。只答「加个 loading 动画」的人,没琢磨过等待体验。面试官想听的是一套完整的进度感设计。

🧭 答题框架

先给原则: 用户能忍受等待,不能忍受不知道在等什么。进度感三原则:让用户看见过程、让进度可感知、让输出渐进出现。

给手段清单: 状态文案(「正在搜索」「正在分析」);把正在调用的工具名直接展示出来;逐 token 流式输出;阶段标记(第 1 步 / 共 3 步);先给中间产物,比如先出大纲再填细节。

给对比画面: 同样等 30 秒,一边只有转圈动画,用户在怀疑卡死;另一边是滚动的状态流「找到 3 条结果」「已分析 2/5 个文件」,用户在阅读。体感完全是两个产品。

补一层控制感: 长任务要给随时可点的停止按钮,能叫停的等待才不焦虑。

⭐ 加分点 点破「进度感 ≠ 进度条」:AI 任务时长本来就没法精确预估,核心是让用户觉得 AI 在认真干活,流式输出本身就是最好的进度条。

用这些课程页组织答案 →

流式体验:别让用户干等

防呆设计

Q14 技术同事

「你 PRD 里写着『单次任务成本控制在 5 美分以内』。你知道用户发一句『帮我重构这个模块』,底层实际烧掉多少 token 吗?」

🎯 对方在考察什么

技术在试探你 PRD 里的成本数字 是算过账还是拍脑袋 。报不出量级的 PM,写的成本指标没人当真。

🧭 答题框架

直接报量级: 查天气这种简单任务,2 轮循环 6 条消息,约 1000 token,成本 $0.003;分析 PDF 要 6 轮,约 5700 token,$0.02;重构代码要 12 轮、二十多条消息、近 8000 token,$0.08。任务复杂度不同,成本差几十倍。

指出成本大头: System Prompt 每一轮都重发;工具返回的长文本(整个文件内容、整页搜索结果)是隐形大户;上下文滚雪球,后面每一轮都要带上前面所有消息。

修正指标写法: 成本上限按任务类型分档设定,配上单任务成本监控,别一刀切一个数。

⭐ 加分点 点出 Agent 成本最反直觉的地方:它随轮次滚雪球,增长超越线性,和传统「一次调用一次计费」的 API 直觉完全不同。

用这些课程页组织答案 →

一条消息背后的真实成本

对话越长越贵、越长越笨

Q15 面试官

「用户反馈你们的 AI 聊到后面越来越蠢,之前说过的要求老是忘。这是用户的错觉,还是真有机制上的原因?」

🎯 对方在考察什么

考你懂不懂 长上下文的三重代价 。答「可能是模型不稳定」的人,说明没理解上下文机制,这个锅模型不背。

🧭 答题框架

先给结论: 不是错觉,是三个机制叠加。费用递增:每轮要重发全部历史,第 8 轮的单次成本能到第 1 轮的 20 倍;注意力衰减:模型对上下文两头热中间冷,第 3 轮提的重要需求到第 8 轮很可能被忽略;窗口溢出:128K 窗口写满后,最早的消息直接被丢掉,AI 是真的看不到了。

区分表现: 「变蠢」主要来自注意力衰减和窗口溢出,「变贵」来自费用递增,两个症状一个根因:上下文无节制变长。

给动作: 上下文管理是必答题,上压缩策略,同时把用户偏好这类关键信息单独保全,不跟着长对话一起稀释。

⭐ 加分点 点出最反直觉的一条:用户以为 AI 忘的是最早说的话,其实注意力最低的是对话中段,中间那轮提的需求才是最危险的。

用这些课程页组织答案 →

对话越长越贵、越长越笨

压缩是一门取舍的艺术

Q16 技术同事

「上下文压缩我打算直接调个模型来做摘要,反正效果好。每轮都压一遍,你看行吗?」

🎯 对方在考察什么

他拿着锤子看什么都是钉子。考你知不知道 压缩是条流水线,先免费后花钱 ,顺序反了就是拿钱换懒。

🧭 答题框架

摆两种手段的账: 本地压缩靠正则、截断、模板替换,零成本、延迟不到 1 毫秒,但粗糙;LLM 压缩让另一个模型读一遍写摘要,精准保语义,但每次都是一笔 API 钱、1 到 5 秒延迟。

给正确顺序: 四步流水线。先本地截断,删工具输出、砍超长 JSON;再模板替换,重复结构换占位符;然后检查还超不超窗口;实在压不下去,最后一步才请 LLM 精炼。

按内容分工: 工具输出、JSON 结果、重复内容交给本地压缩就够了;多轮对话摘要、复杂上下文浓缩才值得花 LLM 的钱。

下结论: 每轮都跑 LLM 摘要,等于给每次对话加一笔固定税。两种手段是流水线上的先后环节,用不着二选一。

⭐ 加分点 提醒他压缩优先级:先删工具原始输出,再压 AI 自己的回复,用户的原话永远不碰。压缩手段再省钱,删了用户的话就是负分。

用这些课程页组织答案 →

本地压缩 vs LLM 压缩

用户说的话能不能删?

Q17 面试官

「你们的记忆系统存了 1000 条用户记忆。每次对话,这 1000 条是全塞给模型,还是怎么处理?」

🎯 对方在考察什么

考你有没有算过 记忆注入的成本账 。答「全塞进去保险」的人没算过钱,也不知道噪声会把模型淹死。

🧭 答题框架

先否掉全量注入: 它只在记忆很少时可行。1000 条全塞进 system prompt,每次调用都为这堆 Token 付费,绝大多数还和当前问题无关,纯噪声,AI 反而找不到重点。

给推荐链路: 用户发消息后先做语义检索,从记忆库里捞出最相关的 3 到 10 条,只把这几条注入 system prompt,再让模型回复。

点出核心原则: 记忆的价值在于每次能拿出最相关的几条,存了多少条本身不重要。随着记忆增长,按需检索是唯一可扩展的方案。

用类比收尾: 好的记忆系统像称职的秘书,从不把整个档案柜搬进会议室,只提前把今天要用的三份文件放在桌上。

⭐ 加分点 补一句取舍:按需检索的代价是可能漏召回,所以检索参数要留给产品调,宁可多召回两条,也别让用户发现「我上次明明说过」。

用这些课程页组织答案 →

记忆注入的成本问题

什么值得记、什么不值得记

Q18 面试官

「你们的 System Prompt 现在多长?谁在维护?改一句话要不要全量回归测试?」

🎯 对方在考察什么

三连问全指向一个点: 你的 System Prompt 是一坨文本还是一个工程 。说不出结构的人,产品稍微复杂一点就会陷进「改一处坏三处」的泥潭。

🧭 答题框架

先给结构: 生产级 System Prompt 分四层管理。身份层管我是谁,名字、性格、能力边界,几乎不变;环境层管现在什么情况,用户语言、系统状态,每次会话可能不同;工具层管能用什么,随功能迭代增删;行为层管怎么行动,输出格式、决策优先级、安全护栏,迭代最频繁。

讲分层的收益: 改一层不影响其他层,加工具只动工具层,调风格只动行为层;产品、工程、运营各改各的文件,Git 合并不冲突。

回答回归问题: A/B 测试只替换行为层,其他三层不动,变量单一;出问题按层排查,是人设错了、环境过时、工具描述有误还是规则冲突,一层层看。

⭐ 加分点 点出频率差异是分层依据:身份层几年不动,行为层每周在改。变化频率不同的东西混在一个文件里,就是把稳定的东西反复暴露在手抖风险下。

用这些课程页组织答案 →

System Prompt 不是一坨文本

Q19 技术同事

「咱们工具越加越多,马上到 100 个了。工具描述全在 System Prompt 里,一次请求光描述就几万 Token,你说怎么办?」

🎯 对方在考察什么

考你知不知道 按需加载 这个解法,以及它省的远不只是钱。工具一多,全量塞的不止是 Token 账单,还有模型选错工具的概率。

🧭 答题框架

先确认账单: 课程里的估算,100 个工具全量加载约 3.4 万 Token,按需加载只要约 2800,省 90% 以上。这笔钱是每次请求都在花的。

给三步方案: 首轮只给名字列表,工具名加一句话说明,让 AI 知道有这个能力;AI 决定调用时,系统再动态注入完整描述和参数格式;用完就收回,下一轮回到只有名字的状态。

点出第二重收益: AI 和人一样,给太多信息反而找不到重点。按需加载在省钱之外还提高了选工具的准确率。

用类比讲给团队听: 公司通讯录不放每个人的完整简历,只放名字和职位,真要合作再看详细资料。

⭐ 加分点 把这题和缓存串起来:工具描述如果放在 System Prompt 前缀里频繁增删,还会把 KV Cache 一起打废,按需加载等于一石三鸟。

用这些课程页组织答案 →

不用的东西别给 AI 看

提示词和缓存的微妙关系

Q20 面试官

「System Prompt、Tool、Skill,这三样东西分别管什么?为什么不把 Skill 的内容直接写进 System Prompt?」

🎯 对方在考察什么

考你能不能把 Prompt 体系讲出 职责边界 。这三样混着用的产品,行为没法迭代也没法追溯,考官在看你有没有把 Prompt 当资产管理的意识。

🧭 答题框架

一句话分工: System Prompt 管我是谁,全局身份,很少改;Tool 管我能做什么,能力菜单,中频改;Skill 管遇到某件事怎么一步步做好,特定任务的流程指引,高频迭代、独立版本。

拆 Skill 的结构: 触发条件定什么时候加载;允许的工具列表用白名单控风险;执行流程写清从确认需求到交付的每一步;输出格式要求保证每次产出质量一致。

回答为什么不进 System Prompt: System Prompt 是全局的,改了影响所有场景;Skill 按需加载,只在匹配任务时注入,不污染其他任务。而且文件即配置,谁改了什么 Git 里一目了然。

落到运营价值: Skill 让 Prompt 可复用、可迭代、可追溯,改文件就是改行为,这是把 Prompt 当代码管的起点。

⭐ 加分点 补一个生命周期视角:编写、注册、触发、迭代四步,每个任务一个文件。面试时能画出这个闭环,比背三个名词强得多。

用这些课程页组织答案 →

Skill:可运营的 Prompt 模块

System Prompt 不是一坨文本

Q21 技术同事

「我把 Skill 的内容直接拼进 System Prompt 了,实现最简单。最近账单有点涨,跟这个有关系吗?」

🎯 对方在考察什么

考你懂不懂 KV Cache 的前缀命中规则 ,以及能不能把一个实现细节和账单涨幅挂上钩。这是产品经理少有的能直接指出工程省钱点的机会。

🧭 答题框架

先讲规则: 缓存对 System Prompt 算指纹,前缀一模一样才命中,差一个字全部重算。这不只是时间戳的问题,任何动态内容插进前缀都一样。

指出问题: Skill 拼进 System Prompt,切换 Skill 就是换前缀,缓存立刻作废。课程里的模拟,这种注入方式命中率只有 20% 左右。

给修法: Skill 作为独立消息追加在 System Prompt 之后,前缀永远不变,命中率能到 90% 左右。用户 ID、Session 标记这些变化的东西同理,全部后置。

给原则: 别动前缀。所有可能变化的内容放到 System Prompt 之后,让前缀永远稳定。

⭐ 加分点 接上Harness 核心篇的经典反例:动态时间戳毁缓存只是特例,这一课的结论更广,所有动态注入前缀的内容都是缓存杀手。

用这些课程页组织答案 →

提示词和缓存的微妙关系

Skill:可运营的 Prompt 模块

Q22 面试官

「多 Agent 系统里,哪些操作可以同时跑、哪些必须排队?给我一条能落地的判断规则。」

🎯 对方在考察什么

考你能不能把并发这个工程概念 压缩成一条产品可执行的规则 。答得出规则还能说出例外,才算真理解。

🧭 答题框架

给出那条规则: 这个操作执行完,世界有没有变?没变就可以并行,变了就必须排队。搜索、读文件、查 API 是只读,10 个一起跑互不影响;写文件、发邮件、支付会改变外部状态,两个同时改一个文件就是数据覆盖。

算收益: 课程里的例子,3 次搜索加 1 次写入,并行编排约 4 秒,全串行约 8 秒。搜索并行跑、写入排最后,时间省一半。

补上例外: 两个写操作改的是不同的东西,不同文件、不同表,也可以并行。冲突只发生在多个操作改同一个资源时。

落到设计动作: 设计多 Agent 系统的第一步,就是把工具分成读和写两类,这个分类是产品要给工程的输入。

⭐ 加分点 把规则说成一句话记忆点:看可以一起看,改必须排队改。面试官记住的往往就是这一句。

用这些课程页组织答案 →

并发的代价:谁能同时跑

什么时候需要多个 Agent

Q23 面试官

「让三个 AI 讨论同一个问题,和把问题问三遍,有区别吗?你要是做脑暴功能,怎么保证它不是自欺欺人?」

🎯 对方在考察什么

考你懂不懂 脑暴模式的关键机制 。做错了,三个 Agent 互相附和,产出和问一遍没区别,还多花三倍钱。

🧭 答题框架

先给机制: 同一个问题扔给多个 Agent,各自从不同角色出发独立回答,比如产品视角、数据视角、用户视角,最后由主持人 Agent 整合。

点出铁律: 每个 Agent 必须独立思考,不能看到别人的答案。和人类脑暴「先各自写,再一起讨论」同一个道理,B 看了 A 的答案就会被带偏,脑暴就废了。这就是和问三遍的本质区别,问三遍是同一个上下文里的三次采样,视角没变。

讲产出物: 主持人汇总的不只是共识,还要标注分歧。三个 Agent 意见一致说明方向明确;有分歧说明这个问题值得更深入讨论,分歧本身就是价值。

补效率账: 思考类任务天然可并行,三个 Agent 同时想,总耗时等于最慢那个,时间不会翻三倍,钱会,所以只把它用在值得多视角的问题上。

⭐ 加分点 点出角色设定是产品活:给三个 Agent 分别写什么人设,决定了视角差异的质量,这比「多跑几个」重要得多。

用这些课程页组织答案 →

脑暴:让多个 AI 吵架

什么时候需要多个 Agent

Q24 老板

「咱们让 AI 每小时整理一次舆情,功能挺好,但我看这项的成本一天比一天高,月底账单吓我一跳。这是怎么回事?」

🎯 对方在考察什么

「一天比一天高」是关键线索,指向 定时任务复用会话的成本雪球 。你要能从账单形状反推出实现问题,并给一个立刻见效的修法。

🧭 答题框架

说出根因: 定时任务复用了旧会话,上下文每次都在累积。第 1 次执行约 2000 Token,第 10 次约 2 万,第 24 次约 4.8 万,每次请求都在为全部历史付费,所以账单逐日爬坡。

给修法: 每次执行新建会话,从零开始。第 24 次的成本和第 1 次一模一样。课程里的对比,跑 7 天每天 24 次,复用会话约 50 美元,新建会话约 5 美元,差 10 倍。

回答为什么可以这么改: 大多数定时任务不需要记忆,每次整理当前的舆情就够了,用不着知道昨天整理过什么。真需要延续的信息,摘要存外部、下次带进去,别拖着完整历史。

⭐ 加分点 给老板一个巡检习惯:凡是成本曲线随时间上翘的 AI 功能,先查是不是上下文在累积。这个模式一眼能认。

用这些课程页组织答案 →

定时任务的成本陷阱

对话越长越贵、越长越笨

Q25 面试官

「你们产品里的 AI,权限是怎么定的?所有功能一个标准,还是分开定?依据是什么?」

🎯 对方在考察什么

考你有没有把权限当成 一条光谱来设计,别当成一个开关 。答「我们要求都确认」或「我们信任 AI」的人,都还没入门。

🧭 答题框架

先立光谱观: 从完全自主到每步审批是一条光谱,中间还有多档。全部放权 AI 可能搞砸一切,每步审批用户会疯掉,产品要做的是给每类操作找到光谱上的位置。

给三个定位维度: 操作的可逆性,发消息不可逆、读文件可逆;出错的代价,删数据代价高、搜索代价低;用户的信任度,新用户谨慎、老用户放权。

回答分不分开: 同一个产品里,不同功能用不同的权限模式。读日历自动执行,发邮件要确认,这才是正常形态,一刀切才是偷懒。

收到本质: 给 AI 多大自由,本质是在回答一个产品问题:这件事出错了,谁来负责?

⭐ 加分点 补一句动态性:权限位置可以随信任演化,用户用了三个月、确认了一百次没出过事,可以给他一个「以后这类不用问我」的选项。

用这些课程页组织答案 →

AI 该有多大的自由

弹窗太多用户烦,不弹又不安全

Q26 面试官

「用户投诉确认弹窗太多,砍掉之后又出了误删事故。弹窗这个度,你怎么拿捏?」

🎯 对方在考察什么

考你会不会用 风险分级 跳出「弹与不弹」的二选一。这是 Agent 产品最常见的体验与安全冲突,几乎每场面试都会换个皮问一遍。

🧭 答题框架

破题: 问题出在无分级。每步都弹,用户点 5 次允许就想卸载;全不弹,删错文件没人兜底。答案是低风险自动执行、高风险必须确认。

给分级线: 读文件、搜索、查日历这类不改变状态的操作不弹窗;删除文件、发送消息、支付、改权限这类不可逆或影响大的操作必须确认。

回答谁来定级: 三个选项。产品经理在设计阶段预定义每个工具的风险等级,最常见;让 AI 根据上下文判断这件事要不要问人,更灵活但不一定准;用户自定义,最灵活但有配置成本。可以组合用,底线档永远人工定。

升华一层: 好的权限设计不是要不要弹窗的二选一,是对什么时候弹、弹什么的精细控制。

⭐ 加分点 提到弹窗文案也是分级的一部分:高危弹窗要说清这个操作不可逆、影响什么,让用户做的是知情决策,而点掉一个烦人的框不算。

用这些课程页组织答案 →

弹窗太多用户烦,不弹又不安全

AI 该有多大的自由

Q27 老板

「用户说 Agent 在后台跑了三分钟才出结果。这三分钟它到底在干什么,你能给我说清楚吗?」

🎯 对方在考察什么

老板问的是一次,背后要的是 随时都能回答这类问题的能力 。答不上来,说明产品是个黑盒,黑盒没法优化成本、排查故障、改善体验。

🧭 答题框架

诚实定性: 今天答不精确,说明缺可观测性。要能回答这三分钟调了几个工具、跑了几轮循环、花了多少 Token、中间有没有出错,靠的是事件流和执行报告,不是猜。

说清要建什么: 给 Agent 装仪表盘。执行时间线、工具调用统计、Token 消耗分布,每次任务一份执行报告。

讲对两边的价值: 对开发,定位哪一步出问题、发现无效循环和浪费的 Token;对产品,理解用户真实使用路径、量化每个功能的成本、给下一版迭代提供数据。

给类比: 没有仪表盘的 Agent 像没有仪表盘的车,不知道油量、不知道转速、不知道什么时候抛锚。这是产品化的基本功,不是锦上添花。

⭐ 加分点 把这次投诉转成立项理由:这三分钟里哪怕只有 30 秒是无效循环,乘上调用量就是实打实的账单,可观测性的建设费用自己就能挣回来。

用这些课程页组织答案 →

Agent 干了什么你知道吗

一条消息背后的真实成本

Q28 技术同事

「产品要接 10 个 MCP 服务,我打算启动时全连一遍,保证随时可用。最近用户反馈启动变慢了,跟这个有关吗?」

🎯 对方在考察什么

考你知不知道 懒连接 这个设计,以及能不能看出「全连一遍」在可用性上的隐患。启动慢只是表象,真正的问题是故障会传染。

🧭 答题框架

先确认因果: 10 个服务启动全连,只要有几个超时,启动就被拖住。课程里的真实数据,启动时全连要 30 秒,改懒连接后 0.2 秒,用户感受是秒开。

给三个原则: 注册不等于连接,启动时只声明有哪些工具可用,不建网络连接;首次使用时才连,大多数工具可能一整天都用不到;故障隔离,某个服务挂了只影响那一个工具,其他照常。

点出产品含义: 这不只是技术优化,是稳定性的基本设计。全连模式下任何一个第三方服务出问题都会拖累整个产品,懒连接把爆炸半径锁在单个工具里。

⭐ 加分点 补一个体验细节:连不上的工具要在用户真正用到时给出清晰提示加重试入口,别在启动时就把失败摊给所有用户看。

用这些课程页组织答案 →

懒连接:不用别连

MCP 不只是「调工具」

Q29 老板

「我看到个演示,用户说帮我查日历,AI 发现没配日历工具,自己就去装了一个。这也太智能了,咱们能做吗?会不会有风险?」

🎯 对方在考察什么

老板一半兴奋一半担心,你要两头都接住:讲清 自配置的机制和它必须配的四道安全设计 ,既不泼冷水也不无脑吹。

🧭 答题框架

先讲机制: 传统做法是报错说不支持,用户得自己去设置页找 MCP 配置项、填参数、测连通,大多数人根本不会。自配置是 Agent 根据需求匹配到候选工具,问用户一声,同意后自动完成配置,门槛从会配置降到会说话。

给四道安全设计: 能力发现,Agent 只能从工具注册中心或预定义候选列表里挑,来路不明的不装;用户授权,必须告知要连接什么服务、等明确同意,AI 不能偷偷连,这是信任底线;即时生效,配置完热加载,当前对话无缝继续;安全边界,敏感工具比如数据库必须管理员手动配,不进自配置范围。

给结论: 能做,而且值得做。自配置不是让 AI 随意装插件,是把复杂的配置过程自动化,决定权留在用户手里。

⭐ 加分点 一句话总结给老板:最好的工具管理是 AI 自己管理自己的工具箱,但要用户点头才行。风险的答案就在后半句里。

用这些课程页组织答案 →

AI 自己加工具

懒连接:不用别连

Q30 老板

「竞品两周就上了个 AI 助手,咱们做了俩月还没上线。人家不也是接个模型加个聊天框吗,咱们慢在哪?」

🎯 对方在考察什么

老板在拿 套壳的速度 逼问你产品化的价值。答不好就是效率低,答好了这是一次把整章内容打包讲给老板听的机会。

🧭 答题框架

先承认表象: 接个模型加聊天框确实两周能上。用户看到的就是冰山水面上那一角:聊天界面、智能回复。

再讲水面之下: 卡死了怎么停、上下文怎么压、用户的话删不删、记忆怎么筛、权限怎么分级、Agent 干了什么看不看得见、第三方服务挂了怎么办。这些是水面下的产品决策,套壳产品一个都没做。

给出差距的量纲: 聊天套壳和真正的 Agent 产品之间,差的是用户看不见的地方上百个正确的产品决策。同一个 Loop 支撑 N 种场景,差异不在代码,在决策。

把时间换算成风险: 竞品省掉的两个月,会在上线后以卡死、账单失控、误删事故的形式一笔笔还回来。我们可以砍范围先上核心场景,但水面下的底线决策不能省。

⭐ 加分点 主动给一个折中方案:列出哪些决策是上线前必须做完的(安全、成本、兜底),哪些可以上线后迭代(记忆、多 Agent),把「慢」变成一张有优先级的清单。

用这些课程页组织答案 →

聊天套壳 vs 真正的 Agent 产品

生图的产品化清单

最后一个建议

这 30 题的共同底色是 算账和兜底 :卡死了怎么停、上下文怎么压、账单怎么控。能把这些讲顺,说明你真的走过了从 Demo 到产品这段路。讲不顺的地方,点关联课程页回去补上。