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

基本信息

导语

随着大语言模型从单纯的对话工具进化为具备自主规划能力的智能体，如何设计稳定、可控的 Agent 系统成为开发者面临的新挑战。本文深入探讨 Agentic Engineering 的核心模式，剖析从单次调用到多步推理的架构演进。通过梳理常见的循环模式与工具调用策略，我们将帮助读者掌握构建复杂 AI 应用的关键工程实践，从而在实际项目中有效平衡系统的自主性与可靠性。

评论

中心观点

文章主张：Agentic Engineering（智能体工程）不应被视为简单的提示词堆砌，而应确立为一门独立的工程学科，通过引入编排、记忆、工具调用等标准化模式，解决 LLM 应用中非确定性输出与确定性行为需求之间的根本矛盾。

核心评价：从“魔法”到“工程”的必要跨越

1. 内容深度与论证严谨性

[事实陈述] 文章试图构建一套分类学，将智能体工作流分解为循环、反思、工具使用等模式。这标志着行业关注点从“如何训练模型”转向“如何让模型稳定工作”。 [作者观点] 文章深刻指出了当前 AI 应用的痛点：LLM 的概率特性与软件工程的确定性要求存在天然冲突。作者提出的“模式”概念，实际上是在试图为混沌的 LLM 输出增加约束层。 [你的推断] 文章的隐含逻辑是：未来的 AI 系统架构将由“确定性代码”包裹“非确定性模型”。这不仅是技术实现，更是组织架构的变革——AI 工程师需要具备更传统的系统设计能力，而不仅仅是自然语言处理能力。

2. 实用价值与创新性

[事实陈述] 文章详细列举了如“COT（思维链）”、“ReAct（推理+行动）”等具体模式。 [作者观点] 其最大价值在于“去魅”。它将看起来神秘的 Agent 拆解为可复用的代码模块（如 Planner、Executor、Evaluator）。对于开发者而言，这降低了从 Demo 转向 Production 的门槛。 [创新性] 文章并未发明新算法，但创新性地将软件工程中的“设计模式”思想引入 AI 领域。它提出了一种标准化的词汇表，使得团队沟通“Agent 架构”时不再是对牛弹琴。

3. 支撑理由

  1. 复杂度管理：随着 Agent 任务从单一问答转向多步骤任务，硬编码 Prompt 变得不可维护。模式化的工程结构（如状态机、图编排）是控制复杂度的唯一途径。
  2. 可观测性需求：生产环境要求 Debug 和日志。文章强调的模式天然带有结构化的日志点（例如：明确区分“思考”步骤和“行动”步骤），这是黑盒 Prompt 所不具备的。
  3. 人机协同：工程模式强调“人在回路”。例如，在执行高风险操作前引入人工确认模式，这在金融或医疗等高风险领域是落地的必要条件。

4. 反例与边界条件

尽管文章观点有力，但在以下边界条件下可能失效：

  1. 过度工程的陷阱：对于简单的 CRUD（增删改查）类任务或单一检索任务，引入复杂的 Agent 框架（如 LangChain, CrewAI）往往会导致“为了用而用”，造成推理延迟和成本激增，此时直接调用 API 效率更高。
  2. 模型能力的替代：随着 GPT-4 或 Claude 3.5 等基座模型逻辑能力的提升，许多原本需要复杂“反思模式”或“多步拆解”的任务，现在可以通过更长的上下文窗口直接完成。[你的推断] 模型越强，外挂的工程模式可能越少，直到模型本身内化这些模式。
  3. 非确定性的本质不可消除：工程模式只能约束流程，无法消除模型幻觉。即使流程完美，如果核心推理步骤出错，整个链条依然会崩溃。

5. 行业影响与争议点

[行业影响] 该文章预示了 MLOps 向 LLMOps 和 Agentic Ops 的演进。它将推动企业从“采购模型”转向“构建智能体系统”，可能催生新一代的中间件和基础设施公司。 [争议点] 社区目前存在“代码派”与“Prompt 派”的分歧。文章显然属于“代码派”，强调结构化控制。然而，另一派认为过度约束会限制 LLM 的涌现能力。此外，关于“记忆”的实现方式（是向量数据库还是长上下文）目前仍有巨大争议。

