配置并上线 FeedLog Agent
建议按三个步骤准备上线：准备它可以使用的产品知识，配置反馈和支持规则，再把反馈组件接入产品。组织所有者和管理员负责内容与设置，开发者负责网站接入和已有账号的身份连接。
第一次了解这个功能，可以先阅读FeedLog Agent 介绍。已有 Widget 接入的产品可以直接检查知识和配置，不必重新安装一套入口。
先从小范围试用开始
即使还没有帮助文章，也可以先接入 Widget，体验对话和反馈收集。产品知识不足时，Agent 对使用方法、功能限制等问题的回答质量会受到影响，因此建议在面向客户开放前，先补齐常见问题的说明。
不必一次写完所有文档。先选择一个核心使用流程，准备相关操作步骤和常见问题，在测试页面接入 Widget，由团队实际提问和提交演示反馈。确认知识、身份和反馈结果符合预期后，再扩大使用范围。
准备首批产品知识
先选出客户最常问的几类问题，为每类问题准备清楚的帮助文章：
| 内容 | 应写清楚什么 |
|---|---|
| 核心任务 | 从哪里开始、需要什么权限、每一步怎么做 |
| 功能限制 | 适用套餐、格式、数量限制和例外 |
| 常见故障 | 用户看到的现象、检查顺序、恢复方法 |
| 支持渠道 | 哪些问题需要人工、应该提供哪些必要信息 |
在帮助中心创建分区和文章，检查标题、描述与正文，开启合适文章的允许 AI 使用。未定稿的草稿先关闭。只有文章可以公开访问时，Agent 才能提供可点击的公开引用。
不需要把所有文章公开才能给 Agent 使用，但不公开资料里的内容仍可能进入客户看到的回答。完整步骤见编写和发布文章及AI 使用范围。外部文档站的文章需要另行整理进当前工作区的帮助中心。
已有文档如何接入
在控制台的帮助中心创建文章，将已有文档中适合回答用户的内容整理到正文，设置清楚的标题和描述，并开启允许 AI 使用。可以先从高频问题对应的几篇文章开始，操作步骤见编写和发布文章。
如果原文仍在外部文档站维护，产品规则变化时，也要同步更新 FeedLog 中的对应文章。更新后用新对话提问，确认答案与最新说明一致。
即将提供：AI SKILL 与 MCP
我们即将提供 AI SKILL 和 MCP，方便你使用熟悉的 Coding Agent 协助编写或导入帮助文档。目前请在帮助中心后台创建和维护文章。
整理反馈看板
检查看板名称和描述，让 Agent 能区分缺陷、功能需求和体验改进。描述应解释收录范围，例如“现有功能没有按预期运行”，而不只是重复“Bug”这个名称。
不用为 Agent 单独建立一套看板；它创建的反馈会进入原有反馈流程。看板管理见创建和管理看板。
配置反馈组件与人工支持
打开设置 → 反馈组件，检查以下配置：
| 配置 | 用途与建议 |
|---|---|
| 启用组件 | 默认开启；关闭后网站上不显示组件按钮 |
| 客服邮箱 | 用户需要人工帮助时提供的联系地址；留空时无法给出具体邮箱 |
| 联系人工规则 | 说明哪些具体场景需要团队处理 |
| 对话可见天数 | 控制用户能访问多久以前的会话 |
联系人工规则包含计费、账号访问、隐私与法律三类内置场景，可以分别启停。自定义规则每条最多 180 字符，内置与自定义规则合计最多启用 10 条。
规则应描述需要人工处理的情况：
| 太宽泛 | 更明确 |
|---|---|
| 计费相关的问题 | 用户需要核实本人账号的扣款、退款或发票 |
| 登录问题 | 用户无法恢复本人账号，需要团队核实身份 |
“支持增加一种支付方式”是产品建议，“这笔钱为什么扣了两次”是个人账单问题。不要把整个主题都定义成人工场景，以免普通建议也被引导到客服。
Agent 提供客服邮箱和联系指引，用户可以通过该渠道联系团队。用户明确要求人工，或存在严重隐私风险时，Agent 仍可引导联系人工；关闭规则不代表彻底禁止人工指引。
将 Agent 接入你的产品
接入后，页面右下角会出现悬浮按钮（Launcher）。用户点击按钮即可打开 Widget，在当前页面向 Agent 提问或提交反馈。
先选择适合产品的使用方式：
- 访客使用：用户无需登录即可开始对话。在工作区开启访客提交，并按需允许投票和评论。
- 沿用产品账号：用户登录你的产品后，以同一身份使用 Agent，无需另注册 FeedLog 账号。未登录时是否允许访客使用，由工作区权限决定。
在设置 → 反馈组件中复制工作区地址，按安装反馈组件完成接入。使用 Coding Agent 接入已有账号系统时，可直接复制Widget 接入 Prompt。
完成后，检查 Launcher 能否打开面板，以及登录和访客两种状态是否符合预期，再继续下方的问答与反馈检查。
自部署需先配置模型服务；支持截图还需要图片存储和视觉模型。
用真实问题检查上线效果
安装好后，从你的产品页面打开组件，使用当前产品资料可以验证的问题进行检查：
| 测试场景 | 检查什么 |
|---|---|
| 问一个帮助文章已说明的问题，再追问条件 | 答案是否遵循文章，是否理解前一轮上下文 |
| 用客户常用的语言提问 | 回复是否使用用户的语言，产品名称与操作说明是否清楚 |
| 打开一条公开文章引用，再返回 | 内容是否可读，能否回到原对话 |
| 问一个资料没有说明的问题 | 是否避免编造步骤、政策或产品承诺 |
| 提交一个已有反馈中的诉求 | 是否找到真正相同的问题，正确显示投票或反馈结果 |
| 提交一个新问题，再纠正一个细节 | 门户里保存的内容是否准确，后续编辑或评论是否符合条件 |
| 请求人工处理个人账号问题 | 邮箱与联系指引是否正确，是否避免把私人内容发布成反馈 |
| 分别以登录用户和允许的访客操作 | 身份、提交、投票和评论权限是否符合你的配置 |
反馈操作会保存实际内容，公开反馈会出现在门户。测试时使用明确的演示内容，不要填写真实的私人信息。管理员与普通用户的通知行为可能不同，不要仅用管理员账号判断订阅效果。
先处理知识缺失、冲突规则和错误联系方式，再开放给用户。遇到问题时按排障指南定位，不必反复重装 Widget。
收到反馈后，团队如何处理
Agent 创建的反馈会进入工作区原有的反馈管理流程。团队在控制台的反馈页面查看新记录，按平时的方式处理：
- 阅读标题、正文和补充评论，确认诉求及所属看板；发现重复记录时，合并重复反馈。
- 根据评估结果更新状态，在评论中回复用户；需要公开计划时，使用路线图与更新日志。
- 有进展需要告知用户时，按反馈通知规则发送更新。用户也可以回到 Widget 的 My feedback 查看本人反馈的当前状态和未读更新。
上线后的维护
产品规则变化时更新原有文章，检查相关资料是否仍引用旧规则。修改知识范围后用新对话复查，避免把已有对话中的旧信息误认为新读取的内容。
定期检查代表性问题和公开引用是否仍准确、可访问。新增产品能力时，把使用步骤与限制一起加入帮助中心，而不是只在更新日志中提到功能名称。
常见问题
可以在后台查看用户与 Agent 的完整对话吗？
目前控制台可以处理已经形成的反馈及其评论，尚无查看完整 Agent 对话的入口。仅发生问答、没有生成反馈的对话，目前也无法在控制台查看。
即将上线：Inbox
Inbox 将支持在后台查看所有用户与 Agent 的对话，包括没有转成反馈的问答，并支持团队直接人工回复对话。目前该模块尚未上线。
已经安装 Widget，还需要另外接入 Agent 吗？
Agent 使用同一个 Widget 入口。已有接入的产品可以从准备帮助文章、检查支持规则和验证实际对话开始；SDK 的接入与更新说明见安装反馈组件。
用户需要另注册 FeedLog 账号吗？
产品已有账号系统时，可以通过 Widget 身份接入使用现有账号；没有账号系统时，可以按需要开启访客提交、投票和评论。具体步骤见本页的“将 Agent 接入你的产品”。