S
SkillNav

Vercel 用 Agent 扩大社区支持规模,同时守住“人的温度”

深度2026-02-27T13:00:00+00:008 分钟阅读
Vercel 用 Agent 扩大社区支持规模,同时守住“人的温度”

5 分钟阅读

2026 年 2 月 27 日

在 Vercel,开发者社区是我们一切工作的核心。这也是我们始终贴近真实用户、了解他们如何使用我们产品的方式。

随着社区不断增长,自动化确实帮助我们提升了规模化能力。但问题依然会被遗漏,分流仍然耗时,频繁切换上下文也让我们无法专注在真正需要专业能力的工作上。而且,自动化永远无法处理那些最关键的时刻——你真正与一个人建立连接并帮助他的时候。AI 无法复制“你在和一个真正在乎你的人对话”的感受。

所以我们构建了 Agent,把不需要人工参与的分流、分诊和跟进工作接管掉。我们把这套系统称为 Community Guardian。下面会讲它做了什么、我们是怎么构建的,以及任何人(包括非工程师)如何也能把 Agent 做出来并上线。

Link to headingCommunity Guardian 运营层

当有新帖子进入时,Guardian 会先做分析、检查重复内容,并把帖子分配给专业方向和带宽最匹配的团队成员。每个人最多先处理 10 个问题,之后新问题会分配给其他人,从而在不同时区之间保持工作负载均衡。

不会有问题被忽略。如果一个问题 48 小时没有得到回复,Guardian 会重新分配。它会在我们等待更多信息时发送提醒,也能识别对话何时已经解决。

在底层,Guardian 通过 AI Gateway 调用 Claude,并运行在 Vercel Workflows 上。这样它可以每 10 分钟检查一次,并在两次循环间休眠而不消耗资源。

这些解决了运营层面的问题,但团队依然需要更强的上下文支持,才能给出更高质量回复。

Link to heading智能层:研究助手 c0

Guardian 负责物流调度,而 c0 是负责深度研究的 Agent。它直接运行在团队本来就在用的 Slack 中。

当团队成员需要某条线程的上下文时,c0 会搜索我们的知识库、文档、GitHub issues 和历史讨论,整理出一个“上下文包”。有了这个上下文包,团队可以更快、更准确地回复,而不是依赖个人记忆。

除了单条线程,c0 还帮助我们和产品团队形成闭环。它会追踪社区情绪与反复出现的技术障碍,所以我们不需要再花几个小时审查一周的帖子,只要让 c0 给出“top product feedback”,就能带着真实数据进入产品讨论。

Link to heading把人的精力拿回来

在系统上线后的前 23 天,它帮助了 281 位不重复用户:

Metric

Outcome

Initial context gathering

在团队成员介入前,已完成 4,716 次首轮回复,用于问题分诊与日志收集

Thread revival

每 8 条“失联”线程中有 1 条被重新激活,并带来 23 个已确认解决方案

Operational scale

最近两周内 Agent 运行超过 1,400 次,覆盖从陈旧线程检查到自动求解

Duplicate detection

通过向量相似度检测出 4 条重复线程,其中 3 条在 95%+ 置信度下自动关闭

所有实质性的回答依然来自我们的团队。Agent 处理的是这些回答周边的其他工作。去掉重复性的分诊和追踪后,团队就能把时间投入到复杂的结对调试和关系建设上,为更广泛的社区产出内容,或者只是和他们关心的开发者轻松交流。

Link to heading自己动手构建

你不需要是开发者,也能做出类似系统。你只需要有想法。我不是工程师,我做的是社区管理、和开发者沟通。当然,我理解我们要解决的问题,但我并不是每天都在写生产代码。

这个想法最早来自 a talk in Zurich,当时我展示了我们如何自动化社区工作流。但那时用的还是传统自动化:脚本、规则和 if-this-then-that 逻辑。它能用,但很脆弱。每个边界场景都要新增一条规则。

