Agent相关题目在字节、阿里、腾讯面试中频繁出现，这18道真题按难度递进排列，从基础概念到架构设计，帮你系统掌握智能体开发的核心考点。

---

基础真题：概念与判断

【真题1 ★基础】你对Agent的理解是什么？

聊一聊你对Agent的理解。

参考解析：

Agent在人工智能领域并不是一个新概念，本质是一个能感知环境、自主决策并且执行动作达成目标的智能系统。这里有三个关键词：感知、自主性、目标导向。

和传统对话机器人相比，核心区别在于自主性。传统机器人是被动响应，你问什么它答什么，最多支持简单的多轮对话。但Agent可以主动规划——给它一个目标，它会自己拆解任务。如果中间发现数据不足，它会调整策略继续查找，整个过程基本不需要你一步一步指挥。

适用场景主要是需要多步骤推理或灵活决策的情况。比如智能客服，Agent能根据用户问题自动查询工单、调取数据、生成解决方案；代码开发场景，它能理解需求、编写代码、运行测试，甚至发现bug后自动修复。

当前落地面临的挑战：决策过程不透明，容易产生幻觉，用户难以信任；成本较高，多轮调用大模型和外部工具对算力开销大；企业级落地时的可控性问题，如何确保Agent不出错、不越权、不泄露数据。

考查能力：对Agent本质的理解，能否从概念层面讲清楚其与传统AI产品的区别。

---

【真题2 ★基础】Agent和Workflow有什么区别？

你认为Agent跟Workflow之间的区别是什么？

参考解析：

从本质上来说，Workflow就像一个事先规划好的剧本，需要提前把每一步都设计好——先做什么、再做什么、最后做什么，整个流程固定可预测。比如客户工单处理系统：用户提交工单、自动分类、派发给对应部门、生成回复、发送给用户，每一步都是确定的。

但Agent更像一个具备自主决策能力的助手。给它一个目标，比如"帮我分析这份市场报告"，它会自己思考怎么做，可能先搜索相关资料，发现信息不够再去调用其他工具，甚至中途发现不对会自己调整策略。执行路径是动态生成的，不是预设的。

核心区别有三点：

灵活性：Workflow是预编排的流程，配置完成后基本固定不变；Agent可以根据环境和反馈实时调整，具备智能性。

适用场景：Workflow适合流程明确、规则清晰的任务，如审批流程、数据处理管道，稳定可控易调试；Agent更适合开放性强、需要探索的任务，如研究分析、复杂客户问题处理，没办法提前把所有情况都列举出来。

成本风险：Workflow每一步都确定，可靠性高、成本可控；Agent虽然更智能，但存在不确定性，可能产生意外的token消耗或超出预期的行为。

实际项目中这两者不是非此即彼的关系。很多时候会结合起来用：用Workflow搭建主干流程，保证核心链路的稳定性；在需要灵活判断的环节嵌入Agent处理不确定性。

考查能力：技术选型判断力，能否根据业务场景选择合适的技术方案。

---

【真题3 ★基础】Agent Skill是什么？

最近Skill很火，请说一下你理解的Agent Skill是什么？

参考解析：

Agent Skill本质上是AI智能体的专业知识和操作流程的结构化封装，让大模型能够像领域专家一样去思考和执行任务。

核心价值是解决传统提示工程的几个痛点：同一个任务要反复写复杂的提示词，输出不稳定，团队之间知识传递效率低。而Skill能够让能力变成标准化单元，可以即插即用。

一个标准的Skill一般包含三个部分：

元数据文件：定义技能的名称、适用场景、触发条件。

知识文档：包括领域知识、操作步骤、最佳实践。

可选执行脚本：比如自动化代码、工具调用逻辑、条件判断规则。

实际产品中的应用场景有三类：

规范输出格式：像生成法律文书或财务报表，确保结构统一。

固化工作流程：按客服SOP处理工单，或自动生成软件测试用例。