实际应用建议与验证方式

应用建议

  1. 从小处着手，按需扩展：不要一开始就构建多智能体系统。从简单的 LLM + Function Call 开始，遇到明确的瓶颈（如需要多步推理或外部工具交互）时，再引入文章中提到的模式。
  2. 关注“评估”模式：在生产环境中，建立一套独立的“评估者”模式比优化核心 Prompt 更关键。这能确保系统在失控前被人工介入。

可验证的检查方式

为了验证文章所提模式的有效性，建议采用以下指标进行观察：

  1. Token 消耗与延迟比：

    • 指标：对比使用复杂编排模式与直接 Prompt 的 Token 成本和端到端延迟。
    • 验证：如果引入模式后，Token 成本增长超过 20% 但任务成功率没有显著提升，则说明存在过度工程。

  2. 任务完成率：

    • 指标：在多步骤任务中，统计流程中断或进入死循环的频率。
    • 验证：文章提出的“反思”和“错误处理”模式应显著降低死循环率。

  3. 可解释性评分：

    • 实验：进行“黑盒测试”，让非技术人员观察 Agent 的执行日志。
    • 验证：如果用户能理解 Agent 为什么

代码示例

 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

# 示例1：多智能体协作模式 - 任务分解与执行
from typing import List

class Agent:
    def __init__(self, name: str, skill: str):
        self.name = name
        self.skill = skill
    
    def process(self, task: str) -> str:
        return f"[{self.name}] 使用{self.skill}处理任务: {task}"

class TaskDispatcher:
    def __init__(self):
        self.agents = [
            Agent("数据分析师", "Python/Pandas"),
            Agent("前端工程师", "React"),
            Agent("后端工程师", "FastAPI")
        ]
    
    def assign_task(self, task: str) -> List[str]:
        results = []
        for agent in self.agents:
            if any(keyword in task.lower() for keyword in ["数据", "分析", "统计"]):
                results.append(agent.process(task))
                break
            elif any(keyword in task.lower() for keyword in ["界面", "前端", "UI"]):
                results.append(agent.process(task))
                break
            else:
                results.append(agent.process(task))
        return results

# 使用示例
dispatcher = TaskDispatcher()
print(dispatcher.assign_task("分析用户行为数据"))
print(dispatcher.assign_task("设计登录界面"))

 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

# 示例2：工具调用模式 - 动态函数注册与执行
class ToolRegistry:
    def __init__(self):
        self.tools = {}
    
    def register(self, name: str):
        def decorator(func):
            self.tools[name] = func
            return func
        return decorator
    
    def execute(self, tool_name: str, *args, **kwargs):
        if tool_name not in self.tools:
            raise ValueError(f"工具 {tool_name} 不存在")
        return self.tools[tool_name](*args, **kwargs)

# 使用示例
registry = ToolRegistry()

@registry.register("计算器")
def calculator(a: int, b: int, operation: str):
    operations = {
        "加": a + b,
        "减": a - b,
        "乘": a * b,
        "除": a / b if b != 0 else "除数不能为0"
    }
    return operations.get(operation, "未知操作")

@registry.register("文本处理")
def text_processor(text: str, action: str):
    if action == "大写":
        return text.upper()
    elif action == "反转":
        return text[::-1]
    return text

print(registry.execute("计算器", 10, 5, "乘"))
print(registry.execute("文本处理", "hello", "大写"))

 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

# 示例3：记忆增强模式 - 简单的对话历史管理
from datetime import datetime

class ConversationMemory:
    def __init__(self, max_history: int = 5):
        self.history = []
        self.max_history = max_history
    
    def add_message(self, role: str, content: str):
        timestamp = datetime.now().strftime("%H:%M:%S")
        self.history.append({
            "role": role,
            "content": content,
            "time": timestamp
        })
        # 保持历史记录在最大长度内
        if len(self.history) > self.max_history:
            self.history.pop(0)
    
    def get_context(self) -> str:
        context = []
        for msg in self.history:
            context.append(f"[{msg['time']}] {msg['role']}: {msg['content']}")
        return "\n".join(context)
    
    def clear(self):
        self.history = []

