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

基本信息

导语

随着大语言模型从单纯的对话工具向具备自主规划能力的智能体演进，如何构建稳定、可控的多步推理系统已成为工程实践的核心挑战。本文系统梳理了 Agentic 工程化的关键模式，旨在解决从 Prompt 编排到工具调用的复杂架构问题。通过剖析这些设计模式，开发者可以掌握构建高鲁棒性 AI 应用的具体方法，从而有效规避非确定性带来的潜在风险。

评论

核心评价：从单次交互迈向流程化工程

这篇文章（基于对 Andrew Ng 等人近期倡导的 Agentic Workflow 概念及社区相关讨论的综合评价）的中心观点是：大模型应用的开发范式正从“即问即答”的单次交互，转向具备反思、规划与工具调用能力的“智能体工作流”，这是当前提升 AI 应用性能与落地确定性的关键工程路径。

以下是从技术与行业角度的深入评价：

1. 内容深度：从“炼丹”到“架构”的认知升级

  • 支撑理由：
    • [事实陈述] 文章准确捕捉了当前 AI 领域的一个关键转折点：模型能力的边际提升正在放缓，但通过工程化手段（如多步推理、自我修正）挖掘模型潜力的空间巨大。
    • [作者观点] 文章通过解构智能体的核心模式（如反思、规划、工具使用、多智能体协作），实际上是在定义 AI 时代的“设计模式”。这不仅仅是技巧的堆砌，而是将模糊的 Prompt 变成了可复用、可编排的标准化组件。
    • [你的推断] 这种深度在于它承认了当前 LLM 的“不完美性”。传统的工程追求确定性的逻辑，而 Agentic Engineering 则是在构建一套“容错系统”，通过循环反馈来弥补模型概率性输出的缺陷。
  • 反例/边界条件：
    • [边界条件] 对于逻辑极其严密、零容忍错误的场景（如核心金融结算逻辑），仅靠 Agentic 的“反思”模式可能无法保证数学上的绝对正确，仍需传统代码或符号执行器介入。
    • [反例] 并非所有任务都需要 Agentic。简单的信息抽取或一次性问答，引入复杂的 Agent 循环反而会增加延迟和成本，属于“过度设计”。

2. 实用价值：解决落地“最后一公里”的抓手

  • 支撑理由：
    • [事实陈述] 许多企业拥有强大的基座模型，但在落地时遭遇“演示效果惊艳，实际应用由于幻觉和逻辑断裂而不可用”的困境。
    • [作者观点] 文章提出的模式（如“先让模型列出草稿，再进行批评修改”）为开发者提供了具体的“抓手”。这种结构化的思维比单纯依赖 Prompt Engineering（提示词工程）更有效，因为它引入了控制流。
    • [你的推断] 实用价值还体现在“可观测性”上。将复杂的任务拆解为规划、行动、观察的循环，使得开发者可以更精准地定位 Agent 在哪一步“想错了”，从而进行针对性优化。
  • 反例/边界条件：
    • [边界条件] 实施这些模式的调试难度极高。传统的代码调试是线性的，而 Agent 的调试涉及非线性的模型输出和循环，目前的工具链（如 LangSmith, Arize）仍在成熟中，这对普通开发者构成了门槛。

3. 创新性：重定义“软件”的构成

  • 支撑理由：
    • [你的推断] 文章隐含的创新在于重新定义了“软件”的边界。传统的软件是 Code + Data，而 Agentic Engineering 暗示未来的软件是 Code + Data + Model + Orchestration。
    • [作者观点] 它提出了“以模型为核心”的架构思想，即让模型决定调用哪个 API、如何处理异常，而不是硬编码的逻辑判断。这是对传统确定性编程范式的补充。
  • 反例/边界条件：
    • [反例] 多智能体协作在文中被描绘为解决复杂任务的利器，但在实际工业界，多智能体往往带来极其复杂的通信开销和“幻觉传染”（一个 Agent 的错误逻辑误导另一个 Agent），其稳定性往往不如精心设计的单智能体系统。

