智能体工程的四个层级划分

基本信息

导语

随着大模型能力的提升，如何构建能够自主规划、使用工具并解决复杂问题的智能体，已成为工程实践的核心议题。本文系统梳理了“智能体工程”的演进层级，从简单的脚本自动化到具备多步推理能力的自适应系统。通过剖析不同阶段的架构特征与技术难点，文章旨在帮助开发者厘清现状，明确从“提示词工程”向“智能体架构”转型的关键路径与实施策略。

评论

深度评论：Agentic Engineering 的分层演进与工程边界

文章核心观点 Agentic Engineering（智能体工程）并非单一的技术栈，而是一个随着系统自主性、复杂度和容错率要求提升而演进的分层能力体系。成功构建智能体系统的关键，在于识别业务需求并匹配相应的工程层级，而非盲目追求全自主的通用模型。

支撑理由

  1. 从“脚本”到“系统”的认知升级 [核心解构] 文章将模糊的“Agent”概念具体化为工程层级（如L0单一模型、L1工具调用、L2多智能体协作、L3自适应组织等）。 [深度洞察] 这种分层方法借鉴了传统软件工程中的“能力成熟度模型”（CMM）。它纠正了当前行业的误区：即认为使用大模型等同于做智能体。实际上，真正的工程挑战在于如何处理不确定性。文章隐含的观点是：确定性逻辑（代码）与不确定性逻辑（模型）的混合比例，决定了工程的层级。

  2. 工程化权重超越模型权重 [行业趋势] 随着GPT-4o、Claude 3.5等模型能力的基线提升，行业焦点正从“模型训练”转向“推理控制”。 [架构关键] 文章强调，在高层级的智能体工程中，上下文管理、记忆检索、工具链解析和错误处理机制比模型本身的参数量更重要。 [案例分析] 以Cognition AI的Devin为例，其核心突破不在于使用了特定的秘密模型，而在于构建了一个复杂的“规划-行动-观察-修正”循环系统，以及能够安全执行沙箱代码的工程环境。

  3. 容错率决定应用边界 [逻辑推导] 文章的层级划分隐含了一个关键逻辑：层级越高，对“非确定性”的容忍度必须越低，或者通过工程手段将“非确定性”封装为“确定性输出”。 这解释了为什么目前的Agentic应用主要集中在代码生成（编译器可纠错）和客服（人工兜底）领域，而难以直接介入金融交易（零容错）。

反例与边界条件

  1. 反例：过度设计陷阱 [场景分析] 并非所有场景都需要高层级智能体。对于简单的“总结文档”任务，引入L2级别的多智能体协作（如引入“批评家”Agent监督“写手”Agent）不仅增加了延迟和成本，还可能引入“幻觉叠加”的风险。此时，简单的RAG（L1级别）往往更优。

  2. 边界条件：硬实时系统的排斥 [技术限制] 在高频交易或工业实时控制系统中，目前的Transformer架构由于推理延迟和概率输出的特性，难以满足微秒级的响应要求。文章中的层级理论主要适用于“软实时”或离线任务处理，对于硬实时系统，传统的符号逻辑AI或强化学习仍占主导。

可验证的评估指标

为了验证该理论在实际项目中的有效性，建议采用以下指标进行评估：

  1. “循环-修正”比率

    • 定义：系统完成任务过程中，平均经历的“行动-反馈-修正”循环次数。
    • 逻辑：L0级别通常为0（直接生成），L2级别通常大于3。若该比率过高（>10），说明系统处于低效的“试错”状态，可能是规划器设计失败。

  2. Token有效利用率

    • 定义：最终输出Token数 / 总消耗Token数。
    • 逻辑：在多智能体系统中，大量Token被消耗在通信、上下文传递和自我反思上。若该比率过低（<5%），说明架构过于臃肿，在商业成本上不可持续。

  3. 错误自愈率

    • 测试方法：在工具调用层（L1/L2）设置会导致错误的工具输入，观察系统能否在无人工干预下恢复并完成任务。
    • 逻辑：这是区分“脚本”与“智能体”的关键。真正的Agentic Engineering必须具备“错误感知”和“自我修复”的能力。

  4. 端到端时间成本

    • 观察方法：对比L1（单Agent+工具）与L2（多Agent协作）解决同一复杂任务（如“预定旅行并生成攻略”）的总耗时。
    • 逻辑：若L2耗时增加超过50%但质量提升不明显，则证明该场景下的Agentic设计属于“过度工程”。

