你的产品是给人用的，还是给 agent 用的：微软开源 Scope，把 agent 体验变成可重复的实验

一个迟到了很久的问题：你的产品是给人用的，还是给 agent 用的

微软在 2026 年 10 月 19 日的官方开源博客上发布了 Scope：一个开源的 AI 编码 agent 评估平台，MIT 协议，跑在 Kubernetes 上，由微软开发者关系团队开发了一年多。它的出发点是一个正在变得无法忽视的现实：编码 agent 已经成了你软件的用户。它们发现 API、选 SDK、读文档、替开发者调工具。一个对人类开发者很顺手的体验，完全可能让 agent 选错 API、漏掉关键指令、卡在半路动不了。传统的开发者体验工作——用户访谈、可用性测试、产品反馈——回答的是“人用着怎么样”，回答不了“agent 用着怎么样”。微软给后者起了个名字：Developer Agent Experience，DevAx。Scope 就是用来把 DevAx 从感觉变成证据的工具。

先划清两道界线，避免和本站近期的文章撞车。第一，本站 cycle100 刚发过 Artificial Analysis 的 Coding Agent Index v2.0，那是一张跨模型的能力榜单：谁在 290 个任务上得分更高。Scope 不是榜单，它不给模型排名，它是给你自己的产品做重复实验的工具：同一个任务、同一套标准，换一份文档或换一个示例，再跑一次，看 agent 的行为变没变。第二，Scope 本身不是一个编码 agent，它驱动的是已经存在的 agent——GitHub Copilot、Claude Code、装了 Copilot 的 VS Code——去完成你定义的任务，然后评判结果。把它当成 agent 来介绍，是对它最常见的误读。

Scope 的一轮实验是怎么跑的

一轮 Scope 实验由四样东西组成：一个代表性任务、一个可选的起始代码库、一套 agent 配置、以及一套成功标准。任务不是“写个 hello world”这种玩具，而是你产品真实使用场景的切片，比如“给示例应用接上我们的 SDK，跑通一个接口调用，并正确处理文档里写明的报错”。成功标准被写成一张有向无环图（DAG）：检查项可以独立，也可以依赖前置项，比如“运行时检查”必须依赖“构建成功”才有意义。跑的过程中，Scope 会流式输出 agent 的活动，保留交互记录和工作区快照；跑完之后，一个基于大模型的 Judge 服务对照标准逐项打分，告诉你哪些要求达到了、哪些没达到，以及失败的那一项之前 agent 都做了什么。所有这些——任务、标准、agent 配置——都被版本化的 profile 管起来：worker、模型、agent 版本、技能、MCP 服务器、扩展，换一个变量重跑时，你知道自己到底换了什么。

这套设计里最值得注意的不是 Judge，而是“重复跑”这个要求。微软官方博客自己就写明了：模型、agent 运行时、技能、插件、MCP 服务器和自定义指令都会影响行为，结果在不同尝试之间会波动，配置本身也在不断变化。一次成功的演示、一次通过的 CI 测试，都证明不了什么；只有同一任务重复跑、把偶发失败和系统性失败分开，结论才站得住。同样，Judge 本身也会判错，官方博客也明确要求：重要结论仍然需要人工复核证据。一个把“Judge 说通过了”直接当成发布依据的团队，是把 Scope 用反了。

Cosmos DB 的案例：数字很好看，但要读对适用范围

官方博客给了一个 Azure Cosmos DB 团队的完整案例，也是全文最适合拿来当范本、同时最容易被断章取义的一段。该团队用 Scope 对比了裸模型与自家 Agent Kit，在 5 种语言、8 个端到端场景里跑评估；评估结果推动修复了 20 个 Agent Kit 问题和 27 个文档问题；其中一次针对性的 Agent Kit 更新之后，分层分区键的采用率从 47% 升到 100%，OFFSET/LIMIT 的误用率从 47% 降到 0%。这些数字全部来自微软官方博客引用的 Cosmos DB 团队自述，适用范围严格限定在“被评估的那 8 个场景”里。它们证明的不是“Scope 让所有产品都变好”，而是“针对性的改动可以在被测场景里把 agent 行为指标推到满分”。引用时去掉这个限定，就成了夸大宣传。反过来读，这个案例的真正价值在于工作流本身：跑评估 → 在证据里找到文档含糊或工具难用的具体位置 → 改文档或改工具 → 再跑一次验证。没有最后一步的“再跑一次”，前面全是感觉。