4. 行业影响：催生“AI 编排工程师”角色

  • 支撑理由：
    • [你的推断] 这篇文章预示了 AI 工程师职能的进一步细分。未来将不再仅仅是“调参侠”或“Prompt 写手”，而是需要懂得系统设计、工作流编排和工具链集成的“AI 架构师”。
    • [事实陈述] 行业趋势已经证明了这一点，从 LangChain、AutoGPT 到最近的 CrewAI，主流框架都在向文章中描述的模式靠拢。

5. 可读性与逻辑性：抽象与具象的平衡

  • 评价： 文章通常能较好地将抽象的 AI 理论（如 ReAct 框架）转化为具体的代码或流程描述。逻辑上遵循了“问题 -> 模式 -> 实践”的闭环。
  • [你的推断] 对于非技术人员或刚入行的新手，关于“工具使用”和“规划”的边界可能仍显模糊，需要更多的具体案例来辅助理解。

代码示例

 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

# 示例1：基础模式 - 反思与修正
def reflection_agent(initial_query: str):
    """
    模拟一个简单的反思型智能体，先执行任务，然后自我反思并修正结果。
    解决问题：减少LLM生成内容的逻辑错误或幻觉。
    """
    # 模拟 LLM 调用
    def llm_call(prompt):
        # 这里仅作演示，实际应用中应接入真实模型
        if "反思" in prompt:
            return "反思：之前的回答中忽略了边界条件，需要修正。"
        return "初步回答：这是根据常识生成的回答。"

    # 第一步：生成初步回答
    initial_response = llm_call(f"用户问题：{initial_query}")
    print(f"初稿: {initial_response}")

    # 第二步：生成反思意见
    reflection = llm_call(f"请对以下回答进行反思和批判：{initial_response}")
    print(f"反思: {reflection}")

    # 第三步：基于反思修正回答
    final_response = llm_call(f"根据反思意见修正回答：{reflection}")
    print(f"终稿: {final_response}")
    
    return final_response

# 运行示例
reflection_agent("如何优化 Python 代码性能？")

 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

# 示例2：工具使用模式 - 智能路由
import random

def tool_use_agent(query: str):
    """
    模拟一个能够根据问题类型，自动选择并调用外部工具的智能体。
    解决问题：让 LLM 能够突破知识截止日期，获取实时数据或执行具体操作。
    """
    
    # 定义可用的工具集
    def get_weather(city):
        return f"{city} 今天是晴天，25度。"

    def search_database(query):
        return f"在数据库中找到关于 '{query}' 的 3 条记录。"

    def calculator(expression):
        try:
            return f"计算结果: {eval(expression)}"
        except:
            return "计算错误"

    # 模拟 LLM 的路由决策能力
    def decide_tool_and_params(user_query):
        # 实际中会通过 Prompt Engineering 让 LLM 输出 JSON 格式的指令
        # 这里用简单的逻辑模拟路由
        if "天气" in user_query:
            return "weather_tool", ["北京"]
        elif "搜索" in user_query or "数据库" in user_query:
            return "search_tool", [user_query]
        elif "算" in user_query or "+" in user_query:
            return "calculator_tool", ["12 + 30"]
        else:
            return "unknown", []

    # 智能体核心逻辑
    tool_name, params = decide_tool_and_params(query)
    
    if tool_name == "weather_tool":
        result = get_weather(*params)
    elif tool_name == "search_tool":
        result = search_database(*params)
    elif tool_name == "calculator_tool":
        result = calculator(*params)
    else:
        result = "抱歉，我不知道该使用哪个工具。"

    return result

# 运行示例
print(f"结果: {tool_use_agent('帮我算一下 12 + 30')}")

 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：规划模式 - 子任务分解
