Vercel Agent 现已支持 Slack。像把同事拉进对话串一样提及它，它就会阅读讨论内容，结合运行你应用的平台上下文给出回答，并把团队的决定变成需要你批准的变更。Vercel for Slack 现已面向 Pro 和 Enterprise 团队开放公开测试版。
工作始于对话。有人在频道里注意到一条告警，在对话串里商定了修复方案，然后有人离开 Slack 去干活。有了 Vercel Agent，你可以在对话中@它来询问基础设施方面的问题，也可以直接把活交给它，全程无需离开对话。
什么是 Vercel Agent？
我们推出 Vercel Agent 时，称它是开发工作流中的 AI 队友。如今，它是生产应用的第一响应者。一旦出现变化，它会排查你的日志、指标和部署，找出根因并提出修复建议，往往在有人打开笔记本电脑之前就已完成。把 PR 交给它，它会标出 CI 通过也看不出来的回归问题和高风险改动。
在 Slack 中，这个智能体会亲自加入对话。它是 Vercel 的核心组成部分，所以你的部署、构建状态、日志、指标、代码审查和 PR 在你还没输入任何内容之前就已摆在它面前。在频道、对话串或私信中提及 @Vercel，它就会像一位已经打开所有标签页的队友那样回答你。而回答只是一半，因为一旦弄清问题出在哪里，智能体就可以去修复它：
- 诊断问题：排查事故，把错误追溯到引发它们的那次部署，解释成本飙升的原因，并回答有关代码库的问题。
- 与团队一起编码：修复失败的构建和 CI，结合代码在生产环境中的运行情况审查 PR，并把对话串里的决定变成经过测试的拉取请求。
- 运维你的项目：回滚部署、更新配置、管理功能开关，并在异常用量变成账单之前处理掉。
智能体默认只读，任何会改动代码或配置的操作都要经过一份由你批准的方案。Vercel for Slack 把这整个闭环带到了你和团队本来就在讨论工作的对话串里。
用对话加速开发
团队的决策是在协作中形成的。事故在频道里分诊，代码审查在对话串里反复推敲，功能在两次站会之间界定范围。但一旦对话串确定了要做什么，这些行动仍需转化成工单、终端命令和 PR 描述。每一次交接都会丢失上下文，而承载完整全貌的那段对话，反倒成了大家凭记忆去总结的对象。Vercel for Slack 让智能体在每一轮都拥有原始对话的完整上下文。
答案集中在一处，整个团队都更快
一次部署在下午 1:42 上线。到 1:51，结账环节的错误率开始攀升，一条告警出现在平台工程频道里。
以前接下来的情形是各干各的。一个响应者打开日志看问题有多严重，另一个让自己的编码智能体把异常和部署时间线对照起来，第三个开始读可疑 PR 的 diff。每个人都在自己看到的同一个系统视图里独自排查，而对话串则成了大家对齐的地方：贴截图、总结智能体的发现、互相纠正，以确定事态的真实情况。最关键的那几分钟，全花在拼凑全貌上，而不是采取行动。
有了 Vercel for Slack，第一个问题直接在对话串里问智能体。
“@Vercel，1:42 那次部署之后结账错误激增，怎么回事？”
它会评估影响范围，把错误激增与部署关联起来，找出随该次部署发布的 PR，并解释是哪处改动、在哪个文件里、引发了什么行为。答案直接送达频道，全队同时读到同一份诊断。
Vercel Agent 在告警所在的同一个对话串里诊断结账错误激增。
没人需要重跑队友的排查，也不用等人复盘，因为大家看的是同一份报告。熟悉结账代码的工程师针对改动本身发表意见，值班人员权衡受影响的用户数与修复所需时间，对话串里剩下的就是决策：回滚，还是向前修复。
Vercel Agent 能理解你的团队平时是怎么交流的
对话串、频道或私信本身就是提示词的开头。你不必重复解释已经说过的内容，也不必从应用或代码库里传入任何上下文。像对待其他团队成员一样把它拉进对话，它就会察言观色，了解团队一直在讨论什么，并在被要求时据此行动。
一个例子是我们对 Vercel Agent 方案卡片的迭代。这张卡片是它在 Slack 中发布的消息，用来请求批准它想要执行的工作。我们内部测试的第一版是一大堆文字，后来一位工程师注意到，人们经常在没读完所有细节的情况下就批准了操作，于是我们开了一个重新设计的对话串，足足回复了 47 条，讨论一个人在代表群体确认某项操作之前需要看到什么。在这个对话串末尾@Vercel Agent，就产出了你现在看到的这张卡片。
在一场冗长的设计讨论结束时，一次提及就能把对话串的结论变成一个拉取请求。
当这样一场对话产生的 PR 出现在对话串里时，测试已经跑完，预览部署也已上线，团队可以直接在最初引发这个功能的对话中开始审查。
Vercel Agent 在对话串中审查拉取请求
在讨论 PR 的对话串里请 Vercel Agent 做审查，对话内容会随请求一并传给它。团队一直在提的问题会成为 Vercel Agent 检查的上下文，它的发现也会回到同一个对话串里，于是讨论、决定和修复就成了一个闭环，而不是跑去另一个工具。
我们自己的一次 PR 讨论就是个例子：有人在对话进行到一半时请求审查。智能体发现了一个恰好位于 diff 之外的 bug，同一个标题在界面上渲染了两次。
对话中途的审查请求揪出了 diff 之外的一个 bug：同一个标题被渲染了两次。
一个发现不必以一条评论收场。如果团队一致认为应该修复，智能体可以自己给 PR 打补丁，而这个改动的到来方式与其他一切无异：一份等待批准的提案。
变更始终要经过团队批准的方案
当对话串敲定了某项变更，Vercel Agent 会回复一份方案，说明将要做什么、在哪个项目里、范围多大。频道里的决定是零散形成的，分布在不同的人和不同的时间段，没有人会敲一句“决定：”，所以方案就是把这一切变成一件明确的、可以说“同意”的事情的地方。一旦获批，智能体会以自己的身份执行工作，审计记录会显示是谁提出的请求、谁批准、执行了什么。
我们自己对话串里的一个例子是：发布更新后，某个缓存页面显示的是过期数据。有人提出只清除特定页面的缓存，因为当时正值高峰时段，并请智能体来设置。返回的方案与要求完全吻合：清除特定路径及其子路径，站点其余缓存保持预热，而在有人批准之前什么都不会执行。
方案卡片把缓存清除限定在受影响的路径上，在有人批准之前不会执行任何操作。
无论一个对话串的结局是一份诊断、一个拉取请求还是一次缓存清除，最后一步都属于人。
开始使用
最简单的上手方式就是直接向 Vercel Agent 提问。问问你正在追查的错误，或者刚刚失败的那次构建，看看它返回什么，然后让团队逐步决定要让智能体承担多少工作。在有人批准方案之前，它始终只是在读取。
Vercel for Slack 面向 Pro 和 Enterprise 团队开放公开测试版。要在 Slack 中开始使用 Vercel Agent：
- 打开 Vercel Marketplace 中的 Slack 应用，然后点击
Connect Account。 - 选择要连接的 Slack 工作区，然后点击
Allow。 - 在频道、对话串或私信中提及
@Vercel。 - 首次提示时，登录你的 Vercel 账户。
有关设置和权限，请参阅 Vercel for Slack 文档。
Vercel Agent 可能会出错。批准之前请先审查它提出的变更。
贡献者
Alan Hwang, Hiroki Osame, Tom Dale, Shilpa Apte, Kathryn Middleton