AI Agent 热潮下，我们是否忽略了最基础的工作流设计？-CSDN博客

本文链接：https://blog.csdn.net/2401_85325726/article/details/149327356

最近 Decoding ML 推出一篇文章《Stop Building AI Agents》，在海外平台引发了很多讨论。作者 Hugo Bowne-Anderson 曾给 Netflix、Meta 和美国空军的工程团队做 LLM 系统辅导，却劝大家“先别上代理”。

文章痛批很多团队一上来就给大模型加记忆、角色和工具，让模型自己调度工作流，结果越做越像多米诺骨牌，一推就倒。

他主张先用五种相对确定的模式：提示串联、任务并行、输入路由、总控-工人、评估-优化，这样九成都能落地，不必让 LLM 完全掌舵。

在这里插入图片描述

对于这篇文章的观点，首先谈下个人的一些关键结论。

即在AI通用智能体或者说完善的大模型+MCP生态没有发展起来的时候，AI Agent智能体开发还会存在相当长的一段时间。而就我们个人的观点和Decoding ML文章的思路基本上一样，核心仍然是能够不做AI Agent的就不做。

首先对于简单的Agent你完全没有必要做，很多简单的智能体本身连workflow可能都没有，仅仅是对提示语模板的一些规范化处理。其次对于复杂的智能体，现在已经不是简单的worklfow处理，而是融入了大量的规则处理，自定义脚本代码等，这些开发的智能体就是一个个信息孤岛，在后续的维护中简直就是一场巨大的灾难。

首先还是回答经典的这个Agent的图。可以看到Agent的核心包括了内容感知，规划计划分解，思维链和推理能力，外部工具调用，执行和长周期记忆能力。在这些能力里面实际上真正不好处理的能力只有两个。

其一是外部工具或资源的调用能力，但是这个问题我在前面已经讲过很多次了，随着MCP协议生态的不断发展，大模型可以接入满足MCP协议的各种外部资源或工具能力。大家也可以看到在Claude推出这个协议，包括Claude Desktop支持MCP后。类似当前的阿里千问，文心各种大模型都逐渐支持MCP调用。各种大模型资源聚合客户端，类似CherryStudio，Cursor，Trae等都完全支持MCP的调用。

这个跟我原来谈过的文章观点完全一样，就是Agent调用外部资源的能力是完全可以转移到大模型自身来完成的，大模型自身就提供了要给Agent的客户端，这个客户端就是一个通用的MCP Client可以调用接入的各种MCP Server提供的能力。再加上大模型本身深度思考，思维链模型的推出，大模型自身的思维链，深度推理也没有任何问题。这个也是问题文章里面谈到的基本用Augmented LLM（增强型大语言模型）就能够解决。

在这里插入图片描述

Augmented LLM的核心能力体现在突破传统语言模型的局限性，实现从单纯的文本生成向多功能智能代理的转变。其关键能力包括：工具集成，能够调用外部API、数据库、计算工具等，将静态知识转化为动态交互；实时信息获取，通过检索增强生成（RAG）技术访问最新知识库，解决知识截止和信息过时问题；多模态处理，整合文本、图像、音频等多种数据形式，提供更丰富的交互体验；推理增强，采用链式思考和多步骤分析，提升复杂问题的解决能力；代码执行，具备实时编程和数据分析功能，将理论转化为实践。这些能力的协同作用使Augmented LLM成为真正的通用人工智能助手，能够在各种场景中提供准确、及时、多样化的服务。

将提示词工程上升到上下文工程

那么接着Agent做的内容理解拆分，长上下文的理解，内容的组装排序，反馈循环这些事情能否也从Agent移出？这个正是我前面文章谈讲提示词工程升级到上下文工程要做的关键事情。

上下文工程是AI领域的新兴概念，它将"上下文"从单一提示扩展为包含七个维度的完整信息体系：系统指令、用户提示、对话历史、长期记忆、外部检索信息、可用工具和输出格式定义。这种方法的核心在于为大语言模型提供完成任务所需的全部信息和能力。

上下文工程具有四个显著特点。首先是系统性，它不依赖静态模板，而是通过动态系统生成上下文。其次是动态性，根据具体任务实时定制信息内容，一个请求可能需要日历数据，另一个可能需要邮件历史。第三是精准性，确保在正确时机提供正确信息和工具，避免信息过载或缺失。最后是格式敏感性，重视信息呈现方式，简洁摘要优于原始数据堆砌。

那么对于上下文工程和传统提示词工程的对比如下表：

在这里插入图片描述

接着我们再看下对于复杂问题上下文工程完整的处理流程如下图：

从上面的逻辑图，我们也可以看到上下文工程的核心组件包括了：

七个上下文维度 - 按照文章中提到的分类，用不同颜色区分
上下文聚合器 - 负责动态组装和优先级排序
智能处理流程 - 5个核心处理步骤
LLM核心 - 大语言模型的推理引擎
智能输出 - 最终的结构化结果
反馈循环 - 持续优化机制

所以看了前面的内容后，我的第一感觉就是上下文工程就是一种通用性的Agent，具备了复杂任务感知理解和拆分，任务规划和执行，长上下文记忆和存储，多轮反思和迭代，高度工程化和自主性等关键特点。

好了，讲到这里。再来看Agent还有一个较难以替代的地方，**我把它叫做精确规则和模糊规则的区别。**大家不要讲Agent的workflow简单理解为流程任务的编排，更加重要的是Agent首先了一个从模糊规则到精确规则的转化。

类似输入的数据是非结构化的，我需要进行结构化处理。类似我要提炼文本中的关键字段项去和API接口输入参数精确匹配然后精准调用API接口。类似在流程执行中间步骤还需要执行一个精确规则的算法逻辑等。这些东西确实是大模型当前最不擅长，也很难胜任的地方，导致这些东西都统一放到了Agent智能体里面来实现。

所以大家可以反过来想，不是AI Agent，而是应用程序增加了AI辅助的能力。AI Agent的本质就是一个应用程序，只是这个应用程序可以调用大模型的能力来对内容进行处理。其他的仍然是需要按应用程序精确的算法和流程进行处理。如果从这个角度来思考的话，AI Agent在通用智能体没有出来前仍然会存在相当长的一段时间。

所以现在的AI Agent已经没有你想的那么存粹，而更像是RPA+大模型能力的一个融合体。这就完成变成了当前企业已有的IT应用系统的一个外挂，游离在当前的整体IT系统架构之外，这个至少从企业应用的角度完全是不能接受的。包括我原来对RPA有专门的评论，即RPA只是传统遗留IT系统无法开发底层API而被迫折中出来的一个产物。

因此从前面的讨论我们基本就清楚了两个关键思路。

其一：不涉及到精确算法，精确规则，精确步骤处理的场景，都不需要用Agent去实现。直接用大模型+MCP+上下文工程的思路大部分问题都能够解决。而且要注意自己提示词的结构化处理，方便后续管理和维护。

其二：就是涉及到精确处理的场景，**不是去做大量的信息孤岛的Agent，而是应该在当前已有的IT应用整体架构，技术架构上纳入大模型技术底座的能力，将大模型的能力作为API开放给上层IT系统使用。**那么你不应该去开发一个个独立的Agent，而是对当前已有的IT系统功能进行新增或优化变更，你新增的功能是自然融入到当前整体IT应用架构的，而不是游离在外面的要给孤岛。、