智能体工程的层级划分与能力进阶

基本信息

作者: bombastic311
评分: 141
评论数: 73
链接: https://www.bassimeledath.com/blog/levels-of-agentic-engineering
HN 讨论: https://news.ycombinator.com/item?id=47320614

导语

随着大模型能力的提升，软件开发的范式正从编写确定性的代码转向构建具备自主决策能力的智能体。这一转变要求工程师不仅要掌握传统的编程逻辑，更需理解如何设计能够规划、推理并使用工具的系统。本文将梳理智能体工程的不同层级，帮助开发者厘清从简单脚本到复杂多智能体系统的演进路径，从而在实际项目中更有效地构建高可靠性的 AI 应用。

文章评价：Levels of Agentic Engineering

文章中心观点 Agentic Engineering（智能体工程）不应被视为单一维度的技术实现，而是一个从静态脚本到具备自主反思、多智能体协作及自我修正能力的连续成熟度模型，其核心在于通过“系统2思维”的工程化来实现AI应用的鲁棒性与可靠性。

支撑理由与深度评价

1. 内容深度：从“Prompt编写”到“系统设计”的认知升维

事实陈述：文章清晰地划分了智能体工程的层级（通常包括Context、Retrieval、Memory、Tooling、Planning、Reflection等）。
你的推断：文章最深刻的贡献在于它打破了当前业界将Agent等同于“AutoGPT”或“复杂Prompt”的迷思。它论证了真正的Agent工程必须引入控制论的反馈回路。
分析：文章指出了“系统1思维”（快思考，即直接生成）与“系统2思维”（慢思考，即规划、推理、反思）的区别。这不仅是技术分类，更是对AI应用落地稳定性的深度思考。目前的LLM本质上是概率性的，若无反思和规划的架构（系统2），其无法在严肃商业场景中通过验收。

2. 实用价值：为“模型能力不足”提供了“工程解法”

作者观点：通过多步规划、工具调用和结果验证，可以弥补模型本身推理能力的缺陷。
分析：这是目前业界最务实的路径。在GPT-5或更强的模型出现前，我们不能仅依赖模型的“顿悟”。文章提出的架构（如ReAct模式、Self-Refine）是解决大模型“幻觉”问题的唯一工程化手段。例如，在代码生成场景中，单纯的补全（Completion）准确率低，但引入“单元测试作为反馈回路”的Agent架构，可以将可用性提升数个数量级。

3. 创新性：确立了“工程化”的独立地位

事实陈述：文章将Agent构建从“艺术”提升到了“工程”的高度。
分析：过去开发AI应用像写诗（靠Prompt技巧），这篇文章暗示未来开发AI应用像造芯片（靠架构设计）。它提出了层级化的成熟度模型，让企业有了评估AI团队能力的标尺。

反例与边界条件

1. 边界条件：延迟与成本是“过度工程”的杀手

反例：并非所有任务都需要Agent架构。对于一个简单的“情感分析”或“摘要生成”任务，引入规划链、记忆检索和多轮反思是巨大的资源浪费。
事实陈述：每一次Agent的推理步骤不仅增加了Token消耗，更引入了数百毫秒到数秒的延迟。在实时性要求高的交互场景（如实时对话、高频交易）中，复杂的Agentic架构可能因延迟过高而不可用。

2. 边界条件：模型能力的“短路效应”

反例：随着模型参数规模的扩大，模型的CoT（思维链）能力正在内化。
你的推断：未来的模型（如Claude 4或GPT-5）可能在单次生成中就能完成现在的多步规划任务。届时，现在复杂的“多Agent协作框架”可能会因为效率低下而被淘汰，回归到更简单的“超大上下文+强模型”模式。文章可能低估了模型能力进化对架构复杂度的简化作用。

3. 边界条件：调试的复杂性

反例：传统的软件工程是确定性的，而Agentic Engineering是概率性的。
分析：文章可能未充分探讨调试的难度。当一个Agent输出错误时，很难分清是Prompt的问题、工具的问题、检索系统的问题，还是模型本身的问题。这种“不可复现性”是工程落地的巨大障碍。

可验证的检查方式

为了验证文章中提到的Agentic Engineering级别是否有效，建议采用以下指标进行验证：

