代理工程的技术层级与能力演进

基本信息

导语

随着大模型能力的提升，工程化构建已从简单的 API 调用演变为复杂的智能体系统设计。理解这一演进过程中的不同层级，对于构建稳健、可控且具备成本效益的 AI 应用至关重要。本文将梳理智能体工程的关键阶段，帮助开发者在系统复杂度与落地可行性之间找到平衡，从而为实际业务场景选择最合适的技术架构。

评论

文章中心观点 智能体工程的成熟度并非取决于单一模型的智力上限，而是取决于系统在“规划、记忆、工具使用与反思”四个维度上的工程化分层与闭环控制能力。

支撑理由与边界分析

  1. 从“提示词编排”向“系统架构”的范式转移

    • [事实陈述] 文章明确区分了简单的 LLM 应用与具备 Agentic 能力的系统，指出后者必须包含状态管理和反馈循环。
    • [作者观点] Agentic Engineering 的核心在于将不确定性的模型输出转化为确定性的系统行为，这需要引入传统的软件工程约束（如 DAG、状态机）。
    • [你的推断] 这种观点实际上是在修正目前市场上对“Agent”的过度炒作，强调 Agent 不是魔法，而是需要被严格设计的软件系统。
    • 反例/边界条件： 对于创意写作或开放域闲聊等非结构化任务，引入过重的系统架构（如复杂的规划器）反而会降低响应速度和自然度，此时简单的 Prompting 依然是最优解。

  2. 多层级能力分解的必要性

    • [事实陈述] 文章提出了不同层级的工程能力（如从简单的 RAG 到自主规划的多智能体系统）。
    • [你的推断] 这种分层有助于企业评估自身技术现状。目前 80% 的业务需求其实只需要“工具使用”和“简单检索”层级，盲目追求“自主反思”层级会导致极高的试错成本。
    • 反例/边界条件： 端到端的大模型（如 o1 或 Claude 3.5 Sonnet）正在通过内部链式思考压缩外部架构的层级。如果模型本身具备极强的规划能力，外部的“工程分层”可能会变得冗余，架构设计需随模型基座能力的演进而动态退化。

  3. 反思与自我修正作为系统稳定性的基石

    • [作者观点] 文章强调“反思”模块是区分高级 Agent 与普通脚本的关键。
    • [你的推断] 这对应了工业界对“幻觉”问题的工程化解法。与其追求模型 100% 准确，不如构建一个允许试错并能快速修正的闭环系统。
    • 反例/边界条件： 在金融交易或工业控制等高风险场景下，允许 Agent “自我修正”意味着允许它先犯错，这在很多硬实时系统中是不可接受的。此类场景必须在前置验证阶段消除错误，而非依赖事后反思。

评价维度深入分析

  1. 内容深度与严谨性 文章没有停留在表面的 API 调用，而是深入到了控制论的范畴。它将 Agent 视为一个控制系统，而非单纯的聊天机器人。这种视角的转换极具深度，指出了当前 AI 应用落地难的症结：缺乏工程化手段来约束模型的随机性。

  2. 实用价值 对于技术管理者而言，文章的价值在于提供了一份“能力地图”。它可以帮助团队判断当前项目是需要一个简单的 RAG（Level 1-2），还是需要引入重资源的 Multi-Agent System（Level 4+）。这直接关系到算力预算和研发周期的制定。

  3. 创新性 文章并未提出全新的算法，但其创新在于将软件工程中的“关注点分离”原则引入了 AI 开发。将规划、执行、反思解耦，是构建可维护、可观测 AI 系统的关键一步。

  4. 争议点与不同观点

    • 架构 vs. 模型能力： 文章似乎倾向于通过复杂的架构来解决问题。然而，随着 OpenAI o1 等具备强推理能力模型的问世，部分观点认为“架构无用论”，即更强的模型可以通过更长的上下文和内部推理替代复杂的外部架构。
    • 成本与收益： 文章可能低估了多步调用的成本。在每一次规划、执行、反思中都进行 LLM 推理，其延迟和 token 消耗可能是商业应用不可承受之重。

  5. 行业影响 此类文章正在推动行业从“模型调参”向“模型编排”转型。未来的 AI 工程师不仅需要懂 NLP，更需要懂分布式系统、并发控制和数据库事务管理。

