某电商企业的客服Agent在Demo阶段表现流畅，但接入大规模商品资料和仓储系统后，知识库切分、接口格式及规则调整问题陆续暴露。项目从"看起来做好了"到"实际能用了"，中间隔的不是功能开发，是工程集成。

这个经历说明一个判断：AI Agent项目的风险不在于模型能不能回答问题，而在于工程底座能不能承载真实业务的复杂性。以下四个工程问题，如果在评估阶段没有逐一回答，后续的返工成本和上线延迟会显著增加。

第一个问题关于知识库——分段策略、版本管理和召回评估怎么做。很多知识库接入项目默认把文档按固定长度切分后存入向量库就完事了，但企业文档不是教科书，一份制度文件中"处罚条款"可能引用另一份文件的"考核标准"，切分成独立片段后引用的上下文就断了。分段策略需要考虑文档类型：操作手册适合按步骤切分，制度文件适合按条款切分，FAQ适合按问答对组织。版本管理同样重要，业务规则更新后旧版知识如果不做标记和下线，智能体可能基于过期规则给出错误回答。召回评估则是在上线前回答一个问题：对于典型的业务问题，系统从知识库中找到准确信息片段的成功率是多少。没有评估就没有优化的方向。

第二个问题关于工作流——正常路径、异常分支和人工介入有没有完整定义。正常路径的测试跑通不等于工作流过关。客户输入"我要退款"之后，如果缺少订单号，智能体是继续追问还是报错？追问几次后仍未提供是否转人工？退款金额超过一定阈值是否需要主管审批？这些异常分支的设计量往往远超正常路径。人工介入的节点也需要在设计阶段确定触发条件和上下文交接方式，不能等到上线后才发现"这个场景应该转人工但当时没设计"。

第三个问题关于系统集成——鉴权、字段映射、重试机制、幂等设计和回滚策略有没有逐一验证。AI Agent调用企业业务系统时，身份鉴权方式不同可能导致调用失败——有些系统用Session Token，有些用API Key加签名，还有些依赖内部网络访问白名单。字段映射是另一个常见问题，智能体输出的数据结构和业务系统接收的格式不一致，一个字段名拼写差异就能卡住整条链路。重试和幂等设计关系到操作可靠性：一个创建订单的请求因为网络超时重发了，如果业务系统没有幂等保护，同一笔订单可能被创建两次。回滚策略则处理最坏情况——如果Agent执行了误操作，能不能撤销、撤销边界是什么。

第四个问题关于持续运维——知识更新、规则调整、接口升级、监控告警、版本评估和责任分工怎么长期运转。知识库的内容不是一次导入就完事的，促销规则每季度变动、产品参数随版本迭代更新、合规条款在政策调整后需要同步修改——知识的保鲜机制决定了智能体的长期可用性。业务规则同样会变，一个审批流程从三级改为两级，工作流中的条件判断就要调整，调整效率和成本取决于当初的架构设计。接口方面，企业内部的OA、ERP和CRM系统本身也在升级，API接口可能在一个版本后发生Breaking Change，如果没有兼容性评估和预升级管理，AI Agent可能某天突然调用失败。监控告警体系需要覆盖的不只是服务是否在线，还应该关注知识库检索命中率的波动、工作流节点的平均处理时长变化和人工介入率是否异常升高。

在部分企业项目中，知识库设计、异常工作流、系统接口和上线运维会在前期统一规划。青山不语网络参与的部分项目也采用了这一工程化顺序。

工程问题可以延后，但无法跳过。我的判断是：Demo验证的是模型能不能回答问题，四项工程验证的是系统能不能持续运转。启动AI Agent项目之前，值得逐项核对知识库的切分策略和评估方案是否确定、工作流的异常分支和人工介入节点是否画完、系统集成的鉴权映射和回滚策略是否与相关团队达成一致、运维阶段的知识保鲜和规则调整机制是否有明确的责任人。这些问题在项目启动前花一周讨论清楚，远比上线后花一个月修补划算。