复杂任务成功率
- 指标：在需要多步推理的任务（如复杂数据分析、长代码生成）中，对比“单次Prompt”与“具备Reflection机制的Agent”的Pass@1（一次通过率）。
- 验证窗口：选取100个真实业务Bug修复任务，观察Agent是否能通过自我修正代码最终通过测试。
鲁棒性测试
- 指标：在面对工具调用失败或检索到无关信息时，Agent的“崩溃率”或“死循环率”。
- 验证窗口：故意干扰环境（例如切断API连接或返回乱码），观察Level 2以上的Agent是否能通过规划路径找到替代方案或优雅报错。
Token效率比
- 指标：输出Token数 / 总消耗Token数。
- 验证窗口：分析Agent在“思考”过程中消耗的Token是否带来了成比例的质量提升。如果Reflection步骤消耗了大量Token但准确率提升微弱，则说明该层级工程在此场景下无效。
时间收敛性
- 指标：任务完成时间的方差。
- 验证窗口：高级别的Agent应当具有更稳定的执行路径。如果同一任务执行时间波动极大（有时1秒，有时60秒），说明其规划逻辑存在缺陷，尚未达到真正的“工程化”标准。

总结《Levels of Agentic Engineering》是一篇具有前瞻性和指导意义的行业文章，它成功地将混乱的AI应用开发梳理为可执行的

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
# 示例1：基础智能体 - 简单任务执行
def basic_agent():
    """
    模拟一个基础智能体，能根据用户输入执行固定任务
    """
    tasks = {
        "天气": "今天晴朗，25°C",
        "时间": "现在是2023-11-15 14:30",
        "笑话": "为什么程序员总是分不清万圣节和圣诞节？因为 Oct 31 == Dec 25"
    }
    
    user_input = input("请输入查询（天气/时间/笑话）：")
    return tasks.get(user_input, "抱歉，我不会这个任务")

