美团 Agent 开发一面凉经：26 问深挖 Agent 工程与 skill 设计

《面试题目》

1. 可以详细介绍一下项目：项目场景、设计方案、开发内容？
2. 选取一个真实问题单，完整描述从 Agent 接收输入、走完全流程到产出最终结果的整条链路？
3. 测试报告 / 测试用例设计，如何判断符合本次新需求改动？新功能无历史问题单，怎么设计测试用例？
4. 需求文档、技术方案为什么没有作为输入信息纳入系统？
5. 最终产出的结果只是文本，是否会执行真实任务？哪些环节需要人工确认？
6. 信息如何持续积累、迭代更新？执行失败后的结果如何回流？
7. 提到将 xx 耗时从 1 小时压缩到 3 分钟，耗时瓶颈在哪，哪些环节快、哪些慢？
8. 项目使用 Python + FastAPI，数据库层如何接入？数据库表是否由你设计？
9. 两个 QA 同时输入相同查询，Agent 给出的报告是否一致？
10. 整体 Agent 流程使用 workflow，为什么该场景适合 workflow？Agent 执行流程有哪些形式，相互差异是什么？
11. 外部环境、参数变化，会不会导致相同测试任务执行结果不一样？如何处理？
12. Agent 项目 2 对比项目 1，在 Agent 设计层面有什么差异？
13. 你主要负责哪些模块、哪些具体开发工作？
14. 项目里封装了 CLI 工具，介绍下 CLI 的实际开发内容？
15. 为什么要把 skill / 工具执行流程封装成 CLI，这种方案有什么好处？
16. 用户输入不完整的信息，系统如何校验、补全参数并继续执行？哪些参数必须用户确认？
17. 残缺信息无法唯一确定资源，系统如何选择？
18. 讲讲你对 skill 的理解，skill 只包含流程说明，还是包含完整设计？
19. 项目 3 整体架构、模块分层？
20. 该项目存储层如何设计？
21. Skill、MCP、Function Calling、Workflow、SubAgent，分别解决什么问题，你在项目中如何组合使用？
22. 介绍下 AICoding 笔试题，拿到题目后如何解读、实现？
23. Agent 开发中，知识维护、记忆模块（短期/长期记忆）你是怎么考虑设计的？
24. Redis 在 Java 开发中的作用、适用场景，底层原理考量？
25. 你通过哪些渠道学习 AI、Java 相关知识，如何跟进技术发展？
26. 岗位 base，城市方面有没有特殊需求？

《参考解析》

「完整描述整条链路」是 Agent 面试的核心题，答法要有固定骨架。 推荐按「输入 → 理解 → 检索 → 规划 → 执行 → 校验 → 输出 → 回流」讲：接收自然语言输入后先做意图识别与参数抽取，缺参数走澄清；然后按需检索知识（RAG）或拉取结构化数据（DB/接口）；接着生成计划（对 workflow 场景是匹配预定义模板，对 ReAct 场景是逐步推理）；每个工具调用都要有参数校验、权限判断和失败处理；产出前做自校验（格式、引用、约束是否满足）；高风险动作进入人工确认；最后把轨迹、结果、人工反馈落库，供后续挖掘。面试官追问的通常是「失败怎么办」和「怎么证明它好了」，所以链路里必须显式带上重试/降级/回滚与可观测性。

「为什么这个场景适合 workflow 而不是自主 Agent」，答案要落在确定性与可验证性上。 测试报告生成这类任务的步骤是可枚举的、每一步的输入输出可以定义清楚、失败可以定位到具体环节、而且需要可复现（同一个问题单应该产出同一份报告）。workflow 的优势是可控、可测、可审计、便宜；自主 Agent 的优势是能应对没预设过的路径。常见误区是「Agent 越自主越先进」——实际上能穷举的流程就该用 workflow，只在分支不可预知、需要动态选工具时才交给模型决定下一步。Agent 执行流程的几种形式可以按自主度排序：单次 LLM 调用 → 固定 workflow → Router/分发 → ReAct 循环 → Plan-and-Execute → 多 Agent 协作，各自的取舍是可控性与泛化能力的交换。

