AI Agent开发一面面经合集

写在前面

【WeThinkIn出品】栏目专注于分享Rocky的认知思考与经验感悟，范围涵盖但不限于AI行业。

干货AIGC、AI Agent、LLM算法工程师/开发工程师面试面经秘籍分享（持续更新）：<a href="https://gw-c.nowcoder.com/api/sparta/jump/link?link=https%3A%2F%2Fgithub.com%2FWeThinkIn%2FAIGC-Interview-Book" rel="nofollow noopener noreferrer" target="_blank">WeThinkIn/AIGC-Interview-Book</a>欢迎大家Star～

大家好，我是Rocky。

一面

1. 自我介绍一下。

回答：

自我介绍要服务于后续追问，而不是把简历从头念一遍。建议在 60～90 秒内建立“经历主线 -> 代表项目 -> 个人贡献 -> 岗位匹配”的闭环，并且所有项目、职责和指标都必须是真实的。

一个可替换的结构是：

1. 一句话定位。 说明学历或工作阶段、主技术栈，以及当前最相关的方向，例如 Java 后端、Agent 应用工程和大模型基础设施。
2. 选择一段实习和一个项目。 每段只讲业务问题、个人负责模块、关键机制和验证结果。不要把团队成果全部说成自己的，也不要把离线实验说成线上收益。
3. 提炼能力主线。 例如后端经验让自己熟悉并发、缓存、数据库、可观测和稳定性；Agent 项目让自己掌握上下文、工具调用、记忆、编排和评测。两者是连续积累，不是临时追热点。
4. 落到岗位。 说明为什么适合内容社区或广告场景：既理解概率模型的不确定性，也能把权限、状态、实验和业务指标做成可控制的工程闭环。

可以这样收尾：“我对 Agent 的理解不是在模型外面套一层 Prompt，而是把模型、工具、状态、验证和真实业务系统组织起来。我希望继续做 Agent 开发，因为这个方向正好需要我已有的后端工程能力，同时也要求对模型行为、评测和业务指标建立更深入的判断。”

2. 介绍一下你这个___实习关注指标是什么？

回答：

题目中的空白必须按真实实习业务补全。回答时不要只报一个结果指标，而要说明指标树、口径、观测窗口和自己的影响链路。

我会把指标分成五层：

层次	要回答的问题	Agent/业务示例
北极星指标	项目最终创造什么价值	任务完成率、采纳率、发布率、增量收入或人工时长降低
质量指标	输出是否正确且可用	工具选择/参数正确率、事实忠实度、人工通过率、错误副作用率
效率指标	单位任务消耗多少资源	P50/P95 延迟、Token、模型费用、工具调用次数、单位成功成本
系统指标	服务是否稳定	可用性、超时率、429/5xx、队列等待、恢复率、缓存命中率
安全护栏	是否越权或伤害业务	越权率、敏感数据泄漏、预算超限、投诉率、回滚率

还要说明口径。例如“任务成功”是模型说完成，还是数据库最终状态、测试和人工验收都通过；转化率看点击后 1 天还是 7 天；指标提升是否来自随机对照实验，还是仅仅与历史同期相比。对多指标项目，应先定义主指标，再用质量、安全和成本做 guardrail，不能只优化一个漂亮数字。

最后落到个人贡献：“我负责的是哪一段链路，改动如何影响中间指标，中间指标为何能传导到业务结果，使用什么实验或回放证明。”如果项目没有线上 A/B，就坦诚给出离线样本数、基线、置信区间和当前局限，不编造业务收益。

3-12. 全都是实习相关问题，涉及Agent就狂追问，问了问数字指标，还有业务上下游，代码框架。

回答：

这一条将第 3～12 题概括为连续的实习追问，没有展开十道独立问题，因此应直接回答项目深挖的组织方法，而不补造题目。可以提前把同一段实习整理成一张“可追问地图”，保证每一层都能回到真实证据。

建议准备六个层次：

