企业 Agent 上线后最危险的状态不是偶尔答错，而是所有人都以为“有人会管”。业务说这是 IT 系统，IT 说规则由业务定，一线发现问题只在群里提醒，服务商等需求单，最后没有人对实际结果负责。
五类角色分别承担什么
| 角色 | 主要责任 | 不应替代谁 |
|---|---|---|
| 业务 Owner | 工作边界、规则、指标、例外裁决 | 不负责修接口 |
| 一线岗位 | 确认高风险动作、反馈错误、接管异常 | 不负责平台配置 |
| Agent 运营 | 评测、版本、知识缺口、异常分析、复盘 | 不擅自改业务规则 |
| IT/系统 Owner | 连接器、身份、数据映射、服务健康 | 不判断客户是否该催款 |
| 安全/管理员 | 权限政策、敏感动作、审计与事件处置 | 不负责日常内容维护 |
外部交付团队可以承担建设、托管或陪跑，但不能代替客户内部的业务批准责任。
每项工作只认一个业务 Owner
“销售跟进 Agent”可能涉及销售、财务和项目部，但仍要指定一个人对工作定义和指标负责。跨部门意见不一致时，由谁裁定；规则变化由谁批准；异常超过多久由谁升级，都应在上线前写清。
Owner 不是每天操作后台的人，也不是所有问题都亲自处理。其职责是确保这项工作有明确终态、正确规则和可接受的风险。
运营例会看四张清单
- 业务结果：哪些任务完成、挂起、失败，指标有没有改善。
- 异常队列：哪些由知识、连接、权限、模型或外部等待造成。
- 变更清单：本周期发布了什么，影响范围和回归结果是什么。
- 知识缺口：高频缺失、冲突和过期主题由谁处理。
例会不需要逐条读聊天记录，但高风险或重复异常要能进入完整回放。指标设计见Agent 可观测性看什么，知识问题可用知识缺口队列持续治理。
用接管机制检验责任是否真实
当连接器失效、模型不可用、规则冲突或外部系统结果未知时，任务应自动进入有责任人的队列，而不是停在“执行失败”。每条异常要有截止时间和恢复条件；修复后重新验证业务终态。
企业 Agent 能否规模化，不只取决于模型能力，更取决于组织是否形成持续运营责任。需要把角色、平台和业务闭环一起设计，可从企业 AI 落地工程开始。
建设期和运营期的责任不同
建设期重点是访谈、系统接入、规则确认、测试和上线；运营期则转为异常处置、知识更新、版本发布、成本复盘与新需求评估。如果项目计划只写到“上线验收”，没有说明上线后谁看指标、谁批准规则和谁处理连接失效，责任会在交付当天断掉。
内部团队尚未成熟时，可以由交付团队陪跑，但每一类责任仍要找到客户内部对应人。否则外部团队即使能修技术，也无法合法决定价格政策、客户承诺和业务例外。
用 RACI 明确每个关键动作
对于“发布技能、扩大权限、发送报价、处理异常、关闭知识缺口、调整预算”等动作，分别标出负责执行者、最终批准者、需要会签者和需要知会者。最终批准者尽量唯一，避免出了问题时每个人都只是参与者。
RACI 不是为了增加签字，而是让日常低风险动作可以快速执行，高风险变化知道由谁拍板。角色或人员变化后同步更新，不让离职员工继续成为唯一 Owner。
给运营人员真实操作权
如果 Agent 运营只能看报表，却不能挂起任务、回退版本、分派知识缺口或触发复测，其责任只是名义上的。相反，运营人员也不应拥有不受约束的业务数据和生产写权限。平台要把处置能力与审批边界同时设计。
成熟度从“有人救火”走向“机制运行”
初期可能靠核心人员逐条看任务；稳定后应形成分级告警、固定评测、版本流程和周/月复盘；再进一步，业务部门可以自行维护规则与知识，平台团队提供共同底座。衡量成熟度的标准不是运营团队人数，而是常见问题是否有明确入口、责任和恢复条件。
