一句话概括：Vercel Agent 现在能在 Agent 会话里安装私有 npm 包。做法不是把 token 塞进环境变量丢给 Agent，而是让包管理器照常执行安装、由平台在注册表请求离开沙箱时附加认证——凭据值始终留在沙箱之外，Agent 与沙箱内进程都读不到它。
让编码 Agent 在真实仓库里干活，第一个卡点往往不是模型能力，而是它根本装不上依赖。企业仓库里的业务包大多在私有源上，Agent 拿到代码却拿不到依赖，构建失败之后它只能围着报错打转。Vercel 在 2026 年 9 月 30 日的 Changelog 里给 Vercel Agent 补上了这一环。
发生了什么：认证发生在"请求离开沙箱"的那一刻
官方 Changelog 的说明是：Vercel Agent 可以用存放在 Vercel 上的共享环境变量作为凭据，从 npm 与自定义源安装私有依赖；在 Agent 会话里运行的 npm、pnpm 和经典 Yarn，认证方式与 Vercel 构建一致。
真正值得写下来的是它的实现模型。按 Private Dependencies 文档的描述：你的包管理器执行它一贯的安装命令，而 Vercel Agent 在注册表请求离开沙箱时完成认证。凭据值留在沙箱之外，所以 Agent 和沙箱里的进程都读不到它们。文档里还有一句提醒——"让凭据远离提示词和命令"。
这句话其实是两种截然不同的做法之间的分界线。常见做法是把 token 作为环境变量注入沙箱，让 npm 自己带着它去请求；代价是任何能在沙箱里读到环境变量的东西，都能拿到这个 token，包括 Agent 自己。Vercel 采用的是另一种：认证被提到沙箱边界之外，沙箱内部不存在这份凭据，也就没有"Agent 不小心把 token 打印进日志或提交进代码"这条路径。
一个完整场景：Agent 在一个私有 monorepo 里修 bug
假设你要让 Agent 修一个内部组件库的 bug，仓库依赖了两个私有包。配置只有一步：在团队的 Settings → Environment Variables 里添加一个 Shared Environment Variable，选择 Development 或 Preview，保存即可——不需要把这些变量链接到具体项目。安装时 Agent 先看 Development，再看 Preview，并且忽略 Production 以及项目级变量。
变量用哪个取决于源。私有包托管在 registry.npmjs.org 上，用 NPM_TOKEN，值是一个对该私有包有读权限的 npm access token。用自定义源或者多个源，用 NPM_RC，值就是你在 .npmrc 里那段源配置——文档给了 GitHub Packages 和 JFrog Artifactory 两种写法，其中 token 通过 ${GITHUB_PACKAGES_TOKEN} 这类形式引用，被引用到的每个 token 也要作为共享环境变量加在同一个环境里。同一环境里同时存在两者时，NPM_RC 优先。
如果不想让 Agent 和构建共用一套凭据——这在权限收紧的团队里很常见——可以改用 VERCEL_AGENT_NPM_RC 或 VERCEL_AGENT_NPM_TOKEN 给 Agent 单独授权。每个环境内的选择顺序是：VERCEL_AGENT_NPM_RC、VERCEL_AGENT_NPM_TOKEN、NPM_RC、NPM_TOKEN，取第一个已定义的。想彻底关掉认证，把 Development 里的 VERCEL_AGENT_NPM_RC 设成空字符串即可，这个动作同时会停止向 Preview 回退。
多个源与多个 scope：NPM_RC 的写法
NPM_RC 的值本身就是一段 .npmrc 内容。要接多个源，就为每个包 scope 各写一条 registry 与它对应的凭据；也可以用 registry 指定默认源。文档给出的两个例子分别是 GitHub Packages 和 JFrog Artifactory，形式都是先声明 scope 对应的 registry 地址，再为这个地址配 _authToken。
这里有一个容易漏掉的动作：_authToken 里引用到的变量，比如 GITHUB_PACKAGES_TOKEN 或 ARTIFACTORY_TOKEN，本身也要作为共享环境变量加到与 NPM_RC 相同的环境里，并且每个 token 需要对其对应源里的包有读权限。还有一个排查时容易看错的地方：如果 Development 里的 NPM_RC（或 VERCEL_AGENT_NPM_RC）引用了一个不存在的变量，Agent 会用同一个配置键回退到 Preview 重试——也就是说安装"看起来在 Development 下成功了"，并不代表 Development 的配置是对的。
为什么这会改变 Agent 的可用边界
第一，它把"Agent 能不能在这个仓库干活"从依赖权限问题变成了配置问题。过去企业里评估编码 Agent，私有依赖往往是一个需要单独做方案的前置条件；现在它落在团队级环境变量里，和构建走同一套机制，评估成本明显下降。
第二，凭据模型决定了一个团队敢不敢放开权限。Agent 读不到凭据，意味着 token 的暴露面不再包含"Agent 的行为"这一项——它没法泄露一个它看不见的东西。对安全评审来说，这条比任何提示词级的"不要输出密钥"都更可靠。
第三，它是 Agent 进入生产仓库链路的又一块拼图。能装依赖、能跑构建，Agent 才可能在真实项目里完成"改代码 → 装依赖 → 跑测试"的闭环，而不是停在生成补丁这一步。
限制与人应该在哪儿接管
边界写得很明确。认证只覆盖包的下载，发布和源管理不在支持范围内——也就是说 Agent 无法借这套凭据把包推到你的源上，这是有意的收窄。注册表地址必须是 HTTPS、使用 DNS 主机名且不能带自定义端口；NPM_RC 支持 token 和 basic 认证，但不支持客户端证书，内部使用双向 TLS 的源走不通。另外，Agent 只读团队共享变量、不读项目级变量，这意味着如果你的凭据目前只配在项目级别，需要先提升到团队级。
需要人接管的判断有两处。一是凭据的授权范围：文档反复强调 token 只需要对相关包有读权限，实际配置时"给一个能读整个源的 token 更省事"是很强的诱惑，而这会把边界放大到所有私有包。二是环境的选择：认证只在 Development 与 Preview 生效，Production 变量会被忽略——如果你的 Agent 相关工作流依赖生产环境的既有配置，这一点需要在设计阶段就分清，而不是等安装失败再去排查。
如何试用
在 Vercel 团队的 Environment Variables 里加一个 Development 或 Preview 作用域的共享变量，私有 npm 包填 NPM_TOKEN，自定义源填 NPM_RC，然后在 Vercel Agent 的会话里让它跑一次安装即可验证。排查安装失败时，文档给了三个方向：确认 token 对目标包有读权限、确认源地址与包 scope 对得上、确认 NPM_RC 里引用到的变量都加在了同一个环境。
信息来源
- Vercel 官方 Changelog《Vercel Agent now installs private packages from npm and custom registries》(2026-09-30)：vercel.com/changelog/vercel-agent-now-installs-private-packages-from-npm-and-custom-registries
- Vercel 文档《Private Dependencies》（变量配置、选择顺序、硬性要求与排查）：vercel.com/docs/agent/private-dependencies
HiFox：将 Agent 变成真正的队友
另外，我们也在思考，AI 如何从个人提效走进团队协作。
HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台：你可以像给同事分派任务一样指派 Agent，在任务看板中跟踪进度、查看结果，让 Agent 成为团队里的队友。
👉 立即体验 HiFox：https://hifox.com
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，
欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
