OPPO IT 开发一面：ReAct、MCP 与智能问数
本场面试题
- Agent 具备哪些核心特征？
- 怎样理解 ReAct 模式？
- 实现 ReAct Loop 时要重点处理什么？
- MCP 的 stdio 与 Streamable HTTP 有什么区别？
- 如果设计地图 MCP，工具层应该怎样拆分？
- 怎样理解 Skill 的渐进式加载？
- 怎样让 Agent 基于 Word 文档返回图文混合答案？
- 智能问数除了 Text-to-SQL 还有哪些实现方式？
- 进入陌生代码仓库后，怎样完成从 0 到 1？
面经与参考答法
OPPO IT 开发一面：ReAct、MCP 与智能问数
作者记述这是一场约 40 分钟的 IT 开发一面，无手写代码题，几乎全程围绕 Agent 项目追问 ReAct、MCP、Skill、Text-to-SQL 与多模态链路。原文及冻结元数据没有明确面试日期，本文不依据届别推定年月。下列 14 组保留原文可见的技术问题，仅省略双方自我介绍、结果和感想；所有解答都是教学整理。
（1）Agent 具备哪些核心特征？
Agent 不只是“能调用工具的聊天模型”。一个可运行的 Agent 至少要能接收环境观察，围绕目标维护状态，根据当前信息规划或选择下一步动作，调用受约束的工具，再依据结果决定继续、改道还是停止。生产系统还需要记忆、权限、预算、可观测性和失败恢复。
固定步骤、没有动态决策的任务更适合普通工作流；只有当后续动作确实依赖中间结果时，才需要 Agent 式闭环。延伸阅读：Agent 系统架构。
（2）怎样理解 ReAct 模式？
ReAct 把推理与行动交替组织：模型基于目标和当前观察决定动作，运行时执行工具并返回新的观察，模型再继续判断，直到给出答案或命中停止条件。它的关键价值是让模型通过外部环境补充事实，而不是只依赖参数记忆一次性作答。
工程实现不必保存冗长的自由文本推理。更稳妥的方式是保留目标、动作、工具参数、观察、关键决策摘要和完成证据等结构化轨迹。延伸阅读：ReAct 范式。
（3）实现 ReAct Loop 时要重点处理什么？
运行时应把循环实现为显式状态机，定义每种状态允许的动作、工具 Schema、最大步数、超时、预算和终止条件。每次调用前校验权限和参数，调用后校验结果并分类处理可重试、需改参和不可恢复错误；有副作用的操作还要使用幂等键或人工确认。
同时记录 run、step、模型和工具版本、耗时与错误，长任务按检查点持久化。这样循环才可测试、回放和恢复，而不是一个无法定位问题的 while。延伸阅读：Agent Run Loop。
（4）除了 Loop 和 Function Calling，还有什么在驱动循环？
关联知识点待核实。
更一般地看，Agent 是一个受目标和约束控制的反馈系统：策略根据状态选择动作，环境返回观察，评估器判断进展，调度器依据预算和停止条件推进状态转移。Function Calling 只是动作的结构化表达，Loop 只是控制结构；真正决定系统行为的还有状态表示、策略、工具契约、评估信号和运行时治理。
（5）上一轮结果怎样传递，是否应把所有文本都塞入上下文？
关联知识点待核实。
工具结果应先规范化为结构化观察，只把下一步决策需要的字段放入模型上下文。大文件、日志和表格保存在外部存储，消息中保留摘要、引用和校验信息；较早轨迹可压缩为已确认事实、未完成事项和关键约束。
每轮无差别追加全部文本会迅速消耗窗口，也会让噪声掩盖目标。裁剪时必须优先保护系统规则、用户目标、待办、关键证据和尚未确认的副作用。
（6）MCP 的 stdio 与 Streamable HTTP 有什么区别？
stdio 通常由客户端拉起本地 MCP Server，通过标准输入输出交换协议消息。它部署简单、天然贴近本机进程边界，适合本地工具，但进程生命周期、日志隔离和单机资源由客户端负责。
Streamable HTTP 面向可独立部署的远程服务，通过 HTTP 请求响应，并可按协议需要承载流式消息。它更适合多客户端、认证、网关、水平扩展和集中运维，同时必须处理网络超时、断线、会话、限流与传输安全。两者改变的是传输和部署模型，不应改变工具的业务语义。延伸阅读：MCP 协议。
（7）如果设计地图 MCP，工具层应该怎样拆分？
先按稳定业务能力提供 geocode、地点搜索、路线规划、距离计算和实时路况等窄工具，而不是暴露一个可任意拼接请求的万能接口。每个工具使用明确 Schema，标注坐标系、单位、时间和数据新鲜度；对地址歧义返回候选并请求确认。
服务端保管密钥并执行权限、配额、超时、缓存和审计，统一映射上游错误。路线结果要附带约束与数据时间，位置等敏感输入遵守最小化原则。延伸阅读：Agent 工具契约与错误语义。
（8）怎样理解 Skill 的渐进式加载？
先只让模型看到 Skill 的名称、用途和触发边界；命中后再加载完整流程，并按当前步骤读取必要的模板、参考资料或脚本。这相当于用轻量索引完成路由，再延迟加载具体内容，可减少无关上下文和规则冲突。
实现时需要稳定的 Skill ID、版本、依赖与权限声明，记录每次命中及加载资源，并为误触发、漏触发和版本回归建立评测。延伸阅读：Agent Skill 的设计与版本治理。
（9）怎样让 Agent 基于 Word 文档返回图文混合答案？
摄取阶段解析 OOXML，保留标题、段落、表格、图片及其锚点关系；正文按语义切分，图片单独存储并生成说明、页码和权限元数据。查询阶段同时进行文本与图片检索，再把相关文本、缩略图或视觉输入交给多模态模型。
模型输出使用结构化内容块，例如文字块与受控的图片资源 ID。服务端只解析和渲染允许的资源，检查访问权限并生成短期地址，不能让模型直接拼接任意图片 URL。延伸阅读：RAG 文档解析、多模态 API。
（10）Text-to-SQL 怎样解决业务“黑话”和语义相近问题？
关联知识点待核实。
先建设业务术语表和语义层，把简称、别名、指标口径、维度、时间规则映射到经过治理的字段或指标。对查询做实体识别和改写，用关键词与向量召回候选表、字段和示例，再结合权限、Schema 关系及重排选择上下文；存在多个可能口径时必须澄清。
生成的 SQL 还要经过语法与 Schema 校验、只读权限、扫描量限制和执行计划检查，并在真实问法集上分别评估表字段选择、SQL 执行和最终答案。仅靠 Embedding 相似度无法解决口径冲突。
（11）智能问数除了 Text-to-SQL 还有哪些实现方式？
可以让模型调用经过治理的指标 API、OLAP 查询模板或 BI 语义层，也可以通过本体或知识图谱表达实体、关系与指标口径。对固定高频问题，参数化查询比自由生成 SQL 更稳定；对文档解释类问题则可路由到 RAG。
生产系统通常先识别意图，再在指标工具、模板查询、SQL、知识图谱和文档检索之间路由，而不是让所有问题都经过 Text-to-SQL。延伸阅读：表格与结构化数据检索。
（12）使用 AI 编程工具辅助编程时，怎样使用？
关联知识点待核实。
从真实任务说明完整闭环：先给出需求、仓库约束和验收标准，让工具用于代码检索、方案比较、窄范围实现和测试生成；随后人工审阅 diff，运行类型检查与测试，并核对安全和兼容性。若结果不佳，应判断是上下文、需求、API 还是架构问题，再缩小任务或人工接管。
（13）进入陌生代码仓库后，怎样完成从 0 到 1？
先读入口文档、构建脚本和仓库约定，成功运行基线测试；再沿一个真实请求追踪入口、核心模块、数据流和外部依赖，结合调用关系与测试定位最小改动面。实现前写清验收条件，完成后跑相关测试和全局检查，并请熟悉模块的人复核关键假设。
AI 可以辅助检索和解释，但结论必须由代码、运行结果和测试相互验证。延伸阅读：Coding Agent 的架构与执行循环。
（14）两个月后需求发生变化，应该怎样继续迭代？
关联知识点待核实。
先恢复原需求、架构决策、监控数据和测试基线，区分新增约束与原设计失效点；再做影响分析，确认接口、数据、权限和迁移范围。优先用兼容的小步改动扩展，必要时增加版本或迁移脚本，并通过回归测试、灰度和指标对比验证。
不要依赖个人记忆重新改一遍。让决策记录、测试、变更日志和可观测数据成为后续迭代的上下文，才能降低需求更迭造成的回归风险。