1. 业务上下游： 谁提出请求、输入数据来自哪里、Agent 输出给哪个系统、失败会影响谁、人工在哪个环节接管。
2. 系统架构： 接入、任务状态、Context Builder、模型、RAG/Memory、工具、消息队列、数据库、缓存、评测和监控如何连接。
3. Agent 决策： 为什么使用 Workflow、ReAct 或 Planner-Executor；哪些步骤由模型决策，哪些规则必须由代码控制。
4. 代码边界： 自己负责哪些包、接口、状态结构和工具；使用了哪些开源组件；为什么改造默认实现；关键异常路径如何测试。
5. 数字指标： 数据量、并发、P95、Token、成本、任务成功率、工具正确率、恢复率以及实验置信度。每个数字都要知道计算公式和数据来源。
6. 失败案例： 最难的 bad case、定位证据、根因、替代方案、最终结果和仍未解决的边界。

回答项目追问时采用“先结论、再机制、后证据”的三段式。例如先说瓶颈是工具结果不确定导致重复副作用，再解释超时、幂等和状态回读机制，最后给 trace、故障注入或线上指标。这样既不会想到什么说什么，也能让面试官清楚地区分团队架构、个人贡献和真实效果。

13. 说一下你这个项目Agent用在哪里。

回答：

这道题考察的不是“项目里有没有 Agent”这个标签，而是 Agent 是否放在真正需要动态决策的位置。回答时应说明业务入口、决策边界、工具、状态和最终验收。

可以按真实项目组织为：用户或上游系统先提交目标；任务层保存当前目标、约束和进度；Context Builder 选择必要的历史、知识和工具；模型根据当前状态决定下一动作；工具执行后把真实 Observation 写回；验证器根据业务状态决定完成、重试、重规划或人工接管。

关键是讲清哪里不用 Agent。鉴权、预算、状态迁移、金额计算、数据写入校验和合规规则应由确定性代码负责；步骤固定的链路使用 Workflow；只有任务路径依赖外部观察、工具结果或开放式语义判断时，才让模型参与决策。

最后补上可验证结果：Agent 替代了哪段人工流程，成功标准是什么，失败如何回滚，采用什么基线比较。如果项目只是对话问答、单次 RAG 或固定 Prompt 链，也应如实描述，不要为了迎合题目把所有大模型应用都叫 Agent。

14. OpenManus 是用的什么框架？

回答：

以当前公开仓库代码为准，OpenManus 不是基于 LangChain 或 LangGraph 搭出来的套壳项目，而是一套 Python 自研的轻量 Agent/Flow 框架。

它的核心继承链是 BaseAgent -> ReActAgent -> ToolCallAgent -> Manus：

• BaseAgent 管理运行循环、状态和消息；
• ReActAgent 抽象 think() 与 act()；
• ToolCallAgent 使用 OpenAI 兼容的工具调用接口选择并执行工具，把 Observation 写回 Memory；
• Manus 组装 Python 执行、浏览器、文本编辑、询问用户、终止以及 MCP 工具，并设置最大步骤和 Observation 长度。

多 Agent/长任务部分位于独立的 flow 层。PlanningFlow 使用 PlanningTool 创建步骤、维护步骤状态，再按步骤类型选择 Executor 执行；官方 README 仍把 run_flow.py 标为不稳定的多 Agent 版本，所以不能把它描述成成熟完备的生产级分布式编排系统。

依赖层面主要使用 Pydantic 做数据模型和配置，OpenAI SDK 做模型兼容调用，Tenacity 做重试，Browser-Use/Playwright 做浏览器操作，MCP SDK 接外部工具，并包含 FastAPI、Docker、Crawl4AI 等工程依赖。OpenManus 团队成员来自 MetaGPT 社区，但“作者来自 MetaGPT”不等于“运行时基于 MetaGPT”。

面试中最好给出一句结论：OpenManus 的主线是自研 ReAct + Tool Calling Agent，外加 PlanningFlow、MCP、浏览器和沙箱能力；回答框架问题要看代码继承与依赖，而不是只看项目作者背景。

15. 讲一下你怎么理解Harness？

回答：

Harness 是模型外部的运行与治理环境，决定 Agent 看见什么上下文、能调用哪些工具、动作如何执行、状态如何持久化、失败怎样恢复以及结果如何验证。模型负责给出概率性的下一步决策，Harness 把这种决策约束在真实软件系统可以接受的边界内。

一个完整 Harness 通常包括：

