待验证｜Chrome Relay改写登录态边界

对读者的影响在浏览器Agent安全边界。让AI Agent复用用户已登录Chrome，是效率最高也风险最高的自动化路径之一。Chrome Relay这次的变化把问题具体化：密码、TOTP、Passkey、Keychain、Touch ID、本地签名和审计日志如何组合，决定了Agent能否进入真实工作流，也决定了出错时谁能止损。

提交到底改了什么

9cff853的提交消息把新增项分成三块。第一块是程序形态：Chrome Relay现在是一个Go程序chrome-relay，既是后台relay服务，也承担CLI职责。提交说明称它替代了Node relay和Python CLI；./build只需要Go就能构建核心能力，如果安装Xcode command line tools，则会加入1Password和Secure Enclave passkeys相关层；有代码签名身份时使用该身份，否则使用ad-hoc签名。

第二块是1Password登录。提交说明称，用户可用chrome-relay vault setup开启，用vault forget关闭。Agent填写的是op://vault/item/field引用，relay负责把密码、其他字段和TOTP代码输入网页。原文还给出几个限制：值只进入该item自己的网站，只进入password fields，并在Agent读回的内容中被遮蔽；每次使用需要Touch ID批准，批准粒度可为每次登录、每个Agent session或永不批准。

第三块是Passkeys。提交说明称，可用chrome-relay passkeys on|off控制Agent标签页中的passkeys；Chrome Relay自己的passkeys位于Secure Enclave，每次签名需要Touch ID；passkeys reuse <s>允许一次批准覆盖同一Agent的登录，最长5分钟。如果passkeys只由1Password持有，则交给1Password自己的prompt处理，toolbar badge会打开相关tab。

登录态风险被写进产品设计

浏览器登录态Agent的特殊之处在于，它绕过了很多API集成的显式授权边界。传统企业集成通常有OAuth scope、API key、服务账号、审计日志和权限撤销；浏览器自动化则直接站在用户已经登录的Chrome里工作。好处是覆盖面广，很多没有API的后台也能操作；风险是Agent可能接触到用户能看到的一切，且很多网页原本没有为机器代理设计权限粒度。

Chrome Relay仓库描述就是“Let your AI agents use your Chrome, signed in as you, in background tabs”。这句话本身已经足够说明风险强度。该项目让Agent在后台标签页中使用用户已有登录态，而非打开一个全新无状态浏览器。此时安全边界会同时牵涉浏览器扩展、relay进程、Agent连接、身份映射、Tab隔离、凭据输入、审计日志和本机安全提示。

9cff853的价值在于把凭据访问写进产品边界，并停止假设用户总是在前台手动登录。1Password路径意味着Agent可能在一定规则下完成密码和TOTP输入；Secure Enclave passkeys意味着Agent登录过程可能触发本机生物识别批准；Go二进制和代码签名则试图把本地Keychain访问绑定到用户自己构建的程序签名。这些都是“真实可用”之前必须面对的环节。

但这些能力也扩大了审计要求。1Password集成需要回答item网站匹配是否足够严格，password fields判断是否可能被恶意页面伪装，TOTP输入是否会泄露到日志或Agent上下文。Passkey复用需要回答会话边界如何定义，同一Agent是否可能跨站点连续触发登录，5分钟窗口内失败重试和误点如何记录。签名Go二进制需要回答普通用户能否理解ad-hoc签名、代码签名身份和Keychain绑定之间的区别。

同日修复暴露的基础工程问题

cf0f458的提交很小，总变更23行，但它说明了浏览器Agent系统中一个典型稳定性问题。提交消息称，由于closeAgentTabs()可能抛错，config分支里的清理失败会导致handler直接reject而不回复，relay于是等待30秒的extCall超时。修复方式是把config放进和其他操作相同的try逻辑中，让relay立即得到错误；relay实例仍然只有在清理成功后才记录，因此下一次config会重试。

6ed9fb1的提交总变更108行，主题是“serialize agent tab grouping per window”。对普通读者来说，这听起来很细；对浏览器Agent来说，它关系到多个Agent标签页如何在同一窗口被分组和维护。Chrome扩展、后台service worker和DevTools命令之间常有异步状态，若分组操作没有按窗口串行化，标签归属、清理和可见状态都可能错乱。