# 使用示例
memory = ConversationMemory()
memory.add_message("用户", "帮我分析这个数据")
memory.add_message("助手", "好的，请提供数据文件")
memory.add_message("用户", "这是sales.csv文件")

print("对话历史:")
print(memory.get_context())

案例研究

1：Cognition AI (Devin) —— 全自主软件工程代理

1：Cognition AI (Devin) —— 全自主软件工程代理

背景: Cognition AI 致力于通过 AI 改变软件开发流程。在传统的 AI 辅助编程（如 GitHub Copilot）中，AI 仅能根据当前光标位置提供代码补全建议，无法理解整个项目的上下文，也无法独立完成复杂的任务链。

问题: 开发者在修复 Bug 或实现新功能时，需要在 IDE、浏览器、文档和终端之间频繁切换，过程繁琐且耗时。现有的 AI 工具只能生成片段代码，开发者仍需手动将这些代码集成到项目中，并自行处理环境配置、依赖安装和测试验证，无法实现真正的“自动化”。

解决方案: Cognition AI 开发了 Devin，这是一个基于 Agentic Engineering Patterns 构建的全自主软件工程师。Devin 不仅仅是一个聊天机器人，它被设计为一个能够使用开发者工具的智能体。它具备长期规划能力，能够将复杂的工程任务拆解为数百个步骤。Devin 拥有自己的 Shell、代码编辑器和浏览器，能够像人类工程师一样阅读规范、分析代码库、编写代码、编译项目并运行测试用例。如果代码出现错误，它能自主分析错误日志，修改代码并重新尝试，直到任务完成。

效果: 在实际应用中，Devin 成功通过了 Upwork 的实际工程任务测试，能够完成从简单的数据迁移到复杂的 Web 应用构建。它在 SWE-bench 基准测试中解决了约 13.8% 的问题，甚至在没有额外文件修改的情况下，其表现优于专门针对该基准测试优化的模型。这使得 Devin 成为首个能够端到端完成复杂工程任务的 AI 代理，显著降低了人工介入的频率。

2：Klarna —— 客服自动化与智能路由

2：Klarna —— 客服自动化与智能路由

背景: Klarna 是一家全球领先的“先买后付”（BNPL）金融科技公司，拥有庞大的用户基础。随着业务扩张，其客服团队面临巨大的压力，需要处理海量的重复性咨询，包括退款、订单状态查询、支付纠纷等。

问题: 传统的聊天机器人通常基于预定义的规则或简单的意图识别，缺乏上下文理解能力，经常无法解决复杂问题，导致会话转接率居高不下。这不仅增加了运营成本，也导致用户体验不佳。同时，人工客服处理大量重复性低价值任务，造成了人力资源的浪费。

解决方案: Klarna 与 OpenAI 合作，基于 Agentic Engineering Patterns 构建了一个高度自动化的客服智能体。该系统不仅仅作为一个问答机器人，而是被赋予了执行任务的“代理权”。它能够实时访问 Klarna 的内部知识库和用户账户数据，理解复杂的查询意图，并自主执行操作，例如直接处理退款、更新账单地址或管理发票。该智能体采用了多轮对话规划和工具调用机制，能够在单次对话中处理多个相关联的子任务，而不会丢失上下文。

效果: 该 AI 客服代理上线后表现惊人，在上线后的第一个月就处理了 230 万次对话，占据了总客服量的三分之二。它直接完成了相当于 700 名全职人工客服的工作量，预计每年将为 Klarna 节省约 4000 万美元的运营成本。同时，客户解决问题的速度缩短至 2 分钟，而人工客服通常需要 11 分钟，且客户满意度与人工服务持平。

3：Rippling —— 自动化员工入职与 IT 配置

3：Rippling —— 自动化员工入职与 IT 配置

背景: Rippling 是一家企业级人力资源管理平台，致力于整合 HR 和 IT 系统管理。对于企业而言，新员工入职是一个涉及多部门协作的繁琐过程，通常需要 HR、IT 和财务部门共同协作。

问题: 传统的入职流程是割裂的：HR 在 HRIS 系统中录入信息，IT 管理员需要手动在 Active Directory 中创建账户，在 Okta 中配置应用权限，在 Slack 中添加账号，并订购硬件。这一过程充满了人工“搬运数据”的风险，容易出现配置错误（如权限遗漏）或硬件配送延迟，且效率极低。

