传统企业应用系统接入 AI 能力的实践与应用
前段时间，我们团队把一个接口管理平台ApiGo的 AI 助手 推倒重做了一遍。重做的直接原因，是第一版做砸了，用户用了两次就再也不碰那个对话框。
但正是这一轮"先踩坑、再回头"的经历，让我对"传统企业系统怎么接入 AI"这件事有了些具体的认识。市面上讲 AI 的文章很多，讲 Agent 框架、RAG、MCP 协议的比比皆是，但站在一个跑了多年、功能已经堆得很厚的业务系统维护者的角度，真正的难题从来不是"选哪个框架"，而是：从哪儿下手、下多深、怎么收住。
一、传统系统的困局：功能越全，越没人会用
做过古法系统的人应该都有体会：一个大型的企业应用系统的开发通常两年起算，需求一版一版加，菜单从最初的十几个膨胀到上百个入口，每个页面塞着几十个表单项。功能是全了，但代价很实在：
- 操作路径越来越深。 拿我们的平台举例，创建一个数据接口，要先选数据源、翻库表结构、手写 SQL、做语法校验、选分组、填一堆信息再保存。熟练的人五六分钟，新员工不照着文档走根本找不到北。
- 培训成本压不下来。 每年新人入职，光"这个系统怎么用"的培训就要占掉好几天，而其中八成内容是"在哪个菜单、点哪个按钮"。
- 同一个东西，每个人叫法不一样。 有人管"发布"叫"上线"，有人管"凭证"叫"密钥"，用户内部口口相传的词汇和系统术语永远对不上。
然后 AI 的浪潮来了。老板在饭桌上听人说"以后软件都不用界面了，一句话搞定"，回来就要求"我们系统也要有 AI"。
于是很多团队开始乱试：有的套了个聊天窗接大模型 API，用户问"帮我建个接口"，AI 一本正经地回答"请您点击左侧菜单第四项"——把一个聊天机器人塞进系统，除了演示时好看，没人真的用；有的激进一点，直接让 AI 自主操作系统，demo 惊艳全场，一周后在生产环境误删了东西，项目悄悄下线。
这大概是过去两年企业软件圈最普遍的窘境：不做 AI 怕被淘汰，做了 AI 怕出事故，做了个摆设又没意义。
二、行业主流的四种接入方式，各自适合谁
冷静下来看，目前企业系统接 AI，主流路线就四条。它们不是互斥的，但选型之前最好想清楚自己系统的形态。
路线一：RAG 知识问答型。 把帮助文档、操作手册、FAQ 灌进向量库，界面上挂一个聊天窗，AI 负责"回答怎么操作"。这是门槛最低的方案——不碰业务代码，两三周就能上线，最坏的结果也就是答非所问，不会弄坏数据。但它有个先天短板：只动嘴，不动手。对操作密集型系统来说，用户问"帮我创建接口"，得到一段操作指南，还是得自己去点鼠标。它适合替代帮助中心和客服，适合制度问答，不适合真正替用户干活。
路线二：全能 Agent 型。 把系统所有功能包装成工具（Function Calling 或 MCP），交给一个通用 Agent，模型自己理解任务、自己规划步骤、自己决定调哪个工具。这是理论上限最高的路线——一句话端到端，架构讲出来也漂亮。但它的代价是不确定性：同一句话两次执行的路径可能不同，出问题几乎没法复现；写操作风险敞口全开；每次模型调用都拖着全量工具的 schema，token 成本居高不下。它适合探索型任务和只读场景，风险承受度高的内部工具可以试。
路线三：页面嵌入型。 不做全局对话，而是在页面内嵌一个小助手，感知当前页面上下文（用户在哪、选中了什么），做填表辅助、操作建议、单点执行。上下文明确是它最大的优点——不用猜用户在说什么；动作范围天然收窄，安全好控。缺点是开发分散，几十个页面就是几十个入口，覆盖不全，用户依然要在页面间穿行。重表单的 ERP、CRM 类系统适合走这条路渐进改造。
路线四：场景编排型。 把系统里的高频任务抽象成有限个"场景"，每个场景预先定义好步骤流程；模型只在入口做语义理解（判断用户想做哪个场景、提取出参数），个别生成类步骤（比如写 SQL）交给模型，其余流程由代码确定性执行。它的好处是可控、可测试、写操作天然有确认点，token 成本能算得清清楚楚。代价是前期设计投入大，且场景之外的诉求需要兜底方案。它特别适合功能边界清晰、操作链路固定的企业系统——而绝大多数跑了十年的业务系统，恰好就是这个样子。
| 路线 | 接入成本 | 可控性 | 能否替用户操作 | 适合的系统 |
|---|---|---|---|---|
| RAG 问答 | 低 | 高 | 否 | 帮助中心、制度问答 |
| 全能 Agent | 中 | 低 | 是 | 探索型、只读、内部工具 |
| Copilot 嵌入 | 高（分散） | 中 | 部分 | 重表单系统 |
| 场景编排 | 中（前期重） | 高 | 是 | 功能边界清晰的企业系统 |
我们最初选的是路线二，摔了跟头之后，最终落在了路线四，保留一个收窄版的路线二做兜底。下面展开讲讲这段过程。
三、第一次尝试：把所有功能都交给模型，然后翻车了
第一版的做法现在看很典型：把平台的好几十多个业务功能（接口的创建、发布、下线，数据源的增改，调用日志查询，元数据探查……）全部注册成工具，后端跑一个 ReAct 循环，让模型自主规划、自主调用。演示效果很好——"帮我建一个查询订单的接口"，它真的能跌跌撞撞走完全程。
上线后不到一个月，三个故障把这条路判了死刑：
一是协议性报错。 模型偶尔在一条消息里返回多个工具调用，循环代码在第一个需要用户确认的地方中断，剩下的调用永远等不到响应，下一轮对话直接 400 报错。这种问题的荒诞之处在于：它不是逻辑 bug，是让模型自己决定流程之后，你根本枚举不完它所有可能的走法。
二是伪流式卡死。 后端把整个循环跑完才一次性吐出结果，链路一长就超过网关 60 秒超时，前端转圈到天荒地老。用户只能刷新页面，然后发现这轮对话卡死了，连重新发送都不行。
三是多轮失忆。 第二轮说"把它发布上线"，AI 一脸茫然——因为重建上下文时只保留了对话文本，上一轮创建了哪个接口、选了哪个数据源，全丢了。它开始现场编造接口 ID。
复盘下来，根因其实只有一个：我们让模型做了它不擅长的事——流程决策。 模型擅长的是理解语言、提取信息、生成内容；不擅长的是在十几步的操作链路里，每一步都做出确定、可靠、可复现的决策。让模型管流程，等于把系统的稳定性押在一个概率引擎上。
顺带一提，这一版的 token 消耗也很惊人：每次模型调用都带着二十多个工具的完整定义，一轮任务十几次模型往返，成本降不下来，速度也快不了。
四、换一条路：把决策权从模型手里拿回来
重设计的核心思想一句话就能说完：流程归代码，语义归模型。
我们把平台的高频任务梳理成七个预定义场景——创建接口、测试接口、发布/下线、数据源管理、调用凭证、日志查询、数据问数。每个场景用一份配置描述清楚：触发词是什么、需要收集哪些参数（槽位）、步骤按什么顺序走、哪一步需要用户确认。比如"创建接口"场景，流程天然就是"选数据源 → 探查库表元数据 → 生成 SQL → 语法校验 → 确认 → 保存 → 交付草稿"这五步，这个顺序是确定的，不需要模型发挥。
模型在这个架构里的职责被收窄到四件事：听懂话（用户这句话对应哪个场景）、填参数（从话语和会话状态里提取出数据源、接口名这些槽位）、写 SQL（基于元数据生成脚本，这是模型真正擅长的）、说人话（解释执行结果、追问缺失信息）。
几个实践中很关键的设计，值得单独说：
路由分层，高频指令根本不过模型。 第一层是词典精确匹配——"发布它""查日志"这类明确指令，同义词表命中就直接路由，零模型开销；词典没命中才走第二层，让模型做一次轻量分类，顺便把槽位一次性提取完；短指令和代词（"发布它"里的"它"）走第三层场景亲和，直接从上一轮的操作记录里解析实体。三层下来，高频路径几乎不需要模型参与理解。
写操作必须有闸门。 所有改动类动作在执行前挂起，弹出确认卡片，用户点确认后才真正落库。确认动作用原子方式消费，用户手抖双击也只会执行一次；确认超时自动收尾并告知"操作已取消"，不会把一轮对话永久悬在那里。这是把 AI 操作放进生产环境的底线。
成本靠工程手段压，不靠"换便宜模型"。 场景内只暴露 3~6 个相关工具的定义，而不是全量二十多个，prompt 体积直接降了六成以上；系统提示和场景模板固定在 prompt 前缀不动，会话动态内容后置，最大化命中模型厂商的前缀缓存折扣——缓存命中部分的计费大约是十分之一；多轮对话的中间轨迹折叠成一行事实回填（"上一轮已创建接口'订单查询'，草稿状态"），而不是把原始工具调用消息全部塞回去，长会话不膨胀，还顺带解决了上下文污染。
观测先行。 每一轮对话的场景命中方式、每次模型调用的 token 和耗时、每个工具的执行时长、失败原因分类，全部落库。前端每条消息带一个轻量徽标显示这轮花了多少 token、多少秒；展开还能看到完整执行链路——场景怎么命中的、AI 每一步做了什么。没有这些，AI 功能等于盲飞，你既不知道用户为什么不用，也不知道钱花在了哪。
五、前后的对比，比想象中更直观
回到最初的问题：引入 AI 到底给这个系统带来了什么？拿创建接口这条链路对比：
引入 AI 之前，一个开发要在工作台里选数据源、翻库表、手写 SQL、校验、填信息、保存，五六分钟是熟练工的速度，新人的时间主要花在"找入口"和"回忆步骤"上。查接口调用情况，要去日志页按十几个条件筛选。培训一个新人熟悉这套操作，得一周。
全能 Agent 版本，理论上是一句话搞定，实际上用户平均试两轮就放弃了——报错、卡死、答非所问，任何一次都足以透支信任。而且一轮十几秒起步，token 成本还高。
场景化重构之后：同样一句"帮我创建一个查询订单的 SQL 接口"，系统秒回一张数据源选择卡，选完自动探查元数据、生成 SQL，确认卡上展示完整脚本，点确认后十秒内拿到接口草稿并可一键跳到工作台继续精调。下一轮直接说"发布它"，系统从会话记录里知道"它"是谁，确认后完成上线。高频明确指令因为词典路由，整轮只发生一次模型调用。
对使用方来说，变化不是"多了一个聊天窗"，而是高频操作的门槛从"会使用这套系统"降到了"会说话"。对维护方来说，变化是每轮的成本和成败都可度量：哪个场景失败率高、失败在哪一步、token 烧在哪个环节，报表上一目了然——AI 功能第一次变得像传统功能一样可以运营。
还有一点出乎意料：场景命中率的数据反过来帮我们看清了系统本身。哪些功能用户实际在用、用户管某个功能叫什么，这些过去靠猜的事，现在同义词词典的命中统计直接给出了答案。
六、传统业务系统接入 AI，总结的几条经验
第一，接入 AI 的第一步不是选模型，是盘点功能。 把系统功能列成清单，逐项标注读/写属性和风险等级。这一步的本质是承认一个事实：AI 接入是给现有功能加一个自然语言的入口，不是让系统凭空长出新能力。想清楚这一点，能挡住八成不切实际的预期。
第二，从只读场景开始。 查询、统计、日志类功能零风险，最适合让用户先建立"这个 AI 靠谱"的心智。信任建立之前，不要让 AI 碰任何写操作。
第三，判断架构是否靠谱，就看一条：同样的输入，是否永远走同一条执行路径。 满足这条，可控、可测、可审计；不满足，写得再炫也是定时炸弹。把流程决策从模型手里拿走，写进代码或配置，模型只做语义理解和生成——这是我们对全能 Agent 路线翻车后最痛的领悟。
第四，写操作的三件套一个不能少： 执行前确认、确认消费幂等、超时自动收尾。生产环境里，用户会双击、会刷新、会关电脑走人，每一种都得有交代。
第五，别轻视工程细节。 流式协议、超时预算、重试与备援、消息协议闭合、上下文折叠——这些东西的存在感远低于 prompt 调教，但决定成败的恰恰是它们。我们第一版翻的三个跟头，没有一个是"模型不够聪明"造成的。
第六，观测和数据要先行。 按场景记录 token、耗时、失败原因，让成本和成功率变成可运营的指标。也把用户的同义词、习惯说法沉淀成词典资产持续维护——三个月后你会发现，词典命中率的提升比换更新的模型更能降本提效。
写在最后
最后对于传统企业系统接 AI 这件事我的的总结是：它不是一次推倒重来，而是给沉淀了十年的功能换一种触达方式。
