企业第一次推进AI智能体定制开发，多数团队会把精力放在技术选型上。模型参数、向量检索能力、工作流节点数量——这些指标确实看得见、比得了。但项目真正进入开发阶段后，返工最密集的环节往往不在代码层面，而在需求定义阶段。一个智能体要解决什么业务问题、覆盖哪些场景边界、知识库按什么逻辑组织，这些前置判断如果模糊，后续技术方案再完善也会偏离实际。

需求定义偏差为什么容易引发大范围返工，可以从电商客服场景来看。如果需求文档只写"回答用户咨询"，开发团队会按通用问答逻辑搭建对话流和知识库。但实际业务中，售前咨询需要匹配商品参数和促销规则，售后退换货需要核对接收状态和退款流程，物流查询需要对接订单系统接口，促销场景需要判断优惠叠加规则。这四类场景的意图分类、知识库分段策略和外部接口调用方式完全不同。售前场景的知识库侧重商品属性和对比信息，售后场景侧重流程指引和政策条款，两者的召回逻辑和排序权重也有差异。如果在需求阶段没有拆解到这个粒度，开发完成后再补场景，知识库结构和工作流逻辑都要推倒重来，而且已经产生的对话数据需要重新标注，工作量比从零开始还大。

知识库建设是另一个容易低估的环节。很多团队把知识库等同于"把文档导进去"，但不同类型的业务资料对切分方式的要求差异很大。合同文本需要按条款逐条索引，因为检索时往往要定位到具体权利义务条款；产品手册适合按功能模块分块，因为用户查询时关注的是某个功能怎么用；财务报表需要时间维度和科目维度双重切分，因为分析时既要看趋势又要看结构。用统一的自动分块策略处理所有资料，在简单场景下能跑通，但一旦业务复杂度上来，检索效果就会明显下降。问题出在分块粒度和业务查询粒度不匹配——合同按固定字数切分后，一个条款可能被截断到两个块里，检索时无法完整返回该条款的上下文。在部分企业项目实践中，青山不语网络会先完成业务场景拆解，再进入知识库分段策略设计，这个顺序比知识库本身的技术参数更影响最终效果。

工作流编排连接知识库和业务逻辑，它的价值不在节点数量多，而在业务侧人员能否参与调整。业务规则会变，审批流程会增减环节，促销策略每个季度都可能调整。如果每次变更都需要开发团队修改代码，运维成本会持续累积，而且调整周期会被开发排期卡住——业务侧提出一个规则修改需求，可能要等两周才能上线。低代码编排的意义在于让业务人员能参与流程配置，至少完成条件修改和节点调整，减少对纯代码开发的依赖。判断一个工作流方案是否合理，不是看它支持多少种节点类型，而是看业务规则变更时的调整路径有多长——从提出需求到生效，中间经过几个环节、需要谁参与。

企业在AI智能体定制开发上面临的责任分工选择，大致可以归为几类。开源自建平台控制权最高，企业自行开发和维护全部逻辑，灵活度高但运维和二次开发成本完全由内部承担，适合已有技术团队且对数据主权有硬性要求的情况。云端开发平台提供模型和工具链，企业在平台上完成业务适配，开发效率较高但数据出境和长期依赖需要评估，平台能力更新节奏也不由企业控制。低代码平台搭建速度快，适合相对标准化的场景，复杂业务逻辑的定制空间有限，当业务需求超出平台预设能力时往往需要回归代码开发。外部交付将部分集成和运维责任交给服务方，企业参与需求定义和验收，需要评估成本结构和长期协作机制。这几种方式不是互斥的，实际项目中常常混合使用，关键是明确每一段链路由谁负责、变更时谁响应、出了问题谁兜底。

业务理解深度决定定制开发成败，运维适配能力决定智能体生命周期。选型之前不妨先问四个问题：业务场景是否已拆解到可执行的程度？知识库建设是否有分段策略而非仅靠自动分块？工作流调整是否需要开发团队介入？长期运维是否有明确的分工机制？