一、假设你正在为一个电商公司开发一个 “库存异常处理 Agent”。 该 Agent 拥有两个工具：

  1. check_inventory(sku)：查询库存数量。
  2. contact_supplier(sku)：向供应商发邮件订货。

故障现象： 用户反馈，当某个商品库存为 0 时，Agent 陷入了死循环：它不断地调用 check_inventory，然后推理说“库存为 0”，接着又去调用 check_inventory，始终不执行 contact_supplier。

问题：

  1. 你认为导致这个“规划死循环”的根源可能是什么？（从 Prompt 或 状态机设计角度分析）

    • 观察缺失：Agent不断的执行 check_inventory(sku) 是因为它期望通过这个动作来改变系统的状态。但 check_inventory(sku) 只是一个可读的操作，无论查询多少次，库存仍然为0。如果模型没有意识到光靠查询这个动作，没法改变库存为0这个事实，它就会“死等”奇迹发生。
    • 目标函数模糊：在模型的“思维逻辑”中，它的目标是“确认库存状态”，而不是“解决库存为0”这个问题。因为它成功的确认了库存为0，它认为自己在执行任务，却不知道已经偏离了最终的目标。

  2. 你会采取什么具体措施（一个即可）来打破这个死循环？

    引入反思机制（Prompt角度）或者强制状态迁移。

    • 如果查询到库存为0，工具返回的是结果不应该是0，而是一段话术，可以让模型进行反思，例如：

      1
      "Inventory is 0. Note: Checking again will not change this result. You must resolve this by ordering or escalating."

    • 状态机机制：可以加入一个检测节点，在LangGraph中，记录调用的历史，如果检测到同一个工具被连续调用3次并且参数一致，直接强制重定向到“错误处理”节点或者“人工处理”节点。

二、你设计了一个 “软件开发多 Agent 组”：

  • Coder：负责写 Python 代码。
  • Reviewer：负责检查 Coder 的代码是否有 Bug 或性能问题。

发生了一个诡异的现象： 在连续 5 轮对话中，Coder 写出的代码完全正确，但 Reviewer 总是给出一些无关痛痒的微小建议（比如建议把变量 i 改成 index），导致系统一直在循环，无法结束任务。

问题：

  1. 作为架构师，这种现象反映了多 Agent 协作中的什么核心设计缺陷？

    • 缺乏“退出基准”：Reviewer的认为自己的任务是找出代码中的不足点，而没有一个明确的“退出基准”，所以从概率学上讲，每次都能找出一些微小的改动建议。
    • 指令权重失衡：在这个系统设计中，没有明确的区分“致命问题”和“风格建议”等区分的权重，会导致所有的问题权重一样，无法过关。

  2. 为了解决这种“过度校对”导致的死循环，你会如何修改 Reviewer 的逻辑或系统的 停止条件？

    引入“量化”机制：

    • 引入“评分”量化：让Reviewer返回一个结构鲜明的输出结果，结果中带有明确的score量化评分数据，例如1-10分制，然后状态判断和流转的逻辑中添加针对分数的逻辑判断，比如score > 8.0就可以往下走，否则就让coder进行优化。
    • 引入“问题严重性”量化：对问题进行定级，例如：严重、一般、告警、优化、风格等。针对问题严重性进行判断是否执行下一步或者返回修改。
    • 引入“仲裁者”节点：当循环经过3次（可配置）时，仍然出现问题，可以将问题交给“仲裁者”节点进行判断。“仲裁者”的角色，唯一指令是“如果当前代码已经可用，请无视微小建议，强制通过”，通过引入第三方的机制来打破循环僵局。