实际应用建议与验证指标

为了验证文章中提到的 Agentic Engineering 级别是否在您的项目中有效落地，建议采用以下检查方式：

  1. 可验证指标：循环收敛率

    • 定义： Agent 在完成任务过程中，平均经历多少次“执行-反思”循环后才能产出最终结果。
    • 观察窗口： 如果一个任务需要超过 5 次反思循环，通常意味着规划器失效或模型能力不足，而非工程架构不够复杂。

  2. 可验证指标：工具调用成功率与回滚率

    • 实验： 故意在工具返回结果中注入错误（如 API 返回 500 或空数据）。
    • 观察： 高级的 Agentic 系统应能自我修正并尝试替代路径，而不是直接报错或产生幻觉。如果系统在工具报错后直接胡乱回答，说明其“反思”层级未生效。

  3. 可验证指标：Token 消耗与任务完成率的边际效应

    • 观察： 记录随着 Agent 复杂度（如引入更多子 Agent）的提升，任务完成率（FCR）的增长曲线。
    • 判断： 如果架构复杂度翻倍，但 FCR 仅提升 5%，则说明陷入了过度工程化

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# 示例1：基础智能体 - 单步决策
import random

def basic_agent():
    """模拟一个简单的客服智能体，根据用户输入关键词做出单步响应"""
    responses = {
        "价格": "我们的产品价格在100-500元之间",
        "发货": "通常24小时内发货，3-5天送达",
        "退货": "支持7天无理由退货"
    }
    
    user_input = input("请输入问题（价格/发货/退货）：")
    # 简单的关键词匹配决策
    for keyword in responses:
        if keyword in user_input:
            return responses[keyword]
    return "抱歉，我无法理解您的问题"

# 运行示例
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

# 示例2：工具调用型智能体 - 多步推理
from datetime import datetime

def tool_using_agent():
    """能调用工具的智能体，先判断需求再执行相应操作"""
    def get_time():
        return f"当前时间：{datetime.now().strftime('%Y-%m-%d %H:%M')}"
    
    def calculate(expression):
        try:
            return f"计算结果：{eval(expression)}"
        except:
            return "计算错误"
    
    tools = {
        "时间": get_time,
        "计算": calculate
    }
    
    user_input = input("请输入指令（如'现在几点'或'计算1+1'）：")
    # 多步推理：先识别意图，再调用对应工具
    for keyword in tools:
        if keyword in user_input:
            return tools[keyword]()
    return "我无法处理这个请求"