注入领域知识：在医疗或金融场景提供诊断辅助或投资分析框架。

通过Skill，大模型能快速具备垂直领域能力，不同Agent之间还能共享和组合这些技能。

考查能力：对Agent组件化、标准化设计的理解。

---

【真题4 ★基础】如何判断业务场景是否适合用大模型？

你是如何判断业务场景适合用大模型的？

参考解析：

从四个核心维度综合判断，既看场景的适配性，也算实际的投入和风险。

第一个维度：任务的复杂度和开放程度

大模型的优势是理解、推理和生成能力强。像智能客服、文档问答、内容创作这种用户问法多样、没法用固定规则穷举的场景，用大模型特别合适。如果是简单分类、固定流程审批这种规则明确的事情，传统规则引擎或小模型就够了，没必要用大模型做过度的投入。

第二个维度：数据和标注成本

传统AI做垂直场景得标注几万甚至几十万的数据，又费钱又费时间。但大模型预训练后泛化能力强，靠提示词或少量的样本就可以适配新场景。如果这个场景拿不到大量高质量标注数据，或者标注成本太高，用大模型就是更优的选择。

第三个维度：投入产出比

大模型的成本不只是API调用或部署的钱，还有后续调优运营的人力成本。得算清楚用了之后能省多少人力、提升多少效率。比如20人的客服团队，大模型能解决70%的问题，那省的人力成本就很可观。但如果是一天就几十个请求的低频场景，或者现有方案已经能解决90%的问题，大模型只能提升五个点的准确率，就要好好算一算这部分提升到底值不值得投入。

第四个维度：技术可行性和潜在风险

主要看三点：

实时性：大模型推理慢，对响应速度要求高的场景得先看能不能通过技术优化解决。

准确率要求：大模型有幻觉问题。像医疗诊断、法律判决这种容错率极低的场景，要用的话必须加多重校验机制。

数据安全合规：涉及隐私或商业机密，用公有大模型API有泄漏风险，私有化部署会增加成本。

综合下来，高频高价值、高复杂度、缺标注数据的场景（如企业知识库问答、智能写作、代码生成）最适合大模型，投入产出比也高。低频低价值、已有成熟方案的场景，先做一个轻量MVP低成本验证，看用户反馈和数据表现，再决定要不要全面铺开。

考查能力：业务判断力，能否从技术可行性、商业价值、风险控制多角度综合评估。

---

进阶真题：设计与实现

【真题5 ★★进阶】如何从0到1设计一个Agent？

你是如何从0到1设计一个Agent的？

参考解析：

一般走六步。

第一步：明确核心解决的问题

不会上来就做全能助手，先锁定具体清晰的场景，比如自动处理客服工单、按需生成周报。只有问题聚焦，后续的设计才不会跑偏。

第二步：拆解Agent要具备的核心能力

按感知、决策、执行的闭环来思考：

• 感知：理解用户输入，确定是纯文本还是多模态能力
• 决策：任务规划，选ReAct模式还是规划式执行
• 执行：确定可调用的工具和API，能不能搜索、调数据库、生成文件

这三个环节缺一不可。

第三步：分层架构设计

• 底层：大模型作为核心大脑
• 工具层：封装之后让Agent能和外部交互
• 记忆层：短期记忆存上下文，长期记忆用向量数据库存知识
• 编排层：把控整个任务流程

分层设计的好处是各层职责清晰，后续迭代调整更方便。

第四步：考虑关键设计细节

• 决策逻辑：简单的任务用Workflow就可以，需要灵活应变的就设计ReAct循环，能根据反馈调整策略
• 工具设计：标准化，每个工具的入参、出参和描述都要清晰，让模型能够正确调用
• 容错机制：针对调用失败、决策错误的情况，设置重试机制和人工介入点

第五步：MVP最小可用版本验证

不会一开始就追求完美，先搭建基础版本，用真实数据跑通。重点关注任务完成率、平均轮次、工具调用准确率、用户满意度这些核心指标，根据数据反馈迭代优化。