• Context Builder：系统规则、任务状态、近期历史、Memory/RAG 和工具的选择与压缩；
• Tool Runtime：schema、权限、沙箱、超时、幂等、限流和副作用确认；
• State/Checkpoint：目标、计划、步骤、artifact、错误和审批状态；
• Control Loop：Workflow、ReAct、Planner-Executor、最大步数、预算和终止条件；
• Reliability/Safety：重试、熔断、降级、回滚、人工接管、注入防护和密钥隔离；
• Trace/Eval：模型与 Prompt 版本、工具轨迹、最终状态、成本、延迟、判分和回归门禁。

需要区分两个常见语境：Runtime Harness 负责线上运行和控制，Eval Harness 负责构造任务/环境、回放轨迹、评分和版本比较。二者可以共享 trace、沙箱和验证器，但不是同一个概念。

Harness 提升复杂任务能力，不是让模型参数突然变强，而是把长任务外化为可见状态，把真实工具结果反馈给模型，把错误限制在可恢复步骤里，并用验证器替代“模型自称完成”。同一个模型放进不同 Harness，任务完成率、成本和安全性可以有显著差异。

16. 多 Agent 并发有什么性能问题？

回答：

多 Agent 并发不是简单把多个协程一起启动。它会同时放大模型、工具、状态和协调四类瓶颈。

1. 模型网关瓶颈。 Fan-out 会快速消耗 RPM/TPM，并触发 429；每个子 Agent 重复携带系统 Prompt、工具 schema 和公共上下文，Token 与费用近似随分支数增长。
2. 尾延迟放大。 汇总节点通常等待最慢分支。并发分支越多，出现一个慢模型、慢工具或重试的概率越高，最终 P95/P99 可能反而上升。
3. 下游资源争用。 浏览器、数据库连接池、Redis、向量库、文件句柄和第三方 API 都有容量上限；上游无限并发只会把等待转移到下游队列。
4. 共享状态竞争。 多个 Agent 同时修改计划、Memory、文件或业务记录会产生丢失更新、重复副作用和顺序不一致，需要版本、锁、幂等与单写者策略。
5. 重复探索和上下文膨胀。 子 Agent 可能检索同一资料、调用同一工具；汇总全部轨迹会挤占上下文并增加信息冲突。
6. 协调故障。 可能出现互相等待、循环交接、部分成功、取消传播失败，以及 Supervisor 成为串行瓶颈。

因此要比较的不是单 Agent 与多 Agent 的“智能感”，而是单位成功任务成本、临界路径延迟、工具负载、重复工作率和最终质量。任务不可并行、共享状态强耦合或结果聚合困难时，多 Agent 往往比单 Agent + 工具更差。

17. 你平时怎么控制 Agent 并发量？

回答：

我会采用分层并发预算，而不是只设置一个全局线程数。

入口层先做鉴权、配额和 admission control；任务进入有界队列，队列满时明确拒绝、降级或延迟执行，不能无限堆积。运行时按 tenant -> user -> task -> model/tool 设置并发上限：模型调用受 RPM/TPM 和成本预算约束，浏览器/代码沙箱按实例池约束，数据库和第三方 API 按连接池及对方限额约束。

实现上常用：

• Semaphore 限制同时执行的模型或工具调用；
• Token Bucket/Leaky Bucket 控制一段时间内的请求速率；
• Bulkhead 为不同租户、工具和任务类型隔离资源；
• 有界队列与 backpressure 防止生产速度长期高于消费速度；
• 对同一业务实体使用幂等键、版本号或单写者，避免并发副作用；
• 并行分支设置总 deadline、最大 fan-out、取消传播和 partial result 策略。

并发值应通过压测和线上反馈校准。可以根据 429、工具错误率、队列等待和 P95 动态降低上限，稳定后缓慢探测增加，并设置滞回避免振荡。还应合并相同检索、缓存公共上下文，并只向聚合器传结构化结论和证据引用。

本质上，并发控制不是追求“同时跑更多 Agent”，而是在模型配额、下游容量、延迟和成本约束下，让每个成功任务消耗可预测。

18. 讲一下长时记忆和短时记忆的底层实现方式？

回答：