它和传统测试的区别：测的不是代码对不对，而是 agent 走不走得通

Scope 的三类改进方向，官方博客列得很清楚，值得逐条对照自己的产品想一遍。第一，文档能不能把 agent 引向成功：看 agent 是不是反复漏掉同一条指令、是不是总在同一个假设上出错，改掉那段文档，再跑一次看失败率降没降。第二，SDK 能不能被发现、被正确采用：agent 选的是不是你希望它选的 SDK，初始化对不对，API 用法是不是符合预期；换一份示例或加一个 agent skill，对比基线看有没有帮助。第三，工具链支不支持任务完成：命令行工具、MCP 服务器的描述清不清楚、报错信息能不能让 agent 自己纠正，下一步该改描述、改报错，还是修集成。注意这三类问题没有一类是“代码有没有 bug”——它们问的是“一个聪明的 agent 照着你给的东西，能不能走到终点”。这正是传统测试覆盖不到的地方：你的单元测试全绿，不代表 agent 能看懂你的 README。

部署形态上也有两个要点。第一，Scope 是你自己部署的软件，不是随发布附带的托管服务：你可以用 Docker Compose 起本地栈，也可以在 Kubernetes 上跑完整平台；你自己选接哪些服务、管理实验数据与凭据的访问权限。跑 agent 和模型评判需要你自己有对应厂商的访问权限，微软不替你买单。第二，它是 MIT 协议开源，仓库里包含应用服务、agent worker、评估服务和文档，欢迎新的 agent 集成、可复用的标准和分析改进。这两点合起来意味着：Scope 的门槛不在价格，而在你愿不愿意为“agent 体验”建一套持续跑的实验——机器、时间、复核的人力，都是成本。

给 vibe 开发者的用法：先给自己的产品当一次“被测对象”

如果你在做一个 vibe 项目，并且它带 SDK、CLI、MCP 服务器或者一份给开发者看的文档，Scope 的用法不需要等团队规模变大，现在就能缩小到三步。第一步，挑一个你的用户最常走、也最容易在 agent 手里走偏的任务，比如“照着 README 接入登录”或“用 CLI 初始化一个项目并跑通第一个命令”，把它写成 Scope 任务，成功标准按 DAG 拆成“装得上、初始化对、接口调通、报错处理对”四项。第二步，先跑基线：不改任何东西，连续跑三到五次，记下哪些项稳定失败、哪些项时好时坏——稳定失败的是文档或工具的问题，时好时坏的是 agent 本身波动，先修前者。第三步，改一处，再跑一次：通常最先见效的改动不是重写文档，而是把 agent 总是漏掉的那一句指令挪到更前面、把报错信息改成“你应该改 X，而不是 Y”这种可执行的形式、或者给 SDK 加一个最小可用的 agent skill。每一轮只改一处，否则你不知道是哪处起了作用。

还有一个容易被忽略的用法：把 Scope 当成“文档评审”来用。很多 vibe 项目的文档是写给人看的，段落优美、例子生动，但 agent 读文档不靠“感觉”，它靠结构：先做什么、用什么命令、成功长什么样、失败了看哪里。跑一次 Scope，失败的轨迹会直接告诉你文档里哪一段在 agent 眼里是不存在的——这比请十个人来读文档评审更便宜，也更诚实。

它的边界，也是这篇文章的边界

最后把 Scope 不能做的事说清楚，免得读者带着过高的期待去部署。第一，它不给 agent 排名，也不是通用基准；拿它去论证“Copilot 比 Claude Code 强”是对工具的误用，官方博客明确说了目标不是一张通用榜单或统一的成功定义。第二，Judge 会错判，单次结果会波动，没有人工复核和重复跑，结论不可信。第三，它评估的是“agent 用你的产品顺不顺”，不评估模型本身强不强、代码质量高不高；你的产品逻辑有 bug，Scope 帮你发现的是 agent 在哪个环节被你的 bug 绊倒，而不是替你修 bug。第四，自部署意味着数据与凭据的责任在你这边，实验里跑的私有代码、密钥配置，要按你自己的安全标准管起来。

