W701 · Stripe 支付集成 + 多 Agent Persona + SOUL.md 行为边界W701 · Stripe Integration + Multi-Agent Persona + SOUL.md Boundariesv1.0

Bobby
2026 年 7 月July 2026

目录Outline

01

Stripe 支付集成Stripe Integration

02

多智能体协作Multi-Agent Collaboration

03

作业Homework

Stripe 关键概念与链路Stripe Key Concepts and Flow

Product / Price

要卖的产品与价格。一个 Product 可挂多个 Price。The product and its prices. One Product can hold many Prices.

Subscription

持续订阅关系。The ongoing subscription relationship.

Webhook

Stripe 异步通知你的后端付款结果——本次支付集成的关键机制Stripe asynchronously notifies your backend of payment results — the key mechanism of this integration.

Price 的定义方式(同一 Product 可组合多种)Ways to Define a Price (one Product can combine many)

计费类型Type 说明Description 示例Example
一次性 One-timeOne-time 买断,付一次,不续费。Pay once, no renewal. 终身版 $199Lifetime $199
周期订阅 · 按月Recurring · Monthly 每月自动续费。Auto-renews every month. $9.9 / month
周期订阅 · 按年(包年)Recurring · Yearly 每年自动续费,通常折算下来更便宜。Auto-renews yearly, usually cheaper per month. $99 / year
自定义周期Custom interval 每周 / 每季度 / 每半年等。Weekly / quarterly / semi-annual, etc. $25 / 季度$25 / quarter
阶梯 / 按量 Tiered · UsageTiered · Usage-based 按用量或阶梯计费(进阶)。Charge by tier or usage (advanced). 前 1000 次免费,之后每次 $0.01First 1000 free, then $0.01 each

组合玩法:同一个 “Demo Pro Plan” 产品下同时建「月付 $9.9」和「年付 $99」两个 Price,前端让用户选月付还是年付,各自对应不同的 Price ID。Combination: under one "Demo Pro Plan" product, create both a "$9.9/month" and a "$99/year" Price; the frontend lets users pick monthly or yearly, each mapping to a different Price ID.

Stripe payment integration flow

Stripe Dashboard 准备 + 项目环境配置Stripe Dashboard Setup + Project Configuration

Stripe Dashboard 操作 4 步4 Stripe Dashboard Steps

进入测试环境(新版面板为 Sandbox,旧版为 Test mode,均不收真钱)Enter the test environment (new dashboard: Sandbox; older: Test mode — no real charges)
Product catalog → 创建产品 Demo Pro PlanProduct catalog → create Demo Pro Plan
加价格:9.9 USD / month,保存 → 复制 Price IDAdd price: 9.9 USD / month, save, then copy Price ID
Developers → API keys → 复制 Secret keyDevelopers → API keys → copy Secret key

项目侧要准备的两个值Two Values the Project Needs

从上面 Dashboard 会拿到两样东西,先复制留好:You'll get two things from the dashboard above — copy and keep them:

STRIPE_SECRET_KEY = sk_test_...   # 后端用
STRIPE_PRICE_ID   = price_...

这两项具体填在哪个文件、用什么变量名,下一页让 AI 结合你的项目告诉你,这里不用写死。安全底线:Secret Key 只放后端,前端绝不能出现 sk_test / sk_live。Where exactly these go — which file and variable name — the AI on the next page will tell you based on your project; no need to fix it here. Security: keep the Secret Key backend-only, never let sk_test / sk_live appear on the frontend.

Stripe Product and Price page Stripe API keys page Environment variables and Vite config

AI 实现「订阅按钮 → Stripe 付款页」AI Builds “Subscribe Button → Stripe Checkout”

演示目标:浏览器点“开通 Pro” → 跳到 Stripe 官方付款页。Demo goal: click “Upgrade to Pro” in the browser → redirect to Stripe Checkout.

请在当前项目实现固定金额 Stripe 月订阅入口。

【项目背景】
- 前端栈:【例:React + Vite / Vue / Next.js】
- 后端形态:【例:Cloudflare Worker / Firebase Functions / Express】
- 用户系统:【例:Firebase Auth / Supabase / 自建】

