要点
- 自动化接口是本地的：暴露在操作方自己机器上的接口，而不是请求要发往的托管端点。
- 两种形态各司其职——CDP 用于直接的浏览器检查与控制，REST 用于 Profile 与生命周期操作。
- 隔离的单位是 Profile，不是浏览器：一个智能体一个 Profile，各自的浏览器状态与网络分配。
- 本地性让连接边界变得明确。它本身不授权某个工具、不保障其代码安全，也不保证某个端点在每个版本里都存在。
- 公开出来的，就是已安装版本文档里写明的那些——不多一分。
自动化接口到底是什么
提到”自动化接口”，人们常常会联想到云端某处的托管服务，脚本通过互联网调用它。这里说的不是那种东西。Agilelogin 把浏览器自动化公开在本地：软件通过操作方自己设备上暴露的接口，对浏览器或某个 Profile 进行控制，而不是一个远程端点。这条连接不会经过任何第三方服务器——工具和浏览器运行在同一台机器上。
这个本地接口有两种有文档说明的形态。当已安装的内核公开 Chrome DevTools Protocol（CDP）访问时，它可以支持直接的浏览器检查与交互——当工作流确实需要浏览器级别的控制、需要像人工操作者一样查看或驱动页面时，应当使用这一层。与之并列的是，某个版本选定公开的 REST 端点，可以提供 Profile 与生命周期相关的操作，而不要求每项任务都拥有完整的浏览器级控制。实际上两者服务于不同的工作：CDP 用于直接的浏览器检查与控制，REST 用于产品选择支持的应用层操作。一个只需要启动 Profile 或查看其状态的智能体，不需要一整套 CDP 会话；而需要读取页面实际渲染内容的工作流则需要。
两种情况下，关键词都是”有文档说明”。本地性让连接边界变得明确——智能体面对的是自己的机器，而不是必须盲目信任的托管 API——但本地性本身既不会授权某个工具，也不会保障其代码安全，更不保证某个端点在每个版本中都存在。公开的内容，就是已安装版本明文写下的内容，不多也不少。
为什么 Profile 才是单位，而不是浏览器
智能体应当以之为推理单位的边界不是浏览器，而是 Profile。面向 AI 智能体的隔离浏览器 Profile，是分配给一个获准自动化工作流的持久本地浏览器上下文：它的浏览器状态和网络分配始终可识别地归属于这个 Profile，而该工作流通过上文所述的本地 CDP 或 REST 接口与之交互。Profile 建立的是一个控制边界；它本身并不会把权限扩展到操作方尚未授权的账号和系统之外。
正是这条边界，防止一个智能体的工作渗入另一个账号的会话。Cookie、存储和网络假设始终附着在某个具体的 Profile 上，因此当一个反复运行的工作流需要获准的会话状态时，给它一个专属 Profile，会比让多个工作流共用一个浏览器更容易检查状态归属和网络假设。由此得出的实践规则很简单：给工作流一个可识别的专属 Profile，而不是复用一个不相关的人工或智能体会话。获准的工作流可以指向这个专属 Profile，这样就能更清楚地知道当前浏览器状态由哪个进程拥有，以及这种所有权何时结束。
让多个智能体共用一个 Profile，通常不是正确的默认做法。当多个智能体并发运行，或者需要各自独立的状态时，每个获准工作流拥有一个 Profile，会让 Cookie、存储、网络假设和故障归属都比共享会话更容易推理。如果确实需要两个智能体共用一个 Profile，那应当是一个经过深思熟虑、经过测试的决定，而不是因为没人另建一个 Profile 而顺手发生的事。
本地接口不会给你什么
把”本地”当作”安全”的同义词很有诱惑力，但这不是正确的理解。本地访问是一条边界，不是一个信任判断。接口和智能体运行在同一台机器上，只说明这条连接终止于何处；它并不说明调用它的代码是否值得信任，Agilelogin 也不会把智能体的权限扩展到操作方已经授予的范围之外。一个接入的智能体或脚本，只获得操作方赋予它的权限，不多不少。
由此直接引出两条纪律。第一，限制设备和网络访问：确认接口的版本支持情况，限制谁、以及什么程序可以在本地访问它，而不是任由这个控制面暴露给设备上运行的任何东西。限制谁能在设备上运行软件、审查接入的工具、保护密钥，是操作方自己的责任，不会因为存在一个本地端点就自动完成。第二，只使用获准的、有文档说明的工具：像审查任何其他拥有账号访问权限的软件一样，审查智能体的代码、权限、提示词、密钥处理方式和更新路径——因为凭据、提示词、日志、依赖项和目标网站的行为，都是本地边界无法解决的独立风险。
第三条纪律，是对照实际安装的版本核实行为。目前尚未针对该自动化接口发布任何生产就绪声明。最稳妥的假设是：在某个版本的接口、身份验证行为、错误信息和兼容性细节形成带版本号的文档之前，接口都是随版本变化的——在让某个工作流依赖某个端点存在之前，先确认这一点。
目前进展到哪一步
以上这些，都还不是一个可以下载的产品。桌面应用尚未发布首个公开版本，因此目前没有任何东西可供安装，本文中的任何内容都不应被解读为相反的说法。已经写明的，是本地 CDP 与 REST 接口在版本发布后、获准工具接入时会呈现的形态，以及围绕它们的边界：Profile 作为隔离的单位、本地设备作为信任边界、操作方作为智能体一切权限的来源。
这也意味着具体细节——存在哪些端点、它们接受什么参数、错误如何返回——目前尚未固定，而且目前尚未针对该自动化接口发布任何生产就绪声明。请把这里以及它所依据的功能文档中写的内容，当作接口的建设方向，而不是一份定稿的参考。当版本真正发布时，任何把智能体接入其中的人，第一步都和上文所说的一样：确认版本，阅读该版本实际写明的文档，只赋予智能体工作流所需的权限，不多给一分。