第六步：上线后的闭环和持续优化

Agent上线之后持续收集数据，分析失败案例，整理用户反馈，针对性地优化——微调模型、调整提示词、扩充工具集。这是长期迭代的过程。

核心就是：先明确问题，再拆核心能力，做分层架构，打磨设计细节，快速做MVP验证效果，最后根据实际数据持续优化。不用追求一步到位，核心是带着产品思维小步快跑，让数据驱动每一次的优化调整。

考查能力：系统设计能力，能否把抽象需求转化为可落地的技术方案。

---

【真题6 ★★进阶】如何保证Agent调用工具的可靠性？

在实际开发中，你是怎么样保证Agent调用工具的可靠性的？

参考解析：

不能只靠优化提示词，核心是搭建一套全链路的预防、拦截、自愈体系。用四层工程架构兜底，解决大模型幻觉乱填、参数执行失控的问题。

第一层：结构化定义层

这是基础，核心是给模型立好规矩。用JSON Schema做强类型约束，把参数的类型、非空要求、枚举值都定死，避免格式错误。同时精细化打磨工具描述，像写提示词一样讲清楚不同场景该调哪个工具，从根源减少误判。

第二层：推理策略层

让模型想清楚再调用：

• 强制加思维链CoT：要求调用前输出思考过程，砍掉80%的低级错误
• 用Few-shot示例：给模型正反模板，靠它的模仿能力提升准确率
• 工具语义检索：只给模型推送和用户相关的工具，减少干扰

第三层：执行护栏层

相当于执行前的安检，绝不执行模型输出的原始结果：

• 用Pydantic做自动化校验，格式参数有问题直接拦截
• 高风险操作比如转账、删库，必须加用户手动确认，防止Agent失控

第四层：自愈修复层

体现工程能力的关键，不会直接给用户抛错：

• 工具执行报错的话，把报错信息原封不动传给模型，让它根据错误重新生成参数
• 工具调用完成之后，让模型校验结果是不是解决了问题，不符合预期就重新规划再次调用

一句话总结：Agent调用可靠性 = 高质量的结构化定义 + 严格的代码执行约束 × 闭环的反思重试机制。本质是不把希望全寄托在大模型本身，而是通过四层架构做全链路管控，让Agent的工具调用从随机化变成标准化、可控、能自愈的稳定执行。

考查能力：工程实践能力，能否设计出生产级的可靠性保障方案。

---

【真题7 ★★进阶】如何让大模型稳定输出结构化结果？

在Agent开发中，你怎么让模型稳定输出JSON这类结构化结果，避免格式错乱？

参考解析：

不能只靠写提示词，工业级场景必须用多层防御加兜底闭环，从提示词到推理引擎再到工程校验，层层加固才能做到几乎零错误。

大模型本身就具备随机性，只说输出JSON很容易翻车，比如前面加废话、字段缺失、类型不对，解析就直接崩。

第一招：精准提示词控制

不直接说"要求格式"，直接给JSON模板，规范TypeScript接口，加字段描述，让模型明确字段类型。再把指示写清楚，禁止多余文字，用XML标签包裹输出区，避免遗忘格式要求。

第二招：API结构约束

用API接口自带的JSON Schema能力，在解码阶段强制约束输出，相当于给模型铺设轨道，想偏都偏不了，遵循率接近100%。

第三招：开源模型推理掩码

私有化部署的时候，用概率在生成每一步强制约束字符。比如该出双引号的时候，就只允许出双引号，从底层杜绝格式错误。

第四招：工程校验加自修复

用Pydantic等工具做强校验，发现字段缺失、类型错误，就把具体报错丢回模型，让它针对性改写修复。长输出可以流式解析，边生成边检查，发现问题立刻中断。

组合起来就是：规范Prompt + 示例 + 接口约束 + 推理掩码 + 闭环自修复，能把结构化输出错误率压到0.1%以下，完全满足工业级的稳定要求。

