代理工程模式：构建自主智能体的设计范式

基本信息

导语

随着大模型应用从简单的对话机器人向复杂系统演进，如何构建具备自主规划与工具调用能力的智能体成为新的工程挑战。本文深入探讨了 Agentic 模式下的核心设计原则，分析了状态管理、错误恢复及多智能体协作等关键架构问题。通过梳理这些工程模式，读者可以掌握构建高鲁棒性 AI 应用的系统化方法，从而在技术选型与架构设计上做出更优决策。

评论

文章核心观点 Agentic Engineering Patterns（智能体工程模式）主张将AI应用开发从传统的“函数调用”范式转变为“状态机+工作流”范式，通过引入显式的记忆管理、工具编排和反思循环，解决大模型在复杂任务中的幻觉与不可控性问题。

支撑理由与边界条件

  1. 从概率到确定性的工程化收敛

    • [事实陈述] 文章指出，当前的LLM本质上是概率性“文本补全引擎”，直接串联（Chaining）处理复杂逻辑会导致误差累积。
    • [你的推断] 文章提出的“模式”实际上是在试图构建一个“概率图灵机”的沙箱，通过将Prompt Engineering转化为结构化的代码逻辑（如LangGraph或State Machine），强制模型在特定步骤进行确定性输出（如函数调用），从而在不可靠的模型之上构建可靠的系统。
    • 反例/边界条件：对于极度依赖语义理解而非逻辑推演的任务（如创意写作、情感陪护），过度的结构化会限制模型的创造力，导致输出僵化。

  2. “反思”作为纠错的核心回路

    • [作者观点] 文章强调“Agent”不仅是执行者，更是观察者。通过引入“观察-思考-行动”循环，让模型先生成草稿，再由另一个实例（或自身）进行批判和修正，能显著提升代码生成等任务的准确率。
    • [事实陈述] 这种模式类似于软件工程中的“红队测试”或“代码审查”，在数据集（如HumanEval）上已被证明能有效提升Pass@1指标。
    • 反例/边界条件：反思循环会显著增加Token消耗和延迟。在实时性要求极高的场景（如实时语音交互）下，这种“慢思考”模式是不可接受的。

  3. 工具使用的显式编排

    • [作者观点] 文章反对简单的“ReAct”模式（即让模型自由决定何时调用工具），主张更严格的工具编排逻辑。
    • [你的推断] 这反映出行业正在从“大模型万能论”回归“LLM作为控制器（Controller）”的务实路线。模型不再负责生成所有内容，而是负责路由和规划，具体的计算和数据检索由外部工具完成。
    • 反例/边界条件：当面对未知的多模态输入或极度开放的长尾任务时，严格的工具限制会导致Agent“手足无措”，无法泛化到训练数据之外的场景。

多维度深入评价

  1. 内容深度：从“炼金术”向“土木工程”的跨越 文章并未停留在Prompt技巧的层面，而是深入到了系统架构的维度。它敏锐地捕捉到了AI工程化的核心矛盾：非确定性的模型与确定性的业务需求之间的冲突。文章对“状态管理”的探讨尤为深刻，指出了当前许多Agent项目失败的原因——忽视了对话历史和中间状态的维护，导致系统在长上下文中“迷失”。

  2. 实用价值：架构师的参考手册 对于正在从POC（概念验证）走向生产环境的团队，该文章提供了极高的实用价值。它实际上提供了一套设计模式清单，帮助开发者避免重复造轮子。例如，将“规划”与“执行”分离的模式，直接解决了单次Prompt无法处理复杂长流程的问题。

  3. 创新性：范式转移的标准化尝试 虽然文中提到的概念（如Reflection, Tool Use）在社区中已有讨论，但文章的创新之处在于将其系统化、模式化。它类似于Gang of Four的《设计模式》，将零散的实践总结为通用的工程语言，降低了团队沟通的认知成本。

  4. 可读性与逻辑性 文章结构清晰，通常遵循“问题定义 -> 模式描述 -> 代码/架构示例 -> 局限性分析”的闭环。逻辑链条严密，较少使用模糊的营销术语，保持了技术文档的克制与精确。

  5. 行业影响：定义L2级应用开发的MVP 这篇文章（及此类思想）正在定义AI应用开发的“L2级自动驾驶”标准。它标志着行业从“玩梗”阶段进入了“工业化”阶段。未来的AI框架（如LangChain, AutoGen）将大概率会内置这些模式，使其成为开发者的默认配置。

  6. 争议点：成本与复杂度的权衡

    • [作者观点] 文章倾向于通过增加系统组件（如多个Agent、数据库、验证器）来提升性能。
    • [批判性观点] 这种“堆砌”架构可能导致过度工程化。对于简单的分类或摘要任务，一个微调过的小模型（SLM）可能比一个复杂的ReAct Agent更高效、更便宜。行业存在一种“为了用Agent而用Agent”的虚荣指标倾向。

