我构建了一个工具来帮助社区支持。然后我一直在构建。
我一天中很大一部分时间都在 CopilotKit 与社区一起工作，在 Discord、GitHub 和 Slack 中回答问题，帮助人们摆脱困境，并指引他们找到正确的资源。
我开始构建answerLoops来帮助我完成这项工作。随着它逐渐成形，我添加了更多集成，将其他社区也纳入进来，这样其他团队也可以使用它。
它是开源的，我正在公开构建它。
查看 answerLoops GitHub ⭐️
这项工作的很大一部分是决定知识如何进入系统。有些答案在文档里。其他的则来自支持对话，或者是团队中某个人恰好知道的事情。
为了让智能体能够使用这些答案，团队需要一种直接的方式来保存、审查并保持它们的最新状态。这就是我一直在构建到知识库中的功能。
回答问题只是工作的一部分
一个问题来了。你找到相关的文档或资源，弄清楚它如何适用于那个人的具体设置，然后写一个回复。
在那次对话中，你可能会发现文档没有覆盖的内容。一个缺失的设置步骤、一个令人困惑的默认值，或者一个值得单独成文的变通方法。
你解决了问题，但那个有用的细节仍然埋在对话里。当其他人再问时，团队不得不再次找到它。
我希望 answerLoops 能帮助这两部分：现在准备一个有用的答案，并为未来的问题保存团队学到的东西。
answerLoops 做什么
answerLoops 将来自已连接渠道（GitHub、Discord、Telegram 等）的支持问题带入一个仪表盘，并使用你的知识库来帮助准备答案。
对于工单流程中基于知识的回复，一个 Mastra 智能体生成草稿，另一个独立的智能体对其进行评估。第二个智能体只是审查者，其作用是确保草稿简洁准确。然后团队可以在仪表盘中审查、编辑或驳回草稿。
还有一个可嵌入的网站聊天小部件，使用 CopilotKit 构建并连接到一个 Mastra 支持智能体。访客可以直接提问，已发布的知识库文章会作为参考资料提供。
该组件现在支持更丰富的回复，包括分步指南、快捷回复、标注、链接卡片和联系方式选项。
但这些答案的质量取决于智能体可获取的信息。这就是为什么最近的大部分工作都集中在知识库上。
添加文档中没有的答案
有时你不需要导入文档站点。你只需要写下智能体应该知道的内容。
所有者或管理员可以打开知识库 → 管理并使用手动编写答案：
- 输入问题或标题。
- 编写答案或上下文。
- 点击添加到知识库。
例如，客户可能会问更改配置是否需要重启。你团队中的某个人知道答案，但这一点没有记录在任何地方。
他们可以直接添加该说明。
文章在保存时即发布并建立索引，使其可用于后续问题。此表单没有草稿步骤，因此答案应适合客户阅读。
以这种方式添加的文章会显示在手动添加下的知识覆盖标签页中。
这是一个小功能，但它为掌握答案的人提供了一种直接改进智能体所知内容的方式。
引入你已有的知识
你也可以从现有内容填充知识库：
- 文档 URL：导入页面或抓取文档站点。
- 文件：上传 PDF、DOCX、Markdown、文本或 CSV 文件。
- GitHub：同步 Markdown 和 MDX 文件，可选在更改推送到默认分支时进行同步。
- Notion：连接你团队想要使用的页面和数据库。
Notion 内容以未发布状态导入。你的团队可以在将其用于面向客户的答案之前进行检查，并且该发布选择在同步过程中会保留。
手动录入表单与这些来源并存。如果答案已存在于你的文档中，请导入它。如果它只存在于某人的头脑中，请写下来。
将已解决的工单转化为可复用的知识
已解决的工单可能包含值得保留的说明。
该提升到知识库操作允许所有者或管理员将该工单的问题和答案转化为知识库文章。
在将其推广之前，请检查该答案是否适用于原始对话之外的情况。移除特定于账户的细节，使该解释对之后遇到同样问题的人有用。
这对网站小组件尤其重要。它检索的参考资料来自已发布的知识库文章，而不是原始的已解决工单。
推广答案会使其在共享知识库中占有一席之地，小组件可以在其中找到它。
让客户的问题帮助你决定写什么
你无法提前知道文档中的所有缺口。
TheReview标签页会捕获现有知识未覆盖的问题。在托管方案中，此队列在 Pro 及以上版本可用。
可用的草稿可以作为起点一并提供。如果没有草稿，该项目会被标记为No usable answer，然后可以由某人撰写。
所有者和管理员可以：
- 编辑问题和答案。
- 点击Approve and add to knowledge base。
- 或拒绝该项目。
在获得批准之前，队列中的任何内容都不会成为可搜索的面向客户的知识。
当同样的问题再次出现时，其计数器会增加，而不是创建另一个副本。被问得最多的问题会排在最前面。
这为团队提供了一个实际的起点。如果有多个人在询问同一个设置步骤，写一个好的答案很可能是值得花时间的。
从知识缺口到新文章
TheKnowledge Gaps页面提供了另一个视角，展示支持工作需要关注的地方。
它会呈现答案置信度低的工单、需要人工处理的工单，以及没有对应知识库文章的已解决问题。
重复的问题会被分组，并带有Asked N times徽章，这样你无需逐一阅读每个工单就能看到反复出现的主题。
The+ KB操作会打开手动录入表单，并填入工单的问题和任何现有答案。检查文本，添加文章，它就会链接回该工单以填补这个缺口。
你不必把问题搁置一旁，再到别处从空白文档开始。
检查智能体实际能找到什么
导入文档并不能告诉你它是否会对某个特定问题有帮助。
TheKnowledge coverage标签页显示按来源分组的文章，包括它们是已上线、未发布还是不可搜索。
还有一个试试客户问题字段。它运行与网站小组件相同的查询，并显示哪些文章匹配——或者没有任何内容覆盖该问题。
添加答案后，你可以尝试客户可能提问的几种方式，并检查结果。
这检查的是检索，而不是每个生成的回复是否都会正确。你仍然需要审查答案本身。但它为你提供了一种方式，去调查预期的信息是否被找到。
知识库是你的团队为智能体维护的产品知识来源。如果没有文章匹配，助手可以回退到通用知识，而这可能不适合你的产品。找出这些缺口并添加合适的材料，是维护它的一部分。
查看哪些文章被使用
最新版本还新增了文章使用情况跟踪。
answerLoops 统计的是文章作为上下文被提供给实际生成的答案的次数，包括网站回复和工单草稿。
这一区分很重要：这意味着文章被提供给了智能体，而不一定是最终回复引用了它。
搜索和模拟不会增加计数。
结合覆盖视图和重复问题计数，这有助于你了解哪些信息正在被检索，以及哪些地方可能需要更多工作。
CopilotKit 和 Mastra 的定位
我在 CopilotKit 从事 DevRel 工作，因此构建 answerLoops 的一部分工作，就是把我日常使用的工具整合进一个产品，并分享我的所学。
Mastra 运行支持草稿和网站对话背后的智能体，包括聊天智能体的线程记忆。
CopilotKit 为自定义小组件界面提供基础。应用程序将该界面连接到智能体，并提供相关的知识库上下文。
该产品还围绕这些部分拥有自己的工作流：导入来源、审查未回答的问题、发布文章，以及处理员工对工单的操作。
这些工作流正是团队得以改进智能体所用信息的地方。有人可以发现缺失的答案，撰写它、发布它，并检查未来的问题是否能检索到它。
随着我不断构建，这已经成为 answerLoops 中更大的一部分。
试试看，告诉我缺了什么
我最初做这个是为了帮助我自己的社区工作。我把它分享出来，是为了让其他开发者和支持团队也能在他们的社区里试用。
代码和安装说明在GitHub上，而知识库文档会带你了解这些工作流程。
如果它看起来有用，给这个仓库点个 ⭐️ star，这能帮助其他人发现它。如果你试用了，我想听听你们所有人的反馈。
如果你是开源新手，尽管联系我，我很乐意帮忙。我
你们团队把那些还没进入文档的有用答案保存在哪里？