500人用AI后，为什么还要单独建XOps？
企业 AI 最容易出现的一种“假进展”是：
买了很多License
培训了很多人
大家都会问AI了
但半年后真正进入核心流程的 Agent 仍然很少。
Pythian 8月27日公开了他们在 500人、27个国家内部推进 Gemini Enterprise 的方法。最值得关注的不是工具本身，而是两组结果和一个组织判断：
活跃用户参与度：
3×增长
数据库Incident Resolution Time：
下降80%
他们的判断：
Agent部署只占20%，
持续生产管理占80%
同时，Pythian 明确反对“每个人省5分钟”式 ROI，把 AI Operating Model 拆成：
Field CTO Strategy
→ Tooling Deployment
→ Dual COE
→ Production XOps
这组案例最值得企业借鉴的地方，是它把“AI采用率”和“AI生产运营”完全分开了。
第一件事：不要把License利用率当ROI
假设：
1000个员工
800人每周用AI
采用率：
80%
很好看。
但如果主要用途是：
改邮件
写摘要
润色PPT
企业可能确实省了一些时间，但很难形成结构性收益。
更重要的指标应该是：
多少核心Workflow被重构？
例如：
Incident Triage
合同审查
订单异常处理
销售预测
客户续约
这些流程的单位成本、周期和错误率是否发生变化。
“每人省5分钟”为什么很容易误导
假设：
500人
每天省5分钟
理论上：
2500分钟/天
≈41.7小时
看起来收益很大。
但这 5 分钟未必真的转换成：
更多收入
更少人力
更快交付
更低风险
它可能只是：
工作节奏稍微舒服一点
不是没有价值，但不能直接当财务 ROI。
我会把AI价值分成4层
L1：个人效率
写得更快
查得更快
整理更快
L2：团队效率
交接更少
Review更快
知识复用
L3：流程重构
原来8步
现在3步
原来人工排队
现在自动处理
L4：业务模型变化
原来做不了
现在可以规模化做
真正高 ROI 通常从 L3 开始。
所以用例筛选不要按“谁想做”
Pythian 的方法里有 16类横向 Agentic Pattern，先用通用模式审视企业操作，再形成优先级 Backlog。
这个方向比：
各部门自己报需求
更稳定。
因为后者经常得到：
HR想要一个聊天机器人
财务想要一个聊天机器人
采购也想要一个聊天机器人
最后全是 Chat UI。
我会用价值矩阵筛Use Case
每个用例评分：
Volume
Manual Time
Error Cost
Data Readiness
Actionability
Risk
例如：
use_case: db-incident-triage
volume_per_month: 420
manual_minutes: 35
error_cost: HIGH
data_readiness: HIGH
actionability: HIGH
risk: MEDIUM
优先做：
高频
高人工耗时
数据已存在
结果可验证
的流程。
Dual COE为什么有价值
Pythian 把 COE 分成：
People Productivity COE
Process Productivity COE
这其实解决了一个很现实的问题：
教员工用AI
和：
做生产级Agent
根本不是同一门工程。
People COE 关注：
采用
培训
No-code Agent
工作方法
Process COE 关注：
系统集成
数据
权限
Tool
SLO
监控
如果混成一个团队，往往两边都做不好。
我会把交付物也分开
People COE：
Prompt Pattern
培训
模板
轻量Skill
采用数据
Process COE：
Agent Service
Eval
Runbook
SLO
Policy
Incident Process
前者可以快速试。
后者必须按软件系统治理。
为什么“部署20%，运营80%”很值得记住
Agent 上线后会持续变化：
模型版本
Prompt
Tool API
知识库
业务规则
数据分布
用户行为
所以一个 Agent 今天 95 分：
三个月后
可能不是95
这就是 XOps 的意义。
XOps至少要管6件事
Quality Drift
Model Drift
Prompt Drift
Tool Drift
Cost Drift
Usage Drift
每一类都能让“曾经好用”的 Agent 慢慢变坏。
Quality Drift
例如：
Task Success
98%
→
91%
可能来自模型变化，也可能来自业务输入变化。
所以需要长期：
Production Eval
而不是只在发布前测试一次。
Tool Drift
CRM API：
字段改名
返回值变化
限流变化
Agent Prompt 没变，也可能开始失败。
所以 Tool Contract 应该版本化。
例如：
{
"capability": "crm.customer.read",
"schema_version": "v8"
}
新版本上线跑 Contract Test。
Cost Drift
同一个 Agent：
每天100次
突然变：
每天1000次
可能不是业务增长，而是自动化循环。
XOps 要同时看：
Cost / Success
Runs / User
Retries
Loop Count
Usage Drift也很重要
用户原本：
做销售研究
后来开始：
拿它生成大量无关内容
并不一定违规，但可能导致：
ROI下降
所以 Adoption 不能只看 DAU。
要看：
High-value Workflow Usage
一个真正有用的ROI公式
我更倾向：
Annualized Value
=
Time Saved Converted Value
+
Error Reduction
+
Throughput Gain
+
Revenue Gain
-
AI Operating Cost
其中：
Time Saved Converted Value
必须非常谨慎。
只有能转化成：
少加班
少外包
更多产出
才计入。
Incident Resolution为什么是好指标
Pythian 给出的 数据库事故解决时间下降80% 比“员工更喜欢AI”更接近业务结果。
因为 Incident 有明确：
Start
End
Severity
Labor
Downtime
可以量化。
企业选 AI 用例时，也应该优先寻找这类指标。
一个Incident Agent Scorecard
MTTA
MTTR
Human Handoffs
Escalation Rate
False Recommendation
Cost per Incident
上线前后对比。
AI项目必须有Baseline
没有 Baseline：
“用了AI以后快很多”
几乎没有意义。
上线前先记录：
过去90天
的：
周期
人工时间
错误率
成本
再比较 Candidate。
价值指标和技术指标要成对
例如：
业务：
MTTR -30%
技术：
Task Success >= 95%
如果技术成功率高，但业务指标没变化：
说明Agent做的不是关键步骤
如果业务提升但安全事故增加：
同样不能接受
我会给每个Agent一个Value Contract
agent: incident-triage
business_metric:
name: mttr
target_delta: -0.30
technical:
task_success: 0.95
p95_latency: 15s
financial:
cost_per_success_max: 0.50
safety:
unauthorized_action: 0
这样团队知道：
为什么这个Agent存在
什么时候应该下线Agent
XOps 不只是维护。
如果连续三个月：
使用量低
价值不明显
维护成本高
应该：
Retire
不要因为投入过成本就永远保留。
一个Retirement Gate
Monthly Active Workflow < threshold
AND
Business Value < Operating Cost
AND
No Strategic Dependency
进入下线评审。
这也是生产 AI 很缺的一层。
Pythian 这个案例真正值得看的是组织方法，而不是“500个人都用 Gemini”。
它说明企业 AI 的两个阶段非常不同：
第一阶段：
让大家开始用
第二阶段：
把高价值流程做成生产系统
前者靠培训和工具。
后者靠：
COE
XOps
SLO
Eval
成本
生命周期
如果 AI 计划一直停留在：
“每个人每天省5分钟”
很难形成真正的结构性 ROI。
更好的问题是：
哪一个原本昂贵、慢、容易出错的流程，可以被重新设计？
找到这种流程，再给它配一套长期运营机制，才更接近企业 AI 的真正价值。
更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：
https://www.zyentor.com/