综合评价 文章提供了一套必要的分类学框架，梳理了混乱的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
37
38
39

# 示例1：基础智能体 - 自动化文件整理工具
import os
import shutil
from datetime import datetime

def organize_files(folder_path):
    """
    自动将指定文件夹中的文件按类型分类到子文件夹中
    解决问题：手动整理下载文件夹中混乱的文件
    """
    # 定义文件类型与目标文件夹的映射
    file_types = {
        'Images': ['.jpg', '.png', '.gif'],
        'Documents': ['.pdf', '.docx', '.txt'],
        'Archives': ['.zip', '.rar']
    }
    
    # 遍历文件夹中的所有文件
    for filename in os.listdir(folder_path):
        file_path = os.path.join(folder_path, filename)
        if os.path.isfile(file_path):
            # 获取文件扩展名
            ext = os.path.splitext(filename)[1].lower()
            
            # 确定目标文件夹
            for folder, extensions in file_types.items():
                if ext in extensions:
                    target_dir = os.path.join(folder_path, folder)
                    os.makedirs(target_dir, exist_ok=True)
                    
                    # 移动文件并添加时间戳
                    timestamp = datetime.now().strftime("%Y%m%d")
                    new_name = f"{timestamp}_{filename}"
                    shutil.move(file_path, os.path.join(target_dir, new_name))
                    print(f"已移动: {filename} -> {folder}/")
                    break

# 使用示例
# organize_files("C:/Users/YourName/Downloads")

 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

# 示例2：中级智能体 - 智能客服路由系统
class CustomerServiceRouter:
    """
    根据客户咨询内容自动分配给最合适的客服部门
    解决问题：提高客服响应效率和客户满意度
    """
    def __init__(self):
        # 部门关键词映射
        self.departments = {
            '技术支持': ['bug', '错误', '无法登录', '崩溃'],
            '账单问题': ['账单', '付款', '发票', '退款'],
            '产品咨询': ['功能', '价格', '比较', '升级']
        }
    
    def route_inquiry(self, inquiry_text):
        """
        分析客户咨询内容并返回最合适的部门
        """
        scores = {dept: 0 for dept in self.departments}
        
        # 计算每个部门的关键词匹配分数
        for dept, keywords in self.departments.items():
            for keyword in keywords:
                if keyword in inquiry_text:
                    scores[dept] += 1
        
        # 返回得分最高的部门
        best_dept = max(scores, key=scores.get)
        return best_dept if scores[best_dept] > 0 else '通用客服'

# 使用示例
router = CustomerServiceRouter()
print(router.route_inquiry("我的账户无法登录了"))  # 输出: 技术支持
print(router.route_inquiry("请问下个月的账单什么时候出"))  # 输出: 账单问题

 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

# 示例3：高级智能体 - 自适应学习助手
import random

