- OpenAI 的内部数据说明 Agent 已能显著放大研究活动量，但其实验数、代码量和运行时长主要是活动代理指标；其成功率样本只覆盖可找到真实结果的任务，并排除结果不确定的分类和小样本点，因此不能把 3.1 个 Agent 工作日直接换算为 3.1 倍生产率。
- Cohere 对 696,291 个公开 MCP 工具的分析显示，按工具名称和描述做严格映射，只有 2.6% 被判定为可端到端执行一个 O*NET 工作任务；工具数量、接口覆盖和完整业务结果是三个不同层次，企业必须先定义可验收的任务单元。
- LiteLLM v1.100.0 把上传入口、调用凭据、MCP 会话、共享预算和路由成本纳入控制面，但发布说明不是生产成效证明；真正的运营账本还要记录人工介入、返工、失败和最终被接受的结果。
活动量已经可见，生产率仍需要另一套证据
OpenAI 在 9 月 6 日公布的内部研究测量中称，到八月中旬，研究团队每个人类工作日产生的 Agent 运行量已相当于 3.1 个标准 8 小时 Agent 工作日。按 API 标价折算，中位研究员每日使用超过 600 美元的推理资源，第 90 百分位超过 7,000 美元；每名活跃实验人员的实验量也达到 2025 年 1 月以来的高点。OpenAI 同时指出，实验量与 Codex 使用相关，但同期算力也在增长，现有观察不能证明因果关系。
这组数字首先证明的是可并行运行的活动规模，而不是业务产出已经按同样倍数增长。代码提交、实验次数、token 消耗和 Agent 占用时长都容易统计，却可能包含失败尝试、重复运行和没有形成决策的探索。OpenAI 自己把测量称为初步结果；其中，成功率只统计可找到真实结果的任务，图表排除了结果不确定的分类以及会话或独立用户少于 50 的点位。因此，企业若只复制运行时长或调用费用，很可能精确记录了投入，却仍不知道哪些结果被采用。
企业应把活动指标和结果指标分开：前者用于容量、预算与排队管理，后者至少记录验收通过率、返工次数、人工复核时间、决策是否采用以及从任务开始到可用结果的周期。只有两组指标能够关联，Agent 使用增长才可被解释为生产率变化。
先定义完整任务，再讨论工具覆盖率
OpenAI 借用 Epoch AI 的框架，把 AI 研发拆成决定、设计、构建、运行、分析和沟通六个阶段，并称高层规划目前只占 Agent 活动的一小部分。Epoch AI 的原始项目列出 60 多项 AI 研发任务，再用 0 至 5 级描述从未使用到自主执行的成熟度；作者明确说这仍是初步、主观且不完备的分类。它的价值不是给所有企业一个固定模板，而是提醒团队：同一个“做研究”标签下面，实际上包含证据、工具、风险和验收方式完全不同的工作单元。
Cohere 对 2026 年 5 月从七个公开目录收集的 123,069 个 MCP 服务器和 696,291 个工具做映射：团队依据工具名称和描述，使用语言模型判断其是否执行最接近的 O*NET 任务；按这一严格标准，只有 2.6% 被判定为可独立完成一个完整工作任务，约为四十分之一，419 个职业没有观察到相应活动。研究者同时强调，公开目录看不到企业内部定制服务器，所以 2.6% 更像可见范围的下界，而且这项分析没有证明工具被实际使用或可靠执行。大量工具只是查询、上传、转换等细粒度动作，接口丰富不等于完整工作已经自动化。
采购和平台团队应先建立自己的任务清单：输入是什么、允许调用哪些系统、完成条件是什么、谁能接受结果、失败后怎样回退。随后再把每个工具映射到任务步骤，而不是用服务器数、工具数或连接器数代替业务覆盖率。
人工介入不是噪声，而是成本与风险的一部分
在 OpenAI 统计的成功任务中，过去六个月内按熟练人类预计需 4 至 8 小时完成的样本，有超过一半至少发生过一次人工介入。介入意味着表面上的长周期任务仍依赖研究人员在关键节点提供引导，但原文没有进一步拆分介入原因和耗时。这个比例只覆盖可找到真实结果的内部任务，不能直接外推到合同审核、客户服务或生产运维，但它足以说明任务难度、Agent 运行时长与人类节省时间是三个不同口径。
更稳妥的计量方式，是把人工触点当作一等事件：记录介入前的状态、原因、耗时、修改内容以及最终结果是否改善。结果不确定的开放式任务也不应被静默删除，可以单列为“需专家判断”，并跟踪采纳、驳回和待验证三种状态。这样，团队既不会因为难以自动评分而高估成功率，也不会把必要的人类判断误算成系统故障。
业务负责人可以为每类任务设定人机边界：哪些步骤可无人值守，哪些必须双人复核，哪些结果只能作为建议。预算模型则应同时计入推理费用、人工介入、质量验证和返工成本，以每项被接受结果的总成本作为跨模型、跨流程比较口径。
控制面正在补课，但功能清单还不是运行证明
LiteLLM 在 9 月 6 日发布的 v1.100.0 中增加或修正了多项运行控制：向量存储上传入口可以实施安全限制，无凭据的 Vertex 透传不再泄露调用方虚拟密钥，转发凭据也不再写入重试线索；MCP 网关会话令牌支持 RS256 签名与 RFC 7662 自省，共享预算可以绑定模型访问组并按时间窗口记录支出。版本还把自动路由分类器的成本计入节省与基准统计，并修复 Lakera 监控模式下未脱敏个人信息仍被转发的问题。
这些改动与结果计量属于同一运营问题：企业必须知道谁在何时用哪个身份、调用了哪些工具、花费多少、是否越界，以及输出最终是否通过业务验收。不过，发布说明只能证明功能进入了某个版本，不能证明默认配置安全、升级无回归或控制已在生产环境生效。尤其是包含大量变更的版本，仍需要在隔离环境验证权限、会话失效、预算并发、日志脱敏和回滚路径。
可落地的 Agent 账本应把四类记录关联起来：任务定义、每次运行及成本、人工介入、最终验收。平台控制负责身份、权限、预算和可追溯性，业务质量门负责判断结果；缺少任意一边，都可能出现“调用越来越多，但价值和风险说不清”的局面。
后续观察
- OpenAI 是否继续公开按任务阶段、难度和人工介入类型拆分的结果，并补充被排除的不确定任务规模。
- 企业内部 MCP 服务器纳入后，完整工作任务覆盖率、实际使用率、失败率和权限事故率会如何变化。
- LiteLLM v1.100.0 的共享预算、MCP 会话和凭据隔离能力在高并发、密钥轮换及回滚场景下能否通过独立验证。
来源与核验
本文由英科铸数基于所列公开资料编辑撰写。事实与数据以原始来源为准；“对企业落地意味着什么”为英科铸数结合企业客户场景所作的编辑分析，不构成对第三方产品的背书。
← 返回每日观察