登录框是为人设计的,Agent 进不去

过去大半年,关于 agent 的讨论几乎都在聊模型能干什么、harness 该怎么搭,却很少有人问一个更前置的问题:agent 想用一个新服务,要怎么进去?WorkOS 创始人 Michael Grinich 在 AI Engineer World’s Fair 2026 收尾日的主舞台上,拿这个问题做了一场 20 分钟的分享,提出了一个新协议 auth.md。

原视频:https://www.youtube.com/watch?v=I2cbIws9j10(约 02:50:03 开始)

从人操作 agent,到 agent 自己跑

Grinich 先给了一个时间线。一年前,写代码还是”人提示、agent 写一点、人再提示”的来回;年中出现 Ralph loop 之类的自动化,但本质还是人机交替。现在变了:一个 prompt 发出去,agent 能连续跑几个小时甚至几天,直接产出一整个功能或产品。他把这个转折归到一句话:agent 从”预测下一个词”的语言模型,变成了能自主执行长任务的系统。

他打了个比方:LLM 本身像一台高性能 V8 发动机,能把燃料转成动力,但发动机装不进车里就没用,你还需要底盘、变速箱、传动轴、轮子,这些拼起来才是 harness。模型越强,人越需要围绕它重新搭一套 harness,这也是”harness engineering”这个说法的来源。他给出 agent 要跑起来需要的五样东西:一个安全的运行环境(sandbox)、能操作世界的工具、足够的上下文、能验证自己做得对不对的反馈,以及最后兜底的人工审核。

这五样里,前四样这两年大家已经讨论得很充分:sandbox、工具调用、上下文管理、验证循环,各家都在做。Grinich 这场要讲第五个前提,大家反而普遍没当回事:agent 想用工具,得先进得去装着这些工具的系统本身。这一步,今天基本没人解决。

登录框是为人设计的

Grinich 摆了个现实:agent 能访问网页,能访问手机端,但基本没法自己”访问系统”,注册这道门没开。过去二三十年,互联网一直在防自动化流量:验证码、邮箱验证、DOS 防护、撞库检测,整套登录基础设施的默认假设就是”来的是人”。不是谁故意针对 agent,是这套系统建成的时候压根没考虑过 agent。

具体拆开看,一个典型注册流程要求:能读懂落地页文案、能填表单、能收验证邮件并点开、能过验证码、能选套餐、能把 API key 复制粘贴到别处。agent 大概率没有邮箱地址,不会去”点一下某个地方”完成邮箱验证,仪表盘这种体验对它也没意义。他说了句挺直接的话:这整套体验的设计对象是人,agent 用不上。他还提了一个有点讽刺的细节:云端浏览器执行环境现在把”能破解验证码”当卖点在推销。行业绕了一圈,又在卖”怎么骗过自己造的门禁”。

MCP 解决的是另一个问题

Grinich 特意澄清,他自己是 MCP 的重度用户和支持者,MCP 在连接工具、传递上下文这件事上做得很好。但他说了一句挺扎心的话:MCP 不够用。MCP 解决的是”agent 已经有权限之后怎么调用工具”,不解决”系统要不要在第一次就放这个 agent 进来”。今天通过 MCP 做认证,人仍然要在环里:你把一个 MCP server 加到 Claude 里,还是要去手动登录、手动授权。他要谈的注册,是要把人从这一步里彻底摘出去,至少不要求一开始就有人在场。

auth.md 具体填什么

Grinich 提出的方案叫 auth.md,名字很直白:一个 markdown 文件,放在服务方那边,告诉 agent”要成为这里的合法用户,需要做什么”。它只解决注册这一件事,不试图解决 agent 身份、长期权限、跨服务连接这些更大的问题,他的原话是”先从小处做起”。

auth.md 具体回答几个问题:服务是否对 agent 开放(可发现性)、这个 agent 能做什么(能力声明)、为什么要注册(注册意图)、支持哪些认证方式(SSO、邮箱、MFA)、给不给免费额度、以及最关键的一条:agent 先注册,人之后能不能把这个账号认领回去(custody)。

他现场演示了一个场景:agent 在帮用户做一个 side project,想部署上线分享给朋友。它去查有哪些服务支持 auth.md,发现 Cloudflare 支持、Stratus 和 Helio deploy 不支持,于是选了 Cloudflare。agent 生成一个身份断言(identity assertion)发给 Cloudflare,换回一个叫 ID JAG(identity JSON access grant)的令牌,再拿这个令牌走正常 API 调用,整个过程人没有点过一次鼠标,只回复了几句”是””继续”。他提到同样的机制也在和 Firecrawl 合作跑通。拿到令牌之后,后续调用走的还是标准 API 和 MCP,auth.md 只管注册这一步,不改动其它任何东西。

他在付费顺序上刻意做了设计:不强迫 agent 一上来就绑定信用卡,先能用起来,产生真实使用之后再谈按什么规则付费。这个顺序,他类比成早年 SaaS 从预付费转向自助注册后付费的路径。他还引用了 Salesforce 创始人 Marc Benioff 的话——”我们的 API 就是 UI”——来说明这不只是一家小公司自说自话,人们习惯归为传统 SaaS 代表的 Salesforce,也在往 agent 优先的方向调整产品形态。

这场分享在当天的位置

同一天稍早的主舞台开场,Amplify Partners 的 Barr Yaron 讲了一份行业问卷,核心结论是 agent 拿到写权限的速度已经超过企业管住它的办法,团队现在能拿出来的应对基本还是人工审批加权限门控。那场谈的是”agent 已经在系统里之后怎么管它”。Grinich 这场把视角切了个方向:先别急着谈怎么管,agent 现在连门都进不去,注册这道最前置的关卡还没人解决。一进一出,两场分享合起来正好是同一个 harness 问题的两端——内部权限治理和外部服务准入,缺一个都不完整。

我的判断

把这场内容摆进已有的判断框架里看,能看出两个此前没人显式覆盖的空白。Harness engineering 这几年大家拆解成执行、工具、上下文、生命周期、可观测性、验证、治理这几层,唯独没有一层专门回答”外部系统怎么第一次接纳 agent”——这次算是把这个空白显式标出来了。另外,这两年关于 Agent 经济身份基建的讨论,大多集中在两条路线:大厂发通行证(Visa/Mastercard Agent Pay、蚂蚁的 Know Your Agent),或者链上自证身份(ERC-8004、x402)。auth.md 走的是第三条更轻的路——不绑定单一平台账户体系,也不需要上链,更像给”agent 能不能注册”这件事配一份类似 robots.txt 的声明文件,谁都能发布,谁都能读。

这条路径的现实门槛也很直白:得两头同时动起来才有意义——服务方愿意发布 auth.md,agent 的 harness 也得知道去读它,这和早期 MCP server 生态冷启动是同一类问题。目前 Cloudflare、Firecrawl、monday.com 这几家在跟进,规模还小。但它选的问题足够窄,窄到不需要先解决”agent 身份”这个更大的哲学问题就能落地——这本身是个务实的工程判断:先把注册这一步的具体协议钉死,比等一个大一统的 agent 身份标准出现更容易真正跑起来。

如果你的产品已经在被 agent 访问,不妨去 auth.md 的开放规范看一眼。继续假设找上门的都是人,这个默认前提已经站不住了。