ReAct Agent 与 Plan-and-Execute

面试回答

ReAct 是让模型判断和工具调用交替进行的一种 Agent 执行方式。在我们的养老知识问答里，模型会根据当前问题和已经拿到的证据，决定下一步调用哪个工具；工具返回结果后，再判断是否需要继续检索，还是已经可以回答。

比如用户询问能否申请护理补贴，Agent 会先检查地区、照护等级这些必要条件是否齐全，缺少时向用户澄清。查到政策后，如果申请条件还引用了另一份认定办法，就继续检索对应资料，补齐回答依据。

模型负责提出工具调用和参数，后端负责参数、权限及时间范围校验。同时设置调用次数和超时上限，结束前检查证据与引用是否齐全，避免反复检索或依据不足就给出结论。

面试回答

ReAct 适合根据当前结果决定下一步，但政策变化分析通常包含多个版本和比较维度，如果一直局部补查，容易漏掉子问题，或者反复搜索同一部分。所以我们在复杂任务中引入 Plan-and-Execute，先拆解目标，再按步骤执行和检查完成情况。

比如比较政策调整前后的申请条件、补贴标准和材料要求，要先确认地区和时间，找到两个适用版本，再分别提取这些维度，最后核对差异和引用。计划会记录哪些步骤已完成、缺什么证据。如果执行中发现文件被替代或附件缺失，可以调整计划；某一步需要动态补查时，内部仍然使用 ReAct。

面试回答

我主要根据对象数量、时间版本、输出维度和步骤依赖判断。查询一个明确条款时，直接检索就可以；需要根据工具结果继续查附件或补条件时，使用有执行上限的 ReAct 循环。

如果任务同时比较多个版本或机构制度，还要求从多个维度给出结论，就先用 Plan-and-Execute 管理整个任务，避免漏项。计划中的某一步仍然可以用 ReAct，比如查旧版申请条件时，先查正文，再根据引用补查认定办法。简单任务不额外生成计划，减少不必要的耗时和模型调用，判断依据也不能只是问题字数。

面试回答

我按明确的业务能力定义工具，比如知识检索、读取证据原文和查询文档版本。每个工具都提供名称、适用场景、输入 Schema 和结构化返回值，让模型知道什么时候调用、参数怎么填、结果代表什么。

以知识检索为例，输入包含查询文本、文档类型、时间条件和返回数量，成功时返回片段、Evidence ID、文档版本和页码；失败时返回错误类型和是否可重试。用户身份和可访问范围由后端认证上下文确定，模型填写参数不能扩大权限。结果正文也控制长度，先返回必要片段，需要完整条款时再调用原文读取工具。

面试回答

后端会把当前任务允许使用的工具说明和参数 Schema 提供给模型。模型结合用户目标、当前步骤和已有结果，生成结构化的工具名和参数；后端根据工具名找到处理器，完成类型、范围与权限校验后执行，再把结果交回模型。

工具说明要写清能力边界，比如找资料用检索工具，已经拿到 Evidence ID 但需要完整条款时用原文读取工具，确认某个时间点适用哪个文件时用版本查询工具。模型提出的调用不会直接执行，未知工具、错误参数或越界数量会被拒绝并返回具体错误，允许模型在合法范围内修正。

面试回答

我们把计划作为结构化任务保存在 MySQL，包含目标、地区和时间等约束、计划版本、步骤列表及依赖。每个步骤记录自己的状态、完成条件、工具执行记录和 Evidence ID，根任务还保存已用步数、调用次数和截止时间。

这样恢复时能够明确知道哪些已经完成、下一步的依赖是否满足，而不必让模型重新解释一段自然语言计划。比较长的工具结果单独存，计划通过记录 ID 关联。需要重规划时保留旧计划和执行记录，生成新版本，已经拿到的证据经适用性检查后继续复用，避免整个任务从头再来。

面试回答

我把完成判断和用户要求关联起来，检查输出维度是否覆盖、证据是否适用、引用是否齐全，以及还有没有未解决项。比如政策对比要找到两个正确版本，申请条件、标准和材料都完成比较，每个差异都有对应原文，才能认为主要目标完成。

工具返回成功只说明这一次调用正常，不能直接当成任务完成。我们同时设置步数、调用次数和总超时上限。如果到上限仍缺资料，就保留已经确认的部分，明确说明缺哪项证据或条件。这样既有内容上的完成条件，也有执行预算，避免无限检索。

面试回答

暂停时保存任务、步骤状态、checkpoint、已有证据和累计预算，并停止发起新调用。恢复时先加载这些记录，重新检查当前权限、文档版本和证据适用性，再从未完成的位置继续，不重复执行已确认完成的部分。

正在进行的外部调用是否能取消，要看工具支持情况，不能认为点击暂停就已经停止。对于已发出但结果不确定的调用，恢复时先核对调用记录或查询结果。步数、重规划次数、模型和工具调用次数以及总时间都按同一个任务累计，重试和恢复也计入，避免每次恢复重新获得完整额度。

面试回答

我根据错误类型决定后续动作。参数错误就返回具体字段问题，让模型修正；超时和连接异常在剩余预算内有限重试；单路检索不可用时，使用其他可用通道。权限不足则停止这次访问，不能靠修改参数绕过。

工具正常执行但没有结果，要考虑改写查询、补条件或说明未找到，不能当作服务故障盲目重试。一次失败也不一定让整个任务重来，比如正文已经取得但附件获取失败，会保留正文证据，只继续处理附件缺口。必要依据始终拿不到时，返回已确认部分，并说明哪些结论暂时无法给出。

面试回答

我会记录每次查询的文本、时间与知识库等过滤范围，以及返回的 Evidence ID。再次调用前，先检查相同请求是否已有可复用结果，权限和版本仍适用时直接复用。

另外还要看检索有没有推进任务。模型即使换了措辞，如果一直返回同一批证据，也没有覆盖新的问题维度，就需要调整检索方向。比如补贴标准已经查到，缺少申请材料，下一次就查材料或附件，不再宽泛地搜索补贴政策。判断重复也不能只看文本，同一句问题查询不同地区、时间或版本，范围不同，仍然属于不同请求。

面试回答

我把当前问题、用户刚补充的条件、任务约束和当前步骤放在优先位置，再装配相关证据、近期消息和历史摘要。近期对话用滑动窗口保留，较早内容压缩为摘要；计划、步骤状态和证据记录单独跟踪，不完全依赖聊天历史。

检索结果先去重并提取相关片段，长工具结果移出上下文后保留记录 ID，需要时再读。计算预算时把工具 Schema、消息结构和引用信息也算进去，并给模型输出预留空间。裁剪不能丢掉条款的必要条件或工具调用与返回的对应关系，摘要里的政策描述也不能直接代替当前适用的原文证据。

面试回答

我们把地区、时间、对象和输出要求单独保存成结构化任务约束，每次装配上下文都明确提供给模型。摘要主要压缩对话背景，关键条件不依赖摘要模型自行记住，所以长对话压缩后仍能按同样范围检索和回答。

用户修改条件时，更新对应字段，后续查询使用新值；没有提供的信息继续保持缺失，不能让摘要自动补齐。摘要里还区分用户明确提供、工具已确认和尚未确认的内容，对重要事实保留来源消息或证据记录。发生不一致时，回到明确的用户要求和原始记录核对，避免错误摘要被不断沿用。