某电商企业的客服Agent在Demo阶段表现流畅但接入大规模商品资料和仓储系统后知识库切分、接口格式及规则调整问题陆续暴露。项目从看起来做好了到实际能用了中间隔的不是功能开发是工程集成。这个经历说明一个判断AI Agent项目的风险不在于模型能不能回答问题而在于工程底座能不能承载真实业务的复杂性。以下四个工程问题如果在评估阶段没有逐一回答后续的返工成本和上线延迟会显著增加。第一个问题关于知识库——分段策略、版本管理和召回评估怎么做。很多知识库接入项目默认把文档按固定长度切分后存入向量库就完事了但企业文档不是教科书一份制度文件中处罚条款可能引用另一份文件的考核标准切分成独立片段后引用的上下文就断了。分段策略需要考虑文档类型操作手册适合按步骤切分制度文件适合按条款切分FAQ适合按问答对组织。版本管理同样重要业务规则更新后旧版知识如果不做标记和下线智能体可能基于过期规则给出错误回答。召回评估则是在上线前回答一个问题对于典型的业务问题系统从知识库中找到准确信息片段的成功率是多少。没有评估就没有优化的方向。第二个问题关于工作流——正常路径、异常分支和人工介入有没有完整定义。正常路径的测试跑通不等于工作流过关。客户输入我要退款之后如果缺少订单号智能体是继续追问还是报错追问几次后仍未提供是否转人工退款金额超过一定阈值是否需要主管审批这些异常分支的设计量往往远超正常路径。人工介入的节点也需要在设计阶段确定触发条件和上下文交接方式不能等到上线后才发现这个场景应该转人工但当时没设计。第三个问题关于系统集成——鉴权、字段映射、重试机制、幂等设计和回滚策略有没有逐一验证。AI Agent调用企业业务系统时身份鉴权方式不同可能导致调用失败——有些系统用Session Token有些用API Key加签名还有些依赖内部网络访问白名单。字段映射是另一个常见问题智能体输出的数据结构和业务系统接收的格式不一致一个字段名拼写差异就能卡住整条链路。重试和幂等设计关系到操作可靠性一个创建订单的请求因为网络超时重发了如果业务系统没有幂等保护同一笔订单可能被创建两次。回滚策略则处理最坏情况——如果Agent执行了误操作能不能撤销、撤销边界是什么。第四个问题关于持续运维——知识更新、规则调整、接口升级、监控告警、版本评估和责任分工怎么长期运转。知识库的内容不是一次导入就完事的促销规则每季度变动、产品参数随版本迭代更新、合规条款在政策调整后需要同步修改——知识的保鲜机制决定了智能体的长期可用性。业务规则同样会变一个审批流程从三级改为两级工作流中的条件判断就要调整调整效率和成本取决于当初的架构设计。接口方面企业内部的OA、ERP和CRM系统本身也在升级API接口可能在一个版本后发生Breaking Change如果没有兼容性评估和预升级管理AI Agent可能某天突然调用失败。监控告警体系需要覆盖的不只是服务是否在线还应该关注知识库检索命中率的波动、工作流节点的平均处理时长变化和人工介入率是否异常升高。在部分企业项目中知识库设计、异常工作流、系统接口和上线运维会在前期统一规划。青山不语网络参与的部分项目也采用了这一工程化顺序。工程问题可以延后但无法跳过。我的判断是Demo验证的是模型能不能回答问题四项工程验证的是系统能不能持续运转。启动AI Agent项目之前值得逐项核对知识库的切分策略和评估方案是否确定、工作流的异常分支和人工介入节点是否画完、系统集成的鉴权映射和回滚策略是否与相关团队达成一致、运维阶段的知识保鲜和规则调整机制是否有明确的责任人。这些问题在项目启动前花一周讨论清楚远比上线后花一个月修补划算。