def planning_agent(goal: str):
    """
    模拟一个能够将复杂大目标拆解为可执行步骤的规划型智能体。
    解决问题：解决复杂多步骤问题，避免 LLM 在长链条任务中迷失方向。
    """
    
    # 1. 规划阶段：将大目标拆解为步骤列表
    def create_plan(objective):
        # 模拟 LLM 生成计划
        return [
            "1. 搜索相关背景信息",
            "2. 基于信息撰写草稿",
            "3. 检查草稿的语法和拼写",
            "4. 最终润色并输出"
        ]

    # 2. 执行阶段：按顺序执行每一步
    def execute_step(step_description, context):
        print(f"正在执行: {step_description}...")
        # 模拟执行过程，上下文会在步骤间传递
        context += f"\n[已完成]: {step_description}"
        return context

    # 主流程
    plan = create_plan(goal)
    print(f"为达成目标 '{goal}' 生成的计划:\n{plan}\n")
    
    current_context = ""
    for step in plan:
        current_context = execute_step(step, current_context)
        
    return "任务完成，最终结果已生成。"

# 运行示例
print(planning_agent("写一篇关于量子计算的博客文章"))

案例研究

1：Klarna (瑞典金融科技巨头)

1：Klarna (瑞典金融科技巨头)

背景: Klarna 是欧洲领先的先买后付（BNPL）和金融服务提供商，拥有超过 1.5 亿客户。随着业务扩张，其客服中心面临巨大的运营压力，每天需要处理大量重复性的咨询。

问题: 客服团队每天接到数十万个咨询请求，其中三分之二涉及退货政策、退款状态和发票管理等常规问题。这导致人工客服工作负荷过大，响应时间延长，且运营成本高昂。

解决方案: Klarna 构建并部署了一个基于 Agentic Workflow 的 AI 客服助手。该系统并非简单的关键词匹配机器人，而是具备多步推理能力的智能体。它能够与 Klarna 的后端系统进行深度集成，执行复杂的业务逻辑，例如查询数据库、处理退款指令以及管理订单状态。该 AI 能够自主判断用户意图，并在必要时接管任务进行实际操作，而不仅仅是回答问题。

效果: 该 AI 助手上线后表现惊人，在上线一个月内就处理了 230 万次对话，占总对话量的三分之二。其直接负责的工作量相当于 700 名全职人工客服。据估算，这项举措预计每年将为 Klarna 节省约 4000 万美元的运营成本，并将客户咨询的解决时间从 11 分钟缩短至 2 分钟，同时保持了与人工客服持平的客户满意度。

2：Cognition AI (Devin 开发团队)

2：Cognition AI (Devin 开发团队)

背景: 软件开发是一个复杂的过程，涉及编写代码、调试、环境配置、文档编写等多个环节。传统的 AI 编程助手（如 GitHub Copilot）通常只能提供代码片段建议，无法独立完成端到端的工程任务。

问题: 开发人员在日常工作中经常需要处理繁琐的重复性任务，如修复 Bug、迁移旧代码或搭建基础项目架构。这些任务虽然逻辑清晰，但耗时费力，且容易出错。现有的自动化工具缺乏上下文理解能力，无法像人类工程师一样规划并执行一系列复杂的操作。

解决方案: Cognition AI 开发了 “Devin”，这是世界上第一个完全自主的 AI 软件工程师。Devin 采用了高级的 Agentic Engineering 模式，具备规划、推理和纠错能力。它拥有自己的命令行、代码编辑器和浏览器，能够独立学习不熟悉的技术。Devin 可以将一个模糊的工程需求拆解为数百个具体的步骤，自主编写代码、部署环境、测试并修复错误，甚至在发现自身代码错误时，能够回溯并重新规划解决方案。

效果: 在实际测试中， Devin 成功通过了顶尖科技公司的实际工程面试，并在 Upwork 等自由职业平台上完成了真实的外包任务。它能够端到端地完成应用程序的构建和部署，将原本需要人类工程师数小时甚至数天的工作量，在几十分钟内完成，极大地释放了开发人员的创造力，使他们能够专注于更复杂的系统设计问题。

3：某大型跨国银行内部合规审查系统

3：某大型跨国银行内部合规审查系统

背景: 面对日益严格的金融监管（如反洗钱法、KYC 规定），银行需要审查海量的交易日志和客户文档，以识别潜在的违规行为。

问题: 合规审查团队每天面临数以万计的交易警报和数千页的非结构化文档（如发票、合同 PDF）。人工审查不仅效率低下，而且由于疲劳容易产生漏判或误判。传统的基于规则的自动化系统会产生大量误报，仍需人工复核。