class AdaptiveLearningAgent:
    """
    根据用户表现动态调整学习内容
    解决问题：个性化教育，提高学习效率
    """
    def __init__(self, user_id):
        self.user_id = user_id
        self.knowledge_map = {
            'Python基础': {'熟练度': 0.5, '题目': ['变量类型', '循环结构', '函数定义']},
            '数据结构': {'熟练度': 0.3, '题目': ['列表操作', '字典应用', '集合运算']},
            '算法设计': {'熟练度': 0.1, '题目': ['排序算法', '搜索算法', '动态规划']}
        }
    
    def select_next_topic(self):
        """
        根据当前熟练度选择下一个学习主题
        """
        # 选择熟练度最低的主题
        sorted_topics = sorted(
            self.knowledge_map.items(),
            key=lambda x: x[1]['熟练度']
        )
        return sorted_topics[0][0]
    
    def generate_question(self, topic):
        """
        为选定主题生成练习题
        """
        questions = self.knowledge_map[topic]['题目']
        return random.choice(questions)
    
    def update_progress(self, topic, performance):
        """
        根据用户表现更新熟练度
        """
        self.knowledge_map[topic]['熟练度'] += 0.1 * performance
        self.knowledge_map[topic]['熟练度'] = min(1.0, self.knowledge_map[topic]['熟练度'])

# 使用示例
agent = AdaptiveLearningAgent("user123")
next_topic = agent.select_next_topic()
question = agent.generate_question(next_topic)
print(f"下一个学习主题: {next_topic}")
print(f"练习题: {question}")

# 假设用户正确回答了问题
agent.update_progress(next_topic, 1)

案例研究

1：Klarna（客服自动化）

1：Klarna（客服自动化）

背景: Klarna 是一家先买后付（BNPL）服务的金融科技公司，在全球拥有超过 1.5 亿用户。随着业务扩张，其客服团队面临巨大的咨询量压力，常规的人力扩充难以匹配增长速度。

问题: 每天有大量的重复性咨询（如退款状态、余额查询）涌入，导致人工客服响应时间长，且运营成本高昂（每年约数亿美元）。传统的基于规则的聊天机器人无法理解复杂的用户意图，体验较差。

解决方案: Klarna 采用了基于 OpenAI GPT-4 模型构建的“Agentic”客服助手。该系统不仅仅是简单的问答机器人，而是具备一定推理能力的智能体，能够访问公司的内部知识库和订单系统，自主处理全流程的客户服务交互。它能理解用户的自然语言意图，并执行相应的业务逻辑。

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

2：Cognition（Devin 软件工程师）

2：Cognition（Devin 软件工程师）

背景: 软件开发过程中存在大量繁琐、重复的辅助性工作，如编写单元测试、修复 Bug、迁移旧代码库等。这些工作往往占用资深工程师大量时间，降低了核心开发效率。

问题: 传统的代码补全工具（如 Copilot）只能提供片段建议，无法独立完成复杂的、多步骤的工程任务。开发者需要一个能够理解项目上下文、自主规划步骤并执行完整任务的智能体。

解决方案: Cognition 公司推出了“Devin”，号称世界上第一个完全自主的 AI 软件工程师。作为一个 Agentic AI，Devin 具备主动规划能力，它能够使用开发者工具（如终端、代码编辑器、浏览器），根据用户的高级指令（例如“为这个开源项目修复一个 Bug”），自主制定计划、编写代码、调试并最终交付软件补丁。

效果: 在实际测试中，Devin 成功通过了 Upwork 上的真实工程任务面试。在 SWE-bench 基准测试中（该测试用于评估 AI 解决真实 GitHub 问题的能力），Devin 解决了 13.22% 的问题，远超之前最先进模型（仅 1.96%）。它能够将工程师从重复劳动中解放出来，显著提升软件交付速度。

3：Rippling（招聘流程自动化）

3：Rippling（招聘流程自动化）

背景: Rippling 是一家企业 IT 和人力资源管理公司。对于任何一家公司来说，新员工入职涉及大量的跨系统操作，如创建账户、配置设备、开通权限等，流程繁琐且容易出错。

问题: 传统的自动化工作流通常是“僵化”的，一旦遇到意外情况（例如输入错误、系统接口超时、数据格式不匹配），流程就会中断，需要人工介入干预，无法处理边缘情况。