考查能力：对大模型输出控制的实践经验，能否从多层面保障输出稳定性。

---

【真题8 ★★进阶】Agent为什么需要设计独立记忆机制？

现在的模型上下文窗口都很长，为什么Agent还需要单独设计记忆机制？

参考解析：

看似长上下文模型解决了问题，但实际落地完全不行。核心有三个原因。

原因一：成本完全不可控

长上下文模型的token定价是阶梯式的，token数越多单价越贵。1M上下文的单次调用成本是8K或16K小模型的几十倍甚至上百倍。如果是商用Agent，多用户对话、长时间交互，成本直接爆炸，中小企业根本扛不住。而外部记忆加检索的方案，只有检索和向量化的成本，推理用小模型成本能降90%以上。

原因二：长上下文模型的注意力衰减问题

模型不是真的能记住所有1M token的内容。原生的Transformer架构对长文本的首尾注意力高，中间内容就基本模糊。尤其是Agent做多步骤推理，中间的关键工具结果、历史决策，模型很容易忽略，导致推理出错，还不如精准给关键信息效果好。

原因三：Agent的任务特性决定了不需要全量上下文

Agent是任务驱动的，每一步只需要解决当前子问题，不需要全程拉着所有历史、所有文档全量塞进去，反而会引入噪声，让模型混淆信息导致决策失误。就算用长上下文模型也得做信息过滤和精简，不是直接无脑全放。

最优方案：分层持久记忆加动态检索

针对长期运行、持续记忆的个人助理Agent：

搭四层记忆架构：瞬时记忆、短期记忆、长期记忆、核心记忆。

做主动记忆召回机制：不是等上下文超了再删，而是Agent每执行一步，先判断当前需要什么信息，主动去长期记忆里检索相关内容。

落地细节：控制单轮上下文token上限，比如给模型留16K的窗口，固定核心记忆占1K，瞬时加短期记忆占5K，检索结果占8K，剩下2K留作缓存，超了就自动压缩。配合轻量的子Agent做记忆压缩，专门用小模型做记忆摘要和抽取，不占用主推理模型的资源。

考查能力：对Agent架构的深入理解，能否从成本、技术、业务多角度分析问题。

---

【真题9 ★★进阶】Agent如何管理多轮对话？

Agent的多轮对话管理模块，怎么样保证长对话中的逻辑一致性和上下文记忆？

参考解析：

通过三重机制来解决这个问题：关键信息抽取存储、逻辑关联追踪、智能遗忘机制。

关键信息抽取存储

不是全量存储，而是提取对话中的实体、意图、行动项，按时间线和关联度结构化存储，既节省token又避免干扰。

抽取规则可配置：业务团队可以定义哪些字段必须保留，比如会议类对话强制提取时间、地点、参会人。同时保留原始对话快照作为兜底，当用户提到"你刚才说的第三点"时，系统回溯到原始文本做指代消解。但主路径仍然依赖结构化信息，因为大模型直接处理长上下文容易幻觉，结构化数据更稳定可追溯。

逻辑关联追踪

对话主题追踪器：实时识别对话的主题切换，当用户返回历史主题时快速调取相关记忆。

任务关联图谱：关联不同对话轮次中的相关任务。比如发布会安排和嘉宾邀请会被标记为同一个项目下的子任务，确保信息不割裂。

智能遗忘机制

按任务类型设置上下文的有效期：短期任务保留七天，长期任务保留30天，自动清理无关过期信息，降低模型计算压力，同时避免信息冗余影响理解。

考查能力：对话系统设计经验，能否在复杂场景下保证对话质量。

---

【真题10 ★★进阶】如何判断对话内容哪些应该写入记忆？

如果给你一段对话，怎么样判断哪些内容应该被写进记忆？

参考解析：

从三个维度判断：持久性价值、结构化程度、个性化价值。

持久性价值