实际应用建议

  1. 不要一开始就上Agent：先用传统代码或单个LLM解决问题。只有当逻辑分支复杂、需要外部工具访问或需要多步推理时，再引入Agentic Patterns。
  2. 建立可观测性：既然引入了复杂的循环和状态，就必须配套Trace工具（如LangSmith），否则调试将是一场噩梦。
  3. 混合架构：不要迷信全Agent架构。将确定性的逻辑（如数据库CRUD）用Python/Java写死，将模糊的决策（如意图识别、总结）交给LLM，通过“Orchestrator”胶水代码连接两者。

可验证的检查方式

  1. **

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

# 示例1：反思模式 - 自动修正LLM输出
import json
from typing import Dict, Any

class ReflectionAgent:
    def __init__(self):
        self.max_attempts = 3
    
    def generate_response(self, prompt: str) -> Dict[str, Any]:
        """生成初始响应并自我修正"""
        for attempt in range(1, self.max_attempts + 1):
            # 模拟LLM生成响应（实际应用中替换为真实API调用）
            response = self._mock_llm_call(prompt)
            
            # 自我评估阶段
            evaluation = self._evaluate_response(response)
            
            if evaluation["is_valid"]:
                print(f"[成功] 尝试 {attempt} 次后获得有效响应")
                return response
            else:
                print(f"[失败] 尝试 {attempt} 失败: {evaluation['reason']}")
                prompt = self._generate_refinement_prompt(response, evaluation["reason"])
        
        return {"error": "达到最大尝试次数", "last_response": response}
    
    def _mock_llm_call(self, prompt: str) -> Dict[str, Any]:
        """模拟LLM调用（实际应用中替换为真实API）"""
        # 这里模拟一个有缺陷的初始响应
        return {
            "content": "巴黎是英国的首都",
            "confidence": 0.6
        }
    
    def _evaluate_response(self, response: Dict[str, Any]) -> Dict[str, Any]:
        """评估响应质量"""
        # 这里可以集成另一个LLM或规则系统进行评估
        if "英国的首都" in response.get("content", ""):
            return {
                "is_valid": False,
                "reason": "地理事实错误 - 巴黎是法国首都"
            }
        return {"is_valid": True}
    
    def _generate_refinement_prompt(self, response: Dict[str, Any], error: str) -> str:
        """生成改进提示"""
        return f"请修正以下错误: {error}\n原响应: {response['content']}"

# 使用示例
agent = ReflectionAgent()
result = agent.generate_response("告诉我法国的首都")
print("最终结果:", result)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

# 示例2：工具调用模式 - 动态函数执行
from typing import Callable, Dict, Any
import inspect

class ToolCallingAgent:
    def __init__(self):
        self.tools: Dict[str, Callable] = {}
    
    def register_tool(self, func: Callable):
        """注册可被LLM调用的工具函数"""
        sig = inspect.signature(func)
        self.tools[func.__name__] = {
            "func": func,
            "description": func.__doc__ or "无描述",
            "params": {name: param.annotation for name, param in sig.parameters.items()}
        }
    
    def execute_tool(self, tool_name: str, **kwargs) -> Any:
        """执行指定的工具"""
        if tool_name not in self.tools:
            return f"错误: 工具 '{tool_name}' 未找到"
        
        tool_info = self.tools[tool_name]
        try:
            result = tool_info["func"](**kwargs)
            return {"status": "success", "result": result}
        except Exception as e:
            return {"status": "error", "message": str(e)}
    
    def get_tool_schema(self) -> Dict[str, Any]:
        """获取工具列表供LLM参考"""
        return {name: {"desc": info["description"], "params": info["params"]} 
                for name, info in self.tools.items()}