解决方案: Rippling 推出了基于 Agentic 原理的工作流自动化引擎。与传统“基于脚本”的自动化不同，该系统内置了具备推理能力的 AI Agent。当工作流执行过程中遇到障碍时，Agent 能够像人类一样思考，尝试读取错误信息、查找相关文档或调整参数以自动修复问题，而不是直接报错停止。

效果: 这种具备自我修复能力的 Agent 将工作流的可靠性提升到了新高度。Rippling 的客户报告称，由于 AI Agent 能够自动处理原本需要人工干预的异常情况，其 HR 和 IT 部门在入职流程上花费的时间减少了 80% 以上，且因配置错误导致的安全事故显著降低。

最佳实践

最佳实践指南

实践 1：明确任务定义与目标对齐

说明: 这是代理工程的基础。核心在于将模糊的用户意图转化为机器可执行的精确指令。必须确保代理不仅理解“做什么”，还要理解“为什么做”以及“成功的标准是什么”。目标对齐能防止代理在执行复杂推理时产生幻觉或偏离轨道。

实施步骤:

  1. 使用结构化提示词框架（如 CO-STAR 或 Role-Context 格式）定义任务。
  2. 明确界定输出格式、约束条件和终止条件。
  3. 在系统提示词中嵌入“成功标准”，让代理能自我校验结果是否符合预期。

注意事项: 避免使用自然语言的歧义表达。不要只说“写一段代码”，而要说“编写一个 Python 函数，包含错误处理，并遵循 PEP 8 规范”。

实践 2：构建模块化与可组合的架构

说明: 不要试图构建一个“上帝模型”来处理所有任务。最佳实践是将代理系统拆解为独立的、可复用的组件（如规划器、执行器、评估器）。这种分层架构允许单独优化各个模块，并在出现问题时快速替换或调试特定环节。

实施步骤:

  1. 将工作流拆分为：感知 -> 规划 -> 行动 -> 验证。
  2. 为每个子任务（如搜索、代码执行、文件解析）创建专用的工具或子代理。
  3. 建立标准化的接口协议，确保各模块间能无缝传递上下文。

注意事项: 确保模块间的通信开销最小化。虽然模块化有助于调试，但过多的层叠可能会增加延迟，需要在灵活性与性能间找到平衡。

实践 3：实现人机协同的反馈回路

说明: 在关键决策点引入人类干预是确保安全性和准确性的关键。与其让代理完全自主运行，不如设计成“代理提议 -> 人类确认 -> 代理执行”的模式。这不仅降低了错误风险，还能利用人类反馈来持续微调模型行为。

实施步骤:

  1. 识别高风险操作（如发送邮件、修改数据库、删除文件），在这些节点设置强制人工检查点。
  2. 设计直观的用户界面，展示代理的“思考过程”和拟执行的动作，以便人类快速审核。
  3. 建立反馈机制，将人类的修正数据存储用于未来的微调或提示词优化。

注意事项: 不要让反馈回路成为瓶颈。对于低风险、高重复性的任务，应允许代理在达到一定置信度阈值后自动执行。

实践 4：强化短期记忆与长期上下文管理

说明: 代理在处理长周期任务时容易丢失上下文。最佳实践要求区分短期记忆（当前会话的变量、中间步骤）和长期记忆（持久化的知识库、用户偏好）。有效的记忆管理能显著提升代理在多步推理中的连贯性。

实施步骤:

  1. 实现向量数据库或 RAG（检索增强生成）系统来存储和检索长期信息。
  2. 在对话循环中维护动态的“上下文窗口”，仅保留与当前步骤最相关的历史信息。
  3. 定期对记忆进行总结和压缩，将关键洞察提取出来，避免 Token 溢出。

注意事项: 需注意记忆的时效性和准确性。过时的信息可能导致代理做出错误判断，应设计机制让代理能验证或遗忘过时信息。

实践 5：建立全面的测试与评估体系

说明: 代理系统的非确定性使得传统单元测试变得困难。必须建立一套针对“行为”的评估体系，包括单元测试（针对工具使用）、集成测试（针对工作流）和端到端评估（针对最终输出质量）。