【实现要求】
1. 后端暴露接口(如 POST /api/billing/checkout),调 Stripe 创建 Checkout Session 并返回付款页 URL
2. 创建 Session 时把当前登录用户的 ID 通过 client_reference_id 带过去(后续 Webhook 要用)
3. 前端加“开通 Pro”按钮,点击调后端接口拿到 URL 后跳转
4. 支付完成 / 取消后,回到用户发起支付时所在的页面:由前端把当前 window.location.origin 传给后端,后端据此动态拼 success_url / cancel_url,不要把回跳地址写死在环境变量里
5. Stripe Secret Key 不能暴露到前端
6. 请一次性把上述功能全部实现,代码里预留好读取 Stripe Secret Key 和 Price ID 的位置;不要中途停下来等我。完成后在最后清楚告诉我这两项该怎么配:
   - 分别应该填在哪个文件 / 哪个环境变量里(给出确切文件名和变量名)
   - 分别去 Stripe 后台的什么位置获取
   - 我填好后怎样让服务读到它们(如需要重启,给出命令)
7. 沿用项目现有代码风格和样式
Implement a fixed-price monthly Stripe subscription entry in the current project.

[Project context]
- Frontend stack: [e.g. React + Vite / Vue / Next.js]
- Backend shape: [e.g. Cloudflare Worker / Firebase Functions / Express]
- User system: [e.g. Firebase Auth / Supabase / custom]

[Requirements]
1. Expose a backend endpoint such as POST /api/billing/checkout, create a Stripe Checkout Session, and return the Checkout URL
2. Pass the current logged-in user ID through client_reference_id for the later Webhook
3. Add an “Upgrade to Pro” button on the frontend; click it, call the backend, receive the URL, and redirect
4. After success / cancel, return the user to the page they started from: the frontend passes its current window.location.origin to the backend, which builds success_url / cancel_url dynamically — do not hardcode return URLs in environment variables
5. Never expose the Stripe Secret Key to the frontend
6. Implement everything above in one go, leaving code hooks that read the Stripe Secret Key and Price ID; do not stop to wait for me. When done, clearly tell me how to configure these two:
   - which file / which environment variables they belong in (give exact file and variable names)
   - where in the Stripe dashboard to obtain each one
   - how to make the service pick them up after I fill them in (give the restart command if one is needed)
7. Follow the existing project style and code conventions

当场跑通验收:浏览器看到“开通 Pro”按钮 → 点击 → 跳到 Stripe Checkout 页面(显示 Demo Pro Plan · US$9.90/月)→ 前端代码 grep 不到 sk_test。Live check: browser shows “Upgrade to Pro” → click → Stripe Checkout page appears (Demo Pro Plan · US$9.90/month) → frontend code does not contain sk_test.

Upgrade to Pro button Stripe Checkout page

测试卡号(Stripe 官方 · 仅测试模式)Test Card Numbers (Stripe official · test mode only)

所有卡:有效期填任意未来日期(如 12/34),CVC 任意 3 位(Amex 为 4 位),其余字段随意。禁止用真实卡测试。All cards: any future expiry (e.g. 12/34), any 3-digit CVC (4 for Amex), any other fields. Never test with a real card.

场景Scenario 卡号Card number 结果Result
支付成功Success4242 4242 4242 4242Visa,付款成功Visa, succeeds
支付失败Decline4000 0000 0000 0002通用拒付 generic_declinegeneric_decline
支付失败Decline4000 0000 0000 9995余额不足 insufficient_fundsinsufficient_funds
支付失败Decline4000 0000 0000 0069卡已过期 expired_cardexpired_card
支付失败Decline4000 0000 0000 0127CVC 错误 incorrect_cvcincorrect_cvc
需 3DS 验证3DS auth4000 0025 0000 3155弹出二次验证流程triggers 3DS challenge
来源:Stripe 官方文档 Source: Stripe official docs docs.stripe.com/testing

Stripe CLI 安装与登录Stripe CLI Install and Login

① 安装(Windows 推荐 npm)① Install (npm recommended on Windows)

