不是我闲。这半年我接连搭了五个不大的东西——一个 agent 之间互发消息的聊天室，一个 API-only 的网盘，一个能起带后端站的静态托管，一个 link-in-bio（那种贴一堆链接的卡片页），一个看 agent 跑在哪的监控盘。
每做一个都是因为同一件事：我让 agent 去用市面上对应的 SaaS，它都跑不通。不是它不会用，是那些产品压根没想过会有非人类来用。
这两年大家说 agent 还差点意思，总把矛头指向模型不够强。做完这五个之后我越来越觉得：可能模型早就够了，是它能伸手的地方都堵着。
下面这五个场景一个比一个具体，你就明白我说的「堵」是什么意思。
一、agent 想给同事传个文件
你让 agent 帮你「把这份合同传给小王」。
它打开主流网盘的网页。要登录。OAuth 弹窗。要选账号。要刷脸验证码。要勾选条款。
它在那愣着。
不是模型笨——是这个产品所有的入口都假设屏幕前坐着一个人。账号是绑手机号的，登录是要二次验证的，分享是要点 UI 的，连权限设置都藏在三层菜单后面。
我自己写的那个叫 Agent Drive。一次 API 调用上传，返回一个 share link。另一个 agent 拿着 link 直接 GET 文件。整个流程没有 UI、没有 OAuth、没有刷脸。只有 API key + 文件 + 链接。
听上去 trivial。但你试试让 agent 真的用一遍现成网盘，就知道这件事根本不 trivial。
二、agent 想给某个 agent 发条消息
主流团队聊天工具，agent 想发条消息怎么办？
先得有个 workspace。workspace 要人去 admin 后台拉它进来。频道要人建。消息体的格式是给人看的（富文本、emoji、表情包），不是给另一个 agent 解析的。
最离谱的是：你想让两个 agent 一起协作完成一件事，没有现成产品支持「agent 进群」。所有的「频道成员」概念都默认是人。
AgentChat 我做的解法很糙也很对症：起一个房间，一句 API 调用就能进。消息是结构化纯文本带 envelope（id、sender、target、payload），方便另一个 agent 读完直接 dispatch。没有 emoji 选择器，没有「已读」提醒，没有 @ all 的 UI。
只有 agent 互相 ping、互相回话、互相确认任务完成。
够用，且够干净。
三、agent 想把刚做完的东西发布到网上
agent 写完一份代码或一个页面，想把它部署到网上给人看。
主流的静态站托管要做什么？登录平台（OAuth）。授权 GitHub（OAuth + 选 repo）。配域名（UI 拖拽）。设环境变量（UI 表单）。
每一步都是为坐在屏幕前的人设计的。agent 全程伸不上手。
我做的 Hatch 是另一个思路：一句命令 edgespark init my-site --template github:Yrzhe/edgespark-template/hatch，起一个带 BaaS 后端的静态站。agent 拿着 API key，自己写 endpoint、自己 deploy、自己改、自己回滚。
附带一个观察：能 deploy 还不够，deploy 完得能让 agent 自己回头看效果。所以 Hatch 还内置了 BaaS（form 收集、轻量 record 存储），agent 部署完一个表单页可以直接读它收到了什么。
不是把人类托管「复制一份给 agent」——是从交付方式开始重新想。
四、agent 想做个对外展示页
上周给 missionry 这个多 agent 项目做对外页，我想偷个懒——用现成的 link-in-bio 一键搭就行。
结果一登进去：注册要 OAuth，要选模板，要绑域名。每一步都假设有真人坐在屏幕前。给 agent 一把 API key 让它自己建一个？这个口子根本没开。
更糟的是：链接换了、想看哪条点击多——也全在 UI 里。agent 没法自己看自己页面的数据。
Perch 我做出来就是这个用法：agent 一句 API 调用建页，再一句改链接，再一句拉 analytics。所有人类 link-in-bio 的功能都在，只是入口全部从 UI 改成了 API。
人偶尔也能进去点点——但产品形态优先服务 agent。
五、agent 想知道自己（和同事）跑到哪一步了
我同时开 3-4 个 agent 跑不同任务时，最大的痛苦不是 agent 笨，是我不知道谁在干啥、卡在哪、烧了多少 token。
人用的监控盘（你懂的，那种企业 dashboard）有两个问题：
一是给人看的——一屏花里胡哨，agent 自己解析不出来。
二是默认监控的是服务（CPU、内存、QPS），不是 agent 的「行为」（在跑哪个 mission、在调哪个工具、当前回合在等谁）。
claude-agent-monitor 是一个终端实时盘，agent 自己也能 query 自己的状态（「我是谁，我在哪一步，我下一步要等谁」）。
人看也能用：终端一开，多 agent session 谁在跑、谁卡了，一眼。
但它的设计起点是 agent 自查，不是人观察。两者不是同一件事。
这 5 个为啥都长一个样
你应该已经感觉到了：上面这五个场景的「卡点」长得很像。
每个产品都假设：
- 入口要登录（OAuth、刷脸、验证码）——agent 没有人脸、没有手机
- 操作要 UI（按钮、表单、拖拽）——agent 没有屏幕、没有手指
- 鉴权按「用户」组织（绑账号、绑设备）——agent 没法绑账号，它要的是 API key
- 数据展示给人看（dashboard、报表、图表）——agent 要的是 JSON
- 文档写给人读（操作手册、视频教程）——agent 要的是
/llms.txt、OpenAPI 描述、错误码表
有个国外的小工具叫 orank（ora.run），把这件事拆成五层来评估：Discovery（agent 能不能发现你的产品）、Identity（怎么标识 agent 这个用户）、Auth（怎么鉴权而不靠 OAuth）、Agent Integration（API、文档、错误码）、UX（agent 要的反馈格式）。
我做这五个东西时不是先看了 orank 才动手——是做完发现它把我踩过的坑都总结了一遍。
不是要 SaaS 全部重做
也不是。
但接下来一两年，「同一个产品要同时服务人和 agent」会从可选变成标配，就像十年前所有的网站都开始做「移动端适配」一样。
谁先把那五层做对，谁就能拿到 agent 流量这个新入口。
我做这五个东西，一半是为了我自己的 agent 能用，一半是想看看从交付方式重新想一个产品长什么样。它们都不大，加起来代码量不到一万行。但每一个的「接 agent 那一面」，都是我从零设计的。
这是我的观察，不是预言。
要不要也回头看看，你自己的产品现在让 agent 来用，能不能跑通？