百度后端一面：ReAct、规划与流式工具参数
本场面试题
- ReAct 怎样形成循环，又怎样限制无效循环？
- ReAct 和先规划再执行、必要时重规划怎样比较？
- 流式工具参数只有半段 JSON 时应该执行吗？
- 单 Agent 加多个工具是否足够，怎样证明需要多 Agent？
- RAG 一定需要独立向量数据库吗？
面经与参考答法
问题选自作者自述的百度 后端开发一面记录。以下短答为备面讲解，不代表作者当场作答。页面发表于北京时间2026-09-23；面试绝对日期未确认。
（1）ReAct 怎样形成循环，又怎样限制无效循环？
Agent根据当前目标与观察选择行动，执行工具后把结果作为下一步输入，直到满足结束条件。工程上应有明确终止判定、步数和预算上限，并检测重复行动与重复失败；退出时保留当前状态和失败原因。ReAct范式本身不保证一定收敛。
（2）ReAct 和先规划再执行、必要时重规划怎样比较？
ReAct更强调根据每次观察即时决定下一行动；先规划再执行会显式保存阶段目标和依赖，执行遇到新信息后再调整计划。短且探索性强的任务常适合较紧凑的行动循环，依赖清晰的长任务可能需要显式计划；实际选择要以任务评测为准，二者也可组合。
（3）流式工具参数只有半段 JSON 时应该执行吗？
不执行。按运行及工具调用标识分别缓存增量，等对应参数流明确完成，再解析完整 JSON、校验 Schema、业务语义和权限后交执行器。如果本执行器尚未发起工具，断流时应记录参数未完成、未执行，不能猜补参数。只有执行请求已经发出却失去回执时，才把执行结果记为未知，并通过结果查询及幂等协调判断能否重试。网络 chunk、完整 SSE 事件和参数完成是不同边界，恢复与完成信号都要按实际提供方协议处理。
（4）单 Agent 加多个工具是否足够，怎样证明需要多 Agent？
先用单Agent实现基线，再看是否需要隔离职责、权限和上下文，或能并行处理相互独立的子任务。引入多Agent会增加路由、通信和合并失败的机会，只有在同条件任务集上取得可解释收益才值得使用；不能把“更智能”当作架构理由。
（5）RAG 一定需要独立向量数据库吗？
不一定。应按相似度检索能力、数据规模、过滤与权限、更新频率、延迟和运维成本选存储。普通关系数据库可承担文档元数据、权限和词法查询，也可能通过相应产品能力提供向量检索；不能把某个MySQL版本默认没有的能力泛化成所有关系数据库都不支持。