已有 Node.js 环境,直接全局安装即可,跨平台一致:With Node.js installed, one cross-platform global install:

npm i -g @stripe/cli

验证安装成功(能打印版本号即安装完成):Verify the install (a version number means it worked):

stripe --version

② 登录并验证② Log in and verify

执行后会打开浏览器,点确认即把 CLI 与你的 Stripe 账号绑定:Opens a browser; confirm to link the CLI to your Stripe account:

stripe login

whoami 验证登录状态与账号信息(返回 account id / 邮箱即成功):Use whoami to verify login and see account info (returns account id / email):

stripe whoami
Stripe CLI browser authorization page Stripe CLI authorization success page Stripe CLI whoami output

Webhook 本地监听与实现Webhook Local Listening and Implementation

与 Webhook 的关系:为什么本地开发要先跑 stripe listenRelationship with Webhook: why local dev needs stripe listen

本地 localhost 没有公网地址,Stripe 云端无法直接把付款结果回调给你。stripe listen 建立一条隧道,把 Stripe 的事件实时转发到你本地的接口,本地才收得到 Webhook;同时它会打印一个 whsec_ 开头的签名密钥,配到后端环境变量里用于校验签名。Local localhost has no public URL, so Stripe's cloud can't call back your payment results directly. stripe listen opens a tunnel that forwards Stripe events to your local endpoint in real time; it also prints a whsec_ signing secret to put in your backend env for signature verification.

stripe listen --forward-to localhost:8787/api/billing/webhook

# 上面命令会输出,复制到后端环境变量:
STRIPE_WEBHOOK_SECRET=whsec_xxx
请在后端实现 Stripe Webhook 接收端。

【项目背景】
- 后端形态:【例:Cloudflare Worker / Firebase Functions / Express】
- 用户系统:【例:Firebase Auth / Supabase / 自建】
- 用户订阅状态存储位置:【例:Firestore users/{uid} 文档 subscriptionStatus 字段 / 数据库 users 表 subscription_status 列】
- Stripe Webhook Secret 已配在后端环境变量:STRIPE_WEBHOOK_SECRET

【实现要求】
1. 后端暴露 POST /api/billing/webhook 接口
2. 用 STRIPE_WEBHOOK_SECRET 验证 Stripe Webhook 签名(安全关键,不能跳过)
3. 处理以下事件并更新对应用户的订阅状态:
   - checkout.session.completed → "active"
   - customer.subscription.deleted → "canceled"
   - invoice.payment_failed → "past_due"
4. 通过 Checkout Session 的 client_reference_id 拿到当前用户 ID,定位到具体用户记录
5. 处理完返回 200 状态码(不返 200 Stripe 会重试)
6. 沿用项目现有代码风格
Implement the Stripe Webhook receiver on the backend.

[Project context]
- Backend shape: [e.g. Cloudflare Worker / Firebase Functions / Express]
- User system: [e.g. Firebase Auth / Supabase / custom]
- Subscription state storage: [e.g. Firestore users/{uid}.subscriptionStatus / users.subscription_status]
- Stripe Webhook Secret is configured in backend env: STRIPE_WEBHOOK_SECRET

[Requirements]
1. Expose POST /api/billing/webhook
2. Verify the Stripe Webhook signature with STRIPE_WEBHOOK_SECRET; this is security-critical
3. Handle events and update subscription state:
   - checkout.session.completed → "active"
   - customer.subscription.deleted → "canceled"
   - invoice.payment_failed → "past_due"
4. Use client_reference_id from Checkout Session to locate the current user
5. Return HTTP 200 after processing, otherwise Stripe retries
6. Follow existing project style
上面三事件是演示最小集,够跑通即可;正式项目请勾选下一页的标准事件集The three events above are the minimal demo set; for a real project use the standard event set on the next page.
Stripe CLI listen event logs

正式环境 Webhook:标准事件集Production Webhook: Standard Event Set