「两个 QA 同时输入相同查询，结果是否一致」是个很好的工程题。 大概率不一致，来源有三类：模型侧（温度采样、模型版本、上下文长度截断）、检索侧（向量检索的近似算法、时间相关的数据快照）、执行侧（外部接口返回时机、并发写同一资源、缓存命中差异）。处理方式是把不确定性显式化：对需要稳定输出的环节把温度设成 0 或低值并固定模型版本；把检索结果快照进报告便于追溯；对结果做规范化与校验；对同一查询引入缓存或幂等键。要主动承认：LLM 系统做「完全可复现」比传统系统难得多，能做的是缩小方差并把差异暴露出来，而不是声称一定一致。

CLI 封装的价值在于「把流程变成确定性接口」。 把 skill / 工具的执行过程封装成 CLI，好处有四条：一是边界清晰——模型只需要拼命令行参数，不用自己组织多步 HTTP 调用；二是可测试——CLI 可以脱离模型单独跑、单独写回归；三是可复用——同一套能力被 Agent、人、CI 共用；四是安全可控——参数校验、权限检查、审计日志都收在 CLI 内部，而不是散落在提示词里。代价是灵活度下降（CLI 覆盖不到的场景还是要回退到裸接口），所以设计上要保证 CLI 的返回值结构化、错误信息可读，便于模型做下一步决策。

参数补全与确认机制，是「别让模型编」的落点。 用户输入不全时有三条路：能从上下文或历史记录推断的自动补全（并明确告知补了什么）；能通过枚举/检索确定的消歧（查询出候选让用户选，而不是自己挑一个）；无法确定的必须澄清。哪些参数必须人工确认，判据是后果不可逆或影响外部——写操作、发消息、扣款、删除、影响他人的配置，都要确认；只读查询可以自动执行。这里有个反直觉的点：「残缺信息无法唯一确定资源时系统如何选择」——正确答案通常是不选择，列出候选让用户决定，因为模型猜错一次的代价往往比多问一句高得多。

Skill 是流程知识，不是代码。 一个 skill 通常包含「什么场景触发、按什么步骤做、每步的判断标准、常见坑、失败怎么处理」，它给模型的是决策依据；而 MCP/Function Calling 提供的是执行能力。两者关系是：skill 说「该怎么做」，工具说「能做什么」。所以「skill 只包含流程说明还是包含完整设计」这个问题，答案是按需分层——流程说明必须有，涉及具体工具时给出参数约定和调用顺序，但不要把工具实现塞进去，否则维护成本和触发准确率都会变差。

记忆模块与知识维护，要区分「存什么」和「怎么取」。 短期记忆是当前会话的上下文（受窗口限制，靠滑动窗口或摘要控制）；长期记忆是跨会话的事实、偏好、历史结论，落到库里。设计要点三个：写入策略（什么值得记，粒度和时机）、检索策略（按需召回而不是全量塞进 prompt，通常混合向量与结构化过滤）、冲突与过期（新信息覆盖旧信息要有规则，事实性内容要有时间戳和来源）。最容易被忽略的是噪音治理——记忆库一旦无节制写入，召回质量会迅速下降，所以要定期清理、去重、并让记忆的写入经过一层判断。

Redis 与学习渠道这两问，属于送分但别答空。 Redis 在 Java 后端的典型角色是缓存（旁路缓存、热点数据、会话）、分布式锁、限流计数、排行榜（ZSet）、消息队列（Stream/List）和去重（SET/布隆过滤器）；原理层面能讲到单线程与 I/O 多路复用、内存淘汰策略、持久化（RDB/AOF）、以及「缓存穿透/击穿/雪崩」三类问题的对策就足够。学习渠道这类问题面试官想看的是你有没有持续输入的稳定来源——官方文档与源码、论文与开源项目的 issue/PR、技术社区的实战复盘、以及自己动手复现，比罗列若干公众号更有说服力。