判断信息未来是否还会被用到。事实性信息后续可能涉及行程、会议准备，未来有参考价值，就应该写入长期记忆。临时性的推理过程，用完就失效，可以放短期记忆甚至不存。

结构化程度

结构化程度高的数据更容易检索和复用。带有明确实体和关系的数据，更适合存入向量数据库。结构化存储便于Agent调用和规定，但纯对话的问答就没有可提取的单元。

个性化价值

信息能不能帮助Agent更懂用户。比如用户表面上说代办事项总忘，其实反映出他容易忘记事情的习惯。这一类用户习惯、偏好、隐藏的需求都值得记录，是个性化服务的基础。

记忆写入机制设计

记忆提取：对话结束后，用一个专门的小模型分析整个对话，识别关键信息。

重要性评分：不是所有提取的信息都值得存。设计评分规则，比如涉及金钱合同给高权重，用户多次强调的内容权重高。根据分数决定存入长期记忆、短期记忆，还是直接过滤。

记忆压缩和遗忘：长期记忆不能无限增长，必须有衰减机制。比如一条记忆三个月没被调用且重要性很低，就自动删除；如果某条信息频繁被使用，就提升权重并保留。对于重复的信息进行合并或去重。

考查能力：对记忆机制设计的深度思考，能否从业务角度设计合理的存储策略。

---

高级真题：架构与协作

【真题11 ★★★高级】多智能体和单智能体有什么区别？

根据你过往的经验，多智能体和单智能体在设计上最核心的区别是什么？各自更适合什么场景？

参考解析：

核心区别在于复杂性由谁来承载。

单智能体把所有复杂性压在自己身上，要理解任务、规划步骤、调用工具、还要处理异常。就像一个全栈工程师，既要写前端又要调数据库。当任务流程线性、工具链清晰的时候，这种模式很高效。但一旦任务分支多、依赖复杂，它的规划能力就容易超载。

多智能体把复杂性转移到交互协议和协作机制上，每个Agent只专注一个子任务，比如查询、分析、格式化。系统的复杂性体现在如何让它们高效通信、避免冲突、保持目标一致。这个时候共享工作区、消息队列或者MCP这类标准化协议就很关键。

判断要不要拆，看两点：

任务能否模块化：像文档处理是线性流水线，每一步输入明确、输出也明确，用单Agent配合Workflow这样的标准化工具接入就简单可靠。

子任务之间是否需要专业分工：软件开发的需求分析、架构设计、编码，不仅专业领域不同，还可能需要反复协商。这个时候拆成多个专业Agent，各自用最合适的模型和工具，再通过MCP协议协同，反而更灵活更可控。

多智能体协作如何保证目标不跑偏

一个Agent理解错了任务会不会带偏整个流程？靠三层机制：

统一的任务上下文：所有Agent共享初始目标和约束条件。

中间结果校验：比如分析Agent输出的结论会由协调者Agent做合理性检查。

MCP协议中的反馈机制：下游Agent如果发现输入不合理，可以触发重试或者回溯。

本质上多智能体不能完全去中心化，必须有一个轻量级的协调者来对齐目标、监控进度、处理异常，不然很容易各犯各的错。

考查能力：系统架构设计能力，能否合理拆分复杂系统。

---

【真题12 ★★★高级】多Agent之间是怎么协作的？

多Agent具体是怎么协作的？主要看哪些协作机制？

参考解析：

多Agent协作要看四个关键点：任务分解、角色分配、通信机制、协作模式。

任务分解

一般会有一个监督者角色，负责把用户需求拆解成一个一个子任务。这个拆解过程用大模型通过提示词工程来实现。

角色分配

拆解完任务之后，监督者会根据每个Agent的角色和能力，把对应的子任务分配给他们。每个Agent都有自己的系统提示词，定义了专业领域、工作方式、输出格式。

通信机制

常见两种方式：

消息传递：上一个智能体的输出直接作为消息发送给下一个。