正式上线不用 CLI,而是在 Dashboard → Developers → Webhooks → Add endpoint 填线上回调地址,并只勾选业务会处理的事件(勾了不处理只会增加噪音与重试)。订阅业务推荐勾以下 6 个:In production you don't use the CLI — go to Dashboard → Developers → Webhooks → Add endpoint, enter your live callback URL, and select only the events you handle. For subscription billing, these 6 are recommended:

事件Event 含义 / 何时触发Meaning / when it fires 后端应做What to do
checkout.session.completedCheckout 付款流程完成Checkout flow completed用 client_reference_id 关联用户,开通入口Link user via client_reference_id
customer.subscription.created订阅被创建(可能 incomplete 待认证)Subscription created (may be incomplete)记录订阅初始状态Record initial state
customer.subscription.updated订阅任意变化(套餐/优惠/状态Any change (plan / discount / status)状态事实来源:同步本地 = subscription.statusStatus source of truth: sync to subscription.status
customer.subscription.deleted订阅结束Subscription ended回收 Pro 权限 → canceledRevoke access → canceled
invoice.paid发票支付成功(首期或续期)Invoice paid (first or renewal)active 事实来源:置 active、延长有效期active source of truth: set active, extend
invoice.payment_failed发票支付失败Invoice payment failed→ past_due:通知用户、催缴/重试→ past_due: notify / retry
Production webhook event selection

支付成功与 Stripe 交易记录验证Payment Success and Stripe Transaction Verification

业务规则Business Rules

active / trialing → 可用 Pro 功能;未订阅 / canceled / past_due → 禁用 Pro 功能,显示订阅引导。active / trialing → Pro feature available; no subscription / canceled / past_due → disable Pro feature and show subscription prompt.

安全原则Safety Rule

权限判断必须读数据库订阅状态,不能只看支付回跳 URL。Access control must read subscription state from the database, not just the payment return URL.

请把订阅状态接入前端 Pro 功能权限。

【项目背景】
- 前端栈:【例:React + Vite / Vue / Next.js】
- 用户系统:【例:Firebase Auth / Supabase / 自建】
- 订阅状态存储位置:【例:Firestore users/{uid} 文档 subscriptionStatus 字段】
- 当前项目里要变成 Pro 的功能:【例:本演示中是“语音实战面试”,你的项目里替换为对应功能名】

【实现要求】
1. 业务规则:
   - subscriptionStatus 为 active 或 trialing → 可用 Pro 功能
   - 未订阅 / canceled / past_due → 禁用 Pro 功能,显示订阅引导
2. 前端权限判断必须读数据库订阅状态,不要只根据支付回跳 URL 判断
3. 无权限时展示订阅引导(含“开通 Pro”按钮)
4. 有权限时正常展示 Pro 功能
5. 沿用项目现有代码风格
Connect subscription state to frontend Pro feature access.

[Project context]
- Frontend stack: [e.g. React + Vite / Vue / Next.js]
- User system: [e.g. Firebase Auth / Supabase / custom]
- Subscription state storage: [e.g. Firestore users/{uid}.subscriptionStatus]
- Feature to turn into Pro: [e.g. "voice mock interview" in this demo; replace it with your project feature]

[Requirements]
1. Business rules:
   - subscriptionStatus active or trialing → Pro feature available
   - no subscription / canceled / past_due → disable Pro feature and show subscription prompt
2. Frontend access control must read subscription state from database, not just the payment return URL
3. Show subscription prompt with “Upgrade to Pro” when unauthorized
4. Show Pro feature normally when authorized
5. Follow existing project style
Stripe Dashboard payment record

支付集成检查清单Payment Integration Checklist

功能闭环Functional Loop

订阅按钮能创建 Checkout SessionThe subscribe button can create a Checkout Session
测试卡付款后能收到 WebhookWebhook is received after test-card payment
数据库订阅状态会更新The subscription state is updated in the database
Pro 功能按订阅状态解锁Pro features unlock based on subscription state

安全边界Security Boundaries

Secret Key 只出现在后端环境变量Secret Key appears only in backend environment variables
Webhook 必须校验签名Webhook signatures must be verified
权限判断读取数据库,不读取 URL 参数Access control reads the database, not URL parameters
测试模式与正式模式密钥分开Test-mode and live-mode keys stay separate

SOUL.md 核心:五原则与四章节SOUL.md Core: Five Principles and Four Sections

没有人格的 Agent = 低速搜索引擎。SOUL.md 就是给 Agent 注入人格的那一层。An agent without personality is a slow search engine. SOUL.md is the layer that gives it one.

官方速查 · 五条核心真相Official Reference · Core Truths

真实帮助(跳过填充语,直接动手)Genuine help: skip filler, get to work
人格至关重要(要有观点 / 判断力)Personality matters: have views / judgment
主动解决问题(先自查再求助)Proactively solve: self-check first
通过能力建立信任(外部谨慎、内部积极)Trust via capability: cautious out, bold in
尊重边界(隐私绝对、不发不完整答案)Respect boundaries: privacy absolute

官方速查 · 四章节结构Official Reference · Four Sections

核心真相(Core Truths):基本立场Core Truths: foundational stances
边界(Boundaries):隐私与外部操作谨慎Boundaries: privacy & external caution
气质(Vibe):人格底色Vibe: underlying personality
连续性(Continuity):跨会话记忆Continuity: cross-session memory

“把 AGENTS.md 用于操作规则。把 SOUL.md 用于声音、立场和风格。”"Keep AGENTS.md for operating rules; keep SOUL.md for voice, stance, and style."

来源:OpenClaw 官方文档 Source: OpenClaw official docs docs.openclaw.ai/concepts/soul

用人格与行为边界区分多智能体角色Differentiating Agents by Persona and Boundaries

多 Agent 协作里,凭什么让每个 Agent 各司其职、不互相打架?——给每个 Agent 一套不同的人格(气质 Vibe)加一套不同的行为边界(Boundaries)。这不是装饰,而是区分多智能体、让它们能分工的一个核心设计手段。In multi-agent collaboration, what keeps each agent in its lane and out of the others' way? Give each a distinct persona (Vibe) and a distinct set of behavioral boundaries. Not decoration — it's a core way to differentiate agents so they can divide the work.

人格(气质)——定角色的"调性"Persona (Vibe) — sets a role's tone

气质写成硬规则就能确定性地决定一个角色怎么说话,而不是"希望它友好一点"这种没有行为效果的话。同一问题、只改气质章节,输出就完全不同:Write the Vibe as hard rules and it deterministically shapes how a role speaks — not vague wishes like "be friendly". Change only the Vibe section and the same question yields very different output:

直给型:首句必须给判断("问题在于…")、禁用鼓励句、能一句不说两句Blunt: first sentence must give a verdict, no encouragement, never two sentences where one suffices
共情型:首句先共情、每步附引导、结尾收一句鼓励Empathetic: open with empathy, guide each step, close with encouragement

放到 3-agent:诊断官要"直给判断"、客服要"共情耐心"——靠各自的气质规则分开。In the 3-agent chain: the diagnostician is blunt, the support agent is patient — separated by their Vibe rules.

行为边界——划角色的"能力圈"Boundaries — set a role's limits

边界规定每个角色能做 / 不能做。官方 Boundaries 四点:Boundaries define what each role may / may not do. The four official ones:

隐私优先,敏感信息不外传Privacy first; never leak sensitive data
外部操作谨慎、内部操作积极Cautious with external actions, bold with internal ones
不发不完整答案Never send incomplete answers
公开渠道语气得体(Sharp is good, annoying is not)Fit public-channel tone (sharp is good, annoying is not)

放到 3-agent:质检官边界=不合格不放行;客服边界=不擅自承诺退款、涉及金额先确认、不泄露他人订单。In the 3-agent chain: the QA agent won't pass substandard output; the support agent never promises refunds on its own, confirms before any payment action, and never leaks others' orders.

“有个性不等于可以草率。”——人格给角色调性,边界给角色底线;两者相加,才是一个能放进真实业务的多智能体角色。"Personality is not permission to be sloppy." Persona gives a role its tone, boundaries give it its floor; together they make a multi-agent role you can actually deploy.

来源:每个 Agent 各自一份 SOUL.md,是各自的“人格边界”,官方原文 “each agentId is a distinct persona boundary… different personalities (per-agent SOUL.md)” —— Source: each agent has its own SOUL.md as a “distinct persona boundary” per official docs — docs.openclaw.ai/concepts/multi-agent;SOUL / Boundaries 定义见 ; SOUL / Boundaries defined in concepts/soul

多 Agent 在飞书群里怎么协作How Multiple Agents Collaborate in Feishu

Feishu Group User Bot A Bot B Bot C @A @B @C Output

关键依赖版本Required Versions

OpenClaw 2026.5.7+
@larksuite/openclaw-lark 2026.5.13+

配置三步走Three Configuration Steps

建 Agent → 关联飞书机器人 → 写 AGENTS.md 定义协作规则(“做完 X 后 @ 哪个 Bot”)。Create Agent → link Feishu bot → write AGENTS.md to define collaboration rules ("after X, @ which bot").

机制依据:一个 Gateway 跑多个隔离 Agent,按 channel / account / peer 路由消息。来源:OpenClaw 官方文档 Basis: one Gateway runs multiple isolated agents, routing messages by channel / account / peer. Source: OpenClaw official docs docs.openclaw.ai/concepts/multi-agent
延伸自学(本课不演示):除频道 @ 接力外,OpenClaw 还提供原生子 Agent 委派 sessions_spawn / sessions_yield(隔离上下文、完成后回传结果),适合并行 / 长任务。 Further self-study (not demoed here): besides channel @ relay, OpenClaw offers native sub-agent delegation via sessions_spawn / sessions_yield (isolated context, results announced back), good for parallel / long tasks. docs.openclaw.ai/tools/subagents

3 智能体协作链Three-Agent Collaboration Chain

01

AIV 诊断官AIV Diagnostic Officer

针对小鹏汽车做 AI 可见度诊断。Diagnose AI visibility for XPeng Motors.

02

GEO 内容官GEO Content Officer

输出优化文案。Produce optimization copy.

03

交付质检官Delivery QA Officer

进行质检。Run delivery quality check.

@AIV诊断官 + 任务描述

关键设计要点:飞书卡片不解析 @Key Design Rule: Feishu cards don't parse @

当 Agent 输出包含 Markdown 代码块Markdown 表格时,飞书插件会把消息转为静态卡片;卡片里的 @xxx 是纯文本,不被解析为飞书原生 mention,下一个 Bot 不会被触发,协作链就此断掉。When an agent's output contains Markdown code blocks or Markdown tables, the Feishu plugin sends it as a static card. Inside that card, @xxx is plain text and is not parsed as a native mention, so the next bot is never triggered and the chain breaks.

3 条设计建议3 Design Rules

协作交接消息禁止包含代码块和表格(写进 SOUL.md / AGENTS.md 作为硬规则)Hand-off messages must not contain code blocks or tables (write it into SOUL.md / AGENTS.md as a hard rule)
必要展示代码 / 表格时拆两条消息:第一条纯文本完成 @ 下一棒,第二条带详情When code / tables are needed, send two messages: first is plain text with @ to the next bot, second carries the details
配置插件 replyMode 时注意:即便选 static,内容里有代码块或表格仍会转卡片When configuring the plugin's replyMode: even when set to static, code blocks or tables still trigger card rendering

作业Homework

在你自己的项目里跑通 Stripe 支付端到端(最小骨架即可)。Run an end-to-end Stripe payment flow in your own project; a minimal skeleton is enough.
设计 2 个不同 Persona,各自有完整 SOUL.md。Design two different personas, each with a complete SOUL.md.
把这 2 个 Persona 关联飞书机器人,在飞书群里做一次协作对话 Demo。Link the two personas to Feishu bots and run one collaboration conversation demo in a Feishu group.

提交方式Submission

操作截图 / 录屏 / SOUL.md 文件Screenshots / screen recording / SOUL.md files

截止时间Deadline

北京时间 2026 年 7 月 17 日 08:40 前
纽约时间 2026 年 7 月 16 日 20:40 前
Before July 17, 2026, 08:40 Beijing time
Before July 16, 2026, 20:40 New York time