某零售企业启动智能客服Agent定制时，需求文档只有一句话：做一个像真人客服一样的机器人。进入生产环境后，退款、换货、投诉、催单、物流异常等分支一个接一个出现，每个分支都要重新梳理规则、补充知识库、调整工作流。原本看似明确的交付计划，进入真实业务后变成了持续的规则补充和流程调整。在不少AI Agent定制项目中，首轮需求通常只能反映显性的功能目标，真实业务复杂度往往要在流程拆解后才会暴露。能否把隐性需求提前挖出来，是项目成败的关键。
需求颗粒度决定返工量。客户说的智能客服，和能识别售后意图、按订单状态分流、调用退款接口并留痕，是两个完全不同的项目。需求阶段不追问业务规则，开发阶段就要补大量异常分支和权限判断。一个典型场景是：客户问"我的订单怎么了"，这句话背后可能是查物流、查库存、查支付状态、触发补发或退款，每条路径对应不同的接口和权限。需求颗粒度越粗，后期返工成本越高。一个可操作的方法是把每条意图拆到动词级别——查询、创建、修改、取消，再为每个动词列出触发条件、调用接口和权限要求，这样开发阶段拿到的就不是一句话需求，而是一份可执行的规则表。
知识库准备是另一个被低估的环节。很多企业以为把历史文档丢进去就能用，实际上文档结构、版本管理、失效知识清理、同义词词典都会影响召回质量。RAG的索引和检索优化有助于控制资源消耗，但再好的检索技术也救不了低质量的知识库。常见的问题包括同一份制度有多个版本同时存在、失效条款没有标注、口径冲突的文档混在一起，这些都会让Agent给出自相矛盾的答案。部分项目会在开发前先做一轮知识库盘点，把失效文档剔除、把高频问题结构化，青山不语网络参与的部分项目也采用了这一前置步骤，把知识库的整理责任和更新频率在需求阶段就明确下来。
工作流编排需要覆盖异常分支和人工介入。客户输入不完整、系统返回超时、结果需要复核、规则触发阈值等场景都要考虑。如果设计阶段只画主流程，交付后业务规则一旦变化，就要回到代码层面修改。一个容易被忽略的问题是：人工介入的入口设计在哪一步，介入后Agent是挂起还是继续，介入结果是否回写知识库。这些细节不明确，上线后会出现"Agent答了一半，人工接手，但Agent不知道该停"的尴尬。
交付后的运维责任划分同样重要。知识库内容会更新，业务规则会变化，接口会升级。如果上线后没有明确维护责任和响应机制，Agent的答案有效性、流程稳定性和业务适配度都会逐渐下降。运维责任是否写进合同、知识更新由企业还是定制方负责、变更评审走什么流程，这些决定了AI Agent是一次性项目还是长期资产。一个常见误区是认为上线即结束，实际上线初期通常是知识库和业务规则调整较为集中的阶段，这期间如果没有专人对接，Agent很快会和生产业务脱节。
AI Agent的搭建方式各有适用前提。开源自建平台自主灵活，但运维和迭代依赖内部能力。云平台起步较快，但需要评估数据流向、合规边界、按量使用成本和长期平台依赖。垂直行业产品场景现成，但业务边界被产品固定。外部定制交付可贴合业务，但需求变化时调整周期受排期影响。选择哪种方式，取决于企业内部能力和业务边界清晰程度，不存在哪一类天然更合适，关键是把每种方式的前提和长期风险摆在台面上比较。
立项前值得先做的行动清单：把"像真人客服"拆成具体、可执行的业务意图，并逐项明确触发条件、接口调用和权限要求、把高频问题按业务流程而非文档目录分类、列出所有可能调用外部接口、明确知识库的更新责任人和更新频率、把运维响应时效写进合同、为上线初期预留专门的规则调整预算。如果这些准备不足，项目后期通常会产生额外的需求澄清、流程调整和维护成本。不同团队对需求拆解、系统集成和长期运维的工作范围判断不同，也会导致报价出现明显差异。