共享记忆：所有Agent的读写都在一个上下文进行存储，实时同步状态。

协作模式

主要分三种：

层级式：一个中心节点负责调度其他Agent，适合流程明确的任务。

平行式：所有Agent地位平等，通过讨论达成共识，适合多角度决策。

流水线式：任务按固定顺序执行，上一个Agent的输出就是下一个Agent的输入。

考查能力：对多Agent系统架构的理解深度。

---

【真题13 ★★★高级】什么是A2A（Agent to Agent）交互模式？

请解释一下A2A是什么意思，你的项目中有没有用过类似的交互模式？

参考解析：

A2A全称是Agent to Agent，智能体对智能体的交互模式。简单来说就是让两个或多个大模型智能体协作，各自负责一块，最后合力完成复杂需求。

实际应用案例

做过一个跨境电商运营系统，用这个模式把系统拆分成三个Agent：

• 数据抓取Agent：专门对接海外电商平台，爬取销量、评价数据
• 数据分析Agent：拿数据做爆款预测
• 文案生成Agent：根据预测结果写商品标题和详情页

三个Agent自动传数据，比如数据分析Agent算出某类产品要火，直接把关键词传给文案Agent，不用人工中转，比单Agent干活效率高太多了。而且每个Agent专精一块，准确率也更好。

智能办公助手设计案例

按任务流转的逻辑拆成四个核心Agent：

需求解析Agent：接用户模糊需求，比如"帮我搞定下周客户拜访"，拆成订会议室、发邀约邮件、准备客户资料三个子任务，再分给对应Agent。

资源调度Agent：会议室、车辆这些办公资源，接需求就查空闲状态，定好之后同步信息。

内容生成Agent：写邀约邮件，调取客户过往合作记录，调用微调过的企业模型确保用词符合公司规范。

进度追踪Agent：监控每个子任务的完成情况，比如邮件没发出去就提醒，最后汇总记录表给用户。

保证协作效率的两点

统一数据模式：Agent间传信息都用"任务ID+核心参数+完成状态"的固定结构，不用猜格式。

加个中间调度器：假如A2A之间有冲突，比如两个任务同时定一个会议室，调度器能立马协调，按任务优先级分配。之前做项目没加调度器就出现过资源冲突，加上之后协作就顺畅了。

考查能力：对Agent间通信协议和协作设计的实战经验。

---

【真题14 ★★★高级】智能体项目如何做任务拆解？

挑一个项目说一说为什么要那样做，解决了什么问题，具体如何解决的？

参考解析：

项目背景

公司内部效率痛点：业务团队每天要从大量会议纪要、产品文档、用户反馈中人工提取结构化信息——竞品动态、用户痛点分析、待办事项等。人工梳理不仅耗时，而且不同人整理的标准不一样。

核心目标是构建一个能自动处理多元异构文本、输出高质量结构化数据的智能体，节省人力劳动，提升信息流转和决策效率。

为什么没直接用大模型端到端处理

评估了几个维度：直接用超大闭源模型做端到端处理，对比用较小模型做专精任务。

端到端方案虽然简单，但成本比较高，输出格式不稳定，难以干预。而这是内部提效场景，对成本、稳定性、可控性的要求很高。

所以选择了后者：把任务拆解为文档解析、信息抽取、格式化输出四个子步骤，用流程引擎串联，确保每一步都可监控可修正。

技术落地

文档解析层：用开源的RAG和PDF解析库。

信息抽取层：不依赖通用大模型，而是基于业务数据微调的中等参数模型，专门负责实体识别、关系抽取、分类。在模型外层套一个规则校验引擎，比如抽取出的公司名称会去内部知识库做匹配。

整个流程设计成明确的工作流，模型只需要负责理解和初步抽取，其余的流程和规则保障准确性。

考查能力：项目架构设计能力，能否清晰阐述技术选型的理由。

---

【真题15 ★★★高级】智能体的指标如何定义和验证？