# 运行示例
print(basic_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
# 示例2：工具调用智能体 - 动态功能扩展
from datetime import datetime

def tool_agent():
    """
    智能体根据需求动态调用不同工具函数
    """
    def get_time():
        return f"当前时间：{datetime.now().strftime('%H:%M:%S')}"
    
    def calculate(expression):
        try:
            return f"计算结果：{eval(expression)}"
        except:
            return "计算错误"
    
    tools = {
        "时间": get_time,
        "计算": calculate
    }
    
    user_input = input("请输入指令（时间/计算 2+3）：").split()
    tool_name = user_input[0]
    args = user_input[1:] if len(user_input) > 1 else []
    
    if tool_name in tools:
        return tools[tool_name](*args)
    return "未知工具"

# 运行示例
print(tool_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
# 示例3：多步推理智能体 - 任务分解与执行
def reasoning_agent():
    """
    智能体将复杂任务分解为多个步骤执行
    """
    def plan_travel(destination):
        steps = [
            f"1. 搜索{destination}的景点",
            "2. 比较机票价格",
            "3. 预订酒店",
            "4. 制定行程表"
        ]
        return "\n".join(steps)
    
    def solve_math(problem):
        steps = [
            f"1. 分析问题：{problem}",
            "2. 识别运算符",
            "3. 计算结果",
            f"4. 验证：{eval(problem)}"
        ]
        return "\n".join(steps)
    
    tasks = {
        "旅行": plan_travel,
        "数学": solve_math
    }
    
    user_input = input("请输入任务类型和参数（旅行 巴黎/数学 2*3+1）：").split()
    task_type = user_input[0]
    params = " ".join(user_input[1:])
    
    if task_type in tasks:
        return tasks[task_type](params)
    return "无法处理的任务类型"

# 运行示例
print(reasoning_agent())

案例研究

1：Klarna（AI客服代理）

背景: Klarna 是一家全球领先的“先买后付”（BNPL）金融服务公司，拥有庞大的全球客户群，每天需要处理海量的客户服务咨询，涉及退货、退款、账户管理等重复性任务。

问题: 传统的客服模式严重依赖人工坐席，导致响应时间长、运营成本高昂，且随着业务扩张，人力招聘和培训难以跟上需求增长的速度。公司急需一种方法来在不牺牲服务质量的前提下大幅降低成本。

解决方案: Klarna 构建了一个基于生成式 AI 的自主客服代理。该系统并非简单的聊天机器人，而是被赋予了执行任务的权限。它与 Klarna 的后端系统深度集成，能够读取账户状态、处理退款、管理退货，并能够理解复杂的自然语言查询。它被部署在 Klarna 的 App 和官方网站上，全天候（24/7）处理客户请求。

效果: 该 AI 代理目前处理了 Klarna 三分之二的客户服务咨询（约 230 万次对话）。

成本降低：预计每年可为公司减少 4000 万美元的运营成本。
效率提升：AI 代理将解决时间从 11 分钟缩短至 2 分钟，且在准确性上与人工代理持平甚至更高。
人力优化：这相当于 700 名全职人工代理的工作量，使公司能够将人力资源重新分配到更复杂的客户问题上。

2：Cognition（Devin 软件工程师）

背景: Cognition 是一家致力于应用 AI 解决复杂工程问题的初创公司，其核心产品是 Devin，被宣传为世界上第一个完全自主的 AI 软件工程师。

问题: 在传统的软件开发流程中，大量的时间被消耗在重复性的“苦力活”上，如编写样板代码、调试环境配置、阅读遗留代码文档以及修复简单的 Bug。这些任务虽然琐碎，但往往占据资深工程师大量精力，且容易出错。

解决方案: Cognition 开发了 Devin，这是一个具备推理能力和长期规划能力的智能体。不同于只补全代码的 Copilot，Devin 能够接收一个高层次的自然语言任务（例如“帮我优化这个网站的 SEO”），然后自主制定计划、调用终端命令、编写代码、搜索文档、运行测试并修复错误。它拥有自己的浏览器和代码编辑器环境，能够像人类工程师一样一步步“工作”。

效果:

实战验证：在 Upwork 的实际自由职业任务测试中，Devin 成功完成了包括编写调试工具、迁移代码库等在内的真实付费任务。
SWE-bench 评分：在权威的 SWE-bench 基准测试中（该测试基于 GitHub 上真实开源项目的 Issue），Devin 解决了 13.86% 的问题，远超之前最先进模型的 1.96%。
价值：它展示了 AI 智能体从“辅助工具”向“独立执行者”的转变，能够端到端地交付工程成果，而非仅仅是生成代码片段。

3：Rabbit（R1 跨应用操作代理）

背景: Rabbit 是一家硬件初创公司，推出了便携式 AI 设备 R1。其核心目标是解决现代智能手机中 APP 生态割裂、操作繁琐的问题（即“APP 噩梦”）。

问题: 用户想要完成一个简单任务（例如“帮我订两张去巴黎的机票”或“帮我叫车去机场”），通常需要在多个 APP 之间切换、点击数十次按钮，并手动输入信息。现有的语音助手（如 Siri 或 Alexa）通常只能打开 APP，无法完成具体的操作步骤。

解决方案: Rabbit 开发了一个名为 Large Action Model (LAM) 的操作系统级代理。不同于传统的 API 调用，Rabbit 通过基于云端的“虚拟手机”环境，让 AI 学习人类在 APP 中的操作界面（UI）。用户只需向 R1 发出自然语言指令，LAM 就能通过识别 UI 元素，模拟人类在后台的点击、滑动和输入行为，直接操控现有的 APP（如 Spotify、Uber、DoorDash）来完成任务。

效果:

跨应用执行：用户无需解锁手机或打开特定 APP，仅通过语音指令即可完成跨应用的复杂操作链。
降低门槛：R1 在发布首日即售出 1 万台设备，证明了市场对于能够“代理执行”而非仅仅“回答问题”的 AI 硬件有强烈需求。
范式转变：它展示了“基于 UI 的 Agent Engineering”在无需服务端 API 接口的情况下，如何通过模拟人类行为来实现对现有软件生态的自动化控制。

最佳实践

最佳实践指南

实践 1：从“脚本化”向“程序化”思维转变

说明: Agentic Engineering 的核心在于将大语言模型（LLM）从单纯的“文本补全工具”转变为“逻辑推理组件”。初级开发者倾向于编写线性脚本，而高级工程师会构建具有状态管理、错误恢复和循环控制逻辑的系统。这意味着不要依赖单次 Prompt 完成复杂任务，而是设计工作流。

实施步骤:

任务分解: 将复杂的用户请求拆解为多个子任务（如：规划、检索、分析、生成）。
状态机设计: 定义 Agent 的不同状态（例如：搜索中、验证中、完成），并明确状态之间的转换条件。
控制流实现: 使用代码（如 Python 或 LangChain）而非 Prompt 来控制 if/else 分支和循环逻辑。

注意事项: 避免在 Prompt 中进行复杂的逻辑判断，应将逻辑判断下沉到代码层，Prompt 仅负责执行具体的原子操作。

实践 2：实施严格的“工具使用”抽象

说明: Agent 的能力取决于其能够调用的工具。最佳实践要求将所有外部交互（API 调用、数据库查询、文件操作）封装为标准化的工具函数。这不仅增强了系统的可扩展性，还便于权限控制和错误处理。

实施步骤:

定义接口: 为每个工具定义清晰的输入模式和输出模式。
文档化: 为每个工具编写详细的文档字符串，因为 LLM 需要通过阅读文档来理解如何调用工具。
沙箱隔离: 确保工具执行在安全的环境中，对文件系统或网络操作设置严格的权限限制。

注意事项: 不要将原始 API 密钥直接暴露给 Agent 上下文，应使用中间层代理请求。

实践 3：建立多层次的反馈与验证循环

说明: LLM 会产生幻觉，且工具调用可能失败。高水平的 Agentic Engineering 必须包含验证机制。系统应具备自我纠错能力，在输出结果不满足要求时，能够自动重新规划或重试。

实施步骤:

输出验证: 在 Agent 输出最终答案前，增加一个验证步骤，检查格式、逻辑或事实准确性。
错误处理: 捕获工具调用的异常，并将错误信息转化为自然语言反馈给 Agent，使其尝试替代方案。
人类反馈: 在关键决策点引入人工审核接口，确保高风险操作的安全性。

注意事项: 设置最大重试次数，防止 Agent 在死循环中无限消耗 Token 和时间。

实践 4：构建基于“记忆”的长期上下文管理

说明: 优秀的 Agent 能够记住之前的交互、学到的经验以及用户的具体偏好。最佳实践包括设计短期记忆（当前会话）和长期记忆（向量数据库存储），以打破上下文窗口的限制。

实施步骤:

记忆存储: 使用向量数据库存储历史对话和关键知识块。
检索机制: 在执行任务前，根据当前问题检索相关的历史信息。
记忆更新: 设计机制让 Agent 能够将重要的新知识写入长期存储。

注意事项: 注意检索的准确性和相关性，避免引入噪音干扰当前的推理过程。

实践 5：设计可观测性与调试架构

说明: Agent 系统的执行路径具有高度随机性和非确定性。如果不具备可观测性，当系统出错时将难以复现和调试。必须记录每一步的思考过程、工具调用和中间结果。

实施步骤:

日志全链路追踪: 记录每一次 Prompt 输入、原始输出以及 Token 消耗。
可视化追踪: 使用工具（如 LangSmith 或 Arize）将 Agent 的执行路径可视化，展示其决策树。
快照回放: 允许开发者加载历史日志，复现当时的执行场景进行调试。

注意事项: 在记录敏感数据时进行脱敏处理，确保符合数据隐私合规要求。

实践 6：采用“测试驱动”的评估策略

说明: 传统的单元测试难以适应非确定性的 LLM 输出。最佳实践是建立一套基于“评估集”的测试策略，关注最终结果的质量而非具体的文本匹配。

实施步骤:

构建数据集: 准备一组涵盖典型场景的测试用例，包含输入和预期的输出标准。
定义评估指标: 使用确定性指标（如是否包含特定关键词）和 LLM 辅助评估指标（如回答的语气、相关性）。
回归测试: 在每次修改 Prompt 或代码逻辑后，自动运行评估集，确保性能未下降。

注意事项: 不要过度依赖单一指标，应结合多种评估维度来衡量 Agent 的综合表现。

学习要点

基于关于“Agentic Engineering（智能体工程）”的讨论，以下是关键要点总结：
智能体工程的核心在于将复杂的任务拆解为可由独立模型或工具解决的子任务，通过编排实现目标。
有效的提示词工程是构建高性能智能体的基础，需要明确指定角色、上下文和期望输出格式。
赋予智能体工具使用能力（如联网、代码执行）能显著扩展其应用边界，解决仅靠语言模型无法处理的问题。
引入反思和自我修正机制，让智能体能够检查自己的输出并进行迭代优化，是提高准确率的关键。
设计多智能体系统，通过让不同角色（如编码员、审查员）的智能体协作，可以模拟人类工作流以解决更复杂的问题。
在智能体工作流中建立人类反馈循环，既能确保安全性，又能有效纠正模型幻觉或逻辑错误。

常见问题

1: 什么是“Agentic Engineering”中的“Agent”层级，它与传统的软件开发有何不同？

A: 在“Agentic Engineering”（智能体工程）的语境下，“Agent”指的是具备一定自主性、能够感知环境、进行推理决策并执行动作以完成特定目标的AI系统。与传统的软件开发不同，传统程序主要依赖预定义的逻辑和硬编码的规则来处理输入和输出，而“Agent”通常基于大语言模型（LLM）构建，具备理解模糊指令、规划任务步骤、使用工具以及在没有人工干预的情况下处理意外情况的能力。层级划分通常反映了智能体在自主性、推理复杂度和任务处理广度上的成熟度。

2: Agentic Engineering 的不同层级通常是如何划分的？

A: 虽然具体的划分标准可能因讨论框架而异，但通常可以归纳为以下几个递进的层级：

基础工具使用: 模型仅作为接口，通过简单的提示词调用外部工具或API，缺乏长期记忆或复杂规划。
上下文感知与检索: 引入了检索增强生成（RAG）技术，智能体能够访问特定知识库，具备了一定的上下文理解能力，但行动路径通常是线性的。
任务规划与拆解: 智能体能够将复杂的宏观目标拆解为多个子任务，并按顺序执行，具备基本的推理能力。
多智能体协作: 系统中包含多个角色（如研究员、程序员、审核员）的智能体，它们相互配合、通信以解决更复杂的问题。
自主组织与自我进化: 最高层级，智能体不仅能完成任务，还能根据反馈优化自身的工作流程，甚至自主生成新的智能体来应对新挑战。

3: 为什么在构建 AI 应用时需要从低层级向高层级演进，而不是直接构建完全自主的 Agent？

A: 直接构建高层级的完全自主智能体面临着极高的技术挑战和风险。首先，可控性是主要问题，自主性越强，系统行为越不可预测，调试和错误修复变得极其困难。其次，成本与延迟，高层级通常涉及多轮模型调用和复杂的推理链，导致API成本高昂且响应速度慢。最后，可靠性，底层级（如简单的RAG或工作流）在特定垂直领域往往比通用的自主Agent表现更稳定、准确。因此，工程实践通常建议从简单的确定性工作流开始，根据实际需求逐步引入自主性。

4: 在 Agentic Engineering 中，什么是“ReAct”模式，它处于哪个层级？

A: “ReAct”是“Reasoning”（推理）和“Acting”（行动）的缩写，是一种提示词策略或执行模式。它处于任务规划与拆解这一层级。在ReAct模式下，智能体并不是直接给出最终答案，而是生成一个思维链来分析当前状态，然后决定执行什么动作（例如搜索、计算），接着观察动作的结果，如此循环往复，直到得出最终结论。这种模式使得Agent能够处理多步推理问题，是连接简单问答与复杂自主规划之间的关键桥梁。

5: 多智能体系统相比单智能体系统有哪些优势？

A: 多智能体系统通常处于较高的工程层级，其优势主要体现在专业化和模块化。通过模拟人类团队的协作方式，可以将不同的任务分配给专门优化的智能体（例如一个Agent负责写代码，另一个负责测试，第三个负责撰写文档）。这种分工不仅提高了特定任务的完成质量，还使得系统更容易维护和扩展。此外，多个智能体之间的相互辩论和审核可以有效减少幻觉和逻辑错误，提高整体输出的鲁棒性。

6: 评估 Agentic Engineering 系统成功与否的关键指标有哪些？

A: 评估这些系统比评估传统软件更复杂，通常需要关注以下维度：

任务完成率: 智能体是否成功达成了用户设定的目标，而不仅仅是生成了看起来合理的文本。
推理轨迹质量: 智能体在解决问题过程中的中间步骤是否合乎逻辑，是否存在无效循环或错误假设。
工具使用效率: 智能体调用API或工具的准确性和必要性，是否存在冗余或错误的调用。
成本与延迟: 完成任务所消耗的Token数量和总时间，这对于商业落地至关重要。
安全性: 智能体在执行动作时是否遵守了安全边界，未产生有害或越权的行为。

7: 目前构建 Agentic 应用面临的最大技术瓶颈是什么？

A: 目前最大的瓶颈之一是上下文记忆和状态管理的局限性。虽然模型具备推理能力，但它们缺乏像人类一样的持久记忆和工作记忆机制，导致在处理长周期任务时容易遗忘之前的细节或指令。另一个瓶颈是循环的自我修正，即当Agent执行出错时，如何有效地让它意识到错误并自动修正，而不是陷入死循环或产生更多错误。此外，非确定性输出也使得工程化系统难以达到生产环境要求的稳定性。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**:

在构建一个简单的 Agentic 系统时，如果只依靠 LLM（大语言模型）的上下文窗口来存储对话历史和中间结果，当任务链条过长时会发生什么？请设计一个简单的机制来验证这个问题，并提出一种不依赖外部数据库的轻量级解决方案。

提示**:

引用

原文链接: https://www.bassimeledath.com/blog/levels-of-agentic-engineering
HN 讨论: https://news.ycombinator.com/item?id=47320614

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

站内链接

分类： AI 工程 / 大模型
标签：智能体 / Agent Engineering / LLM / 能力分级 / AI 架构 / 工程化 / Agentic Workflow / 技术进阶
场景：大语言模型 / AI/ML项目

智能体工程的四个层级划分
智能体工程化的能力层级划分
代理工程的技术层级与能力演进
Agent Skills：AI 智能体的技能框架
Agent Skills：大模型智能体技能框架 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。

AI Stack

智能体工程的层级划分与能力进阶