这些修复不是坏消息，反而说明项目仍处于快速成形阶段。它在10月11日同时补功能和补基础稳定性，意味着早报不应把它包装成成熟平台。更合理的位置是“社区工程线索”：它把登录态复用的关键边界写得比普通demo更清楚，但项目还需要release节奏、安装文档、审计报告和真实用户反馈来证明可用性。

事实口径需要特别收紧

这里最容易误写的是“签名”。提交说明里的签名有两层含义：一层是GitHub commit本身显示verified；另一层是用户在自己的Mac上运行./build，让chrome-relay二进制使用本机代码签名身份或ad-hoc签名。二者不能混为一谈。前者证明提交对象的GitHub签名状态，后者是项目设计的本地运行边界，本文未验证后者在不同macOS环境里的行为。

另一个容易误写的是“可选”。提交消息明确把新增项列为“New, all optional”。1Password需要vault setup，也可用vault forget关闭；Passkeys有passkeys on|off；开发模式用setup --dev。因此本文不能写成Chrome Relay默认接管所有密码和passkeys，只能写成它加入了可选路径，并把批准动作交给1Password prompt、Touch ID和本地配置。

还要单独处理“最多5分钟”。passkeys reuse <s>的意思不是安全性提高，也不是永久免Touch ID，而是一次批准覆盖同一Agent的登录，时间上限为5分钟。这个设计可能改善多步骤登录体验，也可能扩大短时间误操作半径。它的实际安全性取决于同一Agent如何被识别，登录请求如何绑定站点，日志如何记录，用户如何撤销复用。

对开发者和企业意味着什么

对开发者来说，这个项目值得看的重点是边界拆法。它没有只写“Agent可以用Chrome”，而是把身份复用拆成背景标签页、Google登录跳转、1Password字段引用、Touch ID批准、Secure Enclave签名、audit trail和doctor诊断。即使不使用该项目，这些维度也可作为浏览器Agent安全设计清单。

对企业安全团队来说，真正的问题是可治理性。Agent复用个人Chrome登录态，在个人效率场景很自然；进入企业环境后，管理员需要知道哪些vault被允许、哪些网站可被代填、哪些Passkey可用、日志保留在哪里、Agent session如何对应真实操作者、离职或设备丢失后如何撤销。这些问题没有被一次commit完全回答。

对Agent产品团队来说，这条新闻提示了一个竞争变量：谁能把“已登录浏览器”变成可审计、可撤销、可最小授权的产品能力。过去很多Agent demo卡在登录页和2FA；一旦凭据和Passkey流程被纳入可控路径，Agent能完成的真实工作会明显增加。但越接近真实工作，越需要把风险控制做成产品默认值，而不是README里的建议。

对普通用户来说，最现实的建议是保持低预期。这个提交让Chrome Relay更像一个能处理真实登录阻力的工具，但它仍不是官方浏览器能力，也不是被广泛审计的企业安全组件。使用此类工具时，最好从低风险Chrome profile、单独vault、少量测试站点开始，并确认审计日志、关闭命令和撤销路径都能被理解。

接下来重点看什么

先看发布路径。9cff853说明了./build、代码签名身份和ad-hoc签名，但普通用户最需要的是可执行的安装路径、升级路径和故障诊断。若项目后续能明确哪些能力需要Go、哪些需要Xcode command line tools、哪些需要Apple code signing identity，误配风险会下降。

再看凭据路径。提交说明写了很多关键限制，例如值只进入item自己的网站、只进入password fields、Agent读回内容被遮蔽、每次使用需要Touch ID批准。下一步需要看到测试用例、失败场景和边界条件，而不只是提交消息。

审计和撤销机制同样关键。浏览器Agent最怕“做过什么说不清”。一个可用的系统至少要记录哪个Agent session、哪个Chrome profile、哪个站点、哪次凭据输入、哪次Passkey签名、哪次人工批准以及哪次失败。日志还必须避免泄露密码、TOTP和token本身。

最后看同类工具是否把本地安全提示做成标准做法。Chrome Relay不是唯一在探索浏览器Agent的项目，但它把Touch ID、Secure Enclave、1Password和Go签名二进制放到同一次提交里，说明这一层正在成为产品差异点。后续如果更多工具采用类似边界，浏览器Agent生态可能会从“能不能操作网页”转向“怎样可控地代表用户操作网页”。