上一篇文章聊完了企业AI原生架构的上半程重点放在底座选型、数据接入和模型接入。这次我们把剩下的两块核心补上编排和交互。如果说底座是地基、模型是引擎那编排就是驾驶舱里的控制系统交互就是方向盘和仪表盘。这四者合在一起才真正构成一套能在企业里跑起来的AI原生应用而不是一堆散落的模型API和Prompt模板。这篇文章主要面向两类人一类是正在做AI平台落地的架构师另一类是业务系统负责人。前者可以拿走编排和交互层的关键设计思路后者可以参考我们踩坑后沉淀出来的实施方案。我不打算堆理论毕竟企业里做AI最怕的就是技术很炫、业务不认。所有内容都围绕一个目标展开让AI在真实业务链路里稳定干活且出了问题知道去哪查、由谁拍板、怎么回滚。1. 编排层让系统有序干活的“主控台”编排层的本质是把大模型从一个“单次问答工具”变成“可持续执行复杂任务的执行引擎”。很多团队一开始低估了这件事以为编排就是写个循环调模型结果一上线就发现任务一多、分支一复杂整个调用图就成了一团乱麻。1.1 先分清三种编排模式别一上来就上Agent我这里把企业里常见的编排模式分成三种它们之间的差异不是技术实现上谁比谁高级而是可控性和效率之间的取舍不同。第一种是流程式编排。这种方式适合流程固定、规则明确的场景比如工单自动分派、订单状态查询、常规质检。你提前把执行路径画成DAG每个节点做一件事模型只在特定节点上介入。比如用户投诉“物流太慢”流程先走意图识别节点判定为物流类然后调物流查询接口拿到轨迹后生成回复草稿再转人工审核。这种模式最稳因为每一环都可预期出现问题可以直接定位到某一个节点。第二种是决策式编排。它在流程式的基础上加了一个策略判断层由模型决定下一步走哪个分支。比如客服机器人先判断用户情绪情绪激烈就转紧急人工情绪平稳就继续自助处理。这种方式已经引入了模型判断但整体路径依然收敛核心业务动作不会被模型直接触发。第三种是自主式编排也就是常说的Agent模式。模型拿到一个目标后自己拆解子任务、选择工具、决定调用顺序甚至中途调整计划。这种模式灵活度最高但风险也最大。企业里不是说完全不能用而是要用在限定范围内比如数据分析辅助、竞品信息整理这类不直接触发业务写操作的场景。选型逻辑其实很简单**先看任务的失败成本高不高、路径是否确定。**失败成本高就用流程式路径稍微多变就用决策式探索性质强且允许结果有浮动才考虑自主式。我见过不少团队上来就搞Agent结果一个简单查询被模型拆成五个步骤耗时翻倍、出错概率翻倍最后只能推倒重来。AI落地不是炫技是让系统在可控范围内变聪明。1.2 任务分解与状态管理编排层最容易被低估的两件事我接触过的企业中编排层翻车最多的不是模型能力不够而是任务分解粒度不合理和状态管理缺失。任务分解的粒度要控制在“每个子任务有明确输入输出、可独立验证”的级别。举例来说一个“生成本季度销售分析报告”的任务合理的拆分是确定数据范围、提取销售数据、生成指标摘要、输出趋势图表、组装报告正文、风险点标注。每一子任务都能被验证比如“提取销售数据”的输出必须符合预定义的表结构而不是一段含糊其辞的自然语言。如果拆出来的子任务连验收标准都没有那最后的组合结果必然是不可信的。状态管理方面我强烈建议在编排引擎里引入状态快照机制。每个子任务完成之后把当时的上下文、中间结果、决策依据都持久化下来而不是只存一个最新状态。这样做的直接好处有两个一是任务中途挂了可以接着快照恢复而不是从头重跑二是排障的时候可以完整复盘“模型当时看到了什么、基于什么做的决定”。没有状态快照的编排系统一旦出错就只能看到最后一条报错日志等于瞎查。还有两个细节容易被忽略超时控制和重试幂等。调用模型接口要有超时上限不能因为上游响应慢就把整个任务拖死重试时要保证操作幂等尤其是调用外部业务接口时同一请求不能因为重试被执行两次。这些基础能力不做扎实后期线上问题会成倍增长。2. 模型网关与上下文工程编排的中枢配套编排层有了骨架之后接下来要解决的是“模型怎么接”“上下文怎么给”。这两件事我放到一起讲因为在实际工程里它们是一体的网关负责屏蔽模型差异上下文工程负责让模型在有限窗口内得到有效信息。2.1 统一模型网关多模型接入必须有的抽象层企业里几乎不可能只用一个模型原因很实际不同模型的擅长领域不同、成本不同、稳定程度也不同。客服场景可能用中文理解好的模型代码生成场景可能用推理能力强的模型而摘要场景只需要一个便宜快速的模型。如果不做统一网关业务方直接对接各自的模型API后面任何模型替换、版本升级、故障切换都是一场灾难。网关需要做的核心事情有四件统一API抽象、路由策略、成本控制、安全审计。统一API抽象是把所有模型的调用格式归一化业务方只面向一套接口底层是国产开源模型还是海外商用模型业务方不需要关心。路由策略决定了同一类请求会落到哪个模型上可以按意图路由、按成本路由、也可以按可用性路由。比如常规问答走廉价模型一旦检测到任务复杂度高再升级到强力模型这种策略能把成本直接砍掉一半。成本控制不能只做总账单拆分要做到单请求级别知道每一次调用花了多少钱、属于哪个业务线。安全审计则是记录所有出入模型的请求内容方便追溯也方便做敏感信息过滤。给一个最小路由配置示例骨架大致长这样routes: - name: general_chat intent: [chat, faq] model: cheap-model-a fallback: strong-model-b - name: complex_reasoning intent: [analysis, sql_generate] model: strong-model-b max_tokens: 4096 - name: internal_write intent: [create_order, update_status] model: strong-model-b need_confirm: true audit: true这套配置表达了几层含义不同意图流向不同模型复杂任务限定了更长输出涉及内部写操作的调用强制走人工确认并留痕。网关的价值就在于把这些策略集中管理避免散落在业务代码里改一处漏一处。另外注意一点网关要主动做语义缓存。同一类问题的重复性在企业场景里非常高把历史问答向量化存储新请求来了先做语义匹配命中缓存就直接返回既不花钱又省延迟。实测在某些客服场景里缓存命中能把模型调用量减少30%以上。2.2 上下文管理给模型“恰好够用”的记忆上下文窗口再大也不是无限大而且token就是钱。很多团队连这个基本账都没算明白一股脑把聊天历史、数据库文档、企业知识库全部塞给模型结果一次请求的token消耗翻几倍响应速度反而更慢模型还会抓不住重点。我理解的上下文管理应该分三层来做。第一层是会话层管理的是短期记忆也就是多轮对话中的状态和用户偏好。这层要有明确的token预算比如单轮对话最多2000 token超出部分做摘要压缩。会话层还可以做信息抽取把用户的核心诉求抽成结构化字段存起来下一轮响应时只把字段传给模型而不是把整段聊天记录丢过去。第二层是知识层对应企业的长期记忆。知识层最常用的实现就是RAG把文档切块、向量化、存储需要时检索相关片段注入Prompt。这里的重点不在检索多炫而在如何判断哪些知识需要被检索、哪些知识已经过期。知识文档要有更新时间戳检索结果要带上置信度评分模型回答时如果基于的文档过期宁可说“信息不足”也不能强行编造。第三层是任务层记录当前编排任务的进展、中间结果、用到过的工具。这层数据本质上是给编排引擎看的不一定要全部暴露给模型但至少要让模型能在需要时“回忆起”自己之前做过什么。长期记忆不能让模型无限记住所有事要做时间衰减过期的信息自动归档避免模型被陈旧上下文干扰。上下文工程做得好不好直接决定用户体感和业务准确率。我不建议在这块省功夫宁可前期多花时间设计上下文结构也不要在上线后每天处理“模型答非所问”的投诉。3. 交互层从聊天框到可控操作的跨越企业AI应用里最容易被做low的部分就是交互层。很多团队把“AI交互”等同于“聊天机器人”结果做出来就是一个没约束的对话框用户问什么模型答什么完全不受控。但企业场景的交互核心并不是“聊得开心”而是把事情办明白、办得可追溯。3.1 四种交互形态怎么选对话式、表单式、卡片式、组件式我梳理了一下当前企业AI应用里真正有用的交互形态大致四类交互形态适用场景优势劣势对话式开放式问答、辅助写作、顾问式分析自然、门槛低信息不够精确、操作意图易漂移表单式条件明确的任务提交如创建工单、配置规则结构清晰、必填约束强体验偏传统、模型价值体现弱卡片式结果展示、多方案对比、审批确认信息密度高、关键项一眼可见不适合复杂自由输入组件式数据分析、流程编排、可视化配置强交互、反馈即时开发成本高选型的关键不是哪种“更像AI”而是哪种能让用户以最低成本完成任务并确认结果。比如做一个数据分析助手用户输入目标“分析华东区销售下滑原因”之后交互层如果只有对话框用户就得等模型输出一整段文字自己找重点。更好的做法是对话框保留用于输入目标但结果区用组件式展示——左侧是数据筛选条件中间是可视化图表右侧是归因结论和下一步建议卡片。用户既能看结论也能操作数据范围整个分析链路是透明且可干预的。表单式和卡片式最容易被忽视但它们恰恰是企业AI落地最稳的交互形态。所有涉及审批、下单、配置变更的操作都应该有结构化的确认流程而不该让模型直接口述一段“已为您完成”。3.2 关键交互设计确认、引用、拒绝、留痕这四点是我在所有企业AI交互设计中都会坚持的原则每一条都来自实际事故的教训。第一是确认机制。凡是涉及业务写操作必须做二次确认。用户说“帮我把这批订单全部标记为异常”系统不能直接执行要把影响范围展示清楚“共302个订单涉及金额58万元确认标记”用户确认后才执行。这个机制不可省因为大模型很容易在表述中吞掉细节一旦批量操作执行错后果是灾难性的。第二是引用机制。模型给出的结论必须能溯源。回答中每一条关键信息都要带上来源引用比如“根据某产品线7月销售数据数据源销售明细表-202307”这种形式。没有引用的AI回答在企业里等于没有依据业务方根本不敢拿去做决策。第三是拒绝机制。模型要能被“拒绝授权”。当请求超出权限范围、依赖信息不完整、或者任务本身的确定性无法验证时模型应该主动拒绝而不是硬答。这个能力对模型本身要求不高更多是依赖策略层做判定。拒绝的同时给出可执行建议比如“无法直接获取财务数据建议联系财务系统管理员开通数据权限”。第四是留痕机制。所有交互过程都要有记录包括用户说了什么、模型答了什么、中间调用了哪些工具、展示了哪些数据。这不仅是合规要求也是后续优化模型的重要语料。没有留痕的AI系统迭代时连样本集都凑不出来。交互层还有一个细节容易被忽略展示模型“思考过程”的尺度。技术团队总希望把思维链展示出来证明模型确实在思考但企业场景里这会暴露太多内部逻辑而且用户看了也不会更信任。我一般建议只展示“总结后的执行路径”比如“该问题涉及数据查询与归因分析已调用销售数据接口”而不是把模型自言自语的内容原样抛给用户。4. 可观测性与评估体系让AI系统可被治理企业AI和实验性AI最大的区别在于它必须能被监控、能被度量、能被治理而不是靠感觉说“效果还不错”。没有可观测性和评估体系你连“模型今天是不是变笨了”都判断不了更别提持续优化。4.1 链路追踪与成本对账以业务价值为锚构建最小监控闭环每一请求都需要有全局唯一的request_id贯穿从交互层到编排层、到模型调用、到工具调用的整个过程。这个能力做起来不难难的是坚持。有了request_id你才能回答以下几个关键问题某次回答用了多长时间调了哪些模型生成消耗了多少token中间是否有重试最终是否被用户采纳我把监控指标分为三层。第一层是可用性指标包括请求成功率、平均响应时长、超时率、模型报错率。第二层是成本指标包括单次请求token消耗、模型费用占比、缓存命中率。第三层是业务价值指标包括任务完成率、用户采纳率、转人工率。三层缺一不可只看技术指标容易自我感觉良好只看业务指标又不知道问题出在哪个环节。成本对账要锚定在业务价值上。举例来说一个客服问答场景人工客服从接待到解决平均耗时6分钟、成本约15元而AI回答一次成本是0.2元。如果AI能解决60%的问题那单次AI会话的实际业务价值就大约是9元。成本监控的意义不是单纯省钱而是让你心里有底哪些场景AI替代人力已经划算哪些场景其实在倒贴。告警机制也要分层。模型接口大面积报错属于P0需要立即人工介入单条请求耗时超标属于P2可以先观察成本环比波动超过20%属于P1要分析是流量变化还是上下文配置出了问题。告警不能一刀切否则连续轰炸之后没人再当回事。4.2 评测集驱动迭代从拍脑袋调Prompt到有据可依我见过太多团队调Prompt的方式上线后感觉效果不好就拉出几条测试用例手工试试到满意就发布。这本质上是在“用随机游走的方式找最优解”既无法回归验证也无法量化评估。正确做法是建设一套可回归的评测集。评测集包含三类样本第一类是典型业务场景样本覆盖高频问题和主流程操作第二类是边界和异常样本比如含糊表述、超出权限请求、多意图混合第三类是回归保护样本专门用来防止每次优化后旧问题复发。三类样本加在一起初期50~100条就足够发挥作用重点是持续补充而不是追求数量。评估方式我建议采用多维打分而不是单一通过率。每条case可以从回答准确度、格式规范性、安全合规性、用户体验流畅度四个维度打分再合成总分。打分可以用LLM-as-judge的方式提高效率但必须配合人工抽检尤其涉及业务事实的判定。这里有一个实操技巧让模型当评委时要把评审标准和样例同时给出来不然打分稳定性很差。评测集接入CI/CD之后每次Prompt调整、模型切换、编排逻辑变更都要先跑回归。这套流程看起来繁琐但它是从“Demo状态”跨到“生产状态”的必经之路。没有评测你所有的优化都是凭运气。5. 安全闸门与人机协同企业落地的最后防线再聪明的模型也必须限定在企业的规则边界里运行。这个边界不是技术问题而是治理问题。我不打算谈论宏大理论就说几个必须落地的基础设施。5.1 权限与数据边界先想明白“AI能碰什么”很多企业做AI系统时权限控制沿用“人”的逻辑给模型一个账号去调接口结果模型能查什么、能改什么完全跟随这个账号的权限粒度极粗。实际上模型和人的使用模式完全不同模型可以高速并发、批量尝试一旦越权造成的影响是普通用户的成百上千倍。我建议权限设计至少分三层。第一层是接口级权限明确哪些API允许模型直接调用、哪些必须先经过前置校验。第二层是数据级权限模型作为执行主体时同一份数据也要按部门、职级、职责范围过滤比如销售组的模型不能查财务数据。第三层是操作级权限某些写操作即便有接口权限也要二次确认确认人不能是模型自己。还有一个容易被忽视的点文件下载和外部传输限制。模型通过工具获取数据之后要防止它把数据拼装成文件发送到外部。企业做AI的安全基线至少要把这项列为强制要求否则一旦模型被诱导跨出数据边界后果就很难收拾。5.2 人工兜底设计的三种时机什么时候必须让人拍板AI不能替代所有决策我总结出三种必须引入人工兜底的时机。第一种是高风险操作时。批量删除、资金操作、客户合同变更这类逻辑无论模型多自信都必须强制人工确认。确认的形式不能是“点个同意按钮”这种走过场要把操作的完整影响详情展示给审核人让他在充分知情的前提下做判断。第二种是信息不足或矛盾时。模型发现检索到的知识存在冲突或者用户请求的信息在现有数据中找不到依据这时不能靠模型猜一个答案必须转为人工处理。客服场景里就是“转人工”数据分析场景里就是“生成待确认工单”。第三种是首次执行某类操作时。凡是系统第一次遇到的新任务类型默认降级到人工主导模式模型只做辅助建议。等人工完成了几次这一类任务沉淀出固定路径之后再考虑更高级别的自动化。这叫“人在环上”而不是“人在环外”从一开始就让人参与而不是等出了问题才介入。另外要有紧急停用开关。任何一个AI组件出不可控问题运维都要能一键熔断把所有流量切回人工模式或降级模式。这个开关平时用不上但一旦用上就是救命的。6. 实战避坑清单拆编排与交互时最容易翻的车最后分享几条实战中踩出来的坑和建议按重要性排个序。第一不要一上来就全Agent化。AI能力的引入是渐进式的先跑流程式再升级局部决策式最后才考虑自主式。企业场景里稳定性永远第一Agent化对状态管理、工具调用的容错要求是指数级上升的没有治理能力之前别碰。第二编排状态必须有快照。如果现在还没有做这是你系统中第一批要补的欠账。没有快照线上出问题就只能靠猜有快照至少能回放、能恢复。第三上下文预算一定要设上限。每一层上下文都要有token预算超出部分自动压缩或截断。别让一个简单请求因为塞了太多背景知识导致成本翻了十倍这是最冤的一笔钱。第四交互别只做聊天框。对话是入口不是全部。操作类任务要有确认卡片结果展示要有结构化布局信息来源要有引用标注。把交互做成“可控的操作台”而不是一个黑盒问答机。第五单次评测分数不算数。一次你手工测出的“效果不错”没有任何意义只有评测集上的稳定回归结果才有参考价值。这条同样适用于模型选型时的方向评测不要因为一两个case表现亮眼就做决定。第六权限控制别只做前端隐藏。用户界面上不显示不代表数据安全真正的安全在接口层和数据层。模型可以直接调接口你前端藏得再好也防不住它。如果你正在搭企业AI系统我建议的最小落地模板是流程式编排打底网关统一接模型上下文分三层管理交互统一走确认制全链路上trace评测集进CI人工兜底常驻。这套架子不算激进但足够守住底线。AI在企业里能不能站稳比的从来不是谁的模型更强而是谁能把调度、交互、治理控制得更稳。