实施步骤:

  1. 为每个工具或子代理编写模拟输入输出的单元测试。
  2. 构建包含“黄金轨迹”的测试集，验证代理在特定场景下是否能推导出预期的中间步骤。
  3. 引入另一个更强的 LLM 作为“裁判”，对生成结果的质量进行自动化打分。

注意事项: 避免过度依赖单一指标。除了准确性，还应关注响应延迟、Token 消耗成本以及鲁棒性（面对异常输入时的表现）。

实践 6：设计容错与自我修复机制

说明: 代理在执行复杂任务时必然会遇到错误（如 API 调用失败、语法错误）。优秀的代理工程不应在错误发生时直接崩溃，而应具备自我诊断和重试的能力。这涉及到异常捕获、错误解释和策略调整。

实施步骤:

  1. 为所有外部工具调用包裹 Try-Catch 块，并将错误信息转化为自然语言反馈给代理。
  2. 在系统提示词中明确指示：“当遇到错误时，分析原因，尝试替代方案，不要直接放弃”。
  3. 实现回滚机制，允许代理在探索性分支失败后回到上一个稳定状态。

注意事项: 必须设置最大重试次数以防止无限循环消耗资源。对于无法恢复的致命错误，应设计优雅的降级方案或向人类求助。

学习要点

  • 基于“Agentic Engineering”（智能体工程）的层级概念，以下是总结出的关键要点：
  • 智能体工程的核心在于将大语言模型（LLM）从被动响应的工具转变为具备自主规划、工具使用和记忆能力的主动智能体。
  • 构建高阶智能体系统需要采用“手手相传”的递归架构，即通过将复杂任务分解并分配给多个子智能体协作完成。
  • 提示工程在智能体开发中依然至关重要，但重点已从单一的指令优化转向设计复杂的系统提示词和思维链逻辑。
  • 赋予智能体访问外部工具和API的能力是打破模型知识时效限制并扩展其实际应用场景的关键手段。
  • 引入短期记忆和长期记忆机制对于智能体处理多步骤任务以及实现个性化交互至关重要。
  • 智能体的可靠性高度依赖于反馈循环和自我纠错机制，使其能够验证输出结果并在失败时自动调整策略。

常见问题

1: 什么是“Agentic Engineering”中的“Agent”？

1: 什么是“Agentic Engineering”中的“Agent”？

A: 在人工智能工程领域，“Agent”（智能体）指的是一种能够感知环境、进行推理并采取行动以实现特定目标的软件系统。与传统的被动式AI模型（如仅根据输入生成文本的ChatGPT）不同，Agent具备自主性。它通常包含几个核心组件：感知模块（处理信息）、规划模块（制定步骤）、记忆模块（存储历史和上下文）以及工具使用模块（调用API、搜索引擎或代码解释器）。简而言之，Agent不仅能“思考”，还能通过调用工具“做事”。

2: Agentic Engineering 的不同级别是如何划分的？

2: Agentic Engineering 的不同级别是如何划分的？

A: 根据Hacker News及相关技术社区的讨论，Agentic Engineering 的级别通常依据系统的自主性、复杂度和处理多步骤任务的能力来划分，大致可以分为以下几个层级：

  1. L1 - 基础调用与增强: 仅仅使用大语言模型（LLM）生成文本，或者使用简单的Prompt技巧（如ReAct框架）让模型进行少量的推理，但主要依赖人类输入。
  2. L2 - 带有工具的上下文感知: Agent能够根据指令动态选择并使用外部工具（如计算器、数据库查询、API接口）来完成任务，弥补模型知识的不足。
  3. L3 - 多智能体协作: 系统不再由单一Agent运作，而是由多个扮演不同角色的Agent（如“程序员”、“审核员”、“产品经理”）组成，它们相互协作解决复杂问题。
  4. L4 - 自主目标追求: Agent能够被赋予一个高层目标，自主地将其分解为子任务，并在执行过程中根据反馈不断调整策略，甚至在失败时进行自我修正，无需人类频繁干预。