短时记忆维持当前任务连续性，长时记忆支撑跨会话复用。二者底层都不等于“把聊天记录放进向量库”，而是不同生命周期的数据系统。

短时/工作记忆通常由三部分组成：最近若干轮原始消息；结构化任务状态，如目标、计划、已完成步骤、工具结果和待确认项；较早历史的摘要与事件引用。状态可放在进程内、Redis、关系数据库或 Workflow checkpoint store 中，每次模型调用前由 Context Builder 按 Token 预算投影进 Prompt。KV Cache 只是推理加速缓存，不是 Agent Memory。

长时记忆通常按类型分库存储：用户稳定偏好和身份事实适合关系表/画像 KV；具体历史事件适合 append-only event log；自然语言经验适合向量 + 全文混合索引；实体关系复杂时才考虑图数据库。每条记录至少带 tenant/user/project scope、来源、时间、置信度、有效期、权限和原始事件引用。

生命周期是：候选提取 -> 重要性/敏感性过滤 -> 去重与结构化 -> 写入 -> 按需检索 -> 相关性/时效/权限重排 -> 注入 -> 冲突更新或遗忘。当前用户明确表达优先于旧偏好，业务主库实时状态优先于历史摘要，低置信模型推断不能覆盖用户事实。

长期记忆的质量要看召回后是否提高任务成功率、减少重复询问，同时监控错误记忆引用、跨用户串线和隐私删除能力。记忆的目标不是保存最多，而是在正确作用域内保留可纠正、可追溯、未来仍有价值的状态。

19. 讲一下 ReAct 的流程？

回答：

ReAct 是 Reasoning and Acting 的组合，核心是让模型根据当前状态选择 Action，再用真实环境返回的 Observation 修正下一步决策：

<div class="math math-display">

s_t \xrightarrow{\text{reason/decide}} a_t \xrightarrow{\text{tool or env}} o_{t+1} \xrightarrow{\text{state update}} s_{t+1}

</div>

工程流程通常是：

1. 解析目标、约束、可用工具、预算和停止条件；
2. 模型基于当前上下文决定直接回答还是产生结构化工具调用；
3. Harness 做权限、schema、参数、预算和副作用检查；
4. 工具执行，返回被裁剪、标注来源的 Observation；
5. 更新消息、任务状态和 action history；
6. 验证是否完成，未完成则进入下一轮，失败则重试、重规划或人工接管。

ReAct 的优势是外部 grounding：模型不必只靠参数知识猜测，可以搜索、读取文件或查询业务状态。局限是局部贪心、工具循环、长 Observation 挤压上下文，以及每一步串行等待带来的成本和延迟。

生产实现不会只写一个无限 while。要设置最大步数、总 Token/deadline、重复动作检测、工具错误分类、状态 checkpoint 和独立终止验证；高风险 Action 前还需要 policy gate。ReAct 是一种控制模式，不自动等于可靠 Agent。

20. Planner、Executor、Critic 分别怎么做的。

回答：

三者分别负责“拆什么、怎么做、做得是否合格”，但不一定必须是三个独立模型或三个 Agent。

Planner 把目标转成有依赖关系的步骤，输出每一步的输入、期望产物、可用工具、完成条件和风险。计划应写入外部状态并版本化；环境变化或步骤失败时做局部重规划，而不是每轮重写全部计划。

Executor 只执行当前 ready step。它可以在步骤内部使用 ReAct：选择工具、执行、读取 Observation，并生成结构化 artifact。Executor 受权限、超时、幂等和资源预算约束，不能自行修改业务硬规则。

Critic 根据 rubric、测试、业务状态和证据评价计划或执行结果，输出 pass / revise / replan / escalate 以及可定位的问题。确定性检查应优先使用规则、单测、schema 和数据库状态；只有主观质量或长尾语义才交给 LLM Critic。

典型状态迁移是：

<div class="math math-display">

\text{Plan} \rightarrow \text{Execute Step} \rightarrow \text{Verify/Critic} \rightarrow \{\text{next},\text{revise},\text{replan},\text{human},\text{done}\}

</div>

要避免 Critic 无限打回：设置最大修订次数、失败升级条件和成本预算；对 LLM Critic 做盲评、位置随机化、标尺校准和人工抽检。系统完成的依据应是外部验收条件，而不是 Critic 的一句“看起来不错”。

