小鹏 AI Agent 开发 二面

1、自我介绍

2、项目深挖

3、如果让你设计一个 Agent 的评测体系，你会怎么做

Agent 的评测不能只看最终回答像不像，因为很多场景里最终答案看起来没问题，但中间过程其实已经错了。真正可用的评测体系应该至少覆盖三层。

第一层是结果评测，也就是任务有没有完成，最终输出是不是符合目标。第二层是过程评测，要看任务拆解是否合理、工具是否选对、参数是否正确、执行顺序是否稳定。第三层是系统评测，要看延迟、成功率、重试率、单次成本、异常恢复能力这些工程指标。

如果是线上系统，我会把评测拆成离线和在线两部分。离线阶段构造标准数据集，做固定样本回放，评估规划正确率、工具调用成功率、任务完成率和输出质量。在线阶段则重点监控真实请求中的失败样本、用户中断点、异常分布和效果漂移。因为 Agent 的问题很多不是一次性暴露出来的，而是会随着数据分布变化逐渐恶化，所以评测体系必须是持续运行的，而不是只在上线前做一次。

4、Function Calling 和 MCP 你怎么理解

Function Calling 的核心是让模型不只是输出自然语言，还能按照约定格式去调用外部工具。它本质上是一种“受约束的工具调用接口”，模型负责决定要不要调工具、调哪个工具、传什么参数，系统再根据这个结构化结果去执行。

MCP 更像是把模型和外部工具、资源之间的连接方式标准化。它不是只解决“调用一个函数”的问题，而是希望把模型如何访问工具、文件、服务、上下文这些能力抽象成统一协议。这样模型不需要对每个工具都写一套特殊适配逻辑，而是通过统一接口完成连接。

简单说，Function Calling 更偏具体调用机制，MCP 更偏通用连接协议。前者解决“怎么调”，后者解决“怎么统一接”。

5、如果模型工具调用经常出错，你怎么解决

工具调用出错，通常不是单点问题，而是整个链路都可能有风险。最常见的错误有三类：一类是工具选错了，模型理解任务时就偏了；一类是工具选对了，但参数抽取错了；还有一类是工具执行成功了，但模型对返回结果理解错了。

解决时我一般会先把调用链拆开看。首先要把工具定义写得足够清晰，尤其是工具描述、参数含义、必填项和边界条件，否则模型很容易误判。其次是参数层面要做 schema 校验，不能模型传什么就直接执行。再往下，工具返回结果最好结构化，不要返回太随意的自然语言，否则模型后处理时会继续放大歧义。对于高风险工具，还要做执行前确认、执行后校验和失败回退，不能把所有决策都交给模型自由发挥。

6、你怎么理解 Agent 的规划能力和工作流的区别

工作流的核心是提前把路径定义好，系统按既定步骤执行。它的优势是稳定、可控、好观测，适合流程比较固定、边界明确的业务。缺点是灵活性有限，一旦任务变化比较大，就需要频繁改规则。

Agent 的规划能力则更强调根据目标动态决定下一步做什么。它不一定提前知道完整路径，而是会在执行过程中根据环境反馈持续调整。这样灵活性更强，适合复杂任务和开放场景，但稳定性和可控性也更差。

所以两者不是完全对立的。真实业务里，很多时候不是纯工作流，也不是纯自由规划，而是把核心稳定链路做成工作流，把不确定性高的局部交给 Agent 去决策。这样既能保住系统稳定性，又能利用模型的泛化能力。

7、上下文窗口越来越长，为什么模型效果不一定更好

上下文窗口变长，不等于模型真的能有效利用这些信息。窗口只是“能装下”，不代表“能理解好”。如果上下文过长，模型在注意力分配上会更困难，尤其是中间位置的信息很容易被忽略，最后可能出现前面记得住、后面也记得住，但中间关键信息反而利用不好的情况。

另外，长上下文本身也会带来噪声问题。很多内容虽然被塞进去了，但和当前任务并不强相关，模型反而会被这些无关信息干扰。再加上推理时上下文一长，成本、延迟和缓存压力都会上来，所以实际系统里不能只追求窗口更大，而是要考虑怎么把真正有用的信息选出来、压缩好、组织好。

8、如果让你做一个长期记忆模块，你会怎么设计

长期记忆不能简单理解成把所有历史对话都存起来。真正可用的长期记忆应该只保留对未来决策真正有价值的信息，比如用户稳定偏好、常见任务模式、长期背景、关键历史结论，而不是把所有原始聊天记录原封不动堆进去。

设计上我会把长期记忆分成两部分。一部分是结构化记忆，用来保存明确字段，比如用户身份偏好、历史配置、固定业