# 使用示例
def calculate_loan(principal: float, rate: float, years: int) -> float:
    """计算贷款月供"""
    return principal * (rate * (1 + rate) ** years) / ((1 + rate) ** years - 1)

agent = ToolCallingAgent()
agent.register_tool(calculate_loan)

# 模拟LLM解析后的指令调用
execution_result = agent.execute_tool("calculate_loan", principal=100000, rate=0.05, years=20)
print("工具执行结果:", execution_result)

案例研究

1：Devin (Cognition AI)

1：Devin (Cognition AI)

背景: Cognition AI 致力于构建完全自主的 AI 软件工程师。在软件开发领域，传统的 LLM（如直接使用 ChatGPT 编码）虽然能生成代码片段，但无法处理复杂的长周期任务，无法调试未知错误，也缺乏在复杂开发环境中的自主规划能力。

问题: 现有的 AI 编码助手（如 GitHub Copilot）仅能完成“补全”或“聊天”层面的工作。面对一个完整的工单，它们无法独立完成“查找相关文件 -> 修改代码 -> 运行测试 -> 修复报错 -> 提交 PR”的端到端循环。系统需要具备在沙箱环境中自主决策、使用命令行工具和自我纠错的能力。

解决方案: Cognition AI 采用了 Agentic Engineering 模式，构建了 Devin。Devin 不仅仅是一个模型，而是一个拥有独立 Shell、代码编辑器和浏览器的智能体系统。

  • 规划: 将高层级任务分解为可执行的子步骤。
  • 工具使用: 允许模型主动执行 Shell 命令、搜索 API 文档、编写并运行测试用例。
  • 纠错循环: 当测试失败时，Agent 会自动分析报错信息，回溯修改代码，直到测试通过，而无需人类干预。

效果: Devin 在实际演示中成功完成了 Upwork 上的真实任务，能够端到端地运行和调试复杂的 Web 应用。在 SWE-bench 基准测试中，它解决了 13.86% 的问题（远超之前模型的 1.96%），证明了 Agentic 模式在处理复杂、多步骤工程任务上的巨大潜力。

2：Klarna (客服与购物助手)

2：Klarna (客服与购物助手)

背景: Klarna 是一家瑞典的金融科技巨头，提供“先买后付”服务。随着业务全球化，其客服团队面临巨大的压力，每天需要处理数十种语言的海量咨询，包括退款、退货、发货查询等重复性高的问题。

问题: 传统客服成本高昂且响应时间受限于人力。虽然早期的聊天机器人能处理简单关键词匹配，但在面对稍微复杂的语境或需要跨系统操作（如查询订单状态并发起退款）的任务时往往无能为力，导致用户满意度低且人工介入率高。

解决方案: Klarna 构建了一个基于 Agentic 模式的 AI 客服助手。

  • 系统连接: 该 Agent 不仅仅是对话模型，它被集成了到 Klarna 的后端系统中，拥有读取订单状态、处理退款逻辑的“权限”。
  • 多步推理: Agent 可以理解用户的模糊意图（例如“我的东西还没到”），自主规划动作：先查询物流状态 -> 判断是否延误 -> 根据公司政策计算赔偿或提供安抚方案。
  • 自主执行: 在获得用户确认后，Agent 直接调用 API 完成操作，而不是仅仅告诉用户如何操作。

效果: 该 AI 助手上线后，在推出一个月内就处理了 230 万次对话（占总量的 2/3），直接完成了相当于 700 名全职人工客服的工作量。这预计每年可为 Klarna 节省 4000 万美元的成本，同时将咨询解决时间从 11 分钟缩短至 2 分钟，且客户满意度与人工持平。

3：Replit (Core Team Assistant)

3：Replit (Core Team Assistant)

背景: Replit 是一个流行的在线 IDE 平台。为了提升开发者的编码效率，Replit 一直在探索如何将 AI 深度集成到开发工作流中，而不仅仅是作为一个侧边栏的聊天窗口。

问题: 开发者在编写代码时，往往需要频繁地在编辑器、文档、终端和浏览器之间切换。现有的 AI 助手通常是被动响应，无法理解整个项目的上下文，也无法主动帮助开发者完成诸如“重构这个模块”或“修复这个 Bug”这样涉及多个文件修改的复杂任务。