21. Critic什么意思？为什么不用ReAct？

回答：

Critic 是评估器或审查角色，用来判断当前计划、步骤产物或最终结果是否满足 rubric、事实、测试和业务约束，并给出修订、重规划或停止信号。它可以是规则、单元测试、奖励模型、LLM Judge 或人工，并不天然等于一个独立大模型 Agent。

“Critic”和“ReAct”不在同一维度，因此并不互斥：ReAct 描述的是执行过程中 Thought/Action/Observation 的局部循环；Critic 描述的是质量反馈机制。常见组合是 Planner 生成全局计划，Executor 在每个步骤内部用 ReAct 调工具，Critic 在阶段边界验收结果。

不采用纯 ReAct的理由通常有：长任务需要全局依赖和里程碑，ReAct 容易局部贪心；工具调用串行导致高延迟；Observation 持续累积；模型可能重复尝试；完成条件和质量标准不容易仅靠下一步推理保证。对于步骤明确的业务，Workflow + Validator 更稳定；对于开放探索，ReAct 更合适。

同样，Critic 也不是越多越好。若结果可由测试或业务状态确定，就优先确定性验证；LLM Critic 会有偏好、位置和自洽偏差，自己评自己尤其容易放过错误。正确回答不是“Critic 替代 ReAct”，而是根据任务把规划、执行和验证放在合适边界，并说明为什么。

22. 上下文怎么做的？你是拆分的嘛？

回答：

上下文应该拆分，但底层模型最终看到的仍是一段 Token 序列。所谓拆分，是工程侧按来源、生命周期、权限和优先级管理信息，再由 Context Builder 为当前步骤组装最小充分上下文。

我会分成六个区：

1. Policy： System 指令、权限、安全和输出契约，固定高优先级，不参与普通摘要。
2. Task State： 当前目标、计划、步骤、变量、已完成事项和待审批项，结构化存储。
3. Recent Context： 最近交互和当前步骤的原始工具结果。
4. Compressed History： 已完成阶段的结构化摘要，保留事件和 artifact 引用。
5. Retrieved Context： 按需召回的长期记忆、RAG 文档和代码片段，经过权限、时效、冲突与 Rerank。
6. Tool Context： 当前候选工具的最小 schema；工具很多时渐进披露，而不是每轮发送全部定义。

每类设置独立 Token 预算，并为模型输出预留空间：

<div class="math math-display">

B_{policy}+B_{state}+B_{recent}+B_{summary}+B_{retrieval}+B_{tools}+B_{output} \le B_{window}

</div>

多 Agent 场景还要做上下文隔离：子 Agent 只接收自己的任务、必要证据和产物契约，返回结构化结果与引用；Supervisor 不汇总全部内部对话。原始事件保存在外部存储，摘要丢失信息时可回读或重建。上下文工程的核心不是“切几段 Prompt”，而是让当前决策获得足够证据，同时避免无关历史、越权数据和重复工具信息。

25. 讲一下Redis的数据结构。

回答：

Redis 对外提供的是数据类型，对内会根据元素数量、长度和版本选择不同编码。回答时先讲抽象语义，再讲底层实现，避免把某一种编码说成永远不变。

数据类型	核心语义	常见场景
String	二进制安全字节序列，支持整数和位操作	缓存、计数器、分布式锁状态、Bitmap
Hash	field-value 映射	对象属性、用户画像、配置
List	有序可重复序列，两端操作高效	队列、时间线；可靠消息优先考虑 Stream
Set	无序去重集合	标签、共同关注、去重与交并差
Sorted Set	member 唯一、按 score 排序	排行榜、延时任务、范围检索、GEO 底座
Stream	append-only 消息流，支持 Consumer Group	事件流、任务分发、待确认消息
Bitmap/Bitfield	基于 String 的位级操作	签到、活跃状态、布尔特征
HyperLogLog	近似基数统计	UV、去重规模估计
Geospatial	经纬度写入 Sorted Set 并做空间查询	附近的人/店、距离查询

此外还有 Redis Stack 提供的 JSON、Search、Time Series 等模块能力，但不能与 Redis 核心内置类型混为一谈。