我想要更聪明的方式,于是开始用我的 coding agent 做实验,加入“思考层”——也就是“新帖子进入”和“采取行动”之间的那一步。以前是“if post contains 'billing' then route to billing team”,现在变成“先读这条帖子,理解这个人真正需要什么,再做决策”。

这个思考层就像多了一个 DX 工程师在逐条看帖:当用户说“it’s not working”时,它能读懂言外之意;能把线索关联到三个月前的 GitHub issue;能分辨用户是沮丧还是困惑;也知道何时该升级处理、何时该继续收集上下文。用这种方式构建,我只需要用自然语言描述目标,就能拿到可运行的代码,在真实社区线程上测试,再持续迭代。

我希望针对不同任务使用不同模型,让 Agent 能读取我们的文档和社区内容,并在失败时支持 suspend、resume 和 recover。与其从零搭建这些能力,我直接向 coding agent 描述需求,最后选用了 AI GatewayAI SDKVercel Workflows。这些工具已经把复杂性处理好了。

Link to heading构建它的 Prompts

第一条 Prompt 是核心想法:“Build me an agent that helps me with the community, day-to-day operations like assigning posts and formatting. I don't know which model will work best yet but make it easy to switch without needing new API keys. Use the AI SDK for the agent.”

之后,随着我更理解自己在构建什么,Prompt 也变得更具体:“And triggers every 10 minutes, I want to check for the latest threads.” 我一开始用的是 cron jobs,后来切换到了 Vercel Workflows。它的 durable execution 让 Agent 能在检查间隙暂停,并在原位置准确恢复。

“Make sure we're rotating assignments every 4 hours.” 每一条 Prompt 都会解锁下一个问题。我没有照着教程或文档一步步走,而是在进行一场对话,而系统就是从这场对话中长出来的。

你不需要知道正确术语,也不需要会写代码。你只要足够了解自己的问题,能把它描述清楚,并愿意在结果不符合预期时持续迭代。思考层让自动化从“严格执行这些规则”升级为“理解当前情境并做出判断”。

Link to heading带着温度去构建

社区是关于人的。我们希望团队成员拥有足够时间和精力,以完整状态投入其中,与社区开发者一起建设、为他们建设。

如果你也想构建类似系统,我们用 Chat SDK 构建了 c0——这是一个统一的 TypeScript SDK,可用于在 Slack、Teams、Discord 等平台上构建 Agent。Guardian 则使用 Vercel Workflows 来实现 durable execution。欢迎来 in the community 分享你的成果。我们一直很乐意交流我们的实战经验。

原文链接:https://vercel.com/blog/keeping-community-human-while-scaling-with-agents

相关文章

AINews:Harness Engineering 到底是不是一门真学问?
深度·3月5日
AINews:Harness Engineering 到底是不是一门真学问?

这篇文章围绕 AI 工程中的核心争议展开:系统能力究竟主要来自更强的模型(Big Model),还是来自更强的编排层(Big Harness)。文中汇总了 OpenAI、Anthropic、Scale AI、METR 等多方观点与数据,显示两派在“模型进步会不会吞噬 Harness 价值”上分歧明显。作者最终认为,随着 Agent 产品落地加速,Harness Engineering 的独立价值正在被市场和社区进一步确认。

10 分钟
每个 Agent 都需要一个 Box:Aaron Levie 谈 AI 时代的新基础设施
深度·3月5日
每个 Agent 都需要一个 Box:Aaron Levie 谈 AI 时代的新基础设施

在围绕“AI 是否正在杀死 SaaS”的争论中,Box CEO Aaron Levie 提出相反观点:企业内容与文件系统在 Agent 时代反而更关键。随着 Filesystem、Sandbox 和 Agent 工作流快速普及,核心问题从“让 Agent 能做事”转向“如何治理 Agent 的身份、权限与安全边界”。他认为,未来企业将拥有远多于人的 Agent 数量,而真正的竞争力在于率先完成面向 Agent 的组织与基础设施改造。

8 分钟