智能体上线后，最危险的不是偶尔答错，而是出了问题却没人能说清：谁批准了它的权限，谁确认了任务边界，谁审核了执行结果，谁负责停止系统。智能体不是一个普通的软件功能，也不能把责任归因于“模型自主判断”。只要它进入生产环境，责任就必须沿着业务目标、技术实现、安全治理和供应商管理明确分配。
责任边界应覆盖完整链路
业务负责人首先要对“为什么上线”负责：任务是否确实需要动态规划、知识检索或跨系统调用，成功指标是否可度量，错误会造成什么损失。规则明确、流程稳定的任务，通常不必引入智能体；涉及付款、合同变更、权限调整、生产配置和客户权益的任务，则必须预先定义审批、回滚或人工接管机制。
技术负责人要对“能否稳定执行”负责。模型可以生成计划，但关键动作应交给受控的工作流引擎完成。系统需要具备参数校验、超时处理、有限重试、幂等控制、状态保存和异常转人工能力，并记录模型输入、知识来源、工具参数、执行结果及版本信息。没有完整链路记录，就无法进行有效追责和改进。
安全与合规负责人要对“能做什么、不能做什么”负责。智能体的权限不能超过其代表的业务角色，应区分只读、写入、删除、审批和外部发送等操作。高风险动作默认不应直接执行，至少要设置二次确认、多人审批或强制人工接管。知识检索还必须受身份、部门、项目和数据等级约束，避免自然语言入口绕过原有授权体系。
供应商责任也不能被合同条款掩盖。企业应要求其说明模型、知识库、工具调用和运行日志如何追踪，接口变化、服务异常和数据处理如何通知与处置。但供应商无法替代企业对业务结果负责；采购模型或平台，不等于转移生产决策责任。
因此，上线审批不应只问“回答质量够不够”，而要逐项确认：任务是否适合智能体，错误能否发现和撤销，权限是否最小化，过程是否可审计，结果是否可度量，失败后是否有人接管。真正成熟的上线标准，不是让智能体拥有更多自主性，而是让每一次自主行为都能被授权、观察、暂停和追溯。