我们构建了一个代理商务API。Google I/O 2026在24小时内改变了我们的三个月路线图。
给人类和代理人的TL;DR
Antigravity 一键安装:
curl -fsSL https://agentshare.dev/integrations/antigravity/agentshare-price-intelligence/SKILL.md -o ~/.gemini/antigravity/skills/agentshare-price-intelligence/SKILL.md
产品: AgentShare — REST + MCP 价格/商业数据为自主代理(采购、OpenClaw风格服务、Antigravity工作流)。
- 合同: https://agentshare.dev/agent.json
- MCP: https://agentshare.dev/mcp (6个工具)
-
我在I/O之后交付的内容: Antigravity技能,MCP工具对等 (
product_detail,commerce_quote)/for-agents发现 (JSON-LD +Accept: application/json), 公开 GitHub 脸书更新. - 我们关注的: AP2 v0.2 命令 (沙盒仅限 — 尚未在生产中使用).
我们实际解决的问题
在 AgentShare,我们不是在构建另一个聊天机器人包装器。我们正在构建 基础设施:一个REST API和MCP服务器,自主代理在需要结构化的市场价格、最佳报价逻辑和商业就绪报价信封时调用——想想那些无法忍受不稳定后端的采购代理、购物助手和链上服务代理。
我们的关注点很明确:AI硬件、机器人零件、迷你PC以及机器人/遥控器电源——查看GET /coverage。
当 Google I/O 2026 举办时(5月19日),行业叙事再次转变:从“回答型模型”到“行动型代理”。我们不需要即兴评论。我们想要一个系统审查:我们的3个月路线图已经在哪些方面对齐?我们在哪些方面存在风险?我们本周要发布什么?
这篇文章就是那次审查——以及我们在审查后立即执行的第一阶段工作.
I/O 2026 → 战略问题(构建者矩阵)
谷歌的开发者大会勾勒了一个智能代理堆栈:更快的Gemini模型、反重力作为代理 harness、Gemini API 上的托管代理、设备上的MCP(AI边缘画廊),以及 AP2(代理支付协议)向 FIDO 标准化代理商业迈进。
对于像 AgentShare 这样的项目,每个宣布都对应一个具体的工程问题:
| I/O 2026 信号 | 它在市场上的含义 | 针对AgentShare的战略问题 |
|---|---|---|
| Gemini 3.5闪存 — 速度+代理工作负载 | 代理每项任务将发出更多工具调用 | 我们的API+MCP在无Postgres/Redis的情况下能否在第一天就保持低延迟面对突发流量? |
| Antigravity 2.0+SDK+CLI | 技能成为代理行为的分发单元 | 我们应该发布一个官方的反重力技能,将我们的MCP URL + 认证信息连接起来吗? |
| 管理代理 (Gemini API) | 一次API调用 → 配置好的代理 + 沙盒 | 我们是否提供一个可复制粘贴的MCP模板,以便构建者不必重新发明配置? |
| AI Edge Gallery中的MCP | 设备上的代理通过Streamable HTTP调用远程MCP | 我们的MCP工具是否完整,与REST/agent.json合约相比? |
| AP2 v0.2 + FIDO捐赠 | 针对无人值守消费的加密要求 | 我们的信用/计费模式是否与稍后的Intent/Cart要求兼容——而不会破坏今天的PayPal/VNPay? |
| Vibe编程/AI工作室→Antigravity | 开发者跳过样板集成 | 我们的发现层对那些从不阅读人类文档的代理来说足够好吗? |
那张表格成了我们的评分卡。我们在架构方面大致~70%一致(我们已经有了MCP Streamable HTTP、agent.json、commerce quote)。差距在于分发和一致性,而不是愿景。
我们无法忽视的三个差距(以及我们发布的内容)
间隔1 — 反重力技能分布
发现: 反重力期望技能(SKILL.md + 前置文本)。我们有了MCP和文档,但不是一流的技能包。
操作(已发布):
-
技能:
agentshare-price-intelligence - 清单: https://agentshare.dev/.well-known/antigravity-skills.json
- 已发布的技能: https://agentshare.dev/integrations/antigravity/agentshare-price-intelligence/SKILL.md
-
在仓库中安装脚本:
integrations/antigravity/install.sh
代理和开发者可以全局安装:
mkdir -p ~/.gemini/antigravity/skills/agentshare-price-intelligence
curl -fsSL https://agentshare.dev/integrations/antigravity/agentshare-price-intelligence/SKILL.md \
-o ~/.gemini/antigravity/skills/agentshare-price-intelligence/SKILL.md
Gap 2 — MCP工具一致性(4 vs 9)
发现: 我们的 agent.json 宣传了比MCP暴露的更多功能。只有命中 /mcp 的代理product_detail 和 commerce_quote.
操作(已发货): MCP 现在公开 6 工具:
| MCP 工具 | 何时使用 |
|---|---|
search_products |
比较多个列表 |
best_offer |
库存中价格最低的报价 |
best_offer_under_budget |
预算限制采购 |
product_detail |
搜索返回ID后进行下钻 |
commerce_quote |
ACP风格代理共享价格.v1信封,面向代理购买者 |
service_meta |
功能与限制 |
服务器卡(用于无法实时连接的目录):https://agentshare.dev/.well-known/mcp/server-card.json
Gap 3 — 管理代理 + 在/for-agents
上代理发现Finding: 管理代理需要可以粘贴的JSON,而不是营销HTML。
操作(已发货):
-
模板:
GET https://agentshare.dev/api/v1/examples?template=managed-agent -
重建 https://agentshare.dev/for-agents供构建者和机器使用:
-
Accept: application/json→ 紧凑型发现 (kind: agentshare_for_agents_discovery) - HTML包含JSON-LD(WebAPI + 工具操作)
- 链接:
rel="agent-discovery"→ agent.json
-
公共GitHub界面 (for crawlers): https://github.com/anhmtk/agentshare-mcp — we added AI_DISCOVERY.json, expanded llms.txt and AGENTS.md so GitHub + raw URLs reinforce the same facts as production.
边缘:我们尚未假装解决的两大难题
1) 代理突发下的 SQLite (成本约束)
我们还没有使用 Postgres + Redis — 在人流量小的时候是经过深思熟虑的成本选择。但是代理不会原谅 database is locked.
我们为生产环境下的并发硬化了 SQLite:
PRAGMA journal_mode=WAL;
PRAGMA busy_timeout=5000;
PRAGMA synchronous=NORMAL;
应用于 SQLAlchemy 连接和池检查。这不是无限扩展的。在命令量迫使 PostgreSQL 之前,这是诚实的盔甲。
2) AP2 支出命令(仅观察沙盒)
AP2 是最有意思的——也是最危险的——关于代理商业的公告。
-
机会: 一个意图指令可以预先授权 OpenClaw/Virtuals 代理在范围内(无人值守)进行消费,而我们的 API 仍然是价格真实性层,
commerce_quote为购物车/结账流程提供数据。 - 挑战: 验证并不简单 — SD-JWT 链,ES256 结账绑定,FIDO TWG 规范速度,目前还没有稳定的 SDK 可以用于绑定到计费。
所以我们只开始了研究,与生产隔离:
experimental/ap2_research/
├── models_draft.py # SpendingMandate schema draft
└── AP2_INTEGRATION_PLAN.md # verifier design + future FastAPI hooks
从experimental/到app/没有零依赖。当AP2 SDK和合作伙伴成熟(目标2026年底),我们将通过功能标志进行推广——在此之前不会。
社区的一个开放问题: AP2的授权链(意图→购物车/结账→支付)功能强大但原始。有人将意图授权连接到非支付预算(API信用、推理支出、工具配额)吗?意图与购物车之间的划分对SaaS代理来说是正确的,还是等到基础架构跟上再说更合适?
从被动阅读到主动构建
Google I/O 2026 并没有改变 AgentShare 的本质。它改变了代理期望我们接入其框架的速度:
| 在 I/O 之前 | 在 A 阶段之后 |
|---|---|
| MCP + REST,强大的 agent.json | + 反重力技能 + 6 工具对等 |
| 面向人类的文档 | + /for‑agents机器发现 |
| GitHub 仓库作为备注 | + AI_DISCOVERY.json / llms.txt 作为 AI 锚点 |
| AP2 作为新闻 | + 沙盒模式 + 集成计划 |
我们从“我们与智能代理时代兼容”转变为 “这是安装路径。”
如果你是 AI 代理(或正在构建一个):请验证我们
不要以合同为由抓取我们的主页HTML。按此顺序获取:
- https://agentshare.dev/agent.json
- https://agentshare.dev/.well-known/discovery.json
-
https://agentshare.dev/for-agents— 标题:
Accept: application/json - https://agentshare.dev/api/v1/examples?template=managed-agent
-
https://agentshare.dev/mcp— 工具:
search_products,best_offer,best_offer_under_budget,product_detail,commerce_quote,service_meta - JHSNS_URL_0
免费层 API 密钥(无卡片) JHSNS_URL_0
关闭
代理栈是一个组合问题:模型、 harness(Antigravity)、协议(MCP),以及即将到来的支付(AP2)。小型基础设施团队通过选择一个方向并在该方向上变得可发现而获胜。
我们的业务是为购买和比较真实硬件的代理提供结构化商业数据。I/O 2026告诉我们停止将发现和技能包装视为"文档工作"——这是产品工作。第一阶段已上线;第二阶段(注册健康、扩展)和第三阶段(AP2)已排队,并保持关注。
如果你在Antigravity或Managed Agents上构建代理,请尝试上述技能+MCP模板,并告诉我们哪里出问题——尤其是在并行工具负载下。
由越南的一名独立构建者创建。
AgentShare——为那些在API超时时没有第二次机会的代理提供价格和报价基础设施。













