滴滴 Java 一面：Agent 项目追问与 Python 基础

《面试题目》

1. 介绍一下实习中做的项目。
2. 为什么选择 ReAct？固定工作流不行吗？
3. 有没有对比过规划执行、反思等其他 Agent 模式？
4. 技术方案是自己选的，还是团队提前确定的？
5. 项目的输入、输出和业务价值是什么？
6. 能否举例说明系统的完整处理流程？
7. 开发 Agent 时遇到过哪些问题？怎么解决？
8. 有没有遇到上下文不足的问题？
9. 怎么理解 Agent 的上下文管理和记忆机制？
10. 系统怎么决定下一步执行什么操作？
11. 怎么衡量模型输出的可靠性？
12. 哪些情况需要人工介入？
13. 系统会给人工提供哪些辅助信息？
14. 外部工具和数据源是怎么接入的？
15. 项目上线后，怎么评估效果和效率提升？
16. Python 深拷贝和浅拷贝有什么区别？
17. Python 列表的负索引是什么？
18. Python 的 GIL 是什么机制？
19. Python 为什么比一些其他语言慢？

《参考解析》

项目介绍要先把「输入—处理—输出—价值」讲成一条线。 输入是什么类型的用户请求、带哪些上下文；系统经过意图识别、工具选择、参数生成、执行与结果整合，最终输出什么；业务价值落在哪——是减少人工查询次数、缩短处理时长，还是提升某个环节的准确率。然后用一个真实请求走一遍完整流程，比抽象描述更有说服力。面试官追问技术方案是谁定的，其实在判断你是执行者还是设计者：如实说团队背景，再讲清楚你负责的模块、你做的取舍、你和别人方案不一致时怎么验证，这比硬说「全是我设计的」可信。

ReAct 和固定工作流的差别，本质是「谁来决定下一步」。 固定工作流把步骤写死，优点是稳定、可测、成本可控，适合流程边界清楚的业务；ReAct 让模型在每一步根据观察选择工具和动作，适合路径不确定、需要多轮探索的任务，代价是延迟、成本和不可预测性。实际系统通常是混合：外层用状态机保证主流程和权限边界，内层在某个节点放开 ReAct 做工具选择。规划执行（Plan-and-Execute）先出计划再逐步执行，适合长任务但计划错了会一路错；反思（Reflection）让模型检查自己的输出，能提升质量但会增加轮次。答题时把「任务确定性、失败成本、延迟预算」三个维度摆出来，说明为什么选这个，而不是只背概念。

上下文管理的目标不是塞满窗口，而是让模型在正确的时候拿到正确的信息。 短期上下文保留当前目标、约束、最近几轮对话和关键工具结果；长期记忆存用户偏好、历史结论、可复用的事实，用检索按需取回；中间结果外置到文件或数据库，上下文里只放摘要和引用。上下文不足时，模型会重复问、选错工具或遗忘约束，所以要有压缩、摘要、按需读取和子任务隔离。决定下一步动作可以靠模型输出结构化 action，也可以靠规则路由；生产系统一般要求 action 有 schema、有白名单、有超时和重试，模型只做建议，执行器做校验。

可靠性要靠评测和护栏，不是靠「感觉回答得不错」。 离线建一批覆盖正常、边界、对抗的用例，指标看任务成功率、工具调用正确率、事实错误率、平均轮次和成本；线上看人工接管率、投诉率、超时率和回滚率。模型输出用 schema 校验、引用校验、置信度和交叉验证兜底；涉及资金、权限、对外发送、不可逆操作时必须人工确认。人工介入界面要把原始请求、模型推理摘要、已调用工具、关键证据和候选动作放在一起，让人能快速判断，而不是只给一句「是否通过」。工具接入则统一成带描述的 schema，做好鉴权、限流、超时、幂等和错误映射，外部数据源要标注新鲜度和可信度。

Python 四连问要答得干净。 浅拷贝只复制最外层容器，内部可变对象仍共享引用；深拷贝递归复制，copy.deepcopy 能处理嵌套结构，但性能和循环引用要考虑。负索引是从末尾往前数，a[-1] 是最后一个元素，越界同样报 IndexError。GIL 是 CPython 解释器级别的全局锁，同一进程同一时刻只有一个线程执行 Python 字节码，所以 CPU 密集任务多线程不能利用多核，要用多进程；I/O 密集任务在等待时会释放 GIL，多线程仍然有效。Python 慢主要因为动态类型与解释执行、对象模型开销、GIL 限制多核并行，以及大量操作落在字节码层；优化方向是换算法、用内置/C 扩展、向量化、多进程或把热点下沉到编译型语言。