解决方案: 银行技术团队引入了基于 Agentic Pattern 的多智能体审查系统。该系统包含多个专门的 AI 智能体：一个智能体负责 OCR 识别和文本提取，另一个负责将非结构化数据映射到数据库模式，第三个负责逻辑推理和风险评分。这些智能体协同工作：当发现异常交易时，系统会自主启动调查流程，联网检索相关实体信息，并根据最新的合规政策文档进行交叉比对。如果遇到模糊不清的案例，Agent 会收集所有相关证据并生成摘要，供人工复核。

效果: 该系统将合规审查的效率提升了约 80%。AI 智能体能够处理 90% 以上的常规警报，将误报率降低了一半以上。更重要的是，由于 Agent 具备推理和检索能力，它能够发现传统规则系统无法识别的复杂关联风险，显著增强了银行的风险防御能力。

最佳实践

最佳实践指南

实践 1：通过反思机制增强可靠性

说明: 单次生成往往存在幻觉或逻辑漏洞。最佳实践是引入“反思”循环，即让模型在给出初步输出后，自我审视、批评并改进结果。这种模式类似于人类思维中的“慢思考”系统，能显著提高代码生成、逻辑推理和文本输出的准确性。

实施步骤:

  1. 设计一个两阶段的提示词链：第一阶段生成草稿，第二阶段要求模型对草稿进行批评并提出改进建议。
  2. 将批评意见反馈给模型，要求其基于建议生成最终版本。
  3. 对于复杂任务，可以设置多次迭代，直到通过自检测试。

注意事项:

  • 反思循环会增加推理时间和 Token 消耗，需在准确性和成本之间权衡。
  • 避免让模型陷入无限自我否定的循环，应设定最大迭代次数。

实践 2：利用工具调用实现外部交互

说明: Agentic 系统的核心在于能够与外部世界交互。不要试图让大模型（LLM）通过文本生成完成所有任务（如数学计算或实时数据查询），而应通过函数调用或工具使用能力，将特定任务委托给最可靠的代码或 API 执行。

实施步骤:

  1. 在系统提示词中明确列出模型可调用的工具集（如搜索引擎、数据库查询、Python 解释器）。
  2. 强制模型在需要特定信息时必须调用工具，而不是编造数据。
  3. 建立标准化的工具输入/输出格式，确保模型能正确解析工具返回的结果。

注意事项:

  • 工具描述必须极其精准，模糊的描述会导致模型调用错误的工具。
  • 需对工具调用的结果进行边界检查，防止异常输出导致后续流程崩溃。

实践 3：将复杂任务分解为子目标

说明: 面对复杂指令，大模型容易出现“迷失”现象。最佳实践是采用“规划与执行”分离的模式。先由 Planner（规划者）将高层目标拆解为具体的、可执行的子任务列表，再由 Executor（执行者）依次完成这些子任务。

实施步骤:

  1. 初始化阶段，要求模型仅生成任务清单和执行顺序，不执行具体操作。
  2. 在执行阶段，按照清单逐项处理，每完成一步更新一次状态。
  3. 如果某一步失败，模型应尝试重新规划该步骤或寻找替代路径，而不是直接重头开始。

注意事项:

  • 子任务之间的上下文传递至关重要，确保后续任务能获取前序任务的结果。
  • 避免任务拆分过细导致上下文碎片化，影响整体连贯性。

实践 4：实施显式的短期记忆管理

说明: 随着对话或任务链的延长，上下文窗口会被填满，且早期信息容易被稀释。最佳实践是维护一个动态的“短期记忆”对象（如滑动窗口或摘要列表），只保留与当前步骤最相关的历史信息，而非将所有历史记录原样回传。

实施步骤:

  1. 定义一个结构化的数据结构（如 JSON 或对象）来存储关键状态和已完成的里程碑。
  2. 在每一步执行后，更新该状态对象，丢弃无关的对话噪音。
  3. 在生成新的 Prompt 时，只注入当前状态和最近几轮的对话记录。

注意事项:

  • 需要设计合理的摘要策略，防止在压缩信息时丢失关键细节。
  • 确保状态更新的幂等性，防止重复执行导致状态混乱。