选型看访问模式：需要字段级更新用 Hash，需要唯一集合用 Set，需要排序范围用 ZSet，需要可靠消费与 pending/ack 用 Stream。生产中还要考虑 key 大小、BigKey/HotKey、过期、内存淘汰、持久化和集群 slot；数据结构选对不代表系统就自动可靠。

26. 每种的底层机理了解嘛？

回答：

了解，但要加一句版本边界：Redis 的内部编码会演进，阈值也可配置，不能把旧版 ziplist 等实现当成所有版本的固定答案。可以用 OBJECT ENCODING key 观察当前对象编码。

• String： 使用 SDS 保存二进制安全字符串，根据值和长度采用整数、嵌入式或普通字符串编码。SDS 记录长度和容量，避免每次扫描 \0，并支持预分配。
• Hash： 小对象通常使用 listpack 紧凑顺序存储；超过元素数或长度阈值后转为 dict/hashtable，字段查找平均 O(1)，但内存开销增加。
• List： 现代实现通常是 quicklist，即由双向链表组织多个 listpack 节点，在两端操作、局部压缩和内存之间折中。
• Set： 全部是整数且规模较小时可用 intset，保持有序紧凑数组；否则使用 hashtable，成员查找平均 O(1)。
• Sorted Set： 小集合可用 listpack；大集合通常使用 skiplist + dict。dict 做 member 到 score 的快速查找，skiplist 支持按 score 排序和范围查询，复杂度约 O(\log N)。
• Stream： 条目按单调 ID 组织在 radix tree 中，叶节点使用 listpack 紧凑存储；Consumer Group 维护 last-delivered-id 和 Pending Entries List，用于 ack、重投和消费者追踪。
• Bitmap/Bitfield： 底层仍是 String/SDS，把 offset 映射到字节和 bit；空间效率高，但极大偏移会扩展字符串。
• HyperLogLog： 使用稀疏/稠密寄存器和概率估计，在固定小内存下估算基数，结果有统计误差而不是精确计数。
• GEO： 将经纬度编码成 geohash 风格 score 存入 Sorted Set，再做邻域候选和精确距离过滤。

还应知道 dict 的渐进式 rehash、过期字典与惰性/主动删除，以及 listpack 为防级联更新替代旧 ziplist 的背景。底层机制最终服务于复杂度、内存和访问模式，面试回答不能只背编码名称。

27. 讲一下java的类加载机制

回答：

Java 类的生命周期通常描述为：加载（Loading）-> 链接（Linking：验证、准备、解析）-> 初始化（Initialization）-> 使用 -> 卸载。解析可以在规范允许范围内延迟，所以不要把所有 JVM 实现说成完全相同的同步顺序。

1. 加载： 类加载器根据二进制名寻找字节流，JVM 解析 class 文件，在方法区/元空间建立运行时表示，并创建对应的 java.lang.Class 对象。
2. 验证： 检查文件格式、元数据、字节码和符号引用，保证类型与控制流满足 JVM 约束。
3. 准备： 为类的静态字段分配存储并设置默认值；带 ConstantValue 属性的编译期常量可在该阶段赋值。普通静态赋值语句尚未执行。
4. 解析： 将运行时常量池中的类、字段、方法等符号引用转换为直接引用，可以惰性发生。
5. 初始化： 执行 <clinit>，即静态字段赋值与静态代码块合并后的类初始化方法。JVM 保证同一类只初始化一次并进行同步；初始化子类前通常先初始化父类。

主动使用通常包括 new、调用静态方法、访问非编译期常量静态字段、反射和初始化子类。仅引用编译期常量或创建该类型数组通常不会触发初始化。

类身份由“二进制类名 + 定义它的类加载器”共同决定。常见父级委派先向父加载器请求，避免核心类重复定义；插件、容器和模块系统可能使用子优先或隔离加载器。类卸载通常要求定义它的 ClassLoader 及其类对象均不可达，实际回收时机由 JVM 决定。

28. 场景题:  我们想要通过Agent实现对于广告投放的自我迭代，能够自我判别出哪种广告投放方式最优并执行，讲一下你的看法。

回答：