解决方案: Rippling 利用 Agentic Engineering Patterns 构建了工作流自动化引擎。在这个系统中，一个“入职代理”监听 HR 系统的触发事件（如“新员工入职”）。一旦触发，该代理便接管整个流程，自主协调下游系统。它不依赖简单的 API 调用，而是具备逻辑判断能力：例如，根据员工的部门和职位（从 HR 系统获取），自主决定需要开通哪些 SaaS 软件权限，自动生成公司邮箱，向硬件供应商发送采购指令，并安排相应的培训课程。如果某个子流程（如信用卡申请）被卡住，代理会自动尝试重试或通知相关人员介入。

效果: 这种基于代理的自动化模式将原本需要数小时甚至数天的人工协调工作，缩短至几分钟内自动完成。它消除了人工数据录入的错误风险，确保了 IT 合规性，并让 HR 和 IT 团队从低价值的重复劳动中解放出来，专注于更具战略性的工作。对于拥有大规模流动人员的企业，这极大地降低了管理开销。

最佳实践

Agentic Engineering 最佳实践指南

实践 1：显式状态管理

说明: Agentic 系统的核心在于其自主性和循环能力，而 LLM 本质上是无状态的。最佳实践要求不要将上下文完全依赖模型的上下文窗口，而是将 Agent 的内部状态（如计划、当前步骤、已获取的知识）进行显式建模和存储。这有助于防止循环逻辑混乱，并允许系统在出错时回滚或重试特定状态。

实施步骤:

  1. 定义一个标准化的状态数据结构，包含 plan（计划）、current_step（当前步骤）、memory（记忆）和 intermediate_results（中间结果）。
  2. 在每次 Agent 循环结束时，将推理结果和关键信息更新到状态对象中，而不是仅依靠 Prompt 传递。
  3. 实现状态的序列化存储（如 Redis 或数据库），以便在 Agent 崩溃或需要长周期运行时恢复。

注意事项:

  • 避免在状态中存储原始的冗长日志，仅存储处理后的结构化信息。
  • 确保状态更新的幂等性，防止并发循环导致状态覆盖。

实践 2：工具调用的标准化与防御

说明: Agent 通过工具与世界交互。如果工具定义模糊或缺乏防御机制，Agent 可能会生成无效的参数，导致无限循环或系统崩溃。最佳实践是建立严格的工具接口标准，并实施“防御性”参数验证。

实施步骤:

  1. 为每个工具编写清晰的 Pydantic 模式或 JSON Schema，明确描述每个参数的类型、约束和用途。
  2. 在 Agent 调用工具之前，增加一层验证层，检查 LLM 生成的参数是否符合 schema。
  3. 对于关键操作（如删除文件、发送邮件），实施“人机协作”确认机制，要求 Agent 在执行前等待用户批准。

注意事项:

  • 工具的描述应包含示例输入和输出，以减少 LLM 的幻觉。
  • 限制工具返回的数据量，过长的返回值可能会撑爆上下文窗口。

实践 3：基于回路的流式编排

说明: 传统的链式结构不足以处理复杂的 Agentic 任务。最佳实践是采用“循环”或“图”的编排模式，允许 Agent 根据反馈自我修正。这通常涉及“观察-思考-行动”的循环，直到满足终止条件。

实施步骤:

  1. 构建一个核心执行循环，依次执行：读取输入 -> 推理 -> 选择工具 -> 执行工具 -> 观察结果 -> 更新状态。
  2. 在循环逻辑中设置明确的终止条件，例如达到最大迭代次数、成功获取特定输出或用户发出停止指令。
  3. 引入“反思”步骤，在任务失败或遇到阻碍时，要求 Agent 重新审视之前的步骤并调整策略。

注意事项:

  • 必须设置最大迭代步数限制，以防止 Agent 陷入死循环并消耗大量 Token 预算。
  • 监控循环中的“思考”过程，确保 Agent 没有在逻辑死胡同中打转。

实践 4：混合记忆架构

