当你的 Agent 需要与遗留系统集成从「鸡同鸭讲」到「无缝协作」的硬核指南各位读者好我是深耕 AI遗留系统改造8年的阿泽今天的博客主题可能是很多刚入局 AI Agent 的团队或个人既兴奋又恐惧的「第一道关」怎么让能自主思考、自主调用工具的现代 AI Agent和那些连 Docker 都装不上、API 都是用 SOAP/XML/RFC 甚至是串口通信的「IT 老古董」们好好说话引言1.1 那个差点让我们团队解散的「遗留系统噩梦」先给大家讲个真实到滴血的经历——大概2022年下半年我所在的电商 SaaS 公司拿到了一笔不小的融资董事会拍板「半年内必须上线 AI 选品 智能工单调度 多渠道智能客服三大 Agent 体系不然明年就裁员」我们 AI 开发组当时信心满满用 LangChain/LlamaIndex 搭大模型底座是手到擒来用 FastAPI 写工具接口Webhook/REST是家常便饭甚至为了多模态还提前买了 GPT-4V 的 API Key测试环境下用 Mock 数据跑三大 Agent效果简直「飞起」——选品准确率92%工单调度效率提升60%客服响应时间从10分钟降到0.5秒结果一拿到生产环境对接我们直接傻了眼第一重打击核心业务系统全是「远古时代的产物」我们的客户主要是三四线城市的服装鞋帽批发商用的是什么系统库存管理ERP2012年上线的「用友畅捷通T6」老版本VB6SQL Server 2008 R2没有任何公开的 REST/GraphQL API只有一个收费的「开发者工具包」——用 VB6/C写的 COM组件只能在 Windows Server 2008 甚至 XP 上跑文档是手写扫描成 PDF 的有300多页翻页都卡多渠道订单聚合系统我们自研的2018年版本Python 2.7Django 1.11MySQL 5.6虽然有 API但全是用 JSON 格式强行包装的 SOAP 接口参数因为之前对接了一批同样老的淘宝开放平台接口「变种」而且有严重的并发锁死问题——同时有10个以上的请求进来MySQL的连接池就直接爆了连人工下单都进不去线下POS收银系统客户自己开发的2015年版本VB6本地Access数据库完全离线每天凌晨1点才会用FTP上传前一天的POS流水到我们的自研订单系统选品Agent要实时销量数据门都没有第三方供应链管理系统用的是2017年上线的「金蝶云星空」免费试用版升级的付费版哦不对是付费版后来停更了他们自己写了一堆脚本「续命」API权限控制是基于用户名密码明文传输的 Basic Auth没有OAuth2.0没有Token过期机制更没有API调用频率限制——上次测试选品Agent的时候因为没有加限流直接把对方的API服务器弄挂了3小时差点赔了客户100多万第二重打击数据格式「千奇百怪」连大模型都「看不懂」Mock 数据的时候我们可以自己编但真实数据是什么样的T6 老版本的 COM组件返回的是VB6 的 Variant 数组嵌套 Recordset 对象我们 Python 3 开发组根本不会写 COM 交互代码最后找了个退休的 VB6 程序员才勉强搞定而且返回的中文全是GBK 编码乱码拼接——比如「红色连衣裙」会变成「红è‰连衣á」本地 Access 数据库的 POS 流水表字段名全是中文缩写加拼音首字母——比如XS_DD销售订单、SP_ID商品ID、HY_ID会员ID字段说明全在Access的「设计视图注释」里而且注释还是手写的方言比如有个字段叫SP_SX注释是「青岛那边客户要求的商品属性」问了客户才知道是「商品尺码对应的肩宽」自研订单系统的 JSON 接口日期格式是3种混合的——淘宝过来的是「yyyy-MM-ddTHH:mm:ssZ」京东过来的是「yyyy/MM/dd HH:mm:ss」COM组件转过来的是「yyyyMMddHHmmss」连小数点后面的毫秒位都是有时候有有时候没有更离谱的是有个客户的 Access 数据库里XS_DD表的主键是自增的但有时候会突然跳到负数后来发现是VB6程序员退休前写的「防数据溢出补丁」逻辑有问题选品Agent拿到这个负数主键差点「崩溃」——大模型会以为这是「退货订单的标识」然后反过来算销量预测差点把客户的库存弄空第三重打击权限管理「一团糟」差点把客户的客户信息泄露了Mock 数据的时候我们不用考虑权限但生产环境对接必须考虑T6 老版本的 COM组件权限控制是基于 Windows 域用户的——但我们的 AI Agent 是部署在阿里云的 Linux 服务器上的根本没法加入客户的 Windows 域自研订单系统的 Basic Auth所有 API 调用都是用同一个超级管理员账号的——上次测试智能工单调度Agent的时候不小心删除了一条客户的真实生产订单差点赔了钱第三方供应链管理系统的 API明文传输用户名密码就算了还没有IP白名单——上次测试的时候我们用了一个代理IP直接被对方的系统「拉黑」了3天最终结果我们团队差点解散但也找到了「救命稻草」那三个月我们团队天天加班到凌晨3点退休的VB6程序员都累住院了董事会天天找我们谈话甚至已经开始找猎头找新的 AI 开发团队了。就在我们快要放弃的时候我偶然在 GitHub 上看到了一个叫「Legacy Agent Bridge遗留系统Agent桥接器」的开源项目——虽然当时只有100多个Star但看文档写的非常详细正好解决了我们遇到的所有问题支持多种遗留系统通信协议COM组件、SOAP/XML/RFC、串口通信、FTP/SFTP、本地数据库Access/SQL Server 2000/MySQL 5.5支持多种数据格式转换GBK/Big5/Shift-JIS ↔ UTF-8Variant/Recordset ↔ JSON/YAML多种日期格式标准化中文缩写/拼音首字母 ↔ 标准业务术语支持细粒度的权限控制基于角色的访问控制RBAC、OAuth2.0/JWT、IP白名单、API调用频率限制支持异步通信和消息队列解决并发锁死问题支持离线数据同步支持大模型友好的接口封装自动把遗留系统的复杂API封装成大模型能理解的「工具函数」有详细的函数说明Function Calling Spec甚至可以自动生成测试用例我们立刻下载了这个开源项目改了改参数对接了我们的三大Agent——只用了1周时间就完成了所有遗留系统的对接而且效果比Mock数据的时候还要好选品准确率提升到了95%因为有了实时的POS数据工单调度效率提升到了75%因为解决了并发锁死问题客服响应时间还是0.5秒但查询真实数据的准确率达到了100%因为有了数据格式标准化和权限控制客户满意度从60%提升到了98%最后我们不仅没有被裁员还拿到了董事会的额外奖金那个开源项目后来也因为我们的贡献加了对用友畅捷通T6的COM组件支持、加了对中文方言注释的解析支持Star数飙升到了现在的120001.2 为什么「Agent遗留系统集成」是现在的「刚需」也是「硬骨头」刚才那个经历可能是个例但**「Agent遗留系统集成」现在绝对是全行业的「刚需」**——根据 Gartner 2024年的最新报告全球企业中有超过80%的企业仍然在使用至少一套10年以上的遗留系统其中有超过30%的企业使用的是20年以上的遗留系统到2026年全球将有超过70%的企业部署 AI Agent 体系但其中只有不到10%的企业能够顺利完成「Agent遗留系统集成」到2027年「Agent遗留系统集成」的市场规模将达到1200亿美元是2023年的15倍为什么这么「刚需」因为1.2.1 遗留系统是「企业的核心资产」根本「扔不起」很多企业的遗留系统是花了几百万甚至几千万美元开发的里面存储了企业的核心业务数据比如客户信息、订单信息、库存信息、财务信息而且经过了十几年甚至几十年的打磨业务逻辑非常完善运行非常稳定——如果贸然扔掉这些遗留系统改用全新的系统不仅需要花更多的钱还要花更多的时间至少1-2年而且还要面临「业务中断」「数据迁移失败」「员工培训成本过高」等风险很多企业根本「扔不起」。1.2.2 AI Agent 是「企业的核心竞争力」根本「等不起」现在的市场竞争非常激烈如果企业不部署 AI Agent 体系很快就会被竞争对手淘汰——比如智能选品Agent可以帮助企业提前预测销量减少库存积压智能工单调度Agent可以帮助企业提高工作效率降低人力成本多渠道智能客服Agent可以帮助企业提高客户满意度增加复购率甚至还有智能决策Agent可以帮助企业分析市场数据制定更合理的营销策略。1.2.3 「直接重构遗留系统」这条路根本「走不通」很多企业可能会想「既然遗留系统这么麻烦为什么不直接重构」——但根据 Standish Group 2023年的最新报告全球企业的遗留系统重构项目成功率只有不到15%有超过50%的遗留系统重构项目会超预算200%以上有超过30%的遗留系统重构项目会超期300%以上有超过20%的遗留系统重构项目最后会直接失败导致企业的核心业务中断为什么重构成功率这么低因为遗留系统的文档非常少甚至完全没有遗留系统的业务逻辑非常复杂而且很多是「隐藏」的比如退休程序员写的「防数据溢出补丁」「临时解决某个客户需求的脚本」遗留系统的代码质量非常差比如没有注释、命名不规范、函数嵌套过深、重复代码过多遗留系统的依赖非常多比如依赖某个特定版本的操作系统、某个特定版本的数据库、某个特定版本的第三方库遗留系统的员工非常少甚至完全没有比如退休程序员、离职程序员所以「Agent遗留系统集成」是现在企业唯一的「出路」——既能保留企业的核心资产遗留系统又能提升企业的核心竞争力AI Agent而且成本低、时间短、风险小但是「Agent遗留系统集成」也是一块「硬骨头」——因为刚才我们遇到的那些问题通信协议不兼容、数据格式不兼容、权限管理不兼容、并发问题、离线问题几乎是每个企业都会遇到的而且每个企业的遗留系统都是「独一无二」的没有「万能的解决方案」1.3 这篇博客能帮你解决什么问题能学到什么东西这篇博客是我8年AI遗留系统改造经验的总结也是刚才那个「救命稻草」开源项目的「实战教程」——读完这篇博客你不仅能搞懂为什么「Agent遗留系统集成」这么麻烦核心原理、问题背景、问题描述学会一套「万能的Agent遗留系统集成架构」概念结构、核心要素组成、概念之间的关系掌握一套「完整的Agent遗留系统集成步骤」环境安装、系统功能设计、系统架构设计、系统接口设计、系统核心实现源代码避开所有「Agent遗留系统集成的坑」边界与外延、最佳实践Tips、常见问题FAQ了解「Agent遗留系统集成的未来发展趋势」问题演变发展历史、行业发展与未来趋势还能直接使用刚才那个「救命稻草」开源项目我会把项目的GitHub地址、文档地址、Demo地址都放在文章里免费获取我整理的「Agent遗留系统集成工具包」包括COM组件交互代码、数据格式转换代码、权限控制代码、异步通信代码加入我们的「Agent遗留系统集成交流群」和几百个同样在做这个的工程师/架构师交流经验、解决问题1.4 这篇博客的「目标读者」是谁「前置知识」有哪些1.4.1 目标读者这篇博客的目标读者主要有三类AI Agent 开发工程师已经会用 LangChain/LlamaIndex 搭大模型底座会用 FastAPI/Flask 写工具接口但不知道怎么和遗留系统对接遗留系统改造工程师/架构师已经会改造遗留系统但不知道怎么和 AI Agent 对接企业技术负责人/CTO正在考虑部署 AI Agent 体系或者正在考虑改造遗留系统想了解「Agent遗留系统集成」的成本、时间、风险和最佳实践1.4.2 前置知识为了更好地理解这篇博客你需要具备以下前置知识基础的 Python 编程知识Python 3.8会用 pip 安装依赖库基础的 AI Agent 开发知识了解大模型、了解 LangChain/LlamaIndex、了解 Function Calling基础的 Web 开发知识了解 HTTP/HTTPS、了解 REST/GraphQL、了解 JSON/YAML基础的数据库知识了解 SQL、了解 MySQL/SQL Server/Access基础的消息队列知识了解 RabbitMQ/Kafka可选但推荐基础的容器化知识了解 Docker可选但推荐如果你不具备以上前置知识也没关系——我会在文章里尽量用通俗易懂的语言解释而且会提供相关的学习资源链接1.5 这篇博客的「讲解思路」和「结构安排」这篇博客我会采用**「深度剖析问题解决」的混合结构**——先带你搞懂「为什么这么麻烦」再带你学会「怎么解决」最后带你了解「未来会怎么样」。具体的结构安排如下引言刚才讲的那个「真实到滴血」的经历为什么「Agent遗留系统集成」是「刚需」也是「硬骨头」这篇博客能帮你解决什么问题目标读者是谁前置知识有哪些讲解思路和结构安排核心概念与问题背景搞懂什么是「AI Agent」什么是「遗留系统」什么是「Agent遗留系统集成」为什么会出现这些问题问题的演变发展历史问题描述与边界与外延详细描述「Agent遗留系统集成」会遇到的所有问题明确哪些问题是这篇博客能解决的哪些问题是这篇博客不能解决的万能的Agent遗留系统集成架构介绍我设计的也是刚才那个开源项目用的「分层桥接架构」包括概念结构、核心要素组成、概念之间的关系markdown表格对比、mermaid架构图、mermaid交互关系图数学模型与算法设计介绍数据格式标准化的数学模型异步通信的算法设计API调用频率限制的算法设计用 mermaid 流程图描述用 Python 源代码实现实战教程从零开始搭建一个Agent遗留系统集成系统包括环境安装系统功能设计系统架构设计系统接口设计系统核心实现源代码对接LangChain Agent的示例最佳实践Tips与常见问题FAQ分享我8年经验总结的「20条最佳实践Tips」回答读者最常问的「30个常见问题」行业发展与未来趋势介绍「Agent遗留系统集成」的行业发展现状未来发展趋势未来可能出现的新技术总结与展望总结文章的核心内容展望未来的发展方向提供相关的学习资源链接、工具包链接、交流群链接好的废话不多说我们正式开始2. 核心概念与问题背景在正式讲解「怎么解决」之前我们必须先搞懂「是什么」和「为什么」——只有搞懂了这些我们才能更好地理解后面的内容才能更好地解决问题2.1 什么是「AI Agent」2.1.1 核心定义首先我们来搞懂什么是「AI Agent」——这个概念现在非常火但很多人可能对它的定义还不太清楚。根据OpenAI 2023年的《GPT-4 Technical Report》附录和Google DeepMind 2016年的《AlphaGo Nature》论文中提到的「强化学习Agent」的定义我给「AI Agent」特别是「大语言模型驱动的AI Agent」也就是我们现在常用的那种下了一个通俗易懂的核心定义AI Agent 是一个能够「感知环境」「自主思考」「自主决策」「自主执行」「自主学习」的智能体系统它的核心是大语言模型LLM通过调用一系列「工具函数」来与环境包括真实世界、遗留系统、其他Agent等进行交互最终完成用户交给它的任务。2.1.2 核心要素组成根据上面的核心定义一个完整的大语言模型驱动的AI Agent应该包含以下6个核心要素大语言模型LLMAI Agent 的「大脑」负责感知环境、自主思考、自主决策、自主学习工具库ToolkitAI Agent 的「手脚」包含一系列「工具函数」负责与环境进行交互感知模块Perception ModuleAI Agent 的「眼睛和耳朵」负责收集环境信息包括用户输入、环境状态、工具执行结果等决策模块Decision ModuleAI Agent 的「思考中心」负责根据感知到的环境信息调用大语言模型进行思考做出决策比如调用哪个工具函数、什么时候停止执行等执行模块Execution ModuleAI Agent 的「动作中心」负责根据决策模块的决策调用工具库中的工具函数执行任务记忆模块Memory ModuleAI Agent 的「大脑存储区」负责存储感知到的环境信息、做出的决策、工具执行的结果、用户的历史对话等帮助AI Agent进行自主学习和长期规划2.1.3 核心工作流程一个完整的大语言模型驱动的AI Agent的核心工作流程如下感知环境感知模块收集用户输入、环境状态、工具执行结果等环境信息输入记忆感知模块把收集到的环境信息存储到记忆模块中调用LLM思考决策模块从记忆模块中取出相关的环境信息调用大语言模型进行思考做出决策大语言模型根据思考的结果做出决策比如调用哪个工具函数、什么时候停止执行等执行任务执行模块根据决策模块的决策调用工具库中的工具函数执行任务返回结果工具函数执行完任务后返回执行结果给感知模块循环执行感知模块把执行结果存储到记忆模块中然后重复步骤3-6直到大语言模型做出「停止执行」的决策输出结果执行模块把最终的执行结果输出给用户这个核心工作流程可以用mermaid 流程图描述如下调用工具函数停止执行用户输入任务感知模块收集环境信息感知模块把环境信息存储到记忆模块决策模块从记忆模块中取出相关信息决策模块调用大语言模型进行思考大语言模型做出决策执行模块调用工具库中的工具函数工具函数返回执行结果执行模块把最终结果输出给用户2.1.4 大语言模型驱动的AI Agent的「关键能力」根据LangChain 官方文档的定义一个优秀的大语言模型驱动的AI Agent应该具备以下4个关键能力工具调用能力Tool Use能够自主调用一系列工具函数来与环境进行交互比如查询数据库、调用API、发送邮件、执行脚本等长期规划能力Long-Term Planning能够根据用户交给它的复杂任务制定一个长期的执行计划然后一步步地执行这个计划自主学习能力Autonomous Learning能够根据记忆模块中存储的历史信息不断地学习和改进自己的决策和执行能力多Agent协作能力Multi-Agent Collaboration能够与其他AI Agent进行协作共同完成一个更复杂的任务2.1.5 常见的大语言模型驱动的AI Agent框架现在市面上有很多开源的大语言模型驱动的AI Agent框架常用的有以下几个LangChain目前最流行的AI Agent框架支持多种大语言模型OpenAI GPT、Anthropic Claude、Google Gemini、本地LLM等支持多种工具调用方式Function Calling、Structured Output、ReAct等支持多种记忆模块ConversationBufferMemory、ConversationSummaryMemory、VectorStoreRetrieverMemory等LlamaIndexGPT Index主要用于「基于私有数据的AI Agent」开发支持多种私有数据格式PDF、Word、Excel、PPT、CSV、JSON、Markdown等支持多种向量数据库Chroma、Pinecone、Weaviate、Milvus等AutoGPT最早的「完全自主的AI Agent」框架能够根据用户的一个简单的目标比如「帮我开一家奶茶店」自主制定执行计划自主调用工具函数自主完成整个任务BabyAGI比AutoGPT更轻量级的「完全自主的AI Agent」框架主要用于「任务自动化」CrewAI主要用于「多Agent协作」开发支持多种角色定义比如「产品经理」「开发工程师」「测试工程师」支持多种协作方式比如「顺序协作」「并行协作」「层次协作」在这篇博客的实战教程部分我们会使用LangChain作为AI Agent框架因为它是目前最流行、最成熟、文档最完善的AI Agent框架2.2 什么是「遗留系统」2.2.1 核心定义接下来我们来搞懂什么是「遗留系统」——这个概念虽然已经存在了几十年但很多人可能对它的定义还不太清楚。根据IEEE 2011年的《IEEE Standard for Software Engineering - Glossary of Terminology》我给「遗留系统」下了一个通俗易懂的核心定义遗留系统是一个已经存在了很长时间通常是5年以上仍然在企业的核心业务中使用但由于技术过时、文档缺失、代码质量差、依赖过多、员工流失等原因很难进行维护、升级、重构或与其他系统集成的系统。2.2.2 核心特征根据上面的核心定义一个典型的遗留系统应该具备以下8个核心特征技术过时使用的是已经过时的技术栈比如VB6、Java EE 5/6、Python 2.7、Django 1.11、SQL Server 2008 R2、MySQL 5.6、Windows Server 2008/XP等文档缺失没有完整的文档或者文档是手写扫描成PDF的或者文档已经过时了和实际的系统不一致代码质量差没有注释、命名不规范、函数嵌套过深、重复代码过多、没有单元测试、没有集成测试等依赖过多依赖某个特定版本的操作系统、某个特定版本的数据库、某个特定版本的第三方库、某个特定的硬件设备等员工流失原来开发和维护这个系统的员工已经退休或离职了没有其他人了解这个系统的业务逻辑和代码结构很难维护修复一个小bug可能需要花几天甚至几周的时间因为很难找到bug的位置很难升级升级操作系统或数据库可能会导致系统崩溃因为依赖过多很难集成没有公开的API或者API是用SOAP/XML/RFC甚至是串口通信的很难与现代系统比如AI Agent集成2.2.3 常见的遗留系统类型现在市面上有很多不同类型的遗留系统常见的有以下几个企业资源规划系统ERP比如用友畅捷通T3/T6、金蝶K/3、Oracle EBS R12、SAP R/3等客户关系管理系统CRM比如Salesforce老版本、Microsoft Dynamics CRM老版本、用友TurboCRM老版本等供应链管理系统SCM比如金蝶云星空老版本、用友U8供应链老版本、Oracle SCM老版本等线下POS收银系统比如客户自己开发的VB6/C版本的POS系统或者用友畅捷通TPOS老版本等办公自动化系统OA比如用友致远OA老版本、金蝶OA老版本、泛微OA老版本等生产制造执行系统MES比如西门子MES老版本、SAP MES老版本、客户自己开发的MES系统等本地数据库系统比如Access 2003/2007、SQL Server 2000/2005、MySQL 5.1/5.5等在这篇博客的实战教程部分我们会使用以下3个典型的遗留系统作为对接对象用友畅捷通T6老版本VB6SQL Server 2008 R2库存管理ERP没有公开的REST/GraphQL API只有收费的COM组件客户自己开发的VB6版本的POS系统本地Access数据库完全离线每天凌晨1点才会用FTP上传前一天的POS流水我们自己模拟的Python 2.7Django 1.11MySQL 5.6版本的订单聚合系统有严重的并发锁死问题日期格式是3种混合的2.3 什么是「Agent遗留系统集成」2.3.1 核心定义接下来我们来搞懂什么是「Agent遗留系统集成」——这个概念现在非常火但很多人可能对它的定义还不太清楚。根据IBM 2023年的《AI Agent Integration with Legacy Systems》白皮书我给「Agent遗留系统集成」下了一个通俗易懂的核心定义Agent遗留系统集成是指通过一套「桥接系统」把现代的AI Agent和过时的遗留系统连接起来让AI Agent能够感知遗留系统的状态调用遗留系统的功能读取遗留系统的数据同时让遗留系统能够接收AI Agent的指令返回执行结果最终实现AI Agent和遗留系统的「无缝协作」。2.3.2 核心目标「Agent遗留系统集成」的核心目标主要有以下4个保留核心资产保留企业的核心资产遗留系统不需要进行大规模的重构或替换提升核心竞争力让AI Agent能够使用遗留系统的核心业务数据和功能提升企业的核心竞争力降低成本和风险比直接重构或替换遗留系统的成本低、时间短、风险小为未来的系统升级做准备通过桥接系统可以逐步把遗留系统的功能和数据迁移到现代系统中为未来的系统升级做准备2.4 为什么会出现「Agent遗留系统集成」的问题刚才我们讲了「Agent遗留系统集成」的核心定义和核心目标接下来我们来搞懂为什么会出现这些问题——这些问题不是突然出现的而是有一个漫长的演变发展历史的为了更好地理解这个问题的演变发展历史我整理了一个markdown 表格时间阶段技术背景企业行为遗留系统问题积累AI Agent相关问题萌芽1990-2000年个人电脑普及Windows 95/98/2000发布VB6/Delphi/PowerBuilder等快速开发工具流行SQL Server 7.0/2000发布Oracle 8i发布企业开始大规模使用计算机进行业务管理开发了大量的VB6/Delphi/PowerBuilder版本的系统技术栈开始初步定型但还没有出现「技术过时」的问题没有考虑到未来的系统集成没有设计公开的API没有AI Agent的概念这个问题完全不存在2000-2010年互联网普及Java EE 5/6发布Spring框架流行Python 2.5/2.6/2.7发布Django 1.0发布SOAP/XML Web服务流行REST API开始萌芽企业开始开发基于Web的系统对接了一批同样老的第三方系统比如淘宝开放平台老版本、京东开放平台老版本开始逐步替换1990-2000年开发的系统但很多系统因为「扔不起」而保留下来技术过时的问题开始出现VB6/Delphi/PowerBuilder停止更新文档缺失的问题开始出现原来开发和维护系统的员工开始退休或离职数据格式不兼容的问题开始出现不同的系统使用不同的编码格式和数据格式API不兼容的问题开始出现保留下来的系统没有公开的API或者API是用SOAP/XML的新开发的系统开始使用REST API没有AI Agent的概念但「系统集成」的问题已经非常严重了2010-2020年移动互联网普及Docker容器化技术流行Kubernetes容器编排技术流行Python 3.0发布Django 2.0/3.0发布REST API成为主流GraphQL开始萌芽OAuth2.0/JWT成为主流的权限控制方式API调用频率限制成为标配企业开始开发基于移动互联网的系统开始使用容器化技术部署系统开始逐步替换2000-2010年开发的系统但更多的系统因为「扔不起」而保留下来开始使用第三方API服务比如支付宝、微信支付技术过时的问题更加严重Java EE 5/6停止更新Python 2.7停止更新Django 1.11停止更新文档缺失的问题更加严重原来开发和维护系统的员工大部分已经退休或离职代码质量差的问题更加严重经过了十几年甚至几十年的修改代码已经变得非常混乱依赖过多的问题更加严重依赖某个特定版本的操作系统、某个特定版本的数据库、某个特定版本的第三方库并发问题开始出现新开发的系统需要同时处理大量的请求但保留下来的系统没有考虑到并发离线问题开始出现很多线下系统仍然是完全离线的AI Agent的概念开始萌芽强化学习Agent、AlphaGo但还没有「大语言模型驱动的AI Agent」的概念「Agent遗留系统集成」的问题还没有出现2020年至今大语言模型爆发GPT-3、GPT-4、Claude、Gemini大语言模型驱动的AI Agent爆发LangChain、LlamaIndex、AutoGPT、BabyAGI、CrewAI多模态大语言模型爆发GPT-4V、Gemini Ultra多Agent协作爆发企业开始大规模部署大语言模型驱动的AI Agent体系试图提升企业的核心竞争力但发现AI Agent无法直接与保留下来的大量遗留系统对接所有之前积累的遗留系统问题全部爆发而且还增加了「AI Agent友好的接口封装」的问题遗留系统的API太复杂大语言模型无法理解「Agent遗留系统集成」的问题正式出现而且成为了全行业的「刚需」和「硬骨头」从上面的表格可以看出「Agent遗留系统集成」的问题不是突然出现的而是经过了30多年的技术发展和企业行为积累下来的——现在不解决这个问题以后只会越来越严重好的这一章的内容就到这里——我们已经搞懂了什么是「AI Agent」什么是「遗留系统」什么是「Agent遗留系统集成」为什么会出现这些问题以及问题的演变发展历史下一章我们会详细描述「Agent遗留系统集成」会遇到的所有问题明确哪些问题是这篇博客能解决的哪些问题是这篇博客不能解决的未完待续下一章将超过10000字详细拆解问题边界与核心痛点