解决方案: Replit 推出了 Replit Core 和 Agent 模式，采用了 Agentic Engineering 设计。

  • 上下文感知: Agent 能够索引并理解整个项目的代码库结构，而不仅仅是当前打开的文件。
  • 任务编排: 当用户下达指令（例如“将这个 Python 脚本重构为面向对象结构”）时，Agent 会规划修改哪些文件、创建哪些新类。
  • 环境交互: Agent 可以直接在用户的 IDE 中创建文件、编辑代码、并在容器中安装依赖包和运行程序，实时验证修改是否破坏了原有功能。

效果: 这一模式极大地提升了开发者的生产力。数据显示，使用 Replit Agent 的用户在构建复杂项目时的速度显著提升。它使得初级开发者能够完成通常需要高级经验的架构重构工作，并且大幅减少了开发者为了配置环境或查找语法错误而离开 IDE 的次数。

最佳实践

最佳实践指南

实践 1：构建循环反馈机制

说明: Agentic 系统的核心在于其自主性，而自主性依赖于从环境中获取反馈的能力。不要设计线性的“一劳永逸”流程，而应构建一个包含观察、思考和行动的闭环系统。代理需要能够根据执行结果调整后续行为，这需要显式的反馈循环设计。

实施步骤:

  1. 定义清晰的输出验证标准，让系统能判断执行是否成功。
  2. 实现“自我修正”循环，当验证失败时，允许系统重新规划或调用备用工具。
  3. 引入外部信号（如用户确认或自动化测试结果）作为循环的输入。

注意事项: 避免无限循环，必须设置最大重试次数或超时机制。确保反馈信息的信噪比，防止系统因无效反馈而陷入震荡。

实践 2：将复杂任务分解为原子化操作

说明: 大语言模型（LLM）在处理长上下文和复杂多步推理时容易丢失焦点。最佳实践是将复杂的用户请求分解为最小可执行的单元。每个代理应专注于单一职责，通过编排多个小代理来完成大任务，而不是构建一个无所不能的巨型代理。

实施步骤:

  1. 分析任务流程，识别出可以独立执行的逻辑节点（如：搜索、过滤、总结、格式化）。
  2. 为每个节点定义独立的 Prompt 和工具集。
  3. 设计一个“主控”代理，负责将任务分发给子代理并聚合结果。

注意事项: 原子化并不意味着过度碎片化，过多的子代理会增加延迟和上下文传递的难度。需要在粒度和效率之间找到平衡。

实践 3：实施严格的工具使用与沙箱隔离

说明: Agentic 系统通常需要与外部世界交互（执行代码、调用 API、修改文件）。赋予模型过多的权限或过松的执行环境会带来巨大的安全风险。必须限制代理的攻击面，确保其行为是可预测且可撤销的。

实施步骤:

  1. 使用容器化技术（如 Docker）或沙箱环境运行代理生成的代码。
  2. 遵循“最小权限原则”，仅授予代理完成任务所需的特定 API 权限，避免授予通用管理员权限。
  3. 对所有工具调用实施人工审核机制（Human-in-the-loop），特别是在涉及生产环境变更时。

注意事项: 不要信任模型生成的自然语言命令直接转换为系统命令。必须对输入进行严格的参数校验和清洗，防止注入攻击。

实践 4：显式化短期与长期记忆管理

说明: 智能体需要记忆来维持上下文连贯性。然而，LLM 的上下文窗口有限且昂贵。最佳实践是将记忆系统抽象出来，区分用于当前推理的“短期记忆”和用于跨会话检索的“长期记忆”。

实施步骤:

  1. 实现向量数据库作为长期记忆存储，用于保存历史交互、用户偏好和领域知识。
  2. 设计检索机制，在推理前根据当前问题从长期记忆中提取最相关的信息注入到 Prompt 中。
  3. 维护结构化的短期记忆（如对话摘要），仅保留当前任务链路的关键信息，以控制 Token 消耗。

注意事项: 记忆检索的准确性至关重要。如果检索到不相关的历史信息，可能会干扰模型的判断（产生幻觉）。定期清理或归档过时的记忆数据。

实践 5：建立可观测性与状态追踪系统