一句话总结：以前写文档和 SDK 时，读者默认是人；从 Scope 这类工具开始，读者里要正式加上一位 agent。它不会像人一样“意会”你的省略和暗示，只会照着你写的东西一步步走，走到哪卡住，就说明你的产品在哪需要改。把这个视角加进开发流程，比多追一个模型榜单，对 vibe 项目的长期帮助更大。

Scope 的技术组成：四个部件各自负责什么

把 Scope 拆开看，它由四个部件组成，各自的责任要分清，否则部署时会把问题安错地方。第一是 Portal：用来配置实验、查看结果的 Web 界面，适合人来做探索性分析。第二是 CLI 与 REST API：用来把实验提交与结果拉取接进脚本和流水线，适合把评估变成定期任务。第三是 agent worker：真正去跑 agent 的执行单元，负责按 profile 拉起对应的 agent、模型、技能与 MCP 服务器，产出交互轨迹。第四是评估服务（Judge）：对照 DAG 标准给每次运行打分，输出哪些标准通过、哪些没通过。部署时出问题，先定位是哪个部件：任务跑不起来多半是 worker 或 agent 配置的问题；分数不对多半是标准写得不清楚或 Judge 判错；结果拉不出来多半是 CLI 或 API 的问题。把四个部件混成一团去排查，会浪费很多时间。

运行环境上，Scope 完整形态跑在 Kubernetes 上，本地起步可以用 Docker Compose。这两个形态不是“小版”与“大版”的关系，而是“一个人试”与“团队持续跑”的关系：本地栈适合先验证一个任务能不能跑通、标准写得合不合理；Kubernetes 形态适合把几十个任务排成定期实验、并行跑多个 agent 配置、长期积累结果。很多团队的失败模式是反过来的：用本地栈去扛团队的定期实验量，跑着跑着就因为资源与并发问题弃用了，然后得出“评估工具不好用”的结论——其实是部署形态选错了。先想清楚你要跑的实验规模，再选形态。

写一条好的评估任务：标准 DAG 怎么拆才有效

评估任务的质量，九成取决于成功标准拆得好不好。拆得太粗（比如只有“任务完成”一项），失败时不知道卡在哪；拆得太细（比如几十项琐碎检查），Judge 的误判会被放大，维护成本也高。一个可用的拆法是按“用户旅程的必经关卡”拆，每一关都是前一关的依赖：第一关，装得上（依赖安装成功、示例能启动）；第二关，初始化对（SDK 按文档初始化，没有用错配置项）；第三关，接口调通（按预期 API 发出一次成功调用，返回符合文档）；第四关，报错处理对（对文档里写明的错误情形，agent 给出文档里要求的处理，而不是绕过去或忽略）。每一关失败时，轨迹里都能定位到 agent 在哪一步偏离了预期，改文档或改工具时也有明确的靶子。

还有两个写标准的技巧。第一，标准要写“可观测的结果”，而不是“agent 的意图”：写“调用了 X 接口并收到 Y 返回”是可观测的，写“agent 理解了文档”是不可观测的，Judge 对不可观测的标准只能猜，误判率自然高。第二，每个标准后面要附一条“失败时先查哪里”的提示：比如初始化失败先查文档里的配置示例是不是过期了，接口调用失败先查示例代码里的参数名是不是和最新 SDK 对不上。这些提示不是给 Judge 的，是给复核的人的——复核时顺着提示查，比从头翻轨迹快得多。标准写得越像一份检查清单，评估结果就越像一份可执行的改进清单，而不是一份分数。

和传统基准、和 CI 测试的对照：三者各管什么

容易把 Scope 和另外两类东西混起来，这里做一张对照。通用基准（比如 Coding Agent Index 这类跨模型榜单）回答的是“哪个模型更强”，被测对象是模型，产出是排名；Scope 回答的是“我的产品让 agent 用着顺不顺”，被测对象是你的产品，产出是改进清单。CI 测试回答的是“代码改动有没有破坏已有行为”，被测对象是代码，产出是通过或失败；Scope 回答的是“文档与工具改动有没有让 agent 更容易成功”，被测对象是文档、示例、SDK 与工具链，产出是行为变化。三者的共同点是“可重复”，不同点是“被测对象”。一个团队如果只有 CI、没有 Scope，代码质量有保障，但 agent 体验是盲区；如果只有基准分数、没有 Scope，知道哪个模型强，但不知道自己的产品在哪里绊住了 agent。三者补齐，才算把“人用的质量”和“agent 用的质量”都管起来了。