说明: 强大的 Agent 需要跨越多个会话和任务记住信息。仅依赖上下文窗口是昂贵且不可靠的。最佳实践是结合短期记忆（当前上下文）和长期记忆（向量数据库），实现 RAG（检索增强生成）与 Agent 的深度融合。

实施步骤:

  1. 实现一个滑动窗口机制来维护最近的对话历史和操作记录。
  2. 集成向量数据库（如 Pinecone 或 Milvus），将 Agent 的关键发现和用户偏好存储为长期记忆。
  3. 在每次推理循环开始前，根据当前任务查询相关的长期记忆，并将其注入到系统提示词中。

注意事项:

  • 定期清理或归档过时的记忆，防止噪声干扰 Agent 的判断。
  • 注意保护敏感信息，在存储记忆前进行数据脱敏。

实践 5：可观测性与调试

说明: Agentic 系统的执行路径是非确定性的，难以复现问题。最佳实践是建立完善的可观测性系统，记录每一次决策过程、工具调用和中间思考，而不仅仅是输入和输出。

实施步骤:

  1. 集成追踪工具（如 LangSmith 或 Weights & Biases），记录完整的 Trace ID，将用户请求与 Agent 的每一步行动关联起来。
  2. 记录 LLM 的原始输出、解析后的结构化动作以及工具的返回值。
  3. 为 Agent 的思考过程添加可视化界面，方便开发者查看其决策树。

注意事项:

  • 记录日志时注意过滤敏感提示词和隐私数据。
  • 重点关注“失败的转折”，分析 Agent 为什么选择了错误的工具或得出了错误的结论。

实践 6：提示词工程与角色隔离

说明: 在复杂的工程实践中，不应试图用一个 Prompt 解决所有问题。最佳实践是将不同类型的指令分离：系统角色定义、少样本示例、工具使用指南和当前

学习要点

  • 基于“Agentic Engineering Patterns”（智能体工程模式）这一主题的通用核心概念，总结如下：
  • 编排层是智能体系统的核心，负责将复杂任务分解为可执行的子任务并协调执行，而非仅仅依赖大模型的直接生成能力。
  • 模式化的工具调用是智能体与环境交互的标准方式，通过定义清晰的接口规范来增强系统的可控性和稳定性。
  • 引入反思与自我修正机制，使智能体能够根据执行结果或外部反馈迭代优化输出，从而显著提高任务完成质量。
  • 记忆与状态管理是维持长期上下文连贯性的关键，通过区分短期工作记忆与长期知识库来提升决策的准确性。
  • 规划与搜索能力使智能体能够应对多步推理问题，通过树状搜索或思维链来探索最优路径而非盲目生成。
  • 人类在环交互模式通过在关键决策点引入人工审核，有效平衡了系统的自主性与安全性，防止灾难性错误。

常见问题

1: 什么是 “Agentic Engineering Patterns”，它与传统的软件开发模式有何核心区别？

1: 什么是 “Agentic Engineering Patterns”，它与传统的软件开发模式有何核心区别？

A: “Agentic Engineering Patterns”（智能体工程模式）是指用于构建、部署和管理 AI Agent（人工智能智能体）的一套架构设计和开发范式。与传统的软件开发模式相比，其核心区别在于控制流和确定性的不同。

  1. 控制流转移：传统软件遵循开发者预设的固定逻辑（如 if-else 循环）；而 Agentic 模式下，LLM（大语言模型）作为核心控制器，能够根据环境反馈动态规划下一步行动，具有自主决策能力。
  2. 概率性输出：传统代码的执行是确定性的；而智能体的行为具有概率性，同样的输入可能产生不同的思考路径和解决方案。
  3. 工具使用：Agentic 模式强调模型通过 API 调用外部工具（搜索引擎、代码解释器、数据库等）来扩展其能力边界，而不仅仅是处理文本。

2: 在构建 AI Agent 时，最基础且最常见的设计模式有哪些？

2: 在构建 AI Agent 时，最基础且最常见的设计模式有哪些？