说明: Agentic 系统的执行路径具有随机性和非确定性。当系统出错或产生意外结果时，仅仅查看最终的输入和输出是不够的。必须能够追踪每一步的思考过程、工具调用参数和中间状态。

实施步骤:

  1. 记录完整的 Trace 链路，包括每个子任务的输入、Prompt、输出和耗时。
  2. 将代理的“思维链”输出到日志系统中，以便调试其推理逻辑。
  3. 建立仪表盘监控关键指标（如：工具调用成功率、平均任务完成时间、Token 消耗量）。

注意事项: 在记录日志时注意数据隐私，避免将敏感信息（PII）写入日志系统。日志本身也会产生成本，需要制定合理的采样和保留策略。

实践 6：防御性提示工程与输出验证

说明: 模型可能会产生幻觉或遵循用户的恶意指令（例如“忽略之前的指令”）。在 Agentic Engineering 中，必须假设模型可能会失败，因此在系统架构层面构建防御机制，而不是仅依赖模型自身的智能。

实施步骤:

  1. 在 Prompt 中明确界定边界和角色，使用系统级提示词禁止越权行为。
  2. 在代码逻辑层增加输出断言，例如检查 API 返回的数据格式是否符合预期，数值是否在合理范围内。
  3. 实施“双轨验证”，对于关键决策，要求模型提供推理依据，并由另一层逻辑进行校验。

注意事项: 过度限制 Prompt 可能会降低模型的创造力。对于生成类任务，防御重点在于格式和安全性检查；对于推理类任务，重点在于逻辑一致性检查。<|user|>

学习要点

  • 基于对 Agentic Engineering Patterns（智能体工程模式）的讨论，以下是总结出的关键要点：
  • 编排层是智能体系统的核心，它负责管理状态、处理工具调用错误并控制循环逻辑，而非仅仅依赖大模型本身。
  • 状态机是构建可靠智能体的最佳工程模式，通过将工作流显式定义为状态转换，可以有效避免模型陷入死循环或产生幻觉。
  • 工具调用应遵循原子性和幂等性原则，确保每个函数功能单一且可重复执行，这是系统能够自动纠错和重试的基础。
  • 评估智能体性能不能仅看准确率，必须引入“Token 效率”和“轨迹成功率”等指标，以衡量系统在复杂任务中的资源消耗和可靠性。
  • 单一模型难以同时完成规划和执行，采用“规划器/执行器”分离的架构能显著提升系统在复杂任务中的表现。
  • 上下文管理是性能瓶颈，必须实施严格的滚动窗口或摘要压缩策略，以防止长对话历史导致成本失控和注意力分散。

常见问题

1: 什么是 Agentic Engineering Patterns（代理工程模式）？

1: 什么是 Agentic Engineering Patterns（代理工程模式）？

A: Agentic Engineering Patterns 是指在设计和构建自主 AI Agent（人工智能代理）时所采用的一套结构性方法和最佳实践。与传统的被动式 AI 模型（仅根据输入生成输出）不同，Agentic 模式强调 AI 系统的自主性、目标导向性和交互能力。

这些模式通常包括如何让 Agent 进行任务规划、如何使用工具、如何进行记忆管理、以及如何进行多 Agent 协作。例如，ReAct 模式（推理+行动）就是一种常见的模式，它让 Agent 在执行动作之前先进行推理，然后根据观察结果调整下一步行动。这些模式旨在解决大语言模型（LLM）在处理复杂任务时面临的幻觉、上下文限制和缺乏外部反馈等问题。

2: 单体 Agent 与多 Agent 系统（MAS）有什么区别，该如何选择？

2: 单体 Agent 与多 Agent 系统（MAS）有什么区别，该如何选择？

A: 这两者代表了不同复杂度的架构模式：

  1. 单体 Agent：由一个强大的 LLM 核心，配合 Prompt Engineering（提示词工程）、工具调用和记忆模块组成。它通过内部循环来处理复杂任务。
    • 适用场景：任务逻辑相对集中、不需要跨领域专业知识、对延迟敏感且追求成本效益的场景。
  2. 多 Agent 系统：将任务分解，由多个专门的 Agent 协作完成。例如，一个 Agent 负责搜索，另一个负责代码编写，第三个负责审核。它们之间通过自然语言或结构化数据进行通信。
    • 适用场景：高度复杂的任务、需要不同角色（如产品经理、工程师、测试员）模拟、需要并行处理以提高效率的场景。