# 运行示例
print(tool_using_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

# 示例3：自主规划型智能体 - 任务分解
class PlanningAgent:
    """能自主规划任务步骤的智能体"""
    def __init__(self):
        self.task_queue = []
    
    def add_task(self, task):
        self.task_queue.append(task)
        print(f"已添加任务：{task}")
    
    def execute_tasks(self):
        while self.task_queue:
            current_task = self.task_queue.pop(0)
            print(f"正在执行：{current_task}")
            # 模拟任务执行
            yield f"完成 {current_task}"
    
    def plan_trip(self):
        """自主规划旅行任务"""
        destinations = ["北京", "上海", "广州"]
        for dest in destinations:
            self.add_task(f"预订{dest}的酒店")
            self.add_task(f"购买{dest}的景点门票")
        return "旅行规划已生成"

# 运行示例
agent = PlanningAgent()
print(agent.plan_trip())
for result in agent.execute_tasks():
    print(result)

案例研究

1：Klarna (AI客服助手)

1：Klarna (AI客服助手)

背景: Klarna 是一家全球领先的“先买后付”（BNPL）金融科技公司，拥有数百万用户。随着业务规模扩大，其全球客服中心面临巨大的人力成本压力和响应延迟挑战。

问题: 传统的客服模式依赖大量人工坐席，导致运营成本高昂（每年约数亿美元），且在处理高峰期流量时响应时间较长，用户体验不一致。同时，人工客服需要处理大量重复性、低价值的查询（如退款状态、退货流程），无法专注于高价值的复杂问题。

解决方案: Klarna 部署了基于 OpenAI 技术构建的 Agentic AI 客服助手。该系统不仅仅是简单的问答机器人，而是具备一定自主能力的智能体。它能够与 Klarna 的后端系统深度集成，实时访问订单数据库、退款政策和知识库。它可以自主规划多步骤操作来处理用户请求，例如同时查询两个不同的订单状态并计算退款金额。

效果:

  • 该 AI 助手在上线后短时间内就处理了 230 万次对话，占总客服对话量的三分之二。
  • 直接经济效益：预计每年将为 Klarna 节省 4000 万美元的运营成本，相当于减少了 700 名全职客服代理的需求。
  • 效率提升：客户问题的解决时间从 11 分钟缩短至 2 分钟，且与人工服务持平的客户满意度表明服务质量未下降。

2：Cognition (Devin 软件工程师)

2：Cognition (Devin 软件工程师)

背景: 软件工程领域充满了大量重复性、繁琐的“琐事”，如代码迁移、Bug 修复、编写单元测试和搭建开发环境。这些工作通常占用资深工程师大量时间。

问题: 现有的自动化工具（如 Copilot）主要提供代码补全建议，仍需人类工程师不断监督、编写和调试代码。人类需要一个能够真正理解任务目标、自主规划步骤并执行完整软件工程任务的智能体，而不仅仅是一个辅助插件。

解决方案: Cognition 开发了 Devin，被称为世界上第一个完全自主的 AI 软件工程师。Devin 作为一个 Agentic System，具备长上下文记忆、主动规划能力和纠错机制。它能够使用开发者工具（如命令行、代码编辑器、浏览器），自主地将复杂的工程任务分解为子任务，并在执行过程中自我修复编译错误或逻辑漏洞。

效果:

  • 在实际应用测试中，Devin 成功通过了 Upwork 上的真实工程面试，并能够完成完整的端到端编码任务。
  • 在 SWE-bench 基准测试中（该测试评估解决真实 GitHub 问题中的难度的能力），Devin 解决了 13.8% 的问题，而之前的模型（如 GPT-4）仅能解决 1.96% 的问题。
  • 核心价值：它将 AI 从“辅助工具”转变为“独立执行者”，能够独立完成从需求分析到代码部署的整个闭环，极大地释放了人类工程师的创造力。

3：Rippling (IT 采购与配置自动化)

3：Rippling (IT 采购与配置自动化)

背景: Rippling 是一家企业级员工管理平台，处理从入职、设备采购到软件授权的全流程。对于企业而言，新员工入职涉及 IT、HR、财务等多个部门的复杂协同。

问题: 传统的入职流程是割裂的：HR 在系统中录入信息后，IT 部门需要手动采购电脑、配置软件许可，财务部门处理薪资。如果 IT 采购经理忘记审批或配置，流程就会卡住。这种依赖人工传递信息的方式效率低下且容易出错。

解决方案: Rippling 构建了一个高度自动化的 Agentic Workflow（智能体工作流）。当 HR 发起入职请求时，系统会触发一系列智能体操作：自动向供应商（如 Dell 或 Apple）下单购买硬件，同时在后台自动配置该员工的 Google Workspace、Slack 和 Zoom 账号，并安装必要的 VPN 软件。如果某个环节（如信用卡支付失败）出现问题，智能体会自动重试或通知特定人员干预，而不是停止整个流程。

效果:

  • 实现了“一键式”员工入职，将原本需要数小时甚至数天的跨部门协作缩短至几分钟。
  • 消除了人工在系统之间复制粘贴数据的错误风险。
  • 通过智能体处理逻辑判断和状态检查，确保了业务流程的连续性，使 IT 和 HR 团队能专注于战略任务而非行政琐事。

最佳实践

最佳实践指南

实践 1：基于 L0 级别的原型验证

说明: 在 Agentic Engineering 的初期阶段（L0），核心目标是验证可行性。此级别通常指代基础的提示词工程或单次交互。最佳实践建议在此阶段不要过度设计架构，而是专注于验证模型是否理解指令并能在特定上下文中正确执行任务。这是构建更复杂系统的基础。

实施步骤:

  1. 定义清晰的任务输入和期望输出。
  2. 编写高质量的 System Prompt 和 User Prompt。
  3. 在静态数据集上进行小规模测试，验证模型回复的准确性和稳定性。
  4. 评估并迭代提示词，直到达到基线性能。

注意事项: 避免在此阶段引入复杂的工具调用或记忆机制，应先确保核心逻辑的零样本或少样本能力满足需求。

实践 2：构建 L1 级别的工具增强能力

说明: 当基础提示词无法满足需求（例如无法获取实时数据或执行代码）时，需要进入 L1 级别。此级别的最佳实践是将大语言模型（LLM）与外部工具解耦。通过函数调用或插件机制，让模型能够决定何时以及如何使用外部工具来弥补其自身的局限性（如数学计算、知识截止等）。

实施步骤:

  1. 识别模型能力边界所需的工具（如搜索 API、数据库查询接口、代码解释器）。
  2. 定义清晰的工具描述 Schema（JSON/YAML），包括参数含义和返回值格式。
  3. 实现中间层逻辑，负责解析模型的工具调用请求并执行实际操作。
  4. 将工具执行结果反馈给模型，生成最终回复。

注意事项: 工具描述必须极其精准，模糊的描述会导致模型频繁调用错误的工具。同时，必须处理工具执行失败时的异常回退逻辑。

实践 3：实现 L2 级别的多智能体协作编排

说明: L2 级别涉及将复杂任务拆解并分配给不同的角色。最佳实践是采用“分而治之”的策略，不再依赖单一模型处理所有问题，而是设置专门的 Agent（如研究员、程序员、审核员）。这需要引入编排层来管理 Agent 之间的通信和依赖关系。

实施步骤:

  1. 将复杂任务分解为子任务，并映射到具有特定 Persona 的 Agent 上。
  2. 定义 Agent 之间的通信协议（如消息传递、共享黑板机制）。
  3. 设计工作流引擎，确定是串行执行（流水线）还是并行执行（争论/协作）。
  4. 监控中间产物，确保子任务输出的质量能够传递给下一个环节。

注意事项: 避免 Agent 之间的无限循环或无效对话。需要设置最大迭代次数或仲裁机制来终止任务。

实践 4：应用 L3 级别的自主规划与自我修正

说明: 在 L3 级别，系统需要具备自主性和鲁棒性。最佳实践是引入“规划-执行-反思”的循环机制。Agent 不仅执行任务，还需要根据反馈自我评估，并在遇到错误或障碍时自动调整策略，而不是直接失败或产生幻觉。

实施步骤:

  1. 赋予 Agent 高级规划能力，使其能将高层目标转化为具体步骤。
  2. 实现“反思” Prompt，要求模型在每一步执行后检查结果是否符合预期。
  3. 设计重试机制，如果检测到错误，自动生成修正后的计划或代码。
  4. 记录执行轨迹，以便于系统进行上下文学习和错误归因。

注意事项: 自我修正会显著增加 Token 消耗和延迟。需要在自主性和成本之间寻找平衡，防止陷入“自我怀疑”的死循环。

实践 5：建立 L4 级别的持续记忆与知识库

说明: L4 级别的系统需要长期存在并积累经验。最佳实践是将向量数据库、图数据库或键值存储集成到 Agent 架构中。这允许 Agent 跨会话记住用户偏好、历史操作和过往学到的知识，从而实现个性化服务。

实施步骤:

  1. 设计记忆架构，区分短期记忆（当前上下文窗口）和长期记忆（外部存储）。
  2. 实现记忆的读写机制，包括信息的提取、存储和检索。
  3. 定期对记忆进行总结和提炼，避免无关紧要的细节占用存储空间。
  4. 确保敏感数据的加密和隐私合规。

注意事项: 记忆检索的准确性至关重要（RAG 中的检索环节）。如果检索到错误的历史记忆，可能会导致模型产生严重的幻觉或逻辑错误。

实践 6：引入 L5 级别的自动化对齐与安全护栏

说明: 随着 Agent 自主性的提高（L5），风险也随之增加。最佳实践是构建多层安全防御体系。这包括输入输出过滤、权限管理以及针对恶意使用的防御机制。系统必须能够识别并拒绝危险指令，防止 Agent 执行破坏性操作。

实施步骤:

  1. 在 Prompt 层面设置系统级约束，明确界定不可逾越的红

学习要点

  • 基于您提供的主题“Agentic Engineering 的层级”（通常指 AI 智能体工程化的成熟度模型），以下是该领域中最关键的 5 个核心要点：
  • 真正的智能体工程化必须超越简单的提示词编写，转向基于反馈循环的系统化迭代与优化。
  • 有效的工具使用是智能体能力的核心倍增器，能够显著扩展模型在物理世界和数字世界中的行动半径。
  • 实现可靠的长期记忆机制是区分一次性脚本与具备持续学习和适应能力系统的关键分水岭。
  • 将复杂的任务目标拆解为可执行的子任务，并规划执行步骤，是衡量智能体推理能力的重要指标。
  • 构建多智能体系统，通过角色分工与协作，能解决比单一模型更复杂、更专业的问题。

常见问题

1: 什么是“Agentic Engineering”（代理工程）？

1: 什么是“Agentic Engineering”（代理工程）？

A: Agentic Engineering 是指设计、构建和维护 AI Agent（人工智能代理）系统的工程学科。与传统的聊天机器人或被动响应的 AI 模型不同，AI Agent 具备自主性，能够感知环境、进行推理决策、调用工具并执行任务以完成复杂的目标。它结合了大语言模型（LLM）的推理能力与软件工程的严谨性，旨在创建能够独立或半独立完成工作流的智能系统。

2: “Levels of Agentic Engineering”通常包含哪些层级？

2: “Levels of Agentic Engineering”通常包含哪些层级？

A: 虽然具体的划分标准可能因讨论框架而异，但通常根据系统的自主性、推理能力和复杂度，将其划分为以下几个主要层级：

  1. Level 0 - 无代理： 传统的被动应用，没有记忆，没有工具使用，完全依赖用户输入。
  2. Level 1 - 上下文感知： 具备记忆能力，能在当前对话中利用上下文信息，但仍主要依赖提示词，无法自主行动。
  3. Level 2 - 工具使用： 能够检索信息（RAG）或调用外部 API（如搜索、计算器）来增强回答能力。
  4. Level 3 - 多步推理与规划： 具备拆解复杂任务的能力，能够自主制定计划并分步骤执行（例如：ReAct 模式，推理+行动）。
  5. Level 4 - 自主迭代： Agent 能够根据执行结果的反馈进行自我反思、修正错误，并不断优化输出，直到达成目标。
  6. Level 5 - 完全自主： 能够在极少或没有人类监督的情况下，长期在复杂环境中运行，自主进行资源分配和决策。

3: 为什么需要划分 Agentic Engineering 的等级？

3: 为什么需要划分 Agentic Engineering 的等级？

A: 划分等级主要有以下几个目的：

  • 明确能力边界： 帮助开发者和企业清晰地定义当前 AI 系统的能力上限，避免过度依赖或期望过高。
  • 指导架构设计： 不同层级的 Agent 需要不同的技术栈（如简单的 RAG 系统与复杂的反思循环系统架构完全不同），分级有助于选择合适的技术路径。
  • 风险评估： 等级越高，系统的自主性越强，潜在的不可控风险（如幻觉、循环错误、安全漏洞）也越大。分级有助于制定相应的安全干预措施。
  • 衡量成熟度： 为行业提供了一个通用的标尺，用来评估不同 AI 产品的智能化程度。

4: 在构建高等级 Agent 时会遇到哪些主要挑战？

4: 在构建高等级 Agent 时会遇到哪些主要挑战？

A: 随着等级的提升，挑战从“理解意图”转向了“可靠执行”。主要挑战包括：

  • 循环与死锁： 高等级 Agent 具有自主性，可能会陷入逻辑循环或无法终止的任务中。
  • 幻觉累积： 在多步推理中，如果上一步出现微小错误，后续步骤可能会将其放大，导致最终结果完全偏离事实。
  • 调试难度： 传统的代码调试工具难以追踪 LLM 的非确定性输出路径，排查 Agent 的决策逻辑非常困难。
  • 上下文窗口限制： 长期任务和复杂的规划需要大量的记忆，如何高效管理上下文窗口是一个技术瓶颈。

5: Hacker News 社区对“Agentic Engineering”这一话题通常有哪些关注点？

5: Hacker News 社区对“Agentic Engineering”这一话题通常有哪些关注点？

A: Hacker News 作为一个技术导向的社区，对此类话题的讨论通常集中在：

  • 工程落地： 质疑当前的 LLM 是否真的具备支撑高等级 Agent 的可靠性，讨论“Demo 惊艳，生产环境拉胯”的现象。
  • 成本与延迟： 高等级 Agent 需要进行多次 LLM 推理调用，导致成本高昂且响应速度慢，讨论如何优化 Token 消耗。
  • 安全与对齐： 担忧赋予 AI 过高的自主权（如自动执行代码、发送邮件）可能带来的安全风险。
  • 过度炒作： 许多开发者会讨论这一概念是否是资本市场的“新瓶装旧酒”，以及它与传统的专家系统或自动化脚本的本质区别。

6: 普通开发者应该如何开始学习或实践 Agentic Engineering？

6: 普通开发者应该如何开始学习或实践 Agentic Engineering？

A: 建议从低层级向高层级逐步深入：

  1. 掌握基础： 熟悉 LangChain、LlamaIndex 或 AutoGen 等主流 Agent 开发框架。
  2. 从 Level 2 开始： 尝试构建一个能够连接外部 API（如天气查询或数据库查询）的简单应用，理解“工具调用”的机制。
  3. 学习提示词工程： 高效的 Agent 依赖于精准的 System Prompt 来约束行为。
  4. 引入记忆机制： 学习如何使用向量数据库赋予 Agent 长期记忆。
  5. 关注评估： 学习如何使用自动化评估工具（如 TruLens 或 Arize）来测试 Agent 的行为一致性，而不仅仅是测试准确率。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 构建一个基础的“单循环”智能体。该智能体需要接收一个自然语言查询（例如：“帮我查一下现在的天气”），将其转换为工具调用请求，并处理工具返回的结果以生成最终回复。请定义其核心的状态流转逻辑。

提示**: 思考一个标准的 ReAct（推理+行动）循环包含哪几个关键步骤？你需要明确如何将“用户输入”转换为“思考过程”，再转换为“行动指令”，最后如何处理“观察结果”。

引用

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

站内链接

相关文章