来源：抖音 @小北爱编程
Agent作为一种自主决策和执行任务的智能系统，在实际应用中需要高度关注其可靠性和安全性。本文将基于常见的Agent面试问题，系统性地探讨这些关键议题及其解决方案。
一、Agent死循环处理
Agent死循环通常发生在模型需要反复执行某个动作或决策时。理解其发生情境是解决问题的第一步，主要有以下几种情况：
- 模型自主判断-死循环： 当模型在查看结果后，自主决定是否继续执行时，可能会陷入某个判断闭环。
- ReAct框架中的问题： 在基于ReAct（Reasoning and Acting）框架的Agent中，规划（Plan）和执行（Execute）阶段可能会不断产生新的任务，导致无休止的循环。
- 多Agent协同中的死锁： 当多个Agent相互依赖，例如Agent A需要Agent B的数据，而Agent B又需要Agent A确认需求时，可能形成相互等待的死锁状态。
- 模型自我反思死循环： 当模型对自己的批评标准过于严格时，可能会不断进行自我反思和改进，陷入无尽的循环迭代。
处理死循环的策略：
- 设置循环次数限制： 为Agent的执行循环设定最大次数，超过该次数后自动退出。
- 设置任务超时时间： 对任务设置总的执行时间限制，超出时间后强制终止。
- 模型自我判断是否停止： 在Prompt中加入明确的提示词，引导模型在特定条件下（例如达到目标，或者发现无进展）自主判断是否应该停止。例如，可以提示模型“请判断当前任务是否已完成，如果完成请输出’STOP’并总结结果”。
二、保证Agent输出的稳定性
Agent的输出稳定性对于其可靠性至关重要，特别是需要结构化输出或在敏感场景下。
保证输出稳定性的措施：
- 结构化输出与强制JSON Schema： 强制Agent输出遵循特定的JSON Schema，而不是自由文本。这保证了输出格式的一致性和可解析性。
- 输出校验与重试机制： 对Agent的输出进行校验。如果解析失败，允许最多重试N次（例如3次），若屡次失败则给出提示，以便人工介入检查。
- 降级方案：LLM引擎失效时： 当主LLM引擎出现故障时，自动切换至备用降级引擎，或提供兜底服务（如人工编写的回答或预设逻辑），确保系统不完全瘫痪。
- 温度调低以减少随机性： 在Time-Sensitive场景中，将模型的
temperature参数设置为0。temperature代表随机性，值越低输出越稳定，反之则越随机。在需要确定性回答的场景下，低temperature能有效提高稳定性。
三、LLM服务挂了怎么办
LLM服务因各种原因宕机是生产环境中的常见问题。需要有完善的应对方案来保证业务连续性。
LLM服务挂掉的应对方案：
- 完备的兜底方案： 当LLM挂掉时，系统能自动走兜底服务。这可以是预先编写好的文案、基于
if/else逻辑的代码判断，或者其他非LLM的自动化服务。 - 多LLM供应商+熔断机制： 同时接入多个LLM供应商（如主用Claude，备用GPT-4）。通过实现熔断机制，当某个LLM连续失败N次后，自动切换到备用服务，避免单点故障。
四、Prompt注入攻击及防御
Prompt注入攻击是指通过在用户输入中插入恶意指令，诱导Agent执行非预期行为。这与SQL注入攻击类似。
Prompt注入攻击的防御策略：
- 输入过滤和转义： 对用户输入内容进行严格过滤和转义，识别并移除或处理可能导致危险操作的特殊字符或指令。
- 权限最小原则： 严格控制Agent的操作权限，不允许它拥有执行危险操作的权限，例如删除文件或修改关键配置。
- 危险操作前的二次确认： 对于可能带来风险的操作（如删除某个目录），必须先经过人工确认后才能执行。
- 用户输入与系统指令明确分离： 将用户的输入内容和Agent的系统指令在内部进行严格区分和隔离，防止用户输入直接影响到系统底层指令的执行。
五、如何防止Agent做危险操作
Agent进行危险操作可能会导致数据丢失或系统损坏，预防是关键。
防止Agent做危险操作的措施：
- 只开放必要的工具： 仅为Agent提供执行特定任务所需的最小化工具集。例如，在查询订单状态时，只赋予查询权限，不提供修改或删除权限。
- 数据范围限制： 严格限制Agent可访问和操作的数据范围。例如，一个Agent只能查询当前用户的订单，不能访问其他用户的订单信息。
- 操作权限限制： 除了工具层面的限制，还需细化到具体操作权限，如只允许读文件，不能修改或删除文件。
- 危险操作前要求人工确认： 对于任何潜在的危险操作，必须强制要求人工审查和确认。同时，将代码执行放在沙箱隔离环境中，并记录所有操作日志以便审计和追溯。
六、如何处理Agent幻觉问题
Agent的“幻觉”指它可能在没有事实依据的情况下进行回答，或编造事实。
处理Agent幻觉问题的方案：
- 工具调用结果作为数据来源： 强制Agent使用工具调用的结果作为其回答的数据来源，而不是纯粹依赖模型自身的记忆或臆测。
- 关于数据走数据库查询，不走LLM生成功能： 对于需要精确数据支持的问题，引导Agent直接查询数据库，而非通过LLM生成答案，以避免生成式幻觉。
- 输出要求引用来源： 要求Agent在回答中注明其信息来源，如果没有明确来源则不能妄下断言。例如，当模型说“特斯拉2023年销量是200万台”时，应要求它提供数据来源。如果来源是“根据特斯拉官方财报，2023年销量是180万辆”，则说明答案有据可查；若无来源，则应明确表示“我不确定，建议查证”。
- 验证Agent二次检查关键信息： Agent给出答案后，再由另一个Agent（或一套验证机制）对答案中的关键信息进行二次检查，确保其准确性。
七、Tool调用失败怎么处理
Tool调用失败是Agent执行任务时可能遇到的中断情况。
Tool调用失败的处理办法：
- 重试： 如果Tool调用失败，让模型反思失败原因，尝试更换参数后重试。例如，如果查询搜索工具挂了，可以尝试切换备用库或知识库。
- 权限不足请求授权： 如果失败原因是权限不足，应明确告知用户并请求授权。
- 工具彻底不可用时跳过并标记： 如果工具彻底不可用（例如搜索工具彻底宕机），则跳过这一步并对该任务进行标记，通知相关人员处理。
总的原则是：如果能自动恢复，就进行重试或降级；如果不能自动恢复，则应该停止任务并告知用户或管理员。