智能体上线后任务完成率达到92%，召回率85%，效率从15分钟降到2分钟。这类指标怎么定义和验证？

参考解析：

任务完成率

做了明确定义：不仅要求输出非空，还必须包含所有必填字段。比如竞品名称、用户痛点类型、负责人、截止时间，如果缺失关键字段即使有内容也算失败。

准确率

由业务方对抽样的500份文档做人工标注，比对模型输出和标准答案的一致性。比如用户痛点分类是否正确，待办事项是否完整抽取，85%是综合各字段的加权准确率。

效率

两分钟是端到端处理时间，包括文档解析、抽取、校验、格式化输出，完全没有人工介入。

成本和效果对比

试过用GPT-4做端到端的baseline，准确率约82%，略低于我们的85%，但单次处理成本是六倍以上。而且输出格式很不稳定，有时候漏字段，有时候结构错乱，需要额外加后处理。

最终方案是用7B级别的模型微调，配合规则引擎做校验和补全。虽然开发初期多花了两周搭建流程，但单文本成本降低了80%，输出100%符合标准格式，业务可以直接对接下游系统。

ROI不只是算钱，还包括可维护性、可解释性、系统稳定性。

业务和技术对齐标准

早期分歧很大：算法团队只看F1值，业务只看能不能用，容易脱节。

后来通过共同定义可用结果：业务抽样bad case，算法解释原因，产品协调优先级。产品、算法、业务目标对齐后，迭代方向更清晰，落地阻力也小了很多。

考查能力：指标体系设计能力，能否让技术指标和业务价值挂钩。

---

【真题16 ★★★高级】如何设计长期运行Agent的记忆架构？

如果需要做一个持续运行、长期记忆的Agent，突破上下文限制的最优方案是什么？

参考解析：

最优方案是分层持久记忆加动态检索加滚动窗口，再加增量更新的闭环架构。

搭四层记忆架构

瞬时记忆：当前对话的实时上下文。

短期记忆：近期交互的摘要。

长期记忆：向量数据库存储的历史知识。

核心记忆：用户画像、偏好等关键信息。

主动记忆召回机制

不是等上下文超了再删，而是Agent每执行一步，先判断当前需要什么信息，主动去长期记忆里检索相关内容，而不是被动把所有历史背进去。

比如用户问"上个月让你定的会议提醒改时间没有？"要先检索长期记忆里定会议相关的条目，只要把这条信息放进上下文，其他记忆不动。

落地细节

控制单轮上下文token上限：给模型留16K窗口，固定核心记忆占1K，瞬时加短期记忆占5K，检索结果占8K，剩下2K留作缓存，超了就自动压缩短期记忆，不突破上限。

增量记忆更新

只把新的关键信息加入长期记忆，重复信息、无效信息直接过滤，避免记忆库膨胀导致检索变慢。

配合轻量子Agent做记忆压缩

专门用小模型做记忆摘要和抽取，不占用主推理模型的资源，主模型专注做决策和交互。

这样整个系统既不会超窗口，又能长期保留用户的核心信息，体验也流畅。

考查能力：对Agent长期运行的架构设计能力。

---

【真题17 ★★★高级】如何看待OpenClaw这类自主Agent产品？

作为AI产品经理，你怎么看待OpenClaw这个产品？

参考解析：

OpenClaw是今年年初AI圈非常炸裂的现象级产品之一。

核心创新

OpenClaw和传统AI最大的区别：它不是一个等你指挥的助手，而是一个真正能够主动干活的数字员工。

传统AI是对话式的，你问一句它答一句。但OpenClaw是自主式智能体，能够看屏幕、读文件，操作浏览器、执行脚本、模拟鼠标键盘，还有记忆部分——持久化的上下文记忆。发布指令之后，它能在后台执行，不需要时时刻刻盯着。从对话工具到自主代理，本身就是质的跨越。

产品定位

