企业AI智能体试点最容易被误解的，不是模型能力，而是“上下文”范围。上下文并非把企业所有数据都接入系统，而是让智能体在一个明确流程中，获得完成判断所必需的信息、规则、权限和反馈。范围过大，项目会陷入数据治理与接口建设；范围过小，智能体则可能在信息缺失时给出看似合理、实际错误的建议。
先定义任务边界，再定义数据边界
最小可用上下文应围绕一个可验收的业务动作建立，而不是围绕部门或系统建立。例如，零售全渠道退换货试点所需的，不是完整会员画像，而是订单状态、商品退货条件、门店库存和会员等级等直接影响判断的维度。每个字段都应回答三个问题：它是否参与决策，来源是否明确，更新是否足够及时。
数据清单确定后，还要标注字段的可信程度与缺失处理方式。主数据不一致、关键字段为空或跨系统状态不同，不能被隐藏在模型调用之后。对于无法确认的信息，智能体应输出待核验状态或转交人工，而不是补全一个未经证实的结论。最小上下文的核心不是数据最少，而是无关数据最少、关键依据完整。
上下文必须包含规则与权限
只给智能体业务数据，仍不足以支撑安全运行。流程中的SOP、判定条件、审批责任人和处理时限，同样属于上下文的一部分。智能体需要知道“依据什么判断”，也需要知道“判断后能做什么”。例如，制造业订单到工单下发可以让智能体辅助生成工单，但由计划员确认后再执行；涉及例外、数据缺失或高风险操作时，则必须进入人工路径。
因此，试点设计至少应形成一份场景级上下文清单：输入字段、业务规则、可调用权限、禁止执行的动作、异常转人工条件，以及操作日志要求。权限边界不清，自动化越深入，风险越难追溯。
用真实反馈检验“最小可用”
最小可用上下文不是一次性设计完成的。试运行期间，应收集真实案例，记录错误类型、人工介入次数和业务反馈，区分问题究竟来自数据缺失、规则不完整，还是模型理解偏差。效率指标、差错率、一次通过率和人工介入率，则用于判断上下文是否足以支撑目标流程。
如果结果不稳定，优先回查上下文而不是立即升级模型。只有当关键数据可用、规则边界清晰、异常能够兜底，且指标达到预设要求，智能体才具备扩展到更多场景的基础。企业真正要试点的，不是一个“全能助手”，而是一套在有限边界内可解释、可控制、可复盘的业务决策机制。