从“找得到”到“用得好”：支付宝 AI 付如何建设 Agent 友好的开发者体验
摘要：本文介绍支付宝 AI 付如何建设 Agent 友好的开发者体验，让 Agent 能够基于可信的官方公开资料，帮助开发者理解产品差异，顺利完成接入准备、沙箱测试和上线检查。通过静态与动态评测，AI 付开放站点持续发现并改善体验断点：静态评测得分为 85 分，表明关键资料整体较为完整且易于发现；面对开发者常见问题，Agent 的任务完成率达到90%。
什么样的支付站点，才算 Agent 友好？
“我该选哪个支付产品？” “我的 API、Skill 或 MCP 能不能按调用收费？” “接入前需要准备什么？怎样在不影响真实交易的前提下测试？”
越来越多开发者会先把这些问题交给 Agent。它能帮你筛选产品、阅读文档、整理步骤，甚至辅助完成接入。
但这件事有一个前提：Agent 得能找到正确、完整且可信的官方资料。
如果信息分散在不同页面，第一步藏在交互流程里，测试和上线说明又需要反复查找，开发者和 Agent 都会停在“我接下来该做什么”这一步。
这正是我们理解的 Agent 友好：不是让 Agent 替开发者做决定，而是让它能够依据官方公开资料，清楚说明“有哪些选择、每种选择适合什么场景、下一步应该做什么”。
对一次支付接入准备而言，这条路径应该是连续的：
找到公开资料 → 看懂产品和适用场景 → 选定接入路径 → 完成测试验证 → 理解安全与上线边界
Agent 友好因此不等于“页面很多”，也不只是“文档可以被读取”。真正重要的是：开发者提出问题后，Agent 能否沿着公开资料找到足够的信息，给出可检查、可继续执行的答案。
愿景：让 Agent 找得到，也让开发者走得更快
Agent 友好首先服务于开发者本人。
做网页或 App 收款时，你应该能快速找到适合的产品；为 API、Skill 或 MCP 工具设计按量付费时，你应该能直接看到对应路径；准备测试时，也应该知道沙箱、测试身份、验证方式和上线前检查项分别在哪里。
当这件事做好以后，开发者不必先熟悉整个支付产品体系，也不必在多个页面之间反复搜索和拼接流程。你可以直接告诉 Agent 自己的业务形态，再让它基于官方资料帮助你：
- 理解不同支付产品的适用场景；
- 找到接入前需要完成的准备；
- 梳理从 Quickstart 到 Sandbox 的操作顺序；
- 检查测试、上线与安全事项是否遗漏。
这并不意味着把选择权交给 Agent。产品是否适合、何时上线，仍由开发者判断；Agent 的价值是减少寻找信息的成本，让开发者更快走到真正需要决策和动手的地方。
同一套清晰的资料结构也会同时改善人的体验：入口更直接、步骤更连贯、内容更容易引用，第一次接入的开发者和 Agent 都能少走弯路。
AI 付的 Agent 友好：怎样把“有资料”变成“用得上”？
一个页面里有说明，不代表陌生 Agent 能稳定地找到并用上它。产品能力可能已经写在官网里，但开发者仍然不知道该选哪一种方案；沙箱入口可能已经存在，但测试身份、验证方法和上线切换的说明散落在不同位置；关键步骤也可能位于折叠或交互区域中，缺少一个可以直接引用和分享的公开链接。
因此，我们把 Agent 友好当作一段完整的开发者体验来建设，并通过静态评测与动态评测持续检查这条路径：静态评测检查资料是否完整、默认入口是否容易发现；动态评测则让 Agent 带着真实问题进入站点，验证这些资料能否真正支撑任务完成。
静态评测首先从一个初次访问站点的陌生 Agent 视角出发：不登录后台、不替用户完成点击流程，也不依赖猜测寻找答案，只依据公开页面、站内链接和文档入口，检查以下五类关键问题是否都有清晰、可发现的答案：
- 站点提供什么能力，分别适合什么业务场景；
- 不同业务应该选择哪一种产品或接入方式；
- 接入前需要准备什么，第一步从哪里开始；
- 怎样进入测试环境，并完成验证；
- 上线后如何处理鉴权、回调、重复请求和高风险操作。
评测不是终点，而是用来定位开发体验中的断点。根据这些问题，我们正在让关键资料形成更稳定的公开路径：
- Prerequisites：接入前要准备什么；
- Quickstart：第一步从哪里开始；
- Sandbox Access：如何进入测试环境；
- Test Fixtures：使用什么测试材料、怎样判断结果；
- Go-live Checklist：上线前需要确认什么。
这些内容不需要全部堆在首页，但每一个关键问题都应该有明确、可直接访问的答案，并能从产品页、开发者文档首页和 llms.txt 稳定到达。
这些建设解决的是“资料是否准备好、是否找得到”的问题。但从找到资料到真正帮助开发者完成任务，中间还有一步：Agent 能否理解并组合这些信息，形成可信、可执行的判断。这正是动态评测需要回答的问题。
动态评测不会预先告诉 Agent 答案位于哪个页面，也不会指定读取方式。Agent 需要从开发者的自然语言问题出发，自主找到相关入口、访问公开页面、组合分散的信息，再形成有依据、可继续执行的回答。
我们同时观察结果与过程：Agent 是否回答了问题，是否真正使用了站点资料，关键结论是否有证据支撑，访问路径是否清晰顺畅。由此可以区分“网站没有提供答案”“答案存在但 Agent 找不到”和“Agent 找到资料后没有正确使用”等不同问题。
我们希望建立的不是一个专门“迎合 Agent”的网站，而是一套人和 Agent 都容易使用的接入体验：产品关系说得清、关键资料找得到、可靠证据用得上、接入任务能够顺畅推进。
评测结论：内容已具备，默认路径仍可更近一步
我们对 22 个支付行业站点的公开入口 进行了静态评测。支付宝 AI 付获得 85 分，整体处于行业第一梯队。评测显示，AI 付已形成从产品理解、开发接入到测试验证的基本闭环，产品选择、接入路径、测试与安全说明等公开资料较为完整，并正通过优化默认入口，让关键内容从“已经提供”进一步走向“打开页面就能找到”。
在此基础上，我们通过动态评测观察 Agent 能否把公开资料转化为可信、可继续执行的回答。评测让 Agent 带着开发者常见问题访问站点，同时考察最终回答以及获取和使用信息的过程。结果显示，Agent 平均能够完成 90% 的任务要求，回答中 81% 的关键结论有公开资料作为依据。
静态评测回答“资料是否准备好了”，动态评测进一步回答“Agent 能否真正用好这些资料”。两者结合，让 Agent 友好不再只是页面和文档的建设指标，而是成为一种可以持续验证的开发者体验。
支付宝 AI 付将继续围绕产品选择、快速开始、沙箱测试、上线准备和失败排查，优化官方资料与默认入口，让 Agent 不仅找得到答案，还能基于可信信息帮助开发者继续完成任务。
当官方资料更容易被发现、理解和使用，Agent 才能真正成为开发者的接入助手，帮助开发者更快判断：选什么、怎么接、如何测、出了问题怎么办。