OpenClaw并没有做某个垂直产品的智能体，而是做运行任何智能体的基础设施。这个思路跟早期的操作系统很像——不是某个具体的应用，而是让所有应用在上面跑的平台。

通过开源和可编程的特性，吸引大量开发者在上面构建各种智能体，形成快速增长的生态。这种平台化而非工具化的定位，是它能快速破圈的关键。

现实问题

成本问题：自主运行会不停调用大模型API，token消耗很恐怖，普通用户不可持续，需要更好的成本控制和预算管理。

安全和可控性：给AI这么高的权限，能操纵浏览器执行脚本，如果出现bug或被恶意利用，风险很大。虽然本地部署数据相对安全，但技术门槛高，普通用户配置折腾。

稳定性和调试难度：自主智能体不像传统软件可预测，行为路径复杂，一旦出bug调试过程很痛苦。

趋势洞察

AI正在从被动工具进化成主动助手，用户期待从"能回答问题"变成"能把事情做完"。

开源生态在智能体领域的威力：OpenClaw用开源方式快速聚集开发者社区，形成网络效应，对闭源商业产品是巨大挑战。

个人AI助手市场正在打开，以前觉得AI助手是企业级的东西，但OpenClaw证明了个人用户也有强烈的自动化需求，而且愿意为此投入时间和成本。

产品经理视角的评价

最值得学习的是对用户真实痛点的洞察：不是炫技，而是解决"我希望AI能真正替我干活"这个最朴素的需求。

同时也暴露了当前智能体的共性难题：如何在自主性和可控性之间找平衡，如何在功能强大和成本可控之间做平衡。这些是接下来产品需要解决的核心问题。

考查能力：产品洞察力，能否从产品设计角度分析创新产品的价值与挑战。

---

【真题18 ★★★高级】OpenClaw的具体能力和操作模式？

"养龙虾"具体指什么？操作模式和传统AI有什么区别？

参考解析：

"养龙虾"的含义

"养龙虾"是饲养类Agent智能体OpenClaw的形象说法。因为OpenClaw的图标是一个龙虾，所以有了这个称呼，也是今年新晋的网络热词。核心就是打造属于自己的专属AI智能体。

操作模式

把OpenClaw部署到电脑上，就相当于给AI智能体安了一个窝。它具备记忆功能，能在和用户对话中记住使用习惯、各类需求，而且会自主成长。

平时给它"喂粮食"，其实就是提供AI运行的算力，算力投喂得越多，能力就越强。还能实现自我迭代，同时学习调用他人公开可重复使用的技能，熟练之后它还会自动找"螺"干。

和传统AI的最大区别

传统AI大部分只具备对话功能，无法落地完成任务。

OpenClaw彻底打破了这个瓶颈，从单纯的对话工具变成了每个人独一无二的赛博劳动力，真正实现了自主执行各类任务。

能完成的任务

能力覆盖范围很广：

• 小到代码开发调试
• 私域社群全自动运营
• 大到自动炒股
• 全球预测平台的自动套利

只要有相关想法，并且给它对应的操作权限，它都能自主完成所有任务。操作方式也很便捷，用户只需要在手机、手表上通过聊天软件发布指令，它就可以在后台自动完成任务流程。

考查能力：对新兴AI产品的了解程度和学习能力。

---

下一步备考方向

掌握这18道Agent真题，你已经覆盖了智能体开发的核心考点。接下来建议：

动手实践：搭一个简单的Agent项目，用LangChain或AutoGPT框架跑通感知-决策-执行闭环。

深入工具调用：研究Function Calling、Toolformer等工具调用技术，理解结构化输出的工程保障。

关注前沿产品：OpenClaw、AutoGPT、BabyAGI这些开源项目值得深入研究，了解自主Agent的架构设计思路。

准备项目话术：面试时用项目经历串联这些知识点，讲清楚为什么这样设计、解决了什么问题、效果如何衡量。

Agent开发是AI应用的核心方向，技术迭代很快，保持学习、动手实践，面试时就能侃侃而谈。