百度智能体算法二面：工具调用语义校验与状态机

《面试题目》

1. 请先做一下自我介绍，聊聊你实习期承担过的工作。
2. 懂不懂 Go？如果让你转 Go 能接受吗？
3. 介绍下项目，如何设计从数据接入到结论生成的整体架构？
4. 如果 Agent 在调用工具时出现参数类型正确但业务含义错误，如何发现并阻止？
5. 如果工具调用一直没有达到成功条件，任务不断重试并最终卡死，你会如何处理？
6. CoT、ReAct、Plan-and-Execute 在工程实现上有什么区别？如何选择？
7. 在长上下文对话中，模型过早遗忘用户最初的硬性要求，你会怎样解决？
8. 如何设计一个能够避免循环调用的 Agent 状态机？
9. 如何判断一个图片理解 Agent 的评测指标是否足够完整？
10. 如果评测集上的准确率很高，但线上效果很差，你会怎样排查？
11. 如果用户说「只修改图片左上角的文字」，怎样避免模型改动其他区域？

《参考解析》

工具参数「类型对、语义错」怎么拦 JSON Schema 只能保证结构，业务语义要靠分层守卫。① 协议层：类型、枚举、必填、嵌套结构，由 Pydantic / JSON Schema 在服务端强制——模型输出永远当成不可信输入。② 语义层：把每条业务规则写成可执行断言，例如时间不能晚于当前时刻（注意时区）、资源必须属于当前租户（用 user_context.authorized_* 做集合判断）、金额不超过权限上限、破坏性操作必须带 approval_id。③ 影响层：执行前生成人类可读的操作摘要（把 update order 123 status=CANCELLED 渲染成一句话），高风险工具只返回摘要等审批，不直接落库。工程上把这三层收在同一个入口，返回结构化的 (ok, reason)，失败时把 reason 回填给规划模块重新生成参数，而不是抛异常。另外所有写操作都要带幂等键（request_id），这样模型重试也不会重复下单。

重试卡死与循环调用：用同一套状态机解决 先把「是否重试」从模型手里拿走，交给系统判定。每次工具调用记录一条结构化轨迹：工具名、参数指纹（工具名 + 规范化参数的哈希）、错误类型、调用次数、是否产生状态变化、距目标还差哪些条件、上次有效进展的时间。判定规则：可恢复错误（超时、限流、临时不可用）走指数退避 + 退避上限，最多 2~3 次；参数类错误回给规划模块重新生成参数（也要限次）；权限不足、资源不存在、业务状态不允许属于不可恢复错误，立即终止当前分支。最关键的是进展检测——相同参数指纹在没有新证据的情况下重复出现，或连续 N 次调用后状态没有变化，就判定为循环，提前终止并输出失败原因与人工处理建议，而不是等超时。外层再兜三个硬上限：总步数、总耗时、总 token 消耗。

状态机层面，关键是把「模型建议下一步」与「系统实际允许执行」分开：状态集定为 INIT → PLANNING → CALLING_TOOL → VALIDATING_RESULT → (NEED_REPLAN | WAITING_APPROVAL | FINISHED | FAILED)，状态迁移只由代码控制，模型只能返回候选动作，不能直接改状态。每次迁移都写日志（from、to、触发原因、当前步数）。重规划次数也要设上限，NEED_REPLAN 连续超过 K 次就转人工。所有失败出口都必须可解释：告诉调用方走到了哪一步、缺什么信息、建议人工做什么。

CoT、ReAct、Plan-and-Execute 怎么选 三者的差别是「推理与行动的耦合程度」。CoT 只产出推理文本、没有工具交互，适合一次性分析、分类、生成，不适合当执行协议——自然语言推理不稳定、不可审计，还容易把内部信息带进输出。ReAct 是「想一步 → 调一次工具 → 看结果 → 再想」的循环，适合需要多源查询、路径不确定的任务（排障、检索问答、数据探查），代价是调用轮次多、延迟和成本高，必须配步数上限与循环检测。Plan-and-Execute 先产出结构化计划（步骤列表、依赖关系、每步预期产物），再由执行器逐步或并行执行，适合流程稳定、步骤多、需要并行或审计的任务（批量数据处理、报告生成），风险是前置计划一错后面全偏，所以要留「执行中重新规划」的出口。

