1. 为什么Salesforce要搞“六合一”：AI落地最大的瓶颈从来不在模型
过去一年，我和不少企业客户聊AI落地，听到了一个高度重复的痛点：“我们的AI助手明明很聪明，问什么都能答，但就是办不成事。”
这句话几乎成了行业缩影。问题不在模型能力，而在于AI只长了一个“脑子”，却没有手脚、没有记忆、没有合规边界、没有跟现有业务系统对话的接口。说得直接点，大模型再强，它也只是个能说会道的顾问，不是能办事的员工。
Salesforce这波把六大核心工具整合进AI Harness框架，本质就是在回答一个问题：怎么让AI从“能聊”变成“能干”。
所谓AI Harness，你可以把它理解成一套“安全带+缰绳”系统。它决定了一个AI Agent能看到什么数据、调用什么工具、走什么流程、什么时候需要人类批准、每一步行动有没有审计记录。没有这套东西，Agent就是个裸奔的模型；有了它，Agent才真正嵌进业务流程里，变成一个受控的“数字员工”。
那为什么偏偏是这六大工具，为什么非要在Salesforce这个生态里整合？因为在企业级场景里，AI不是孤立运行的。数据要有人管，流程要有人跑，外部系统要有人连，效果要有人看，突发情况要有人接管。这五件事，恰好对应了Salesforce手里最成熟的几个平台。把它们挂在同一个Harness框架下，才可能形成一个完整的飞轮。
这篇文章我就把这六个工具在AI Harness里的分工、它们之间的协作逻辑、以及我在实际项目中落地这套架构时踩过的坑，一次性讲清楚。
1.1 “六合一”不是简单打包，而是重新分层
很多人一听到“整合”两个字，第一反应是“不就是把六个产品绑在一起卖吗”。如果你这样理解，后面的架构思路就全偏了。
AI Harness的核心思想是分层，不是拼接。整个架构落地下来有这么几层：
- 接入层：Agentforce在这里充当“大脑”，负责理解用户意图、拆解任务、决定调用哪个工具。
- 数据层：Data Cloud统一所有客户数据、行为数据、业务数据，给Agent提供记忆和上下文。
- 执行层：Flow承载确定性的业务规则，MuleSoft对接外部系统，一个管“公司内部的标准化动作”，一个管“跟外面世界的握手协议”。
- 观测与治理层：Tableau做效果度量，Slack承载人在回路的审批、提醒、人工接管。
- 编排层：整个Harness的事件总线把这些层串起来，每一步动作都有触发条件、执行记录、异常处理。
这一套分层逻辑，跟做工程的人搭微服务架构是同一个思路：每层只干一件事，层与层之间通过明确定义的接口通信。只不过这里的“接口”不再是REST API那么简单，而是自然语言指令加上结构化事件的双通道。
1.2 为什么说大厂必须走整合路线
这里有个很现实的背景：像Salesforce这种体量的平台，客户业务早就长在了它的CRM、Service Cloud、Marketing Cloud、Commerce Cloud这些系统上。如果AI Agent只能在一个孤岛里运行，那价值就大打折扣。
举个最直白的例子：一个客户在微信上留了一条售后投诉。传统做法是人工把信息搬到工单系统，再查客户历史订单，判断是否符合退款条件，然后走退款流程。这套链路要至少打开三四个系统，跨越两三个部门。
在AI Harness架构里，这条链路变成：Agentforce收到投诉 → 从Data Cloud里瞬间拉出这个客户的订单历史和过往工单 → 调用Flow里的退款审批流程 → 需要核实外部物流信息时通过MuleSoft调接口 → 全程数据写入Tableau做监控 → 退款成功率异常或金额超限时，通过Slack通知人工审核。
你看，六个工具各自只做自己最擅长的事，但被编排成了一条完整的“业务流水线”。这才是“六合一”真正的价值，不是说六个产品能打开就叫整合，而是它们能不能围绕一个业务目标，像一套班子一样协同工作。
2. 六大核心工具在AI Harness里的分工：一个AI任务的完整闭环
这一章我把六个工具逐一拆开讲，重点说清楚每一样在这套架构里到底承担什么角色，以及它们之间的边界在哪里。边界这个东西特别重要，我在实际项目中看到最多的设计失误，就是工具职责不清，Agent试图干Flow的活，Flow又想去管数据，最后全乱套。
2.1 Agentforce：负责“脑子”
Agentforce在这套架构里是最贴近用户的入口。它做的事情像一个聪明的调度员：听明白用户要什么 → 判断这件事该怎么处理 → 决定是自己直接回答，还是去查数据、走流程、调接口。
技术上核心的三件套是Topic、Action和Model：
- Topic：定义Agent能处理哪些类型的任务。比如“退款申请”“订单查询”“投诉升级”，每个Topic绑定一套处理策略。
- Action：把Agent的能力边界画出来。Agent只能调用你预先配置好的Action，要么直连Data Cloud查数据，要么触发一段Flow，要么通过MuleSoft调外部API。没有配Action的领域，Agent再聪明也碰不到。
- Model：决定Agent用哪个大模型来做推理。你可以用Salesforce自带的模型，也可以接外部模型，通过Prompt和知识库来控制回答的风格和边界。
实际配置时有个关键经验：Topic不要铺太宽。我见过有人一上来就建了五十多个Topic，结果Agent经常分不清该用哪个，回答就会飘。最稳的做法是以业务目标为粒度，一个核心场景对应一个Topic，宁可少而精，不要多而乱。
2.2 Data Cloud：负责“记忆和上下文”
企业在过去十几年积累的客户数据，分散在CRM、ERP、电商平台、客服系统、甚至Excel表格里。没有统一，Agent就是个“失忆的聪明人”。
Data Cloud在Harness里的定位就是统一记忆层。它的拿手好戏是实时数据接入和统一客户ID——把来自不同系统的数据通过匹配规则归到一个客户名下，形成360度视图。
这套东西在AI场景里的价值体现在哪里？我举个例子：老客户打电话进来问“我上次买的耳机还在保修期吗”。如果没有Data Cloud，Agent可能查得到订单，但匹配不到保修信息，甚至可能因为数据源字段不统一而报错。有了统一的客户数据模型之后，Agent只需要一个标准查询动作，就能把订单、保修、历史工单全部拿齐。
这里要特别强调一个容易被忽略的设计原则：Agent的Prompt里塞不下所有数据，数据必须提前结构化。Data Cloud里建的语义模型、字段映射、统一ID规则，直接决定了Agent回答的准确率。我曾经在一个项目里为了追一个字段不一致的问题，前后排查了三天，最后的根因就是Data Cloud里的客户ID规则和Flow里的主键规则没对齐。数据底座不牢，上层全得遭殃。
2.3 Flow：负责“标准动作”
Flow是Salesforce生态里的低代码流程编排工具，在Harness里的角色是确定性流程的执行者。
为什么需要Flow？因为企业业务里有大量固定的规则，比如“退款金额超过5000元必须经理审批”“VIP客户优先排障”“订单发货后才能发起评价邀请”。这些规则不能交给大模型来自由发挥——模型有幻觉，但合规流程不允许有幻觉。
所以正确的分工是：Agent管“不确定的对话”，Flow管“确定的流程”。Agent理解了用户意图之后，如果要执行一个标准操作，就调用对应的Flow，把参数传进去，Flow按定义好的步骤执行，每一步都有日志、有条件判断、有审批节点。
Flow和Agent的边界怎么划，我的判断标准很简单：如果这个操作必须100%按规则执行、不能有变通，就放Flow；如果这个操作需要根据上下文灵活判断，就放Agent的推理逻辑里。把这条线划清楚，后面能少掉无数头发。
2.4 MuleSoft：负责“跟外部系统握手”
企业级场景里，没有哪个系统是孤岛。订单要对接仓库管理系统，支付要对接第三方支付平台，物流要对接快递公司的API。MuleSoft在这套架构里干的活就是让Agent的能力突破Salesforce的边界。
MuleSoft的Anypoint Platform本质上是一套API管理平台，它可以把各种外部系统的接口统一封装成标准的API，然后暴露给Flow和Agent调用。你在Harness里配置一个Agent Action，背后实际调用的可能是一个经过MuleSoft编排的复杂API链条。
我见过一个比较典型的场景：客户在网站发起退货申请，Agent需要先判断订单是否超过退货期限。这个判断不能只查Salesforce里的订单记录，还要去外部ERP系统确认发货时间。这时候MuleSoft就起作用了——通过一个封装好的接口，把ERP里的发货时间拉回来，Agent拿到数据后再做决策。
这里有一个实操提醒：外部API的延迟和稳定性，直接影响Agent的体验。你给Agent配再聪明的模型，如果调一次外部接口要等六秒，用户的耐心早就耗完了。所以我在做这类集成的时候，会优先把高频调用做数据同步，把低频实时查询做成异步任务。别贪图“每次都是实时查询”的理想状态，真实业务里性能和准确度需要平衡。
2.5 Tableau与Einstein Analytics：负责“回头看”
AI Agent上线之后，怎么知道它干得好不好？答案不在开发环境，在度量体系里。
Tableau在Harness里并不是一个直接面向用户的交互组件，而是观察Agent运行状态的“仪表盘”。数据处理这块，现在行业里基本都把它划到Data Cloud和Tableau的联合架构里做——Data Cloud负责物理层的指标计算与汇总，Tableau负责面向业务方做可视化展示与分析。你要看的核心指标包括：
- 意图识别成功率：用户说的话，Agent有没有正确理解并归类到对应Topic。
- Action调用成功率：Agent决定调用的动作，有没有执行成功，失败的根因是什么。
- 平均处理时长：从用户发出请求到问题解决，整条链路花了多长时间。
- 人工介入率：多少比例的会话需要转人工，转人工的原因是什么。
这套观测体系还有一个更重要的用途——给优化提供信号。比如你发现“退款申请”这个Topic的人工介入率特别高，点进明细一看，原来是外部ERP接口偶尔超时导致退款失败。这时候优化方向就明确了：不是去调Agent的Prompt，而是去修MuleSoft的接口超时策略。
2.6 Slack：负责“人在回路”
最后是Slack。很多人在规划AI架构的时候会忽略协作工具，但落地之后就会发现，没有人工接管通道的Agent，完全不敢放量跑。
Slack在Harness里的角色是“人与AI的交接台”。当Agent遇到三种情况时，必须交给人类：
- 超出权限边界：比如退款金额超过规定额度，Agent不能自行决策，需要通过Slack通知审批人。
- 低置信度场景：Agent对用户意图的把握不够高，与其猜错，不如转人工确认。
- 异常情况：数据查不到、外部接口报错、流程执行失败，需要人来介入排查。
这里有个设计细节值得展开：审批不是把消息甩给单个人，而是要有升级机制。比如第一级审批人两小时没响应，系统要自动升级给第二级审批人，否则一个卡住的审批会拖死整条业务线。Slack允许你通过Workflow Builder搭这种升级链路，我在实际项目中搭过三级审批链，从一线主管到部门负责人再到合规负责人，每一级都有明确的时间窗口和提醒机制。这套东西，跟自动化运维里的告警升级策略是同一个逻辑。
3. AI Harness真正的心脏：编排层与统一的语义管道
六个工具都认识了，但如果它们只是各干各的，那跟以前用人工把六个系统串起来没什么区别。AI Harness架构能不能成立，取决于一件事：有没有一条统一的“语义管道”把这六个工具串起来，让它们说的每句话、传的每个字段，都能被其他工具正确理解。
这一章是整个架构最核心的部分，也是网上讲得最少的部分。我尽量用大白话拆开讲。
3.1 所有工具都挂在同一套事件总线上
整个Harness的底层是一条事件总线。业务世界里发生的每一件事，都可以变成一个标准化的业务事件——比如“客户提交投诉”“订单发货”“退款完成”“告警触发”。这些事件被发布到总线上，任何挂载在上面的工具都可以订阅、响应、处理。
以客户投诉为例，从事件驱动的视角看，整条链路长这样：
- 用户在网页表单提交了一条投诉 → 生成“投诉已提交”事件。
- Agentforce订阅到该事件，识别出这是“售后投诉”Topic → 触发一次推理。
- Agent决定需要查客户完整历史 → 调用Data Cloud的查询Action → 拿到订单、工单、物流数据。
- Agent判断需要走退款流程 → 调用对应的Flow → Flow按规则执行内部审批。
- 审批过程中需要验证物流签收信息 → 通过MuleSoft调外部快递API → 拿到真实签收时间。
- 整条链路的状态、处理时长、结果指标，实时写入Tableau背后的指标存储里。
- 如果退款金额超过规则上限 → 事件转到Slack，通知人工审批。
你发现没有，事件总线在这里的意义，是让每个工具之间不需要直接两两对接。六个工具如果两两对接，至少要几十个接口关系，而且每改一个系统都要牵动其他五个。有了事件总线，每个工具只需要订阅自己关心的那几类事件、发布自己产生的那几类事件，彼此解耦。
这也是为什么AI Harness不叫“六件套”而叫“框架”的原因。它的重心不在那六个工具本身，而在它们之间那条看不见的事件管道。
3.2 统一语义层：让六个工具说同一种语言
事件总线解决的是“消息怎么传”，统一语义层解决的是“消息传的是什么”。
企业级系统里最经典的问题是同一个概念在各系统里有完全不同的叫法。CRM里叫“客户ID”，ERP里叫“Account Number”，Data Cloud里叫“Unified Contact ID”，到了外部系统里可能还有一套“Customer Reference”。如果Agent从Data Cloud拉到一条数据，要把其中某个字段传给Flow，但这个字段在Flow那边的字段名不一样，整个链路就断在中间了。
AI Harness里的语义层，干的活就是把所有这些字段、对象、事件名称映射到一套统一的标准概念上。具体落地时有这么几个关键动作：
- 统一身份体系：所有来自不同系统的业务主体（客户、订单、产品），都映射到Data Cloud的统一ID规则下。
- 标准化事件命名：定义好“退款申请”这个事件在系统里的统一名称，各工具发送事件时严格按标准命名。
- 字段级映射：同一个业务字段在不同系统里的不同叫法，在语义层里建立映射关系表。
- 自然语言到结构化指令的桥接：Agent输出的自然语言指令需要转成标准化的Action调用，这一步也需要语义层做翻译。
这一层做得扎不扎实，直接决定了Agent的运行效果。我见过太多项目，前期把时间都花在调试模型Prompt上，结果真正浪费时间的全是字段对不上、事件名不一致、ID规则冲突这类基础问题。语义层的建设没有捷径，只能一遍一遍跟业务方确认“你说的客户，到底指的是哪个系统的客户”。
3.3 策略治理层：给Agent画一个不可逾越的围栏
最后是治理层，这是金融、医疗、政务类客户最关心的一层。
Agent的推理能力越强，就越需要约束边界。AI Harness里的策略治理层，本质上是给Agent的一整套“交通规则”：
- 数据权限：Agent能查哪些数据、不能查哪些数据。比如普通客服场景下的Agent无权读取客户支付信息，这通过Permission Set和Data Cloud的权限模型控制。
- 动作边界：Agent可以触发哪些Action。高风险动作，比如批量退款、修改客户核心信息，必须在Agent配置层面就降为“只读”或“需审批”。
- 人审触发条件：定义哪些情况必须进入人工审批流程。比如金额阈值、涉及敏感客户、新客首笔退款等。
- 全链路审计：每一步推理、每一次API调用、每一轮对话，必须有日志可追溯。出了纠纷能拿出完整证据链。
我在实际项目中配置治理策略时，会习惯性先画一张“决策权限矩阵”——横轴是操作类型，纵轴是风险等级，表格里的每个交叉点写上“自动执行”“需审批”“禁止操作”中的一种。这张矩阵既是给Agent配置策略的依据，也是将来跟合规部门沟通的底稿。
4. 从零落地“六合一”架构：一套可以直接抄作业的步骤
前面讲了这么多原理，这一章进入实操。我把一套能跑通的落地路线拆成五步，每一步都会讲清楚要做什么、为什么要这么做、做的时候容易踩什么坑。
这套路线不依赖某个特定行业的业务背景，你只要有一个具体的业务场景（比如售后赔付、订单变更、客户投诉处理），就能按这个框架往里套。
4.1 第一步：先画业务闭环图，再碰任何工具
这是最重要的一步，但恰恰是大多数人会跳过的一步。很多团队拿到项目的第一反应是打开控制台开始配Agent，配到一半才发现数据没打通，流程没想清楚。
正确顺序是：先在纸上画出目标业务场景的全流程闭环。
拿“售后赔付自动化”举例。你要画出来的内容包括：
- 触发点：用户在什么渠道、什么状态下会发起请求？是微信、网页表单，还是客服电话？
- 信息诉求：Agent要完成这个任务，需要哪些数据？订单号、客户等级、购买时间、物流状态、历史赔付记录？
- 决策规则：什么条件下可以自动赔付，什么条件下必须人工审批？金额阈值是多少，等级的权重怎么算？
- 执行动作：赔付是通过退款、优惠券，还是寄送新商品？这个动作要调用哪套系统？
- 异常分支：数据查不到怎么办？外部接口超时了怎么办？用户情绪激烈了怎么办？
- 事后度量：这个流程的成功率怎么算，客服成本降低了多少，用户满意度变化如何？
这张图画完之后，六个工具的职责边界才会浮现出来——哪些环节需要Agent判断，哪些环节走Flow，哪些数据来自Data Cloud，哪些接口要MuleSoft接。工具是为业务流程服务的，别让工具反过来定义流程。
4.2 第二步：数据底座先行，字段规则一次对齐
业务图画清楚后，先做数据层，再做Agent，这个顺序不要颠倒。
Data Cloud落地时有几个关键步骤：
- 接入数据源：把CRM、ERP、电商平台等系统的数据连接到Data Cloud。先连最核心的两三个源，别贪多。
- 建立统一数据模型：定义好客户、订单、产品、工单这些核心对象的数据结构。
- 配置统一客户ID：这是Data Cloud的灵魂配置——不同系统里的同一个人，要靠什么规则匹配成一个人？手机号还是邮箱？匹配的优先级是什么？
- 搭建语义层：把各系统的字段映射到统一命名空间，为后续Agent和Flow的调用打好基础。
这一步最容易被忽视的是数据质量。我做过一个项目，Data Cloud接入完了，跑历史数据分析没问题，但一落到Agent实时查询就频繁报错。查到最后，问题出在源系统的数据里，有大量垃圾数据——比如生日字段填了“1900-01-01”、邮箱字段乱用“test@test.com”占位。Agent把这些脏数据当成真实信息披露给用户，造成了很严重的信任危机。
所以做数据层的时候，一定要配一套基础的清洗规则。别太复杂，先把空值、格式错误、明显的占位数据过滤掉，能挡掉七八成的低级错误。
4.3 第三步：先做Flow，再做Agent，最后接通
这个顺序也是踩过坑之后总结出来的。我的强迫症做法是：
- 先把确定性的业务规则全部用Flow实现。比如赔付金额计算、审批路由规则、通知发送逻辑。这些流程不依赖AI，先跑通，验证逻辑没有问题。
- Flow稳定之后，再创建Agentforce的Topic和Action。把需要用到的Flow挂到Agent的Action上。
- 最后才调Prompt和模型参数。因为Agent的行为是基于一套已经稳定的流程框架展开的，调Prompt只是优化它的“表达方式”，不会影响底层的流程正确性。
很多人喜欢一上来就调Prompt，因为Prompt见效快——改几个字，回复就不一样了。但Prompt调得再好，Flow里的逻辑错了，Agent照样会把错误流程执行得无比流畅。先稳骨架，再调表情，这是我在多个项目里验证过的顺序。
4.4 第四步：外部系统走MuleSoft，内部审批走Slack
外部系统接入这块，我的建议是：在MuleSoft里做一个标准的API网关层，不要让外部系统直接暴露给Agent。
原因不复杂。一方面是为了安全——你不希望Agent有权限直接调外部系统的原始接口，中间加一层，可以统一做认证、限流、审计。另一方面是为了稳定——外部接口的响应格式可能随时变，你可以在MuleSoft层做格式转换和异常兜底，而不是每次外部接口变了都要去改Agent配置。
Slack的人工审批通道，建议在一开始就设计好，不要等出了问题再补。具体做法是：
- 在Slack里建一个专门的审批频道，比如#agent-approvals，跟日常沟通频道隔离开，保证审批消息不被刷屏淹没。
- 配置审批卡片，卡片上直接显示关键信息：客户信息、请求内容、触发审批的原因、Agent的完整推理链路。
- 配置升级机制：一级审批人多久没响应，自动提醒；再多久没响应，升级到二级审批人。
这套审批通道设计好之后，你已经具备了让AI Agent放量运行的底线保障——出了任何问题，人可以在第一时间接管。
4.5 第五步：上线前先建立观测面板，别等跑起来了再补监控
最后一步，在上线前把Tableau的观测面板建起来。我推荐的起步指标就四五个，别整太复杂：
| 指标维度 | 指标名称 | 核心作用 |
|---|---|---|
| 任务完成度 | 意图识别成功率 | Agent有没有听懂用户要什么 |
| 流程健康度 | Action调用成功率 | 链路上的每一步有没有执行成功 |
| 效率 | 平均处理时长 | 从请求到解决花了多久 |
| 人工压力 | 人工介入率 | 多少比例的会话需要转人工 |
| 业务结果 | 自动化处理占比 | 真正被Agent“办成”的业务比例 |
这五个指标建好之后，后续的优化才有的放矢。哪个指标变差了，就顺着链路往下查：是意图识别错了，还是数据没查到，还是Flow执行失败，还是外部接口超时。观测面板是优化轮子的起点。
5. 真实项目里最容易踩的坑：犯过错才能说给你听
这一章写的东西，都是我在实际项目中真金白银踩出来的。我不打算写成一篇“完美案例复盘”，只想把那些最容易翻车的细节摆出来，让你在规划的时候就避开。
5.1 坑1：Agent和Flow的边界没划清，方案设计阶段就埋雷
这是我在多个项目里反复见过的问题，也是几乎每个初次做智能体架构的人都会犯的错：觉得Agent厉害，恨不得所有业务判断都丢给Agent做，Flow只用来发通知。
结果就是Agent在一堆不确定的决策里越权处理了本该走合规审批的流程。比如某个客户怒吼着要退款，Agent判断“客户情绪激动需要安抚”，就直接执行了全额退款——而这个退款金额远超它的授权额度。
复盘下来，根因就是方案设计阶段没有把“确定性规则”和“不确定性判断”分清楚。我的建议是分三层来划定边界：
- 完全确定性规则（比如金额上限、审批层级），一律写在Flow里，Agent无权绕过。
- 半确定性规则（比如退货是否在期限内），Agent可以查询数据后做判断，但最终要调Flow来执行标准动作。
- 完全不确定性判断（比如用户意图识别、投诉情绪分级），交给Agent的推理能力，但结果必须受到第一条和第二条的约束。
这套三层体系的本质是：Agent可以聪明地判断“该走哪条路”，但路径上的每一处护栏都必须是Flow定死的。
5.2 坑2：Data Cloud的字段语义和Flow不一致，Agent调用时静默报错
很经典的一个案例：Data Cloud里客户状态字段用的是枚举值，有“active”“inactive”“pending”三档；但Flow里同一个字段用的是中文，分别是“活跃”“停用”“待审核”。Agent从Data Cloud查到了“active”，传给Flow时，Flow里的判断条件只认“活跃”——匹配不上，流程直接走异常分支。
更要命的是，这个错误不是每次都发生，因为Agent有时会自己把“active”翻译成“活跃”再传给Flow，有时又不翻译直接传。这就导致同一个流程时好时坏，排查起来极其痛苦。
我现在做项目的时候有个死规矩：凡是Agent要跟Flow、MuleSoft交互的字段，全部走语义层的标准枚举值，不允许不同系统各自定义自己的叫法。建一套字段映射校验脚本，在上线前把所有字段的取值枚举全部对一遍。宁可前期多花两天做对齐，也强过上线后查三天定位问题。
5.3 坑3：没设计人工接管通路，出了问题只能全量关停
这是所有坑里最疼的一个。项目上线初期跑得很顺，团队信心很足，决定放开流量。结果某天外部物流系统接口超时，导致Agent连续错判了十几个订单的处理状态，客户投诉瞬间涌进来。
这时候想人工干预，发现压根没有预设的人工接管渠道。Agent还在按自己的节奏继续处理新请求，想要手动切断，得登录后台一个个禁用Action——等操作完，影响面已经扩散了。
从那以后，“人工接管”被我列为上线硬性条件，没有这条不上线。具体做法就是前面说的Slack审批通道再加一个“全局急停”按钮：一个事件发布到总线上，所有Agent实例立即暂停对新请求的响应，已处理中的请求转入安全暂停状态，运维团队可以从容介入排查。这玩意儿平时用不上，但关键时候能救命。
5.4 坑4：只测Happy Path，Agent的多轮上下文一断就翻车
这个坑踩得让我印象特别深。当时做的是购车售后服务场景，测试时单轮对话的各项指标都很好看。结果一上线，用户在对话中先问A问题、再问B问题、接着绕回来补充A问题的细节，Agent就开始懵了——上下文丢失，把用户之前提过的信息全忘了，重新问一遍。
后来分析原因，是Prompt里没有明确要求Agent在关键信息变化时做上下文重建。比如用户一开始说“我买的这台车是去年3月提的”，过五分钟又说“车牌号是XXXX”，Agent可能会丢失第一段信息，导致后续推荐保养方案时选错了保养周期。
解决方式是在Prompt里埋一个“关键信息检查点”，每轮对话结束前强制Agent把已知的关键信息整理成结构化笔记，作为下一轮对话的上下文基础。这样做本身不复杂，但前期不做压力测试，根本暴露不出来。所以我的测试清单里专门加了一条：至少测五轮以上的多轮对话，而且每轮都要穿插信息变更，看Agent能不能正确继承和更新上下文。
6. 上线之后：用运营数据让Harness越跑越顺
架构上线跑通只是起点，真正拉开差距的是后续的持续调优。这一章聊三个我在实际项目里验证过有效的优化方向。
6.1 顺着指标链路倒查瓶颈
前面第五步建的观测面板会暴露各种指标波动。别一看到指标掉下来就急着改Prompt，先顺着链路往下查：
- 意图识别成功率低：优先排查是不是Topic划分得太粗，用户的不同说法没有被正确归类。可以拉一段时间的历史对话，看看哪些用户输入被Agent分到了错误的Topic。
- Action调用成功率低：优先查对应的数据查询或Flow执行日志，看看是超时、报错还是权限不足。
- 人工介入率高：重点看转人工时的对话上下文和分类原因，人工介入一般有三种：数据缺失、意图不明、情绪风险。三种对应的解法完全不同，数据缺失要去补数据，意图不明要优化Prompt，情绪风险要考虑是不是要交给更资深的人工客服。
一个朴素的经验是：优化要打在“瓶颈环节”，不要平均用力。比如意图识别成功率已经95%了，你再花大力气把它提到96%，业务体感几乎无感；但如果Action调用成功率只有70%，那就是一条手臂废了，再怎么优化Prompt也补不回那30%的流程失败。
6.2 Prompt版本管理和回归测试
Agent上线之后，调Prompt是家常便饭。但这里面有一个大坑：改了一版Prompt，某个场景变好了，另一个场景却悄悄变差了。
我的做法是建立一个迷你版“回归测试集”。把每个Topic的典型输入、边界情况、历史翻车案例整理成几十条测试用例，每改一版Prompt，先全量跑一遍回归测试，对比关键指标有没有劣化。这跟软件工程里改代码要做单测是同一套逻辑，做AI Agent一样不能省。
版本管理也用最朴实的方式：每次改Prompt，把改动内容、改动人、改动原因、回归测试结果记到一个版本日志里。这个日志在你排查“为什么这个场景突然变了”的时候，价值远超想象。
6.3 从一个场景起步，再把“六合一”扩成“更多合一”
最后说扩展。AI Harness这套架构最好的地方在于它的可生长性。
第一个场景跑通之后，第二个场景的落地速度会快得多——因为数据底座已经建好了，MuleSoft的API网关层已经通了，Slack的审批通道已经能用了，观测面板也现成。你只需要新增一个Topic、挂一两个新Flow，就能跑一个新的业务自动化场景。
再往后，你可能会在这个框架里接入更多工具——比如接RAG向量数据库给Agent挂外部知识库，接自动化运维工具做告警自愈，接BI报表系统输出业务分析。这都不是问题，因为Harness的架构本来就是事件驱动的，新工具只需要订阅相关事件、发布自己的事件，就能融入整个体系。
我个人在实施这类整合时最大的体会是：别把“六合一”当做一个固定清单，要把当做一个可生长的底座。六个工具只是起点，框架的健康与否，取决于事件管道通不通、语义层齐不齐、治理边界清不清。这三件事做到了，后面接多少个工具都不怕。
