8.0
热点
AI SCORE
编程提效2026-08-19 08:00
Vercel Agent正式登陆Slack
Vercel Blog#Vercel#Agent#开发工具
Editor brief · 编辑速览
Vercel AI Agent集成到Slack，可在对话中调查故障、审查PR、触发部署，无需切换工具。
Vercel Agent 现已支持 Slack。你只需要像拉同事进群讨论那样 @ 提它，它就会阅读对话内容，结合你应用运行平台的上下文给出回答，并把团队的决定转化为待你审批的变更。Vercel for Slack 即日起面向 Pro 和 Enterprise 团队开放公测。
工作始于对话。告警在频道中被注意到，修复方案在线程中达成共识，然后有人离开 Slack 去动手执行。借助 Vercel Agent，你可以把它拉进来回答关于基础设施的问题，或者直接交给它处理工作，全程无需离开对话。
当我们推出 Vercel Agent 时，称之为"开发流程中的 AI 队友"。如今它是生产环境应用的第一响应者。一旦有情况发生，它会调查日志、指标和部署记录，找到根本原因并提出修复方案，往往在任何人打开笔记本之前就已经完成。给它一个 PR，它会标记出那些 CI 流程通过但实际存在的回归和风险变更。
在 Slack 中，这个 Agent 直接参与对话本身。它是 Vercel 的核心部分，因此你的部署、构建状态、日志、指标、代码审查和 PR 在你输入任何内容之前就已经在它的掌控之中。在频道、线程或私信中 @Vercel，它会像一个已经打开所有标签页的队友一样回答问题。回答只是其中一半，因为一旦你知道出了什么问题，Agent 就可以去修复它：
诊断问题：调查事故，将错误追溯到引发它们的部署，解释费用突增的原因，回答关于你代码库的问题。
与团队协作编码：修复失败的构建和 CI，用代码在生产环境的实际运行情况来审查 PR，把线程中的决定转化为经过测试的 Pull Request。
运维项目：回滚部署，更新配置，管理功能开关，在异常用量变成账单之前解决它。
Agent 默认是只读的，任何涉及代码或配置的变更都会经过一个待你审批的计划后才会执行。Vercel for Slack 将这整个流程带入了你和团队已经在讨论工作的线程中。
团队的决策通过协作形成。事故在频道中分级处理，代码审查在线程中反复讨论，功能在站会之间被定义范围。但一旦线程确定了需要做什么，后续行动仍然需要被转译成工单、终端命令和 PR 描述。每次交接都会丢失上下文，而承载完整画面的大讨论最终变成了每个人都凭记忆去总结的东西。Vercel for Slack 让 Agent 在每一轮对话中都拥有原始讨论的完整上下文。
下午 1:42 一次部署上线。1:51，结算错误率开始攀升，一条告警进入平台工程频道。
以往接下来发生的是一片混乱。一个响应者打开日志查看情况有多严重，另一个让他的编码 Agent 把异常与部署时间线对齐，第三个开始阅读可疑 PR 的 diff。每个人各自调查，在同一系统的各自视角中独力查看，然后在帖子中通过粘贴截图、总结 Agent 发现、相互纠正来还原现场。那些关键的几分钟花在了拼凑全貌上，而不是有人能够据此行动。
有了 Vercel for Slack，第一个问题直接抛给 Agent，就在帖子中。
"@Vercel，1:42 部署后结算错误飙升。怎么回事？"
它评估爆炸半径，将峰值与部署关联，识别出随该部署推送的 PR，并解释哪个文件的什么变更导致了什么行为。答案出现在频道中，整个团队在同一时间阅读同一份诊断报告。
没有人需要重新运行队友的调查，也不需要等待复盘，因为每个人都在看同一份报告。熟悉结算代码的工程师直接针对该变更发言，值班人员权衡受影响用户数与修复耗时，线程中剩下的就是决策——是回滚还是继续修复。
帖子、频道或私信本身就是提示的开端。你不需要重新解释已经说过的任何内容，也不需要传入任何关于你应用或代码库的上下文。像对待其他团队成员一样把它拉进对话，它会阅读现场氛围，获取团队一直在讨论的内容，并在被问到时据此行动。
这方面的一个例子是我们在 Vercel Agent 的计划卡片上的迭代——这是它在 Slack 中发布的一条消息，用来请求对其要做的工作的审批。我们内部测试的第一个版本是一大段文字，但当一位工程师注意到人们经常在没读完细节的情况下就批准操作时，我们有一条重新设计的讨论帖，跑了 47 层回复，深入探讨了一个人在代表团队确认操作前需要看到什么。在那条讨论帖末尾 @Vercel Agent，才有了你今天看到的卡片。
当这样一个对话产生的 PR 最终出现在帖子中时，测试已经跑过，预览部署也已经上线，团队可以在最初发起功能的对话中开始审查它。
在讨论 PR 的帖子中向 Vercel Agent 请求审查，对话会连同请求一起传递过去。团队一直在提出的问题成为了 Vercel Agent 检查的上下文，它的发现会回到同一个帖子中，这样讨论、决策和修复就形成了一个闭环，而不是去另一个工具中来回折腾。
我们自己的 PR 讨论中有一个例子，是有人在帖子中途请求的审查。Agent 回来时发现了一个在 diff 之外的 bug——同一个标题在 UI 中被渲染了两次。
一个发现不一定要以评论结尾。如果团队同意应该修复，Agent 可以直接给 PR 打补丁，这个变更以与其他所有内容相同的方式到来——作为一条等待审批的提案。
当一个帖子最终确定需要做一个变更时，Vercel Agent 会回复一个计划，说明将在哪个项目中发生什么、范围是什么。频道中的决策碎片化地形成，跨越不同的人和数小时，没有人会在前面打"DECISION:"，所以计划就是把那些碎片汇成一个明确的东西让大家审批。一旦获批，Agent 会在自己的身份下执行工作，审计记录显示谁请求了、谁批准了、运行了什么。
我们自己的帖子中有一个例子，是一次更新推送后一个缓存页面显示了过期数据。有人呼吁只针对特定页面做缓存清除，因为正值高峰期，并让 Agent 来设置。回来的计划与请求完全匹配——清除特定路径及其子路径，其余站点的缓存保持温热，在有人批准之前什么都不运行。
无论一个帖子的结尾是诊断、Pull Request 还是缓存清除，最后一步都属于一个人。
最简单的方式是直接向 Vercel Agent 提问。问你在追的错误或刚失败的构建，看看会返回什么，让你的团队慢慢决定 Agent 承担多少工作。在有人批准计划之前，它始终只是阅读。
Vercel for Slack 面向 Pro 和 Enterprise 团队开放公测。要开始在 Slack 中使用 Vercel Agent：
Vercel Agent 可能会犯错。在审批前请审查拟议的变更。
Alan Hwang, Hiroki Osame, Tom Dale, Shilpa Apte, Kathryn Middleton