AI 编程代理已经能够跨越后端接口、前端页面和浏览器操作来搭建 Stripe 集成，但 Stripe 推出的基准测试把问题推进了一步：代理生成了代码之后，能否真正执行、测试并验证完整支付流程？在接近生产环境的约束下，“代码看起来正确”和“系统可以交付”之间仍有明显距离。
基准测试关注的是端到端工程能力
普通代码评测往往检查函数输出、单元测试通过率或补丁是否能编译。Stripe 的测试场景覆盖后端、前端和浏览器结账流程，因此代理需要处理一条更长的链路：
- 后端创建支付或 Checkout 会话。
- 前端发起结账并跳转到托管页面。
- 浏览器完成用户交互。
- 服务端接收回调或 webhook。
- 测试确认金额、状态、跳转地址和异常路径符合预期。
这种任务不是“调用一次 API”那么简单。环境变量、测试密钥、URL 配置、异步事件、浏览器状态和错误处理都会影响最终结果。代理即使成功生成了大部分集成代码，也可能没有证明代码真的运行过，更没有证明支付结果能被业务系统可靠确认。
最危险的误判：把执行成功当成业务正确
支付集成中的失败经常不是语法错误，而是验证缺失。例如，Checkout 页面能够打开，却使用了错误币种；付款完成后浏览器跳转成功，但 webhook 签名没有校验；测试只覆盖成功支付，没有检查重复事件和失败支付。
因此，评估代理时至少要区分三个层次：
- 构建：代码、依赖和配置能否正确生成。
- 执行：服务能否启动，API 和浏览器流程能否跑通。
- 验证：系统是否检查了金额、币种、支付状态、签名和幂等性等业务不变量。
第三层最容易被省略，也最接近生产事故发生的位置。HTTP 200 只能说明请求被接受，不能说明订单已经安全结算。
可以这样实践：建立一个可验证的最小 Checkout 服务
下面不是该基准测试的官方实现，而是一种可改造的验证样例。它使用 Flask 创建 Stripe Checkout Session，并对 webhook 进行签名校验。运行前需要准备 Stripe 测试密钥，把 STRIPE_SECRET_KEY 和 STRIPE_WEBHOOK_SECRET 替换为测试环境中的值。
# app.py
import os
import stripe
from flask import Flask, jsonify, request
app = Flask(__name__)
stripe.api_key = os.environ["STRIPE_SECRET_KEY"]
WEBHOOK_SECRET = os.environ["STRIPE_WEBHOOK_SECRET"]
@app.post("/checkout")
def create_checkout():
session = stripe.checkout.Session.create(
mode="payment",
line_items=[{
"price_data": {
"currency": "usd",
"product_data": {"name": "Agent validation demo"},
"unit_amount": 1500,
},
"quantity": 1,
}],
success_url="http://localhost:5000/success?session_id={CHECKOUT_SESSION_ID}",
cancel_url="http://localhost:5000/cancel",
)
return jsonify({"id": session.id, "url": session.url})
@app.post("/webhook")
def webhook():
try:
event = stripe.Webhook.construct_event(
request.get_data(),
request.headers.get("Stripe-Signature", ""),
WEBHOOK_SECRET,
)
except (ValueError, stripe.error.SignatureVerificationError):
return jsonify({"error": "invalid webhook"}), 400
if event["type"] == "checkout.session.completed":
session = event["data"]["object"]
if session.get("payment_status") != "paid":
return jsonify({"error": "unexpected payment status"}), 409
app.logger.info("validated paid session %s", session["id"])
return jsonify({"received": True})
@app.get("/success")
def success():
return "Payment flow returned successfully", 200
@app.get("/cancel")
def cancel():
return "Payment was cancelled", 200
if __name__ == "__main__":
app.run(port=5000, debug=True)
安装依赖并启动服务：
python -m venv .venv
. .venv/bin/activate
pip install flask stripe
export STRIPE_SECRET_KEY='sk_test_replace_me'
export STRIPE_WEBHOOK_SECRET='whsec_replace_me'
python app.py
另开终端检查后端返回的不是任意成功响应，而是同时包含会话 ID 和可跳转 URL：
curl --fail-with-body -sS -X POST http://localhost:5000/checkout \
| python -m json.tool
如果本地安装了 Stripe CLI，可以把测试事件转发给服务，再通过测试模式完成浏览器支付：
stripe listen --forward-to localhost:5000/webhook
这个样例仍然不是生产实现。实际系统应把已处理的 event.id 写入具有唯一约束的持久化存储，以抵御 webhook 重放；订单状态应由服务端验证结果更新，不能仅凭成功跳转页面确认付款。
给代理增加一份“完成定义”
要提高 AI 代理在此类任务中的可靠性，提示词不应只写“集成 Stripe Checkout”。可以把可验收条件直接交给代理：
实现测试模式下的 Stripe Checkout，并完成以下验证：
- 服务可通过一条命令启动；
- 创建会话接口返回非空的 id 和 HTTPS Checkout URL；
- 金额固定为 1500 美分，币种为 USD；
- webhook 必须验证 Stripe-Signature；
- 无效签名返回 400；
- checkout.session.completed 只有在 payment_status=paid 时更新订单；
- 重复 event.id 不得重复履约；
- 提供成功、取消、无效签名和重复事件的自动化测试；
- 输出实际执行过的命令及测试结果。
这里的关键不是让代理多写一段解释，而是要求它提交可观察的证据：启动日志、测试结果、浏览器断言和事件处理记录。验证条件越具体，评审者越容易区分“生成了集成”与“完成了集成”。
采用时要守住的边界
Stripe 的基准测试提醒团队，AI 代理的价值不应只用代码生成速度衡量。支付、身份认证和权限控制等高风险集成需要独立验证层：测试密钥与生产密钥隔离，webhook 签名和幂等性必须由服务端保证，浏览器成功页面不能充当付款凭证。
更稳妥的采用方式是让代理负责实现和执行测试，让 CI 固化业务不变量，再由工程师审查资金状态转换、重试和异常路径。代理可以缩短接线时间，但是否能够上线，仍应由可重复的端到端验证结果决定。