1. 企业智能体落地的真实图景企业智能体这个词最近一年被聊得很多但真正动手做过完整项目的人都知道它跟我们在技术社区里看到的那些演示 Demo 完全是两码事。演示里一个对话框加几个工具调用就能跑通但放到企业环境里要面对的是权限体系、历史遗留系统、审批流程、数据隔离、审计合规这一整套东西。我前后参与过几个不同规模的企业智能体项目从最初的需求梳理到最终上线运维踩过的坑比想象中多得多。这篇文章想聊的是企业智能体开发从场景选择到系统集成的完整流程。核心关键词包括企业智能体、系统集成、场景选择、开发流程以及一个在交付环节越来越关键的岗位角色 FDEForward Deployed Engineer前置交付工程师。如果你正在负责或即将参与企业侧的智能体项目不管你是算法工程师、后端开发、产品经理还是交付负责人这篇内容应该能帮你少走一些弯路。先说一个基本判断企业智能体项目的成败技术只占三成剩下七成在场景选择、流程梳理和系统集成。我见过太多团队一上来就选最复杂的场景结果三个月过去连一个可用的闭环都没跑通。也见过技术方案很漂亮但跟企业现有的审批流、工单系统对接不上最后只能搁置。所以这篇文章的重点不会放在模型选型或者 Prompt 调优上而是把整个项目从零到一的流程拆开讲清楚每个阶段该做什么、为什么这么做、容易在哪里翻车。2. 场景选择决定项目生死的第一步2.1 什么样的场景适合做智能体企业里能做的事情太多了但不是什么场景都适合用智能体来解决。我的经验是筛选场景时用三个维度来打分任务复杂度、数据可及性、容错空间。任务复杂度指的是这个场景需要多少步骤、涉及多少个系统。太简单的场景比如单纯查个天气或者做个单位换算用规则引擎或者一个 API 调用就搞定了上智能体是杀鸡用牛刀。太复杂的场景比如端到端的供应链优化涉及十几个系统、几十个决策节点智能体目前的能力还兜不住。比较合适的区间是三到八个步骤、涉及两到四个系统的任务。举个例子员工报销审批这个场景需要读取报销单、核对预算、检查发票合规性、推送审批人、记录审批结果大概五六个步骤涉及财务系统、OA 系统和发票查验服务这个复杂度就刚刚好。数据可及性说的是智能体完成任务所需的数据能不能拿到、好不好拿。有些场景听起来很美但数据散在十几个系统里接口文档缺失字段含义没人说得清这种场景做起来就是无底洞。我一般会要求在做场景评估时把每个步骤需要的数据列出来标注数据来源、获取方式、是否有现成接口。如果超过三成的数据需要从零建设接口这个场景就要慎重。容错空间是很多团队容易忽略的维度。智能体不是百分百准确的它会有幻觉、会理解错意图、会调错工具。所以场景选择时要问一个问题如果智能体做错了后果有多严重。像客服问答、内部知识检索、文档摘要这类场景错了顶多是用户体验差一点人工可以兜底。但像资金划转、合同签署、生产控制这类场景错了就是事故。我的建议是第一期的智能体项目一定要选容错空间大的场景先跑通闭环、建立信任再逐步往高风险场景渗透。2.2 场景优先级排序的实操方法选定了几个候选场景之后怎么排优先级我通常用一个简单的打分表来操作让业务方和技术方一起打分避免拍脑袋决策。评估维度权重打分说明业务价值30%节省的人力成本、提升的效率、减少的错误率实现难度25%涉及系统数量、接口成熟度、数据质量容错空间20%出错后的可挽回程度、人工兜底成本可量化程度15%效果能否用数字衡量便于后续验收干系人支持10%业务方配合意愿、是否有明确的负责人每个维度按 1 到 5 分打分加权求和后排序。这个表看起来简单但实际用起来很有效因为它强迫各方把模糊的判断变成具体的分数讨论的时候有依据。我经历过一次场景评审业务方觉得某个场景价值很高但技术方打实现难度只有 1 分因为那个系统的接口是十年前的老古董连文档都没有。最后这个场景被排到了第三期先做前两个容易落地的。还有一个实操心得第一个场景一定要选业务方有强烈痛点的。智能体项目前期需要业务方大量配合梳理流程、提供数据、参与测试如果业务方本身不痛不痒配合度就会很低项目推起来特别费劲。反过来如果这个场景是业务方天天抱怨的痛点他们会主动帮你推很多协调工作不用你操心。2.3 场景边界定义与预期管理场景选定之后有一件事必须做在前面明确智能体的能力边界。很多项目后期扯皮根源都在这里。业务方以为智能体什么都能干技术方觉得我已经做得很好了双方预期不一致。我的做法是输出一份《场景能力说明书》用大白话写清楚智能体能做什么、不能做什么、遇到什么情况会转人工、准确率大概在什么水平。比如报销审批场景说明书里会写智能体能自动核对预算和发票但发票模糊无法识别时会转人工智能体能给出审批建议但最终审批权在人对于超过一定金额的报销智能体只做信息汇总不做判断。这份说明书要跟业务方逐条确认最好让业务方的负责人签字。听起来有点正式但这一步能省掉后期无数的扯皮。我吃过亏有个项目上线后业务方抱怨智能体连这个都做不了翻出当初的会议纪要才发现根本没聊过这个边界最后只能返工。3. 智能体架构设计与技术选型3.1 整体架构的分层思路企业智能体的架构跟通用聊天机器人不一样它需要跟企业现有系统深度集成所以架构设计上要特别考虑解耦和可扩展。我一般把架构分成四层交互层、编排层、能力层、集成层。交互层负责跟用户打交道可能是企业微信、钉钉、内部 OA 的对话框也可能是一个独立的 Web 页面。这一层的关键是适配企业现有的入口不要另起炉灶让用户装新 App。我做过一个项目一开始做了个独立的 Web 端结果用户根本不用后来嵌到企业微信里使用率立刻上来了。编排层是智能体的大脑负责理解用户意图、规划任务步骤、决定调用哪些工具、处理异常情况。这一层是智能体区别于传统自动化的核心。编排层可以用现成的 Agent 框架来做也可以自研。我的建议是如果团队没有特别强的框架研发能力优先用成熟框架把精力放在业务逻辑上。能力层是智能体能调用的各种工具和技能比如查询数据库、调用 API、生成文档、发送消息。这一层要设计成插件化的每个能力是一个独立的模块方便增删和替换。我见过一个项目把所有能力写在一个大文件里后来要加一个新工具改得心惊胆战。集成层负责跟企业现有系统对接包括 ERP、CRM、OA、财务系统等等。这一层是最脏最累的活但也是最关键的。集成做不好智能体就是个空中楼阁。3.2 编排层技术选型的考量编排层的技术选型有几个方向用开源 Agent 框架、用云厂商的智能体平台、或者自研。每种方式都有适用场景。开源框架的好处是灵活、可控、社区活跃遇到问题能查到资料。缺点是版本迭代快今天能用的明天可能就 breaking change 了而且企业级特性比如权限、审计、监控需要自己补。我一般会在项目初期用开源框架快速搭原型验证可行性之后再决定是继续用还是替换。云厂商的智能体平台好处是开箱即用很多企业级特性已经内置了比如权限管理、日志审计、监控告警。缺点是绑定性强迁移成本高而且有些平台对自定义工具的支持不够灵活。如果企业本身就在用某家云的服务用同厂商的智能体平台会比较顺。自研的编排层适合有较强技术团队、且业务逻辑非常特殊的情况。自研的好处是完全贴合业务坏处是工作量大、容易重复造轮子。我的观点是除非有非常明确的理由否则不建议自研编排层把精力放在业务逻辑和系统集成上更划算。选型时还要考虑一个因素团队的技术栈。如果团队都是 Python 背景选一个 Python 生态的框架会顺手很多。如果团队是 Java 背景就要考虑框架的 Java 支持情况。不要为了用某个热门框架而强行切换技术栈学习成本和维护成本都很高。3.3 工具调用的设计原则智能体跟传统程序最大的区别在于它是通过调用工具来完成任务。工具设计得好不好直接决定智能体的能力上限。第一个原则是工具粒度要适中。太粗的工具比如一个处理报销的工具内部逻辑太复杂智能体很难正确使用。太细的工具比如读取单元格 A1这种智能体要调用几十次才能完成一个任务效率和准确率都低。合适的粒度是一个工具完成一个语义完整的操作比如查询员工预算余额、校验发票真伪、提交审批请求。第二个原则是工具描述要清晰。智能体是根据工具的名称和描述来决定调不调、怎么调的。描述写得含糊智能体就会调错。我一般要求工具描述包含三部分这个工具做什么、需要什么参数、返回什么结果。参数说明要写清楚类型、是否必填、取值范围。这些细节看起来琐碎但能大幅提升智能体的调用准确率。第三个原则是工具要有容错和降级。企业系统经常不稳定接口超时、返回异常是家常便饭。工具内部要做好重试、超时处理、异常捕获返回给智能体的结果要包含明确的成功或失败标识以及失败原因。不要让智能体去猜这个空返回是成功了还是失败了。3.4 FDE 角色在架构落地中的作用FDE 这个角色在国内还比较新但在企业智能体项目里越来越重要。FDE 全称是 Forward Deployed Engineer直译是前置交付工程师实际上就是驻扎在客户现场、既懂技术又懂业务、负责把方案落地的人。为什么企业智能体项目需要 FDE因为这类项目跟传统软件项目不一样需求在初期很难完全说清楚业务方的流程有很多隐性知识技术方案需要根据现场情况不断调整。如果技术团队在后方业务方在前方中间隔着产品经理传话信息损耗会非常大。FDE 的作用就是消除这个损耗直接在现场理解业务、调整方案、解决问题。FDE 需要具备的能力比较综合技术上有足够的广度能看懂接口文档、能写脚本、能调试问题业务上有足够的敏感度能快速理解客户的流程和痛点沟通上要能跟业务方和技术方都聊得来。我见过一些 FDE 技术很强但沟通不行结果业务方不信任他方案推不动。也见过沟通很好但技术太弱遇到问题解决不了业务方觉得他不专业。如果你在组建智能体交付团队我的建议是至少配一到两名 FDE尤其是在项目前期和上线初期。FDE 的轮岗和晋升机制也很重要因为这个岗位压力大、出差多如果没有清晰的成长路径很难留住人。我了解到一些公司会给 FDE 设计技术专家和交付管理两条晋升通道让不同倾向的人都有发展空间。4. 系统集成最脏最累但最关键的一环4.1 企业系统集成的常见模式系统集成是企业智能体项目里工作量最大、最容易出问题的部分。企业里的系统五花八门有自研的、有采购的、有上云的有本地的接口方式也各不相同。我总结了几种常见的集成模式每种都有适用场景和注意事项。API 直连是最理想的方式企业系统提供标准的 REST 或 RPC 接口智能体直接调用。这种方式效率高、实时性好但前提是系统有现成的接口。很多老系统没有接口或者接口不对外开放这时候就要想别的办法。数据库直连是次选方案直接读企业系统的数据库。这种方式能拿到数据但风险很高一是可能绕过业务逻辑读到不该读的数据二是数据库结构变化会导致集成失效三是对生产库有性能影响。如果非要用这种方式一定要用只读账号并且跟 DBA 确认好影响。中间件集成是比较稳妥的方式通过消息队列、ESB企业服务总线或者集成平台来对接。这种方式解耦性好但需要企业有相应的中间件基础设施而且配置起来比较复杂。RPA 模拟操作是最后的兜底方案用机器人模拟人在界面上的操作。这种方式不需要系统提供接口但稳定性差、速度慢、容易受界面变化影响。我一般只在实在没有其他办法时才用 RPA而且要跟业务方说清楚它的局限性。集成模式适用场景优点缺点API 直连系统有标准接口高效、实时、稳定依赖系统接口能力数据库直连无接口但可访问数据库能拿到数据风险高、易失效中间件集成有 ESB 或消息队列解耦、可靠配置复杂、依赖基础设施RPA 模拟无接口且无法访问数据库无需系统改造慢、不稳定、易受界面影响4.2 接口对接的实操细节接口对接听起来简单实际做起来细节特别多。我挑几个容易踩坑的点说一下。认证和授权是第一道坎。企业系统的认证方式五花八门有 API Key、OAuth、JWT、还有自研的签名机制。对接之前一定要拿到完整的认证文档并且确认 token 的有效期和刷新机制。我遇到过一个系统token 有效期只有 15 分钟而且刷新接口有频率限制导致智能体经常调用失败。后来跟系统方协商把有效期延长到 2 小时才解决。字段映射是第二道坎。企业系统的字段命名往往很随意同一个概念在不同系统里叫法不一样。比如员工编号在 HR 系统里叫 emp_no在财务系统里叫 employee_id在 OA 系统里叫 user_code。对接时要建一个字段映射表把每个字段的来源、含义、转换规则写清楚。这个表在后期排查问题时特别有用。分页和限流是第三道坎。企业系统的接口通常有分页限制和调用频率限制。智能体在批量处理数据时如果不注意这些限制很容易触发限流被封。我的做法是在集成层做统一的限流控制把每个系统的限流规则配置化智能体调用时由集成层来排队和重试。错误处理是第四道坎。企业系统的错误码往往没有统一规范有的返回 HTTP 状态码有的返回业务错误码有的直接抛异常。集成层要把这些错误统一转换成智能体能理解的格式包含错误类型、错误信息、是否可重试。这样智能体才能做出正确的决策比如是重试、换一种方式、还是转人工。4.3 数据同步与一致性保障智能体完成任务往往需要多个系统的数据这就涉及到数据同步和一致性问题。比如报销审批场景需要从 HR 系统拿员工信息、从财务系统拿预算数据、从发票系统拿查验结果。如果这些数据不一致智能体的判断就会出错。我的做法是尽量实时获取避免缓存。能实时查的就实时查不要图省事缓存一份。缓存带来的问题是数据可能过期而且缓存失效的处理逻辑很复杂。如果确实需要缓存一定要设置合理的过期时间并且有机制在数据变更时主动刷新。对于跨系统的数据一致性我一般用最终一致性的方案。智能体的操作先落到一个中间状态然后通过异步任务去各个系统执行执行结果汇总后再更新最终状态。这样即使某个系统暂时不可用也不会阻塞整个流程等系统恢复了再补偿。还有一个细节是时区和格式。不同系统的时间格式可能不一样有的用时间戳有的用字符串时区也可能不同。数据在集成层要做统一的格式转换避免智能体拿到混乱的数据。4.4 审批流程的集成要点审批流程是企业智能体最常见的应用场景之一也是集成难度比较高的场景。因为审批流程往往涉及多个系统、多个角色、多种状态而且每个企业的审批规则都不一样。集成的第一步是梳理清楚审批流程的全貌。我一般会画一张流程图把每个审批节点、每个节点的触发条件、每个节点的操作人、每个节点的输出都标清楚。这张图要跟业务方反复确认确保没有遗漏。我见过一个项目流程图漏了一个分管领导审批的节点上线后才发现返工花了两周。第二步是确定智能体在流程中的角色。智能体是替代某个审批节点还是辅助审批人做决策还是只做流程的发起和跟踪不同的角色集成方式完全不一样。如果是替代节点智能体需要有审批权限这涉及到权限系统的改造。如果是辅助决策智能体只需要读取数据、给出建议集成相对简单。第三步是处理异常和回退。审批流程里经常出现异常情况比如审批人离职了、审批超时了、审批被驳回了。智能体要能识别这些异常并且按照预设的规则处理。比如审批人离职智能体要自动转给其上级或者指定的代理人。这些规则要在集成时配置好不能等出了问题再临时处理。第四步是审计和留痕。审批流程涉及责任认定所以智能体的每一步操作都要有日志记录包括读取了什么数据、做了什么判断、调用了什么接口、返回了什么结果。这些日志要能跟企业的审计系统对接方便后续追溯。5. 开发实施与测试验收5.1 开发阶段的节奏把控企业智能体的开发跟互联网产品不一样不能追求快速迭代、小步快跑。因为企业环境的变更成本很高每次上线都要走变更流程所以开发阶段要把该想清楚的问题都想清楚尽量一次做对。我的经验是把开发分成三个阶段原型验证、功能开发、集成联调。原型验证阶段用最快的速度搭一个能跑通的 Demo验证核心流程是否可行。这个阶段不要追求代码质量用脚本、用现成工具都行目的是确认技术路线没问题。我一般会在一到两周内完成原型然后跟业务方演示收集反馈。功能开发阶段是把原型工程化补齐异常处理、日志、配置、权限这些企业级特性。这个阶段要写单元测试核心逻辑的测试覆盖率要达到 80% 以上。因为企业环境的调试成本很高很多问题要在开发阶段就发现。集成联调阶段是跟各个企业系统对接这个阶段最耗时也最容易出问题。我的做法是按系统逐个联调不要同时对接多个系统。每对接完一个系统就做一轮完整的测试确认没问题再对接下一个。这样出问题时容易定位不会多个系统的问题混在一起。5.2 测试用例的设计思路企业智能体的测试跟传统软件测试不一样因为智能体的输出不是确定的同样的输入可能得到不同的输出。所以测试用例的设计要特别考虑这一点。我的做法是分层测试。第一层是工具测试单独测试每个工具的功能是否正确这部分可以用传统的单元测试方法。第二层是编排测试测试智能体在给定输入下是否能正确规划步骤、调用正确的工具。这部分要设计多种输入场景包括正常场景、边界场景、异常场景。第三层是端到端测试从用户输入到最终结果完整跑一遍。对于智能体输出的不确定性我用断言关键点的方式来测试。不要求输出完全一致但要求输出中包含某些关键信息或者满足某些条件。比如报销审批场景测试用例会断言智能体是否读取了正确的报销单、是否调用了预算查询、是否给出了审批建议、建议是否合理。还有一个重要的测试是对抗测试故意输入一些奇怪的、恶意的、模糊的内容看智能体怎么处理。比如输入空内容、输入超长内容、输入跟场景无关的内容、输入试图诱导智能体做危险操作的内容。这些测试能发现很多正常测试发现不了的问题。5.3 验收标准的制定验收标准要在项目开始时就定好不能等到快上线了才来讨论。企业智能体项目的验收标准通常包括几个方面功能完整性、准确率、响应时间、稳定性、安全性。功能完整性指的是约定的功能是否都实现了。这个相对好判断对照需求文档逐条验收就行。准确率是最容易扯皮的地方。什么叫准确智能体给出正确答案的比例是多少这个要在项目初期就定义清楚。我的做法是跟业务方一起标注一批测试数据作为准确率评估的基准。比如标注 200 条报销单其中 150 条应该通过、30 条应该驳回、20 条应该转人工。智能体跑完这 200 条看结果跟标注的吻合度。吻合度达到约定的阈值比如 90%就算通过。响应时间指的是用户从发出请求到收到响应的时间。企业场景下用户对响应时间的容忍度比互联网产品高一些但也不能太慢。我一般要求简单任务在 3 秒内响应复杂任务在 10 秒内给出初步反馈。稳定性指的是智能体在长时间运行下的表现。要测试连续运行几天看是否有内存泄漏、是否有累积错误、是否有性能下降。安全性包括数据安全、权限安全、操作安全。要测试智能体是否会越权访问数据、是否会执行未授权的操作、是否会泄露敏感信息。5.4 上线前的检查清单上线前有一堆事情要确认我整理了一个检查清单每次上线前逐条过一遍。所有接口的认证信息是否配置正确token 是否在有效期内所有工具的异常处理是否覆盖是否有兜底逻辑日志是否完整是否包含关键信息是否方便排查问题监控告警是否配置关键指标是否有阈值告警回滚方案是否准备好出问题时能否快速回退业务方是否完成培训是否知道怎么用、怎么反馈问题应急预案是否制定智能体不可用时人工流程是什么数据权限是否确认智能体只能访问授权范围内的数据审计日志是否开启所有操作是否可追溯性能压测是否通过峰值情况下是否能扛住这个清单看起来琐碎但每一条都是踩过坑之后总结出来的。我经历过一次上线忘了确认 token 有效期结果上线第二天 token 过期智能体全部调用失败排查了半天才发现。6. 常见问题与排查技巧实录6.1 智能体调用工具失败的排查思路工具调用失败是最常见的问题原因可能有很多。我一般按这个顺序排查先看认证。token 是否过期、API Key 是否正确、签名是否算对。这类问题占失败原因的一半以上。我习惯在集成层加一个认证检查的定时任务提前发现 token 快过期的情况。再看网络。企业网络环境复杂可能有防火墙、代理、白名单限制。要确认智能体所在的网络能访问目标系统。我遇到过一个案例开发环境能调通生产环境调不通最后发现是生产环境的防火墙没开白名单。然后看参数。智能体传的参数是否符合接口要求类型对不对、必填项有没有漏、取值范围是否合法。这类问题要看接口的详细日志对比智能体传的参数和接口期望的参数。最后看目标系统。目标系统本身是否正常是否有维护、是否有限流、是否有 bug。这类问题只能跟系统方协调智能体这边能做的是做好重试和降级。6.2 智能体理解偏差的纠正方法智能体理解错用户意图导致调用了错误的工具或者给出了错误的回答。这类问题的排查和纠正比较麻烦因为涉及到模型的行为。我的做法是先看日志再看 Prompt最后看工具描述。日志里能看到智能体收到的输入、它的思考过程、它调用的工具、工具返回的结果。通过日志能定位到是哪一步出了问题。如果是 Prompt 的问题比如指令不够清晰、示例不够充分就调整 Prompt。我一般会在 Prompt 里加一些 few-shot 示例特别是容易混淆的场景给智能体一些参考。如果是工具描述的问题比如描述太模糊导致智能体选错工具就优化工具描述。工具描述要写清楚这个工具跟其他工具的区别什么情况下用这个、什么情况下用那个。如果是模型能力的问题比如模型本身对某个领域的理解不够那就考虑换模型或者做微调。但微调的成本比较高我一般会先尝试 Prompt 优化和工具优化实在不行才考虑微调。6.3 性能瓶颈的定位与优化智能体响应慢是另一个常见问题。定位性能瓶颈要看几个地方模型推理时间、工具调用时间、编排逻辑时间。模型推理时间通常是最大的瓶颈尤其是用大参数模型的时候。优化方法包括换更小的模型、做模型量化、用流式输出让用户先看到部分结果。我一般会先测一下纯模型推理的时间如果这部分就占了大部分那优化重点就在模型上。工具调用时间取决于目标系统的响应速度。如果某个工具特别慢可以考虑异步调用让智能体先做其他事情等结果返回了再处理。或者做缓存对于不常变的数据缓存一份。编排逻辑时间通常不是瓶颈但如果编排逻辑写得不好比如做了很多不必要的判断和循环也会拖慢速度。这部分可以通过代码审查来优化。6.4 常见问题速查表问题现象可能原因排查方法解决措施工具调用全部失败认证过期检查 token 有效期刷新 token加自动刷新机制部分工具调用失败网络或限流检查网络连通性和调用频率加白名单做限流控制智能体选错工具工具描述不清查看工具描述和调用日志优化工具描述加区分说明智能体理解错意图Prompt 不清晰查看 Prompt 和输入日志优化 Prompt加 few-shot 示例响应时间过长模型推理慢分段计时定位瓶颈换小模型做量化流式输出输出不稳定模型随机性多次测试同一输入降低 temperature加约束数据不一致缓存过期对比各系统数据减少缓存实时获取权限报错权限配置错误检查智能体的权限范围调整权限配置最小权限原则6.5 几个踩坑之后的经验第一个经验是不要相信这个接口很稳定。企业系统的稳定性往往没有想象中好尤其是老系统。我现在的做法是不管对方怎么说集成层都要做重试和降级宁可多写点代码也不要上线后天天救火。第二个经验是日志要打够但不要打敏感信息。日志是排查问题的命根子但企业数据往往涉及隐私和商业机密。我的做法是日志里记录关键字段的哈希值或者脱敏后的值既能定位问题又不会泄露数据。第三个经验是跟业务方保持高频沟通。智能体项目周期长、变数多业务方的预期很容易跑偏。我一般每周跟业务方开一次短会同步进展、确认需求、收集反馈。这个习惯能避免很多后期的扯皮。第四个经验是留好回退方案。智能体再稳定也有出问题的时候一定要有回退到人工流程的方案。我一般会在上线初期保留人工流程作为备份等智能体稳定运行一段时间后再逐步减少人工介入。7. 上线运维与持续迭代7.1 上线初期的观察重点智能体上线后的前两周是最关键的时期这段时间要密切观察几个指标调用成功率、用户反馈、异常日志、性能指标。调用成功率是最直观的指标如果成功率低于预期要立刻排查。我一般会设置一个告警阈值比如成功率低于 95% 就告警。用户反馈是了解智能体实际表现的重要渠道。我一般会在智能体的交互界面加一个反馈按钮让用户可以快速反馈问题。同时会安排人每天看反馈及时响应。异常日志要每天过一遍看看有没有新的异常类型。有些问题不会立刻影响用户但如果不处理积累下来会变成大问题。性能指标包括响应时间、资源占用、调用频率等。这些指标能反映智能体的健康状态也能为后续扩容提供依据。7.2 持续迭代的节奏智能体上线不是终点而是起点。企业场景会变化用户需求会变化智能体也要持续迭代。我的做法是小步快跑但每次变更都要可控。小的优化比如调整 Prompt、优化工具描述可以每周做一次。大的变更比如新增功能、对接新系统要走完整的变更流程提前跟业务方沟通。迭代的输入来自几个方面用户反馈、日志分析、业务方的新需求、技术上的优化空间。我一般会维护一个需求池把收集到的迭代点都放进去按优先级排序定期评审。每次迭代后要做回归测试确保新变更没有破坏原有功能。企业场景下回归测试尤其重要因为很多问题是上线后才发现的如果每次迭代都引入新问题用户会失去信心。7.3 效果评估与价值量化智能体项目要持续获得资源支持必须能证明自己的价值。所以效果评估和价值量化是运维阶段的重要工作。我一般从几个维度来量化价值节省的人力工时、提升的处理效率、减少的错误率、用户满意度。节省的人力工时是最直接的指标。比如原来报销审批需要财务每天花 2 小时处理现在智能体处理了 80%每天节省 1.6 小时一个月就是 30 多个小时。提升的处理效率指的是处理速度的提升。原来一笔报销审批平均需要 2 天现在智能体处理只需要 2 小时效率提升很明显。减少的错误率指的是智能体比人工更少出错。人工审批可能会漏看某些信息智能体只要规则配置正确就不会漏。用户满意度可以通过调研来获取了解用户对智能体的接受度和满意程度。这些数据要定期整理成报告向管理层和业务方汇报。一方面是为了争取后续资源另一方面也是为了让业务方看到智能体的价值增强他们的信心。7.4 FDE 在运维阶段的角色FDE 在上线运维阶段的作用依然很重要。他们是最了解现场情况的人能第一时间发现问题和机会。FDE 在运维阶段的工作包括收集用户反馈、分析使用数据、发现优化点、协调资源解决问题、跟业务方保持沟通。我见过一些项目上线后 FDE 就撤了结果问题没人处理用户抱怨越来越多最后项目被搁置。所以我的建议是上线后 FDE 至少要继续驻场一到两个月等智能体稳定运行、业务方形成使用习惯后再逐步撤出。FDE 的轮岗和晋升机制在这个阶段也要跟上。长期驻场的 FDE 容易产生倦怠如果没有清晰的成长路径很容易流失。我了解到一些公司会让 FDE 在多个项目之间轮岗既能保持新鲜感又能积累不同行业的经验。晋升方面FDE 可以往技术专家方向走也可以往交付管理方向走让不同倾向的人都有发展空间。8. 一些个人体会做企业智能体项目这几年最大的感受是技术不是最难的部分最难的是理解业务和协调各方。一个智能体项目能不能成往往在场景选择阶段就决定了。选对了场景后面的事情顺水推舟选错了场景技术再强也推不动。另一个感受是不要追求完美先跑通闭环。我见过一些团队一开始就想做一个大而全的智能体结果做了半年还没上线业务方失去耐心项目被砍。反而是那些先做一个简单场景、快速上线、然后逐步扩展的团队最后做成了。还有一点是FDE 这个角色真的很有价值。企业智能体项目需要有人既懂技术又懂业务能在现场快速做决策。如果你在考虑职业方向FDE 是一个值得关注的方向。它要求的能力比较综合但成长也快能接触到不同行业、不同场景积累的经验很宝贵。最后分享一个小技巧每次跟业务方开会都带一个具体的 Demo。不要只讲方案要让他们看到实际效果。业务方看到智能体真的能干活配合度会高很多。我试过几次带着 Demo 去开会原本犹豫的业务方当场就拍板了。