当一家公司把 AI Agent 开放给几乎所有员工，并且不限制 token 使用量，最先出现的往往不是生产力跃升，而是使用量、账单和各种新鲜的实验。美团内部被称为“全员养虾”的 AI 运动，正好暴露了组织级 AI 推广中一个容易被忽略的问题：让所有人都能用 AI，只能完成工具普及，不能直接完成工作方式升级。
据公开复盘，今年 2 到 3 月，美团约有 8 万名员工获得了 AI Agent 的开放使用权限，token 不设上限。公司希望通过大规模使用换取认知，让组织快速完成 AI 扫盲。结果很快体现在算力账单上，每天消耗达到千万元级别，但高使用量并没有自然转化为对应的生产力提升。
“用起来”不等于“产生价值”
大规模开放有明显价值。员工可以在真实工作中接触 Agent，组织也能更快发现哪些场景适合自动化。这比只让少数专家做演示，更容易暴露权限、数据、流程和模型能力上的真实问题。
但使用量本身不是生产力指标。下面几种行为都可能增加 token 消耗，却未必改善业务结果：
- 员工把 AI 当作更长上下文的搜索框，重复询问相似问题。
- Agent 只生成草稿，最终仍需要人工从头检查和重做。
- 工作流程没有改变，AI 只是额外增加了一个复制粘贴环节。
- 团队追求“每天使用”，却没有定义交付时间、错误率或成本目标。
- 高价值场景没有接入内部数据、权限系统和业务工具，Agent 只能停留在通用问答层。
组织推广 AI 时，应该把“活跃用户数”和“token 消耗”放在观测面板上，而不是放在结果面板上。真正需要追踪的是单位成本带来的有效产出，例如每个自动完成的工单成本、每份报告节省的人工时间、上线后的返工率，以及 AI 介入前后的业务指标变化。
规模化试错需要边界
“token 不设上限”可以快速收集使用反馈，但它把试错成本全部转化成了公司的基础设施账单。更重要的是，无上限使用会削弱员工和团队对成本的感知：当一次低质量请求与一次高价值请求对个人都没有区别时，系统很难形成自然的成本约束。
这不意味着企业应该一开始就把 AI 使用卡得很死。更可行的做法是把开放试用和正式生产分成两个阶段：
- 探索阶段：允许员工自由试用，记录真实任务、失败原因和高频需求。
- 收敛阶段：从探索数据中筛选高价值工作流，建立模板、权限、数据连接和评估集。
- 生产阶段：对稳定场景设置服务等级、预算、审计和责任人，按业务结果评估收益。
成本控制也不应该只有一个总预算。团队至少要知道钱花在了什么任务上，以及哪些请求可以用更小的模型或更短的上下文完成。下面是一个可以直接运行和改造的 Python 示例，用来估算 Agent 请求的月度成本，并比较“全量高规格模型”和“按任务分层”的差异。
运行前只需要把示例中的请求量、token 数和单价替换成企业实际数据。这里的价格是假设值，不代表任何具体供应商的报价。
from dataclasses import dataclass
@dataclass
class ModelPrice:
name: str
input_per_million: float
output_per_million: float
def monthly_cost(
requests_per_day: int,
working_days: int,
input_tokens: int,
output_tokens: int,
price: ModelPrice,
) -> float:
input_cost = requests_per_day * working_days * input_tokens / 1_000_000
output_cost = requests_per_day * working_days * output_tokens / 1_000_000
return input_cost * price.input_per_million + output_cost * price.output_per_million
high_end = ModelPrice("high-end", input_per_million=5.0, output_per_million=15.0)
small = ModelPrice("small", input_per_million=0.3, output_per_million=0.6)
# 假设每天有 80,000 名员工各发起 3 次请求，每月按 22 个工作日计算。
users = 80_000
requests_per_user = 3
working_days = 22
input_tokens = 2_000
output_tokens = 800
all_high_end = monthly_cost(
users * requests_per_user,
working_days,
input_tokens,
output_tokens,
high_end,
)
# 假设 20% 的请求是复杂任务，使用高规格模型；其余请求使用小模型。
complex_ratio = 0.20
mixed = (
all_high_end * complex_ratio
+ monthly_cost(
users * requests_per_user * (1 - complex_ratio),
working_days,
input_tokens,
output_tokens,
small,
)
)
print(f"全量高规格模型月成本: ${all_high_end:,.2f}")
print(f"分层路由月成本: ${mixed:,.2f}")
print(f"预计节省: ${all_high_end - mixed:,.2f}")
这个模型仍然很粗糙，实际系统还需要加入缓存命中率、失败重试、工具调用、并发峰值、上下文增长和人工复核成本。它的价值在于先把“规模很大”转换为可讨论的成本结构：哪些请求量最大，哪些任务最贵，哪些场景值得继续投入。
从 Agent 试用走向工作流重构
AI Agent 真正产生价值，通常需要嵌入已有流程，而不是单独存在于聊天窗口中。一个客服团队可以把“让 AI 写回复”升级为“读取工单、查询订单状态、依据规则生成候选方案、要求人工确认后回写系统”。一个研发团队也可以把“让 AI 看代码”升级为“关联变更、运行测试、总结失败原因，并在满足条件时创建修复分支”。
这类工作流至少要明确四件事：
- 输入是什么：数据来自哪里，格式是否稳定，是否包含敏感信息。
- Agent 能做什么：只能生成文本，还是可以调用内部系统和执行动作。
- 谁负责确认：哪些步骤必须人工审批，哪些低风险动作可以自动执行。
- 如何判断成功：用时、准确率、返工率、转化率和成本分别如何变化。
没有评估集时，团队很容易被几次精彩的演示说服；没有责任边界时，Agent 一旦输出错误，大家又会回到人工流程。生产化的关键不是把模型接入更多系统，而是让每一个自动化动作都能被追踪、回滚和复盘。
一份更可执行的组织推广清单
可以把“全员使用”改造成“全员发现、少数流程生产化”：
- 给所有员工提供低门槛试用入口，但记录任务类型、请求成本和结果反馈。
- 建立按部门或项目划分的预算，而不是只看全公司的总账单。
- 用真实业务样本建立离线评估集，避免只用主观满意度评价 Agent。
- 优先改造高频、规则清晰、可衡量、允许人工兜底的流程。
- 对复杂任务使用强模型，对分类、改写和结构化提取等任务尝试小模型。
- 通过缓存、提示词模板、上下文裁剪和批处理降低重复消耗。
- 把“使用次数”作为认知普及指标，把“单位成本产出”作为生产力指标。
“全员养虾”的价值，不一定要用短期 ROI 来定义。它至少说明，大规模 AI 试用可以迅速完成组织启蒙，也可以迅速暴露成本和流程问题。下一步的挑战，是把这些试用记录沉淀成少数真正改变交付方式的工作流。只有当 Agent 影响了完成时间、质量、收入或风险控制，算力账单才有机会变成可解释的生产性投入。