A: 根据 Hacker News 社区及工程实践讨论，目前最基础且常见的模式主要包括以下几种：

  1. ReAct 模式：即推理+行动。这是最基础的循环模式，模型先进行思考，然后执行动作，观察结果后再进行下一步思考，直到完成任务。
  2. 反思模式：引入自我修正机制。Agent 在执行任务或给出初步答案后，会由另一个角色或自身进行批判和审查，检查错误或优化结果，然后进行修正。
  3. 规划模式：用于处理复杂任务。Agent 在行动前先制定一个分步计划，然后按计划逐步执行，并在执行过程中根据情况调整计划。
  4. 多智能体模式：通过多个 Agent 扮演不同角色（如产品经理、程序员、测试员）进行协作，通过对话或工作流来解决单一 Agent 难以处理的复杂问题。

3: 为什么在 Agentic Engineering 中，“记忆"和"上下文管理"被视为最大的挑战之一？

3: 为什么在 Agentic Engineering 中，“记忆"和"上下文管理"被视为最大的挑战之一？

A: 这是因为 LLM 本质上是无状态的，且受限于上下文窗口，而 Agent 任务往往需要跨越较长的时间周期。

  1. 上下文窗口限制：随着对话或任务步骤的增加，Token 消耗会迅速膨胀，最终超过模型的最大处理长度，导致模型"遗忘"早期的关键信息。
  2. 信息筛选：并非所有历史信息都有用。工程上需要设计 RAG（检索增强生成）或摘要机制，从海量历史数据中提取与当前步骤最相关的信息，否则会引入噪音，干扰模型判断。
  3. 状态一致性：Agent 在执行过程中修改了外部状态（如文件内容），如果记忆系统没有及时更新，可能会导致 Agent 在后续步骤中基于过时的信息做出错误决策。

4: 在 Agentic 架构中，如何平衡 LLM 的"自主性"与"安全性”？

4: 在 Agentic 架构中，如何平衡 LLM 的"自主性"与"安全性”？

A: 这是一个工程落地的核心痛点。赋予 Agent 自主性意味着允许其执行代码或修改数据，这带来了巨大的风险。常见的平衡策略包括：

  1. 沙箱环境：Agent 的代码执行环境必须与生产环境隔离，通常使用 Docker 容器或临时虚拟机，确保 Agent 无法直接破坏宿主机或关键数据库。
  2. 人机协同：在执行高风险操作（如删除文件、发送邮件、部署生产环境）之前，强制暂停流程，等待人工审批确认。
  3. 工具权限分级：不要给 Agent 无限制的 API 访问权限。通过 API 网关限制其只能访问特定的资源，或者只授予只读权限，除非必要才授予写权限。
  4. 输出验证：在 Agent 生成的代码或指令发送给执行器之前，通过规则或另一个轻量级模型进行安全扫描。

5: Hacker News 讨论中经常提到的 “Tool Calling” (工具调用) 的主要陷阱是什么？

5: Hacker News 讨论中经常提到的 “Tool Calling” (工具调用) 的主要陷阱是什么？

A: 虽然工具调用让 Agent 变得强大，但在工程实现中经常遇到以下陷阱：

  1. 幻觉调用：模型可能会自信地调用一个不存在的工具，或者编造工具的参数。这需要通过严格的 Pydantic 模型定义或提示词约束来缓解。
  2. 参数格式错误：即使模型知道要调用哪个工具，它生成的 JSON 参数格式可能不符合 API 的要求（例如类型错误、缺少必填字段），导致解析失败。
  3. 死循环：Agent 可能会陷入一个调用工具、观察结果、再次调用同样工具的循环中。工程上通常需要设置"最大步数"限制或专门的检测逻辑来中断这种循环。
  4. 错误处理困难：当工具返回错误（如 500 错误或网络超时）时，Agent 往往不知道如何重试或回退，容易直接崩溃。需要设计专门的错误处理流程，让 Agent 能够理解错误并尝试替代方案。

6: 单个智能体和多智能体系统，

6: 单个智能体和多智能体系统，

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 在构建一个简单的 Agent 时，你发现它经常陷入死循环，不断重复同一个动作（例如反复搜索同一个关键词）。请设计一种基于“状态检查”的终止机制来解决这个问题，而不依赖人工干预。

提示**: 考虑在 Agent 的记忆模块中维护一个历史记录列表，并在执行动作前引入一个判断逻辑，检查当前意图是否与历史记录中的前 N 个意图高度重合。

引用

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

站内链接

相关文章