这是我们计划按季度更新的报告的第一期：人们究竟会让他人的编程 agent 做些什么，以及发起之后会发生什么。数据来自 muti 的内测，涵盖截至 2026 年 9 月 6 日的三十天，样本量不大：58 次请求、6 台机器、10 个房间。我们依然选择公开，因为业内尚无关于共享 agent 的公开发布，真实的小数据好过虚构的大数字。
所有数据均为汇总统计。不包含请求文本、姓名或房间名称。
数据
前三十天的五项数据及其分母。
我们的解读
对于一个没有任何营销推广的内测来说，三分之一的请求来自非主人，这个比例相当高。 主人们发出了邀请，受邀者也实际使用了 agent。共享本身就是这款产品的核心，而这一切都是自然发生的，无需刻意引导。
当审批极少出现时，审批速度就会很快。 58 次请求中仅有 9 次审批，中位数响应时间为 38 秒。这正是设计预期的效果：四项必须暂停的操作和权限模式让 prompt 极为少见，因此留下的 prompt 能够得到认真的审视。参见agent 在执行前必须询问的四项操作。
Bash 最常请求审批。 绝大部分审批都是 shell 命令。文件读取和编辑大多在 acceptEdits 下运行；真正需要人工介入的时刻都是执行命令时。这正符合权限模式的设计初衷。
失败多为运行环境故障，而非权限问题。 共有 10 次请求失败；在时间线中，它们表现为测试失败、工具缺失以及一次运行环境超时。没有一次是因为审批被拒绝。
41 秒是任务的中位数耗时。 到目前为止，被共享的 agent 通常被要求处理细小具体的事项：重新运行这个、总结那个、导出这些。耗时较长的重构很少见，而且大多由主人自己发起。
这些数据不代表什么
- 它们不具备代表性。 仅有 6 台机器，且大部分属于我们和我们的朋友。随着主人基数的扩大，非主人请求的比例可能会先下降，然后再回升。
- 完成不等于正确。 “完成”仅意味着运行环境无报错结束；结果的好坏并未在此统计。
- 审批延迟取决于主人。 9 个数据点、数位主人、最终得出一个数字。建议将其理解为“一分钟以内”，而非精确的“38 秒”。
接下来会增加的内容
下一期将包含：请求类别（代码 / 文档 / 数据 / 文件）、带附件的请求比例，以及按全天各时段划分的审批延迟。全部采用汇总统计，且均附带分母。
统计方法
数据来自产品运行所依赖的同一批数据库表：请求、工具审批、房间成员关系以及时间线事件，按 UTC 日期统计。无抽样。软删除的房间和 agent 不计入“当前”计数，但计入“历史发生”计数。审计模型详见共享编程 agent 的审计日志必须记录什么。
常见问题
我可以获取原始数据吗？ 不能。我们仅发布汇总数据；请求对其所在的房间是私密的。
为什么在 n = 58 的时候就发布？ 因为另一个选择是什么都不发布，而且说明分母能让读者自行评估权重。下一期的样本量会更大，否则我们会说明原因。
发布的频率是怎样的？ 按季度发布，采用相同的指标以便对比，并补充上一期预告新增的内容。
如果你希望出现在下一期中，给你的 agent 开一个房间。
发布于