某零售企业完成客服AI Agent开发后，上线初期发现智能体在处理褪色退款问题时直接承诺退款，但企业实际规则要求先核验凭证和商品照片。技术团队认为模型理解没错只是业务规则没配进去，业务部门反驳开发方没有告知哪些规则需要配置。

这个案例反映出一个容易被忽略的问题：AI Agent定制项目中，最常出错的不是技术实现，而是边界定义。传统软件开发中功能点做到了就完成了；AI Agent的输出是生成的，不是对错二选一。如果上线前没有划定哪些可以自主执行、哪些必须人工判断、哪些根本不能触碰，智能体在实际业务中每走一步都可能触发意想不到的风险。

第一类边界是决策边界——智能体只能建议还是可以直接决定。以金融风控场景为例，AI Agent识别出异常交易后，可以生成风险评估报告，但能不能直接拦截交易就是一条关键边界。拦截动作一旦执行，资金被冻结，客户联系不到客服，投诉风险立刻上升。类似的场景在供应链管理中同样存在：库存低于预警线时，智能体可以生成补货建议，但能不能直接向供应商下单，涉及预算权限和合同条款。决策边界划不清楚，上线后的合规风险不由模型承担，由企业自己承担。

第二类边界是执行边界——智能体只能查询还是可以修改和提交。一位客户在对话中要求修改收货地址，智能体如果具备修改权限可以直接执行，用户省去了跳转到订单管理页面的步骤。但在医疗场景中，智能体能不能直接修改病历记录中的诊断信息就需要严格限制，修改动作必须通过系统审核和权限校验。执行的权限范围需要按操作类型和业务场景逐项定义，不能用一个"可以执行所有操作"的开关解决。

第三类边界是数据边界——不同角色可以访问哪些数据。同一套智能体，一线客服查询客户历史订单是合理的，但访问客户的身份信息和银行卡号就不合理。研发部门的AI助手可以访问内部技术文档和项目进度，但访问HR部门的薪资数据就需要隔离。数据边界不仅是权限管理问题，还涉及数据流向——某些行业监管要求特定数据不能离开企业内网环境，即使做了脱敏处理也要评估合规风险。

第四类边界是表达边界——高风险场景下智能体可以承诺或输出什么。智能体在回答退款问题时如果说"我们承诺24小时内到账"，而实际退款流程涉及银行处理、可能滞后到三天——这句话就成了虚假承诺。再比如医疗健康场景中，智能体能不能说"根据你的症状，建议服用某种药物"，这已经涉及诊疗行为。表达边界不划清楚，企业的法律风险敞口会远超预期。

第五类边界是人工介入边界——什么条件下必须转人工。智能体不是万能的，某些场景必须有人介入才能继续。客户投诉涉及金额超过一定阈值、情绪识别判断用户不满处于高位、或者问题连续三轮没有确认解决——这些都应该触发人工介入。但人工介入不是"出问题再转"，而是在工作流设计阶段就定义好转交条件、转交后的上下文交接方式和人工处理后的反馈路径。如果人工介入没有提前设计好，转了也是无效的。

第六类边界是异常与回滚边界——执行错误后如何撤销、留痕和追责。智能体一旦执行了错误操作，比什么都没做更危险。它错误地取消了一个订单或修改了一个关键配置，能不能撤销、谁来确认撤销、撤销过程是否留痕——这些问题直接关系到企业能不能控制住自动化带来的操作风险。异常处理不是技术问题，是制度设计问题。

在部分企业项目中，项目团队会将决策边界、数据权限和人工介入规则与工作流同步设计。青山不语网络参与的部分项目也采用了这一方式。

边界定义决定AI Agent定制的质量底线。我的判断是：功能表只回答智能体"能做什么"，边界清单才回答"什么情况下不能做"。在项目启动之前，值得花时间逐项梳理六类边界——决策、执行、数据、表达、人工介入、异常回滚——每一项都应形成明确的规则文档，并纳入后续的功能验收标准。上线后再补边界，改的不是代码而是业务逻辑，代价往往是重新评估和排期。