Stripe 推出的基准套件，把 AI Agent 放进接近真实生产环境的支付集成任务中：它不仅要编写后端接口，还要连接前端与浏览器结账流程，并证明整个链路确实可用。研究传递出的关键信号很直接：Agent 往往能够产出集成代码，但在执行、测试和验证环节仍容易留下缺口。
支付集成不是一次 API 调用
一个 Stripe 集成至少横跨三层：
- 后端创建 Checkout Session，并正确处理金额、币种和商品信息。
- 前端跳转到托管结账页，再处理成功、取消和重复操作。
- Webhook 验证签名，根据异步事件更新订单，而不是盲目信任浏览器跳转结果。
这类任务很适合检验 Agent 的端到端工程能力。生成一个看起来合理的 checkout.sessions.create() 调用并不难，难点是确认它能启动、能访问、能在异常输入下返回正确状态，并且不会把未付款订单标记为已完成。
因此，评估 Agent 时不能只检查代码是否出现了正确的 SDK 方法。更有价值的问题包括：依赖是否能安装、环境变量是否完整、路由能否实际调用、Webhook 原始请求体是否保留、测试是否真正执行，以及浏览器最终看到的状态是否与服务端一致。
最容易漏掉的是“证据”
Agent 生成的支付代码可能通过静态检查，却仍然无法投入使用。常见风险包括：
- 使用占位价格或错误币种，但测试只断言 HTTP 200。
- 成功页出现后直接认为付款成功，没有等待服务端接收 Webhook。
- Express 在签名验证前解析了 JSON，导致 Webhook 验证失败。
- 测试只覆盖正常路径，没有检查缺少参数、重复事件和网络超时。
- 浏览器自动化只点击按钮，没有断言页面跳转目标和最终订单状态。
这正是“实现”与“验证”的边界：实现回答代码能否表达意图，验证回答系统是否在真实约束下兑现意图。对支付、身份认证和基础设施变更来说，后一个问题通常更重要。
可以这样实践：给 Agent 一条可验证的最小链路
下面不是 Stripe 基准套件的原始题目，而是一个可以用于内部评测的最小项目。运行前需要安装 Node.js，并把测试模式密钥写入 .env。不要使用生产密钥。
先创建项目并安装依赖：
mkdir stripe-agent-check && cd stripe-agent-check
npm init -y
npm install express stripe dotenv
printf 'STRIPE_SECRET_KEY=sk_test_replace_me\nSTRIPE_WEBHOOK_SECRET=whsec_replace_me\n' > .env
创建 server.js：
require("dotenv").config();
const express = require("express");
const Stripe = require("stripe");
const app = express();
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
// Webhook 必须在 express.json() 之前读取原始请求体。
app.post("/webhook", express.raw({ type: "application/json" }), (req, res) => {
try {
const event = stripe.webhooks.constructEvent(
req.body,
req.headers["stripe-signature"],
process.env.STRIPE_WEBHOOK_SECRET
);
if (event.type === "checkout.session.completed") {
console.log("paid session:", event.data.object.id);
}
res.json({ received: true });
} catch (error) {
res.status(400).json({ error: `Invalid webhook: ${error.message}` });
}
});
app.use(express.json());
app.post("/checkout", async (req, res) => {
try {
const quantity = Number(req.body.quantity);
if (!Number.isInteger(quantity) || quantity < 1 || quantity > 10) {
return res.status(400).json({ error: "quantity must be an integer from 1 to 10" });
}
const session = await stripe.checkout.sessions.create({
mode: "payment",
line_items: [{
quantity,
price_data: {
currency: "usd",
unit_amount: 1500,
product_data: { name: "Agent integration test item" }
}
}],
success_url: "http://localhost:3000/success?session_id={CHECKOUT_SESSION_ID}",
cancel_url: "http://localhost:3000/cancel"
});
res.status(201).json({ id: session.id, url: session.url });
} catch (error) {
res.status(502).json({ error: error.message });
}
});
app.get("/success", (_req, res) => res.send("Checkout returned successfully"));
app.get("/cancel", (_req, res) => res.send("Checkout cancelled"));
app.listen(3000, () => console.log("Listening on http://localhost:3000"));
启动服务并验证输入边界：
node server.js
# 另开终端：无效数量应返回 HTTP 400
curl -i -X POST http://localhost:3000/checkout \
-H 'Content-Type: application/json' \
-d '{"quantity":0}'
# 有效请求应返回 HTTP 201、Session ID 和 Stripe Checkout URL
curl -i -X POST http://localhost:3000/checkout \
-H 'Content-Type: application/json' \
-d '{"quantity":1}'
如果本机安装了 Stripe CLI，还可以把测试事件转发到本地服务。先用测试账户登录，再替换 .env 中的 STRIPE_WEBHOOK_SECRET：
stripe listen --forward-to localhost:3000/webhook
stripe trigger checkout.session.completed
这组步骤不只验证“代码存在”，还验证进程可以运行、错误输入被拒绝、Stripe 能创建会话、Webhook 签名路径可以执行。进一步评测浏览器流程时，可以要求 Agent 使用 Playwright 打开返回的 url，完成测试模式付款，并在服务端观察到对应的 checkout.session.completed 事件。
把验收标准写进任务，而不是留给 Agent 猜
采用这类 Agent 时，可以把任务拆成可观察的检查点：
- 构建检查：从空目录安装依赖并启动服务，禁止依赖未声明的全局工具。
- 接口检查：覆盖正常输入、无效输入、Stripe API 失败和超时。
- 安全检查：密钥只从环境变量读取，Webhook 必须验证签名，日志不得输出敏感数据。
- 浏览器检查：断言跳转域名、取消路径、成功返回页和重复点击行为。
- 业务检查：只有经过服务端确认的异步事件才能改变订单状态，并对重复事件保持幂等。
- 证据检查：要求提交测试命令、退出码、关键响应和浏览器断言，而不只是提交源码。
Stripe 的这项基准工作提醒开发团队：衡量 Agent 不能停留在“是否写出了像样的代码”。在真实支付链路中，执行结果、测试覆盖和验证证据才决定集成是否可信。更稳妥的采用方式，是让 Agent 负责实现和修复循环，同时用确定性的测试、沙箱账户、权限边界与人工审查约束最终交付。