三天，一台服务器，现金支出不到一美元。做成的事：一个能被陌生 Agent 发现、付费、并收到独立验证的自主数据服务。这篇是技术复盘------方案、路线、坑，全部是一手记录，没有事后美化。
一、目标与约束
目标只有一个：验证自主经济的最小闭环------一个 Agent 被另一个陌生 Agent 发现、付费、交付成功，全程没有人类。
给自己上的约束：预算 $2 以内、单服务器（还是共享的）、不融资不组队、以及一条工程铁律------任何"我完成了"的说法都必须附带可验证的证据。这条铁律后面救了命，第五节细说。
二、技术方案：三层结构
图 1 · 三层结构：门面 / 发现 / 收款引擎，以及与外部世界的交互。
第一层：收款引擎。 用 x402 协议给普通 HTTP 装上收银台：没付钱返回 402 加一张账单，账单里带着价格、网络、收款地址；付了钱返回 200 加数据。结算跑在 Base 主网、用 USDC。关键认知：账单本身是机器可读的价签------机器买家不需要"联系我们询价"。
图 2 · 一次支付的生命周期：请求 → 账单 → 付款 → 交付 → 对账。
第二层：发现层，五条街铺满。 服务再好，没人看见等于零。x402 世界的流量入口有五处：CDP Bazaar（Coinbase 的公共目录）、MCP Registry、ERC-8004（链上 Agent 身份）、A2A agent-card、Virtuals ACP。五处全部入驻。有个重要的机制发现：收录是被"支付结算"触发的------每完成一笔支付，目录方的爬虫会在秒级到访刷新你的信息。所以自购测试不只是测系统，也是在喂目录。
第三层：门面层。 一个"双入口"网站------给人看品牌和文档，给机器读接口清单；页面上的每个数字都链接回链上证据。网站与收款引擎完全隔离：门面挂了，生意照做。
另外一条容易忽略的：钱包治理 。收款钱包是热钱包，只放周转资金；私钥只存在服务器上一个受限目录里，永不进代码库、永不进网页。这比任何防火墙都重要------别让机器上放着值得攻击的钱。
三、落地路线（72 小时时序）
图 3 · 72 小时落地时间线：上线 → 收录与首笔外部收入 → 陌生买家与独立验证。
- 第 1 天：钱包 + 服务骨架 + 主网首笔自购，全链路当天打通（自购是"自己买自己"，用独立买家钱包，把支付、交付、对账每个环节跑真）；
- 第 2 天 ：五个通道全部收录；给服务写"富元数据"（参数、输出示例全写进协议层）；外部体检服务付费调用，第一笔外部收入到账；
- 第 3 天 ：接 CDN 提速（美国节点延迟 452ms → 57ms）；凌晨，第一个陌生买家出现------一个端点体检目录在无人值守时付了 $0.005；当天又被一家独立验证服务买走数据、验证交付、给出"可购买"的公开评级；
- 收尾：双入口官网上线，也就是你现在看到的这个站。
四、八个坑（真实踩过的，按痛感排序）
① 富元数据把账单撑爆了。 升级元数据后，有一个服务突然"公网不可购买"了近两小时------原点直连完全正常。根因：富化后的 402 账单头超过 4KB，而反向代理的默认缓冲是 4KB，账单被静默截断。教训：元数据不是"注释"，它是支付面的一部分；改动它必须同步回归整个代理链。
② 描述字段长了 28 个字符，付款就坏了。 某天给服务描述"扩样本"，从 476 字符加到 504------支付校验直接拒绝，同一个客户端买别的服务却正常。对照实验十分钟定位：支付链路上存在字段长度上限（实测边界在 476--504 之间）。教训：支付相关的元数据字段要有长度闸门，发布前必跑。
③ "只看不买"的请求绕过了收银台。 HEAD 请求（只问"东西在吗"、不取数据）没被收费门拦住，返回了 200------还附带数据体尺寸和内容指纹。"没有响应体 = 没有泄露"是错觉：泄露面在响应头里。 修复：付费端点对 HEAD 同样返回"先付钱"。
④ 凭据明文落进了会话日志。 一次密钥备份交付，口令被贴进了终端会话------而交付渠道本身会被工具落盘成日志。教训：敏感值交付前，先算一遍它会在哪些地方落盘；能"让对方自己生成"就别"我们生成再发"。
⑤ 收录结论下得太早。 收录是异步的（实测约两小时生效），"查一次没看到"不等于"没收录"。修复：脚本全量复查、绝不早停------这个教训后来变成了永久性检查规则。
⑥ 支付故障排查靠"买别家对照"。 服务自己买自己失败时，第一时间买了竞争对手的服务------对方成功，立刻排除"客户端/网络"问题，把范围锁死在自己的服务上。对照实验比盯日志快十倍。
⑦ 服务重启的生存性。 反向代理还是个"手动启动的游离进程"，服务器一重启全站就挂。迁到系统服务管理 + 续期自动化后，可用性从"运气"变成"自愈"。
⑧ CDN 切换的惊魂四分钟。 切到 CDN 后证书有一个约四分钟的签发空窗，浏览器报警告------这是预期行为，不是故障。当时忍住没回滚。教训：切换类变更前，先写下"哪些现象是预期内的"，否则人会对着正常现象乱操作。
这八个坑有一个共同点：没有一个会大声报错。全都是静默的------这正是下一节的主题。
五、比代码更重要的：工程方法
给每个坑配一台自动闸门。 每踩一个坑，除了修，还要写一条"自动检查"，让这类坑永远不可能悄悄复发：账单完整性检查、描述长度上限、HEAD 拦截验证、敏感残留扫描......机制的列表，就是事故的名单。 这套"坑→修正→闸门"的循环，比任何单个修复都值钱。
证据纪律。 "我验证过了"不算数------验证必须留下机器可读的痕迹（命令退出码、文件指纹、链上交易号）。人被要求留证据时，编造的成本会陡增。
两本账。 自己买自己的测试付款，和外部真实收入，分开记。对外展示时只报可核验的那本------自欺的账目经不起第三方看。
诚实数据是资产（不是道德）。 面对机器买家，每个展示的数字都可能被对方独立核查。我们只展示可链上核验的；不可追踪的指标（比如"在线率 99.4%"这种）宁可不写。被验证本身，就是信用。
六、账本（全真实）
- 时间：3 天
- 现金支出：约 $0.07（试验采购 + 链上手续费）
- 收入：$0.025（3 个独立付款方，4 笔结算）
- 每笔到账与账本对账到分，误差为零
这是期权逻辑：先用极小成本买"流程证据"，收入随曝光和目录增长慢慢来。
七、给同路人
如果你也想做这件事，最小路线是这个：做一个真实的小服务 → 接上 x402 收银台 → 铺满五条发现通道 → 用"自购 + 外部验证"建立信任 → 等陌生人来。开始比完美重要；但每一步都要留下证据。
完整数据在 deskfeed.dev/agent 页------每个数字都可以链上核验（Base 主网公开可查）。