上一篇文章聊完了企业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在企业里能不能站稳，比的从来不是谁的模型更强，而是谁能把调度、交互、治理控制得更稳。
