用 AI 智能体扩展社区，同时保持人性化

作者：Pauline P. Narvas

原文：查看原文

在 Vercel，开发者社区始终处在我们所有工作的核心位置。这是我们与真实用户保持最紧密连接的方式。

随着社区不断扩大，自动化确实帮我们把规模做起来了。但现实问题并没有因此消失：帖子会漏掉，分流需要时间，频繁的上下文切换也会消耗团队的注意力，让我们很难专注在那些真正需要专业判断的工作上。

与此同时，社区里最重要的那部分工作——真正理解一个人、与他建立连接、帮他把问题解决——本来就不该被机械化处理。自动化可以把重复劳动拿走，但它替代不了真诚的交流。

所以，我们搭建了一套 AI 智能体系统，来接管那些不需要人工逐条处理的分流、分类和后续跟进工作。我们把其中的核心流程叫作 Community Guardian（社区守护者）。下面就讲讲它具体做什么、我们是怎么搭起来的，以及为什么即使你不是工程师，也能把这类系统做出来。

Community Guardian 运营层

当有新帖子进入社区时，Guardian 会先分析内容、检查是否重复，再把帖子分配给最合适、同时当前有处理余量的团队成员。为了让跨时区协作保持平衡，系统会控制每个人在新问题持续流入时所承接的任务量。

它的目标很简单：不要让任何问题被悄悄遗漏。如果某个问题在 48 小时内还没有收到答复，Guardian 会重新分配；如果还在等待更多信息，它会自动发出提醒；如果对话已经解决，它也会识别出来并更新状态。

底层实现上，Guardian 通过 AI Gateway 调用 Claude，并运行在 Vercel Workflows 上。这样一来，它可以每 10 分钟检查一次新动态，又能在检查间隙休眠，不会白白消耗资源。

这解决的是“运营效率”问题，但团队要想给出高质量回应，仍然需要更完整的上下文。

智能层：c0 研究助手

Guardian 负责处理后勤流转，c0 则负责深入研究。它直接运行在 Slack 里，也就是我们团队本来就在工作的地方。

当团队成员需要理解某个话题的来龙去脉时，c0 会去检索知识库、文档、GitHub issues 以及历史讨论，再整理成一个上下文包。这样一来，团队的回应不必高度依赖个人记忆，而能更快、更准地建立在完整信息之上。

向 c0 询问关于 v0 的社区反馈

它的价值不只体现在单个问题上。c0 还帮助我们把社区与产品团队真正连起来：它会持续跟踪社区情绪，以及那些反复出现的技术障碍。于是，我们可以直接向 c0 询问“当前最重要的产品反馈是什么”，把真实数据带进产品讨论，而不是让某个人花几个小时去手工翻完一周的帖子。

重获人类专注力

在最初的 23 天里，这套系统帮助了 281 位独立用户：

指标	结果
初始上下文收集	完成 4,716 次初始响应，在团队成员正式接手前先完成问题分类与日志收集
话题复活	大约八分之一原本“被遗忘”的话题被重新激活，其中 23 个最终收敛为确认可行的解决方案
运营规模	最近两周内累计运行超过 1,400 次，从超时检查到自动结案都能覆盖
重复检测	通过向量相似度识别出 4 个重复话题，其中 3 个在 95% 以上置信度下被自动关闭

真正有分量的回复，依然由团队成员来完成。AI 智能体负责的，是围绕这些回复展开的大量重复性工作。少了分类、跟踪、提醒这些后勤负担之后，团队就能把时间放回更值得人来做的事情上：复杂排障、深度沟通、内容创作，以及和社区成员建立真实关系。

构建你自己的

你不必是开发者，也能做出类似的系统。你首先需要的，不是工程头衔，而是一个清晰的问题意识。

我自己就不是工程师。我的工作是运营社区、和开发者交流。我当然理解团队想解决什么问题，但我并不是每天都在写生产代码的人。

这个想法最早来自我在苏黎世的一次演讲中分享的社区自动化流程。那时候我们做的还是传统自动化：脚本、规则、以及 if this then that 式逻辑。它当然有用，但也确实脆弱——每出现一个边缘情况，你几乎都得再补一条规则。

在 Vercel Ship Zurich 演示我们的社区自动化工作流程