实践 5：建立护栏与安全验证层

说明: Agentic 系统通常具有自主性，这带来了潜在的风险。必须在其输出端或行动端建立非模型化的验证层，确保系统的行为符合预设的规则和安全标准，防止恶意指令或无意的破坏性操作。

实施步骤:

  1. 在 Agent 执行不可逆操作（如发送邮件、修改数据库、执行交易）之前，引入确定性代码进行校验。
  2. 检查输出内容是否包含敏感信息、仇恨言论或非法指令。
  3. 对于高风险操作，强制执行“人机协同”模式，要求人工确认后才能最终执行。

注意事项:

  • 验证规则应基于代码逻辑而非概率模型，以确保 100% 的拦截率。
  • 避免过度限制导致 Agent 无法完成正常任务，需精细调整阈值。

实践 6：采用多智能体协作模式

说明: 单一 Agent 很难同时精通编程、写作、逻辑分析等多种领域。最佳实践是采用“多智能体”架构，为每个 Agent 分配特定的角色（如编码员、审查员、产品经理），通过角色扮演和协作来解决问题。

实施步骤:

  1. 定义不同角色的系统提示词，明确各自的职责和局限性。
  2. 建立通信协议，规定 Agent 之间如何传递信息和任务（例如：Draft Agent 生成 -> Critic Agent 审查 -> Fix Agent 修正）。
  3. 设立一个协调者 Agent，负责调度其他 Agent

学习要点

  • 基于 Agentic Engineering Patterns（智能体工程模式）的讨论，以下是总结出的关键要点：
  • 将复杂的任务目标分解为可独立执行、验证和修正的子任务，是构建高鲁棒性智能体的核心模式。**
  • 通过外部化记忆（Memory）和上下文管理来突破大模型的上下文窗口限制，实现长期信息的持久化与检索。**
  • 利用“反思”和“自我修正”循环机制，让智能体能够检查输出结果并根据错误进行迭代优化。**
  • 采用工具调用模式，赋予大模型通过 API 或函数执行实际操作的能力，从而连接虚拟与现实世界。**
  • 构建多智能体系统，通过分工协作（如一个负责写代码，一个负责审查）来提升解决复杂任务的效率与质量。**
  • 设计“规划-执行”分离的架构，将高层战略决策与具体操作步骤解耦，以增强系统的可控性与透明度。**

常见问题

1: 什么是 Agentic Engineering Patterns（智能体工程模式）？

1: 什么是 Agentic Engineering Patterns（智能体工程模式）？

A: Agentic Engineering Patterns 是指在构建人工智能智能体系统时，为了解决复杂性、可控性和扩展性问题而总结出的一套标准化架构和设计方法。随着 LLM（大语言模型）的发展，简单的“提示词+模型”已无法满足复杂任务的需求。这些模式通常包括：循环模式（Loop，如 ReAct 模式，让模型进行推理和行动的循环）、规划模式（Planning，拆解复杂任务）、工具模式（Tool Use，调用外部 API）以及多智能体协作模式（Multi-agent，如 Supervisor 模式或角色扮演模式）。这些模式旨在将 AI 从单纯的对话机器人转变为能够自主规划、执行和修正任务的“智能体”。

2: 在构建 Agent 时，应该选择“单体大模型”还是“多智能体系统”？

2: 在构建 Agent 时，应该选择“单体大模型”还是“多智能体系统”？

A: 这取决于任务的复杂度和对系统的可控性要求。

  • 单体大模型：适合逻辑相对简单、上下文连贯性强、且不需要长期记忆或复杂分工的任务。优点是延迟低、开发成本低、调试简单。
  • 多智能体系统：适合需要高度专业化、复杂工作流或需要并行处理的场景。通过将不同角色（如编码员、测试员、产品经理）分配给不同的 Agent，可以提高系统在特定任务上的表现。缺点是交互成本高、调试困难且延迟较高。 目前的工程趋势是：对于简单应用，优先使用单体模型配合强大的上下文；对于复杂工作流，则采用多智能体协作。

3: 如何解决 Agent 在执行过程中的“幻觉”或“死循环”问题？