这张对照还有一个实际用途：争取资源。很多团队想给 agent 体验投入时间，但立项时说不清它和 CI、和基准有什么区别，最后被当成“锦上添花”砍掉。用上面这张对照去讲，Scope 的定位就很清楚：它不是重复建设，而是补了一块 CI 和基准都不覆盖的盲区——文档、示例、SDK、工具描述这些“人看着没问题、agent 走着有问题”的地方。立项语言越具体，资源越容易批下来。

还有一个反直觉的结论值得单独说：agent 体验差，往往不是模型差。很多团队看到 agent 在自己的产品上频频失败，第一反应是换一个更强的模型，或者等下一代模型解决问题。但 Scope 这类实验反复揭示的规律是：同一批失败里，大部分都指向文档里的某句含糊表述、示例里的某个过期参数、工具描述里的某个缺失前提——改掉这些，同一个模型在同一个任务上的成功率就能明显上升。模型升级当然有帮助，但它解决的是“能力上限”问题，而文档与工具问题解决的是“能力下限”问题：再强的模型，照着一份自相矛盾的文档也走不到终点。先修下限，再谈上限，这个顺序能省下很多换模型的冤枉钱。

还有一个反直觉的结论值得单独说：agent 体验差，往往不是模型差。很多团队看到 agent 在自己的产品上频频失败，第一反应是换一个更强的模型，或者等下一代模型解决问题。但 Scope 这类实验反复揭示的规律是：同一批失败里，大部分都指向文档里的某句含糊表述、示例里的某个过期参数、工具描述里的某个缺失前提——改掉这些，同一个模型在同一个任务上的成功率就能明显上升。模型升级当然有帮助，但它解决的是“能力上限”问题，而文档与工具问题解决的是“能力下限”问题：再强的模型，照着一份自相矛盾的文档也走不到终点。先修下限，再谈上限，这个顺序能省下很多换模型的冤枉钱。

从失败轨迹到文档 PR：一次完整的改进闭环长什么样

前面讲了 Scope 的部件与任务写法，这里把一次完整的改进闭环走一遍，让“评估”这个词落到具体动作上。假设你的 SDK 文档里有一段“配置客户端”的说明，评估任务是“照着文档配置客户端并调通一次查询”。第一轮跑下来，失败轨迹显示：agent 在三个不同的尝试里都跳过了文档中段的一句前提条件（需要先设置某个环境变量），直接去调接口，然后被鉴权错误卡住。这时候不要先改代码，先去看那句前提条件在文档里的位置：它是不是藏在段落中间、是不是没有配示例、是不是和前后步骤的顺序不一致？通常答案是三者占其一。改法也很具体：把前提条件挪到步骤的最前面、配上一行可复制的命令示例、在鉴权失败的报错信息里加一句“请检查环境变量是否已设置”。改完之后不要只跑一次就宣布胜利：按官方博客的要求，同一任务重复跑几次，确认失败率确实下降、而不是某一次运气好；同时检查有没有引入新的失败模式（比如 agent 现在每次都去设置一个其实不需要的环境变量）。确认无误后，把文档改动提成 PR，PR 描述里附上评估任务名、改动前后的失败率、以及重复跑的次数——这样评审的人看到的不是“我觉得文档不清楚”，而是“评估显示三成尝试卡在这里，改动后降到零”。

这个闭环里还有一个容易被跳过的环节：把失败模式归档。每次评估发现的失败类型（漏前提、选错 SDK、误读报错、用错参数）都值得记下来，形成一份“agent 常犯错误清单”，下次写新文档或新示例时对照着查：这一段有没有埋同样的坑？清单越长，新文档的质量越高，因为大部分失败模式都是重复出现的。Scope 的价值到这里才算完整：它不只是一次性的测试工具，而是一台持续生产“产品哪里难用”证据的机器；证据积累下来，文档与工具的改进就不再依赖个人感觉，而是有账可查。

图注： 开发者在屏幕前查看指标的实拍照片，象征用实验数据改进产品体验的工作方式——配图为通用工作照，并非 Scope 官方界面截图。