实践中是组合使用：意图分类做路由，简单问答直连；多数据源查询用 ReAct；长流程先规划再执行，失败时触发 replan；高风险写操作在计划里插审批节点。系统只依赖结构化的计划与工具返回值，不依赖模型的自然语言「思考」。

长上下文里硬约束被遗忘 根因是注意力被无关内容稀释，而不是窗口不够大。解法是按「约束强度」给上下文分层：① 硬性约束（不能修改库存、所有结论必须引用来源、输出格式、权限范围）单独存成结构化字段，每次推理前重新注入到 system prompt 的固定位置，不参与摘要；② 任务目标与关键实体（单号、时间范围、仓库 id）同样结构化保存，摘要只压缩闲聊和已完成的中间过程；③ 工具返回按相关性与时间窗保留，旧的、与当前子目标无关的清掉；④ 金额、时间、编号这类关键字段永远保留原文，因为自然语言摘要一定会丢精度。工程上再加一道「约束检查器」在输出前做断言（例如输出里出现库存修改就拦下来），把软约束变成硬校验。

图片理解 Agent 的评测指标 只算分类准确率一定会漏。分层设计：任务正确性（最终答案或产物是否满足指令）、定位能力（编辑类任务看 mask/框与真值的 IoU 或点命中率）、非目标区域保持度（对未编辑区域算像素级差异或 SSIM，超过阈值即算误改）、内容一致性（OCR 文字、商标、人脸等关键对象有没有被改动）、安全性（违规内容召回率、误报率、类别间偏差，以及对抗样本和边界样本上的稳定性）。图片编辑类还要测多轮累计误差——连续编辑 5 轮后画质与结构是否崩坏；以及指令遵循度，用户说「只改左上角文字」，其他区域差异必须为 0。线上再补业务指标：人工复核率、用户投诉率、平均处理时延、单次任务成本。评测集本身也要有代表性：按分辨率、压缩质量、场景类别分层采样，并固定保留一个困难集做回归。

离线准、线上差怎么排查 先验证「评测集和线上是不是同一个分布」：分辨率与压缩质量、用户指令的口语化与歧义程度、类别分布漂移、是否把失败样本和边界样本排除在评测集之外、线上检索或工具是否有延迟与空返回、评测时是否不小心用了真值或隐藏信息，以及最容易被忽略的——线上模型版本、prompt 模板、后处理逻辑与评测时不一致。做法上：① 建线上失败样本池并人工归因，把问题拆成数据问题、模型问题、工具问题、评测问题四类分别处理；② 每次优化都在「固定回归集 + 困难集 + 线上采样集」三个集合上同时评测，只涨一个集合往往意味着过拟合评测集；③ 把线上人工修正的结果回流成新样本，但要打版本号并保留旧版评测集，避免评测集被逐步污染导致指标虚高。

「只改左上角文字」怎么约束住 把自然语言约束翻译成可执行的空间约束，不要指望提示词里的「不要改其他地方」——那是软约束。流程：① 用 OCR 或检测模型定位左上角文字区域并生成 mask（适当膨胀几个像素避免边缘残留）；② 用支持局部重绘的 inpainting 模型只在 mask 内生成，或把 mask 作为额外通道输入；③ 生成后做差异检测：mask 外区域像素差异超过阈值就判违规，回退原图或重试；④ 对改动区域再做一致性校验（文字是否清晰、是否仍是同一语言、字号是否与周围协调）。接口层也要把「保留非目标区域」写成结构化字段传给执行器，而不是混在一句话里让模型自己理解。