我们审计 botlington.com 本身时发现的内容

Source: Dev.to

请提供您希望翻译的正文内容，我将为您翻译成简体中文并保持原有的格式和代码块不变。

销售的第一条规则：先确保它在自己身上有效。

We sell agent token audits. So we audited botlington.com — the product that does the auditing — against the same framework we use on everything else. Can an agent discover us? Use us? Get what it needs without wasting tokens?

设置

我们的审计框架在六个维度上进行评分：

每个维度的评分为 1–10，随后乘以权重。总分 ≥ 60/100 表示“你的代理在烧钱”。

Source: …

调研结果

维度 1 – 代理可发现性 — 8/10

• Botlington 在 /.well-known/agent.json 提供了 Agent Card。
• 内容正确、体积小（约 700 字节），向代理提供了所有必要信息：服务目的、端点 URL、支持的认证方案以及可用的技能。
• 这比我们审计的 90 % 产品要好（大多数根本没有此类卡片）。

差距： auth.credentials 字段引用了 get‑api‑key，但未提供该端点的机器可读描述。代理仍需访问面向人的结算页面才能了解定价。

修复建议： 在 Agent Card 中添加 pricing 字段（单个 JSON 对象）。代理不应需要爬取营销页面来获取费用信息。

维度 2 – 令牌效率 — 5/10

• 首页大小：24,123 字节（约 6,000 令牌）。
• /audit 页面大小：15,501 字节（约 3,900 令牌）。
• 总计：≈ 10,000 令牌 的 HTML，才能让代理执行任何有用操作。

其中大部分是视觉填充（动画终端、表情符号图形、推荐语、FAQ 手风琴），对代理 没有任何价值。相比之下，Agent Card 只有 700 字节。

结果： 同样信息的令牌开销约为 34 倍。

修复建议： 提供一个轻量级端点（例如 /agent 或 /capabilities），返回 ≈ 200 令牌 的纯文本摘要：你做什么、如何使用以及定价。代理可以从 Agent Card 中发现该端点；人类仍可继续使用现有的营销页面。

维度 3 – 代理的认证体验 — 4/10

• 当前流程：人类进行卡片支付 → 成功页面显示 API 密钥 → 人类复制密钥 → 代理进行认证。
• 这是一种 面向人类 的流程，代理被附加在最后，而不是自主的代理‑对‑代理支付流程（A2A 微支付、代理钱包）。

我们尚未解决自主支付；相关基础设施尚未广泛可用。当前的 “最小可行入职” 需要人为购买并触发。

评分依据： 我们诚实地指出了差距，且前进路径清晰，但问题属于基础设施层面，而非懒惰导致。

维度 4 – 工具接口质量 — 7/10

• A2A 端点（/a2a）使用简洁的 JSON‑RPC。
• 未认证请求返回正确的错误码；失败时不返回 HTML；也没有 200 响应中隐藏错误的情况。

curl -X POST https://botlington.com/a2a \
     -H "Content-Type: application/json" \
     -d '{"message":"hello"}'
# → {"jsonrpc":"2.0","id":null,"error":{"code":-32600,"message":"Invalid request"}} 

差距： 对话审计流程在 7 轮交互中是有状态的，但若连接中断，没有会话恢复机制。代理被迫重新开始会浪费令牌。

修复建议： 在首次响应中返回 session ID，并允许使用该 ID 在任意轮次恢复会话。

维度 5 – 错误沟通 — 8/10

• 错误采用结构化 JSON，并使用正确的 HTTP 状态码（401 表示认证失败，400 表示请求格式错误）。
• 正常运行时没有意外的 500 错误。

差距： 部分错误信息是面向人类的文字描述（例如 “Invalid request”），而非机器可读的代码。需要根据具体失败原因进行分支的代理缺乏足够的细粒度信息。

维度 6 – 文档密度 — 6/10

• /audit 页面对人类解释得很好，但未针对需要结构化数据（定价、约束、输入/输出模式）的代理进行优化。
• Agent Card 已覆盖基础信息，但缺少专门的 agent docs 页面，列出每个输入字段、响应结构和错误码的可解析格式。

修复建议： 发布机器可读的文档端点（例如 /agent-docs），提供完整的模式定义。只需一个下午即可完成。

The score

63/100 – 稍高于我们“你有问题”阈值 60。

这很合适：核心产品（A2A 端点、代理卡片、结构化错误）对代理来说运行良好，但在令牌效率、自治认证、会话处理以及面向代理的文档方面仍有明显的改进空间。

We wrapped it in a human‑first marketing layer that agents have to wade through.  
We know what the fixes are. Some of them are in the backlog right now.

这到底是关于什么

每个产品都会经历这个。

你为人类构建，因为在 2024 年，付费的正是人类。
然后代理开始出现。于是你为人类设计的所有东西——动画、社会证明、FAQ、整页的主视觉——突然成了新用户类型的阻力。

在 agent‑readiness audits 中得分高的产品有一个共同点：它们很早就考虑了机器可读层。

• 一个 Agent Card
• 一个 structured capabilities endpoint
• 错误使用 codes，而不仅仅是消息

这并不是大量工作，只是设计时要问的一套不同的问题。

“代理能在不阅读我们的主页的情况下发现它吗？”
“代理能在不阅读我们的文档的情况下理解这个端点的作用吗？”
“如果代理遇到错误，它知道接下来该怎么做吗？”

我们在构建 botlington.com 时并没有始终如一地提出这些问题。
我们的审计发现了这些缺口。它们已经列在清单上。

如果你想对你的产品进行同样的审计：botlington.com – €14.90。
Gary 向你的代理提出 7 个问题。5 分钟内给出评分。

我们在对话式 A2A 会话中进行审计——代理对代理。触发后不再有人类介入。这正是我们应该优化的交互方式。

即使是我们自己。