我不会让 Agent 根据自己的自然语言评价直接修改生产投放。广告优化涉及预算、归因、延迟转化、用户干扰和合规，正确架构应是“Agent 提候选，实验与因果评估判优，策略引擎决定能否执行”。

第一步先定义目标和硬约束。主目标可能是增量转化、利润或长期价值；CPA、ROAS 只能在统一归因窗口和成本口径下比较。护栏包括预算、频控、品牌安全、用户体验、公平性和素材合规。多目标可以采用约束优化，而不是把所有指标随意加权成一个 LLM 分数。

第二步建立可审计的数据与实验层。记录广告、受众、素材、出价、曝光、点击、转化、成本、时间和策略版本；候选策略先经过规则、离线回放和小流量随机对照。核心比较应看增量效果：

<div class="math math-display">

\Delta = \mathbb{E}[Y\mid T=1]-\mathbb{E}[Y\mid T=0]

</div>

而不是把历史高转化人群误认为策略带来的提升。延迟转化、样本比例失衡、跨广告干扰和归因污染都要进入实验设计。

第三步再做在线分配。稳定阶段可用 A/B；需要在探索和利用间动态分配时，可使用 UCB、Thompson Sampling 或受约束 Contextual Bandit，但必须有最小样本、置信/后验标准、最大预算步长和不可探索人群。离线 RL 只有在行为策略日志、覆盖度和反事实评估可信时才值得使用。

第四步设置执行控制面：Agent 只能输出结构化策略提案；Policy Engine 检查预算、频控、权限和实验状态；高风险变更人工审批；上线采用小流量 canary，实时监控 spend、CPA/ROAS、投诉和漂移，触发 kill switch 后回滚到已验证策略。Memory 只沉淀带实验 ID、样本量、置信度和适用范围的经验，不能把 Critic 的主观结论直接写成“最佳策略”。

Rocky认为，这个场景的本质不是让 Agent 自我进化，而是把候选生成、因果实验、约束决策和安全执行组成闭环。模型负责扩大策略搜索空间，统计实验负责判断增量价值，确定性系统负责控制真实资金和用户影响。

反问: 什么时候二面，有什么可以提高的地方。

回答：

可以问，但表达要更职业化，并把流程问题与能力反馈分开。

流程问题可以问：“想了解一下后续面试大致有几轮、预计推进节奏如何，我也方便安排时间。”不要把“什么时候二面”问成默认自己已经通过。

能力反馈可以问：“结合今天的交流，您认为我在 Agent 工程、后端基础或项目表达上，哪一部分最需要继续补强？”如果面试官给出具体建议，可以追问团队真实工作中这项能力如何使用，但不要当场争辩。

还可以补一个高价值业务问题：“这个岗位当前最核心的 Agent 场景和成功标准是什么？团队更关注任务成功率、广告/内容业务增量，还是研发效率？”这能帮助候选人判断岗位，而不只是获得面试技巧。

反问控制在 2～3 个，并根据对方回答继续追问。目标是确认岗位问题、团队评价标准和下一步流程，而不是把准备好的清单全部念完。

<a href="https://gw-c.nowcoder.com/api/sparta/jump/link?link=https%3A%2F%2Fwww.nowcoder.com%2Fusers%2F648015371" target="_blank"></a>

原帖广告策略解答配图文字

BUSINESS OBJECTIVE + HARD CONSTRAINTS：BUDGET、FREQUENCY CAP、BRAND SAFETY、FAIRNESS。
CANDIDATE STRATEGIES：Agent proposes strategies。
OFFLINE CHECKS。
CONTROLLED EXPERIMENT：CONTROL、TREATMENT。
CAUSAL ESTIMATOR：INCREMENTAL LIFT、CONFIDENCE、DELAYED CONVERSION。
POLICY DECISION：Deterministic policy decides what may run。
APPROVAL GATE：Deterministic gate approves or rejects execution。
BUDGET-LIMITED EXECUTION：Execute approved strategy within budget and constraints。
MONITORING + ROLLBACK：SPEND、CPA / ROAS、DRIFT、GUARDRAILS。
AUDITED EXPERIENCE STORE：Store results and context for learning and audit。
图中另标注 AGENT SELF-SCORE、PRODUCTION、NO DIRECT SELF-DEPLOYMENT。