3: 为什么我们需要关注 Agentic Engineering 的级别划分？

3: 为什么我们需要关注 Agentic Engineering 的级别划分？

A: 划分级别有助于工程师和产品经理在构建AI应用时设定合理的预期和技术边界。

  • 技术选型: 知道项目处于L2级别，工程师就知道需要重点优化RAG（检索增强生成）和工具调用接口；如果是L4级别，则需要重点解决任务规划和长期记忆的问题。
  • 成本控制: 更高级别的Agent通常意味着更多的Token消耗和更长的推理时间。明确级别可以帮助企业在成本和性能之间找到平衡点。
  • 可靠性评估: 目前的Agent技术越高级，出现“幻觉”或逻辑循环的风险可能越大。分级有助于评估在特定场景下引入自主Agent的风险。

4: 在构建高级别 Agent 时面临的最大技术挑战是什么？

4: 在构建高级别 Agent 时面临的最大技术挑战是什么？

A: 目前最大的挑战主要包括规划能力和调试难度。

  • 规划: 让Agent理解一个模糊的目标并制定出可执行的长期计划是非常困难的。模型很容易在多步推理中迷失方向，陷入死循环。
  • 调试: 传统的软件调试是确定性的，而Agent的行为是概率性的。同一个输入可能会产生不同的执行路径，这使得测试和修复Bug变得极其复杂。
  • 上下文窗口与记忆: 随着任务级别的提升，Agent需要处理的信息量呈指数级增长，如何高效地管理记忆并在有限的上下文窗口中保持连贯性是一个核心工程难题。

5: Agentic Engineering 与传统的自动化脚本（RPA）有什么区别？

5: Agentic Engineering 与传统的自动化脚本（RPA）有什么区别？

A: 虽然两者都旨在自动执行任务，但核心逻辑截然不同。

  • 确定性 vs 概率性: 传统RPA（如Python脚本或UiPath）是基于规则的、确定性的。如果A发生，则执行B。而Agentic Engineering基于LLM，是概率性的。它能够处理未见过的情况、非结构化数据（如自然语言描述的模糊需求），并能根据上下文“猜测”下一步该做什么，而不是严格按照预设的硬编码路径执行。
  • 灵活性: Agent具有更强的泛化能力。面对格式变化的文档或突发的错误，传统脚本通常会崩溃，而Agent可能会尝试理解错误原因并寻找替代方案。

6: 目前有哪些主流的框架或工具用于开发 Agentic 应用？

6: 目前有哪些主流的框架或工具用于开发 Agentic 应用？

A: 随着该领域的火热，出现了许多开源和商业框架来支持不同级别的Agent开发：

  • LangChain / LangGraph: 目前最流行的框架，提供了构建链式调用和状态机（用于复杂Agent循环）的标准化接口。
  • Microsoft AutoGen: 专注于多智能体协作，允许开发者通过定义多个Agent之间的对话来解决任务。
  • CrewAI: 一个基于角色的代理框架，非常适合扮演特定角色（如研究员、作家）的Agent组队工作。
  • LlamaIndex: 虽然以数据索引著称，但其Agent功能也非常强大，特别是在与数据交互（RAG）方面表现优异。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 在构建一个基础的 Agent 时，最简单的架构是直接使用大语言模型（LLM）配合工具调用。请设计一个名为 “FileOrganizer” 的 Agent，它能够接收用户的自然语言指令（例如：“把下载文件夹里的图片都移到图片文件夹”），并生成相应的 Python 脚本，但不执行代码。

提示**: 考虑如何定义 System Prompt 以限制 LLM 的输出仅为代码块，以及如何将文件结构作为上下文输入给模型。思考"感知"层在这里是如何体现的（即如何让模型知道当前有哪些文件）。

引用

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

站内链接

相关文章