后来，我想要的是更聪明的一层：在“新帖子到达”和“系统采取行动”之间，先加入一步判断。所以我开始用 Coding Agents 反复实验。不再只是“如果帖子里出现 billing，就转给计费团队”，而是变成“先读懂这个帖子，判断对方真正需要什么，再决定下一步怎么处理”。

这层“判断”不是在模仿某个虚构角色，而是在给流程补上一段语义理解和情境判断能力。它可以帮助系统：

• 在用户只说“它不能用了”时，也先推断出更具体的问题方向
• 把当前帖子和几个月前的 GitHub issue 关联起来
• 区分对方是在表达挫败感，还是只是暂时困惑
• 判断什么时候应该升级处理，什么时候先补充更多上下文

这样构建的好处是：我可以直接用自然语言描述我想要什么，拿到一版可运行的代码，再用真实社区话题去测试、继续迭代。

我希望不同任务能调用不同模型，希望智能体可以访问文档和社区数据，也希望它在任务中断时能够暂停并恢复执行。这些能力我并没有从零手搓，而是把需求直接讲给 Coding Agents，最后选用了 AI Gateway、AI SDK 和 Vercel Workflows。这些工具本身已经处理了大量底层复杂度。

如何一步步把 prompt 具体化

第一个 prompt 很简单，核心只是把目标说明白：

构建一个帮助我处理社区日常运营的 agent，
比如分配帖子和格式化。我还不知道哪个模型效果最好，
但要让它能够方便切换，而不需要重新处理 API 密钥。
使用 AI SDK 构建这个 agent。

随着我对系统理解越来越深，prompt 也逐渐变得更具体：

每 10 分钟触发一次，检查最新的话题。

一开始我用的是 cron jobs，后来切换到了 Vercel Workflows。原因很简单：持久执行意味着智能体可以在两次检查之间暂停，并在中断点继续恢复，而不是每次都从头开始。

确保我们每 4 小时轮换一次分配。

每一个 prompt 都会引出下一个更具体的问题。我并不是按着某篇教程一步步照做，而是在和系统持续对话，系统也在这轮对话里逐渐成形。

你不需要先掌握所有正确术语，也不必等到“完全会写代码”才开始。你真正需要的是：能把问题描述清楚，并愿意在结果不符合预期时继续迭代。这样一来，自动化就不再只是“死板执行这些规则”，而是开始具备“理解情境后再行动”的能力。

用心构建

社区最终关乎人。我们希望团队成员有足够的时间和精力，以最好的状态出现在社区里，和开发者一起构建，也为他们构建。

如果你也想做类似的东西，我们用 Chat SDK 构建了 c0。它是一个统一的 TypeScript SDK，可以跨 Slack、Teams、Discord 等平台构建智能体。Guardian 则运行在 Vercel Workflows 上，负责持久执行。欢迎来社区分享你做出来的东西，我们也很乐意继续交流这一路踩过的坑和学到的方法。

---

关键要点

1. 自动化后勤，保留人味：把分流、分类、跟进这类重复工作交给 AI 智能体，让人把精力放回需要专业判断与同理心的问题上。
2. 双层架构：运营层由 Guardian 负责分配和跟踪，智能层由 c0 负责研究与上下文补全。
3. 非工程师也能搭建：只要你能把问题描述清楚，就可以借助 Coding Agents 和自然语言逐步把系统做出来。
4. 渐进式迭代：先从简单 prompt 开始，再通过真实场景不断细化约束和流程。
5. 工具要各司其职：AI Gateway 负责模型访问与切换，Vercel Workflows 负责持久执行，AI SDK 负责智能体开发。

技术栈

• AI Gateway：统一的 AI 模型访问层，支持灵活切换模型
• Vercel Workflows：持久执行引擎，支持暂停与恢复
• AI SDK：用于构建 AI 智能体的 TypeScript SDK
• Chat SDK：用于在 Slack、Teams、Discord 等平台构建聊天智能体
• Claude：主要使用的 LLM 模型

适用场景

• 社区管理与支持自动化
• 客户服务工单的分类与分流
• 知识库检索与上下文聚合
• 团队工作负载平衡
• 情绪分析与反馈收集