我做了个 Agent 后台，发现是伪需求
June 20, 2026
网页要不要给 Agent 加一个 headless 层？
这是我这两天突然冒出来的一个想法。
TL;DR（太长不看版）：外部网页适配 Agent，大概率是伪需求。愿意开放的会直接开放 API，不愿意开放的会反爬、风控、验证码。真正可能有价值的是复杂后台给自家的 AI 助手加一层可确认、可审计的 Action Layer。
一开始我想得还挺兴奋。
AI 时代，为什么一定要让 Agent 学会操作网页？让它点按钮、选日期、开下拉框、填表单、跨页面跳转，这事儿本身就很怪。网页是给人眼睛看、给手操作的，Agent 被迫用这套界面，就像让程序去模拟人类拿鼠标办公。
尤其是后台系统。
一个大型后台里，表格、筛选、日期组件、弹窗、批量操作、状态流转全都有。如果让 Agent 去点这些 UI，它光一个日期组件就可能卡半天。很多时候它不是不聪明，是我们逼它走了一条很笨的路。
后台真实想做的事情其实很简单。
{
"action": "queryOrders",
"input": {
"createdFrom": "2026-06-01",
"createdTo": "2026-06-21",
"status": "paid",
"minRiskScore": 20
}
}但是 UI 会把它拆成一堆动作：点日期、点下拉、输金额、点筛选、勾选表格、打开批量操作、确认弹窗。
所以我做了一个 demo：
https://www.maidang.me/demo/agent-ready-admin
标题叫：
别再让 Agent 点后台了
左边是一个模拟电商后台，里面有订单、履约、退款、审计。右边是一个 Agent controller。它通过 iframe 加载后台页面，然后用 postMessage 往里面发命令。
人类可以继续点 UI。Agent 不点 UI，直接发 command。
比如查订单、改状态、建履约、批退款、看审计。
看起来确实挺像回事。
当时我还试图用一种马斯克式的方式去论证它。不要先做大标准，不要先做 SDK，不要先幻想所有网页都适配 Agent。先找一个最痛的后台任务，然后问它能不能比 UI automation 快 10 倍、稳 10 倍。
这个思路本身没问题。
问题出在后面。
我突然问了自己一个很朴素的问题：如果我把这个页面直接丢给 Codex，它知道怎么交互吗？
比如这个页面：
https://www.maidang.me/demo/agent-ready-admin/surface
答案是，不知道。
它最多知道这是一个网页。它不知道这个页面监听了 postMessage，不知道消息的 source 要写 maidang.agent，不知道有哪些 method，不知道参数怎么传，也不知道返回格式长什么样。
更关键的是，postMessage 这东西本来就是给窗口关系用的。父窗口、iframe、opener，这种场景。你只是打开一个页面，它天然没有一个外部 controller。
所以要让这个 demo 真跑起来，我还得套一层 iframe：
controller 页面
-> iframe 加载后台 surface
-> controller 往 iframe.contentWindow 发 postMessage
-> surface 返回 response看到这里我就有点绷不住了。
这不就是开放 API 能解决的问题吗？
如果一个网站真的愿意让 Agent 操作，它为什么不直接开放 API？API 信息更完整，权限更清楚，性能更好，也不需要依赖页面有没有被 iframe 嵌进去。
再往前一步，OpenAPI、OAuth、webhook、MCP server，这些东西都比一个藏在网页里的 headless 层更像正道。
反过来，如果一个网站不愿意让 Agent 操作，它就更不可能主动加一个 headless 层。它会做的是反爬、风控、验证码、检测自动化行为。
所以这个需求两头都不成立。
愿意开放的人，会开放 API。
不愿意开放的人，会阻止 Agent。
那“网页主动适配外部 Agent”这个命题，大概率就是伪需求。
我觉得这次实验有意思的地方就在这里。它不是证明了一个方向成立，而是把一个看起来很性感的方向干掉了。
这比做出一个 demo 更重要。
不过这个想法也不是完全归零。
它有一个更窄的版本，我现在觉得还值得继续想：
复杂后台如果要内置自己的 AI 助手，不能让它点 UI。
这里的关键不是“外部 Agent 操作任意网页”，而是“系统主人自己想让 AI 执行业务流程”。
这两个完全不是一回事。
外部 Agent 操作网页，像是在敲别人家的门。别人愿意开门，就给你 API；不愿意开门，就上锁。
但后台内置 AI 助手不一样。比如 Shopify、Salesforce、客服系统、电商 OMS，产品方自己想让 AI 帮用户处理后台任务。这时候它需要的可能不是一个裸 API，也不是让 AI 去点页面。
它需要的是业务动作。
API 通常是给程序员用的，很底层：
POST /orders/bulk-update但 AI 助手真正要处理的是：
{
"action": "markVisibleRiskOrders",
"context": {
"page": "orders",
"filters": {
"status": "paid",
"riskScore": ">20"
},
"selectedIds": ["ord_24003", "ord_24006"]
},
"requiresConfirmation": true
}这里多出来的不是通信能力，而是业务语义和监督机制。
谁在操作，当前页面是什么，用户选中了什么，这个动作要不要确认，执行之后怎么审计，出错了怎么解释，这些才是后台 AI 助手真正麻烦的地方。
所以我现在会把这个东西改个名字。
它不叫网页 headless 层。
它应该叫 Agent Action Layer。
它也不是给外部 Agent 随便调的网页协议，而是 SaaS 内部给 AI 助手准备的一层业务动作注册表。
比 UI 稳，比裸 API 更接近业务，比 RPA 更容易审计。
当然，这句话现在也只是一个判断。真要做，还得继续被质疑。比如权限怎么做，确认怎么做，和现有 API 怎么接，前端状态要不要参与，哪些动作应该暴露，哪些动作绝对不能暴露。
I don't know。
但至少这次实验让我确认了一件事：
我一开始想做的“网页适配外部 Agent”，太大了，也太虚了。
真正值得留下的问题小很多：
当 AI 助手成为后台系统里的第二类操作者时，产品应该给它什么样的动作边界？
这个问题比最初那个想法小。
但真实很多。