3: 如何解决 Agent 在执行过程中的“幻觉”或“死循环”问题？

A: 这是 Agentic Engineering 中最大的挑战之一，常见的工程解决方案包括：

  1. Human-in-the-loop (HITL)：在关键决策点引入人工确认，防止 Agent 偏离轨道。
  2. 护栏与验证：在 Tool 返回结果或 Agent 生成最终输出前，增加一层验证逻辑（如代码执行检查、输出格式校验）。
  3. 时间步限制：强制限制 Agent 的思考-行动循环次数，防止无限死循环。
  4. 反思模式：引入“审查者”角色，让 Agent 在执行完一步后自我反思或由另一个 Agent 进行批评，从而修正错误路径。

4: 什么是 LangChain/LangGraph 等框架在 Agentic Engineering 中的作用？

4: 什么是 LangChain/LangGraph 等框架在 Agentic Engineering 中的作用？

A: 这些框架提供了实现上述工程模式的基础设施。直接调用 OpenAI 或 Anthropic API 需要开发者手动处理状态管理、记忆存储和工具调用的逻辑。LangChain 等框架提供了标准化的接口（如 Chains），而 LangGraph 则更进一步，允许开发者通过定义图结构来构建有状态的、循环的智能体工作流。它们的作用是让开发者专注于业务逻辑和 Agent 的“大脑”设计，而不是底层的连接和状态维护代码。

5: Agent 的记忆机制是如何设计的？

5: Agent 的记忆机制是如何设计的？

A: 在工程实践中，Agent 的记忆通常分为三个层级，这与 Transformer 的上下文窗口管理密切相关：

  1. 短期记忆：即当前的对话上下文，直接塞入 Prompt 中。
  2. 长期记忆：使用向量数据库存储历史交互或特定知识，通过 RAG（检索增强生成）技术按需召回。
  3. 混合记忆：结合两者，同时利用滑动窗口保持最近对话的连贯性，以及利用 RAG 调用更久远的关键信息。 工程上的难点在于如何高效地检索相关信息以节省 Token，同时保持信息的准确性。

6: 评估 Agent 系统的性能为什么比评估传统模型更难？

6: 评估 Agent 系统的性能为什么比评估传统模型更难？

A: 传统模型的评估通常基于静态数据集（如 MMLU），而 Agent 是一个动态系统。

  1. 非确定性：Agent 涉及多步推理和外部工具调用，同样的输入可能导致完全不同的执行路径。
  2. 环境依赖：Agent 的表现依赖于它调用的工具（如搜索引擎、代码解释器）的实时状态。 因此，Agentic Engineering 的评估通常需要建立专门的评估框架，不仅关注最终答案的正确性，还要关注中间过程（如是否选择了正确的工具、规划是否合理），通常采用“黄金轨迹”对比或基于 LLM-as-a-judge 的自动打分系统。

7: 目前 Agentic Engineering 在落地时面临的主要瓶颈是什么？

7: 目前 Agentic Engineering 在落地时面临的主要瓶颈是什么？

A: 尽管技术演示令人印象深刻，但企业级落地面临三个主要瓶颈：

  1. 成本与延迟：Agent 需要进行多次模型调用和思考，推理成本是普通 Chatbot 的数倍甚至数十倍，且响应时间较长。
  2. 可靠性：目前的成功率很难达到 100%。在金融或医疗等容错率低的领域，99% 的准确率可能仍然不够。
  3. 数据安全与隐私：Agent 需要访问企业内部 API 和数据库来执行任务，如何进行精细化的权限控制（防止 Agent 越权操作）是一个巨大的安全工程挑战。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 在构建一个简单的 Agentic 工作流时，你需要让 LLM 调用两个不同的工具（例如：查询天气和查询时间）。请设计一个 System Prompt，明确指示模型何时调用哪个工具，并处理模型可能产生的“幻觉调用”（即调用不存在的工具）。

提示**: 考虑在 System Prompt 中定义严格的 JSON Schema 输出格式，并加入“如果无法匹配工具，则输出特定错误代码”的指令。思考如何通过 Few-Shot 示例来减少幻觉。

引用

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

站内链接

相关文章