选择建议：通常建议从单体 Agent 开始，如果发现 Prompt 变得过于复杂或难以维护，再考虑拆分为多 Agent 系统。

3: 在 Agentic 架构中，如何解决 LLM 的“幻觉”和错误累积问题？

3: 在 Agentic 架构中，如何解决 LLM 的“幻觉”和错误累积问题？

A: 在 Agentic Engineering 中，解决这一问题主要依赖以下几种模式和策略：

  • 反思与自我修正：Agent 不仅仅是输出结果，还会检查自己的输出。例如，让 Agent 生成代码后，自动运行一个测试用例，如果失败，则将错误信息反馈给 Agent 进行修正。
  • 工具使用验证：不依赖模型的内部知识，而是强制 Agent 调用外部工具（如计算器、搜索引擎、数据库 API）来获取事实性信息。
  • 多轮辩论：在多 Agent 系统中，设置一个“审查者”或“反对者”角色，专门负责挑刺和验证其他 Agent 的输出，通过相互辩论来逼近真相。
  • 人类反馈：在关键决策点引入人工审核机制，确保 Agent 的行动方向不偏离预期。

4: 什么是“记忆模式”，为什么它对 Agent 至关重要？

4: 什么是“记忆模式”，为什么它对 Agent 至关重要？

A: 记忆模式是指 Agent 如何存储、检索和利用过去的信息。由于 LLM 本身是无状态的，记忆机制赋予了 Agent “上下文连续性”和“学习能力”。

常见的记忆模式包括：

  • 短期记忆：利用当前的上下文窗口，存储正在进行的对话或任务步骤。
  • 长期记忆：使用向量数据库存储过去的交互、用户偏好或领域知识。Agent 可以根据语义搜索检索相关信息。
  • 混合记忆：结合两者，并利用 RAG（检索增强生成）技术，确保 Agent 既能记住细节，又能利用庞大的外部知识库。

没有有效的记忆模式，Agent 就无法处理长期项目，也无法根据用户的历史行为进行个性化服务。

5: 构建生产级 Agent 时，最大的工程挑战是什么？

5: 构建生产级 Agent 时，最大的工程挑战是什么？

A: 虽然原型很容易制作，但将 Agent 投入生产环境面临几个主要挑战：

  1. 延迟与成本：Agent 通常需要多次调用 LLM（进行思考、行动、观察），这导致响应时间较长且 API 调用成本高昂。优化推理速度和 Token 使用量是关键。
  2. 可观测性：与传统软件不同，Agent 的行为具有概率性。追踪 Agent 为什么做出某个决策（推理过程）变得非常困难。建立完善的日志和追踪系统是工程化的重点。
  3. 评估：如何测试一个 Agent？传统的单元测试不再适用。工程师需要开发新的评估框架，例如使用另一个 LLM 来打分，或者构建模拟环境来测试 Agent 的表现。
  4. 循环控制：防止 Agent 陷入无限循环或死胡同，需要设计超时机制和中断逻辑。

6: Agentic Workflow 与传统的 Chain-of-Thought (CoT) 提示词有何本质区别？

6: Agentic Workflow 与传统的 Chain-of-Thought (CoT) 提示词有何本质区别？

A: 虽然 Chain-of-Thought (CoT) 也是一种提示技术，但 Agentic Workflow 是更高阶的工程概念。

  • CoT：主要是在 Prompt 中引导模型“一步步思考”，通常是在单次请求中完成，模型输出思考过程后直接给出答案，无法在中间步骤暂停或自我修正。
  • Agentic Workflow：将任务拆解为一个动态的工作流。Agent 不仅仅是在“思考”，它还在“行动”。它

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**:

在单 Agent 系统中，当 LLM（大语言模型）需要调用外部工具（如搜索或计算器）时，经常会遇到幻觉问题，即模型编造了不存在的工具参数或工具名称。请设计一种基于“反馈循环”的工程模式，要求 Agent 在执行工具调用后，必须将执行结果回传给 LLM 进行确认，如果结果为空或报错，需要触发重试机制。

提示**:

引用

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

相关文章