帮助中心进工单台：从共享 Token 到按人鉴权，以及反馈如何回流内容运营
帮助中心进工单台，是指客服在工单控制台内检索、引用甚至起草帮助文章，而不是先离开工单再打开另一套知识门户。本文以 Document360 12.11.1（2026-11-02/03）把 Zendesk 扩展从共享 Token 改为按人登录，并开放文章与 Eddy AI 反馈 API 为新证据，对照 Zendesk 将于 2027-04-30 全面停用 Support API Token 的官方时间表，说明权限边界、用量归因与反馈回流如何决定集成是否真正可用。读完可以对着自有连接器清点：谁能看见哪篇文章、搜索与 AI 记在谁头上、点踩之后有没有变成可指派的改稿任务。
浏览 13
巴克励步
导语：工单台里的知识，先问「谁在用、记在谁头上」
帮助中心进工单台，是指客服在工单控制台的侧栏或扩展里检索、引用甚至起草帮助文章，而不必先离开工单、再打开另一套知识门户。看起来只是少点一次切换，真正决定这条链路能不能用的，却是三件更底层的事：权限有没有按人生效、搜索与 AI 用量能不能归因、读者点踩之后能不能变成可指派的改稿任务。
支柱文 帮助中心如何支撑 AI Agent 已经把「工单反哺文章、发布评测与灰度上线」讲清楚。本文不重写那套发布框架，而是往工单台这一侧补一层新证据：2026 年 11 月初，Document360 12.11.1（2026-11-02 发布，11-03 更新）把 Zendesk 扩展从共享 Token 改为支持按人登录，并开放文章与 Eddy AI 反馈的 API；与此同时，Zendesk 已在推进 Support API Token 退役——官方公告写明，2027 年 4 月 30 日起剩余 Token 将永久停用，范围包括 Ticketing、Help Center 与 Voice API。
共享 Token 摊平权限，也抹掉了用量归属
Document360 在 12.11.1 发行说明 里，把旧模式的问题写得很直接：Zendesk 里的 Document360 应用此前使用共享 Token，每一位客服都能访问全部已发布内容，不论其个人权限如何；搜索与 Eddy AI 的使用，也无法归属到具体用户或坐席。
新版本允许客服用自己的 Document360 用户或读者（reader）账号登录，并支持企业 SSO。此后，搜索与 Eddy AI 用量会记在已登录账号上。读者账号是只读的，适合「只需查、不能改」的一线坐席；需要在工单里起草文章的人，则应使用具有相应角色的用户账号。发行说明同时指向了设置文档 Set up Document360 for Zendesk：从 Zendesk 创建的文章不会立即发布，需由管理员、所有者或编辑在知识库门户审核后才会上线——这与「面板能写」不是一回事。
对帮助中心运营，这意味着至少要分清三类内容，而不能假设「已发布 = 工单台里人人可见」：
- 对外公开文：密码重置、计费说明、产品操作步骤，本就应该被自助门户、SEO 与坐席共同引用。
- 登录客户 / 套餐可见文：仅付费客户或特定产品线可见的排障步骤，若被共享 Token 摊平，会在回复里被误贴到不该看到的人。
- 内部排障文：已知缺陷、补偿口径、升级路径，一旦出现在对外回复或被下游 AI 引用，就是一次内容事故。
按人登录并不能自动解决内容架构问题，但它让知识库侧已经配好的角色与读者权限，有机会在工单面板里被遵守，也让「谁搜过、谁用了 AI」变得可审计。共享 Token 图的是开通快；代价是权限与归因一起被拿掉。
Zendesk 停用 Support API Token：帮助中心连接器也在时间表上
把知识库接到 Zendesk，过去最常见的做法是：在 Admin Center 生成一枚长期 API Token，再把它贴进知识库、Ticket Deflector 或同步脚本。这条路正在被关掉。
Zendesk 于 2026 年 6 月 1 日发布 《Announcing the removal of API tokens as an authentication method for API requests》，并在 开发者迁移指南 与 API changelog 中给出同一套三阶段时间表：
| 节点 | 变化（以 Zendesk 官方说明为准） |
|---|---|
| 2026-07-28 | 闲置满 30 天的 Token 自动停用；停用满 60 天永久删除；该日及之后新开的账户不能再创建或使用 API Token |
| 2026-10-27 | 既有账户也无法再通过界面或 API 新建 Token；仍有效的 Token 可继续用到 2027-04-30，除非因闲置被停用 |
| 2027-04-30 | 所有剩余 Support API Token 被永久停用，不可恢复，Admin Center 中的 Token 管理页也将移除 |
今天（2026-11-11）已经过了「禁止新建」这一档。还在跑的集成，靠的是存量 Token。公告写明：受影响的是当前使用 API Token 的 Ticketing、Help Center 与 Voice API，不自动覆盖 Messaging、Chat 等其他产品线。Zendesk 给出的理由也很清楚：API Token 无过期、无范围限制、不绑定具体应用——一旦泄露，只要还在被使用，就可以一直有效；OAuth 则以短时访问令牌、可配置范围与刷新机制取而代之。迁移期间，OAuth 与 API Token 可以并行到 2027-04-30，不必一天切完。
Document360 12.11.1 正是顺着这条时间表改连接方式：联邦搜索、Ticket Deflector，以及 Eddy AI 聊天机器人的工单升级与知识源，改为用 Zendesk 账号授权，不再要求在每条集成里手工粘贴 API Token。建立连接需要同时具备 Zendesk 与 Document360 的管理员权限，每条集成要单独授权一次。这不是「换一个更方便的密码」，而是把长期、全权、共享的凭证，换成可撤销、可审计、按应用分开的授权。
对帮助中心团队，清点范围不应只限于「Zendesk 扩展面板」本身，还要包括：
- 把帮助中心文章同步进工单搜索或联邦搜索的作业；
- Ticket Deflector、在提交前推荐文章的小部件后端；
- 调用 Help Center API 做导入、重定向、多品牌站点维护的脚本；
- 第三方 iPaaS、自定义 webhook（公告写明：用 API Token 回调自己 Zendesk 实例的 webhook，会在同一截止日后失效）。
一份「还在用哪枚 Token、最后一次调用是哪一天、对应哪条知识库集成」的清单，现在比再写一篇「如何安装扩展」更要紧。闲置 30 天即停用的规则，会先打倒那些只在月末跑一次的同步任务。
反馈若出不了门户，就变不成改稿任务
鉴权解决的是「谁能看见」；内容会不会变好，取决于「看见之后的信号能不能回到编辑队列」。12.11.1 的第二条主线，是给文章反馈和 Eddy AI 反馈补上 API。
按 Document360 的说明，团队可以把读者反馈接到已有的工单或项目管理工具，而不必只在知识库门户里处理：
- 文章反馈：可按状态、赞/踩、文章或页面分类、日期范围查询；查看内部讨论；更新状态或指派人；关闭条目时可选回复读者。
- Eddy AI 反馈：可按来源、已回答/未回答、原因查询，或取回完整对话。
- 重新打开已关闭反馈：读者跟进、内容修订没有站住，或关早了，都可以把条目从 Closed 拉回 Open，并可附加仅内部可见的说明；指派人与讨论历史保留。此前一旦关闭，就无法再改状态或继续讨论。
同一篇管理文档也写清了 API 的边界，选型时不要把「有 API」理解成「门户可做的事都能远程做」：
- 关闭后的条目不能通过 API 更新或重新打开，必须回到 Feedback manager；
- 讨论备注与批量改状态/指派不在 API 范围内；
- 接口返回读者评论，但不含姓名与邮箱；
- 关闭并选择通知读者时，仅当读者提交时勾选了「有更新时通知我」才会发信；
- 门户里导出 CSV 一次最多覆盖最近 90 天。
与 API 并行的，是 12.11.1 新增的一组 MCP 工具：列出/推迟/完成分配给自己的任务，按语言维护术语表，查看或为单篇文章设置复习提醒，提交文章反馈，以及更新指派给自己的反馈状态。通过 MCP 提交的原因会被映射到 Feedback manager 的标签（例如 Unclear →「难以理解」，Outdated → 归入 Others 并加上
[Outdated] 前缀）。换言之，智能体不仅可以读文档，还可以把「这篇过时了」写成一条跟人工反馈同一套队列的任务。这条闭环之所以重要，是因为「自动更新知识库」目前仍然停在草稿这一步。eesel AI 于 2026 年 10 月 19 日更新的对照 写明：当时没有一家主流帮助台会在无人点击发布的情况下，把对现有文章的修改直接上线；做得最好的产品是标记过时内容，或根据已关闭工单起草修改，发布权仍在人手里。eesel 的判断是：对退款政策这类内容，就应该如此。Mintlify 的 2026 State of Knowledge 从文档站点一侧给出相近的数字：调查中 83% 的受访者表示会让 AI 智能体起草文档更新，但只有 9% 允许智能体在无人审核的情况下发布。反馈 API 和 MCP 提高的是「信号进队列」的效率，不是把发布闸门拆掉。
对照：不要把「能在工单里搜到」当成集成完成
把 12.11.1 的改动和 Zendesk 的 Token 时间表放在一起，可以看出一条选型清单。下表用于自检，而不是给某一家产品打分。
| 检查项 | 仅共享 Token、反馈困在门户 | 更完整的集成应看到的样子 |
|---|---|---|
| 鉴权 | 一枚长期 Token 给全组用 | 按人登录或 SSO；系统间连接走 OAuth / 账号授权，可按应用撤销 |
| 权限 | 已发布内容对坐席一视同仁 | 公开 / 登录客户 / 内部文在面板里按角色继承 |
| 归因 | 搜索与 AI 用量算「这个扩展」的 | 记到具体坐席，可做质检与授权审计 |
| 反馈出口 | 点赞点踩只留在知识库后台 | 可按状态、赞踩、未回答问句导出到工单或项目工具，并能回写指派与状态 |
| 关闭语义 | 关掉即锁死，或关掉即消失 | Closed 与 Complete 分开；允许在跟进时重新打开并留下内部说明 |
| 发布闸门 | 面板里保存即上线，或完全不能写 | 工单侧可起草，发布仍经知识库角色审核 |
| 凭证生命周期 | 靠「这枚 Token 还没坏」 | 已按 2027-04-30 清点 Help Center / 同步 / Deflector 脚本 |
工单套件擅长会话、升级与座席工作台；帮助中心要负责的是可分发、带权限、能回流信号的内容真相源。二者重叠在「侧栏里能搜到文章」，并不等于后者已经就位。
Baklib Help Center 在这条链上补的是内容体验底座，而不是再做一套工单系统：
- 权限分级：公开、登录客户与内部分层可以分开托管，避免内部排障文进入对外回复，也避免为了保密把本该开放的 SEO 层全站锁死。
- Widget / API / Iframe 分发：官网、产品内与坐席工作台引用的应是同一份现行说明，而不是在工单工具里再复制一套宏。
- 反馈与运营数据：有用/无用、搜索失败与未解决问题，应能进入内容待办，而不是停在门户报表里（见 功能分析）。
- FAQ + 产品文档 + 更新日志 + 视频统一托管：坐席和下游 Agent 面对完整资产，而不是只覆盖工单域里的几篇宏。
- AI / LLM 语义搜索：按意图命中可核验文章，减少「关键词没命中就认为知识库没有」的假空窗；机制见 语义搜索一文。
- SEO / 多站点 / 多语言：现行说明要能被搜索与答案引擎找到，并在多语言下保持术语一致（见 SEO/AEO 与 多语言帮助中心）。
会话是否算 Verified，仍然要看帮助台自己的口径（见簇内文 Deflection 与 Verified Resolution）；但若工单台里引用的不是带权限的同一份真相源，分辨率报表再细，也只是在放大一份过时或越权的说明。
选型与运营启示（可执行清单）
- 立刻清点仍在使用 Zendesk API Token 的知识库集成。把联邦搜索、Ticket Deflector、Help Center API 脚本、同步作业和自回调 webhook 写成一张表：Token 用途、最后一次调用、负责人、迁到 OAuth 或账号授权的截止日期。已过 2026-10-27，不能再靠「先新做一枚 Token 顶上」。
- 工单面板默认改为按人登录或 SSO，不要用一枚共享 Token 给整层客服。先核对外开发布集与内部集是否被面板正确分开，再开放「从工单起草文章」。
- 把点踩、未回答的 AI 问句、MCP 提交的「过时」映射成内容待办：每条有指派人、状态和到期日；关闭前先确认文章已改、读者关切已处理——这与 Document360 自己写的 Feedback manager 实践一致。
- 区分 Complete 与 Closed，并保留重新打开的路径。读者跟进或修订没有站住时，应能带着内部说明回到队列，而不是另开一条丢失上下文的新反馈。
- 保留人工发布闸门。工单侧与智能体可以起草，高风险主题（计费、权限、退款、封禁）必须经知识库角色审核后再上线；这与支柱文 540a 的评测与灰度主张一致。
- 每月看一次「反馈转化率」：有多少点踩或未回答问句，在约定周期内变成了已发布的文章修订。只统计反馈条数、不统计改稿闭环，会把运营做成收件箱。
- 帮助中心与 Agent 知识源清单对齐：面板里能搜到的、Widget 里能打开的、AI 能引用的，应是同一套带权限的现行页；口径漂移会同时抬高复访，并污染 Verified Resolution 的供给。
收束：集成完成，以权限与回流为准
帮助中心出现在工单侧栏，只是集成的可见部分。Document360 12.11.1 把两件过去常被省略的事写进了产品：共享 Token 会摊平权限、抹掉用量归属；反馈若不能进入团队已经在用的工单或项目工具，就很难变成改稿任务。Zendesk 把 Support API Token 的终点钉在 2027-04-30，则提醒所有还在「粘贴一枚长期密钥」的知识库连接器：无过期、无范围、不绑定应用的凭证，正在退出帮助中心集成的默认做法。
鉴权解决「谁能看见哪一篇」；反馈 API 与复习提醒解决「看见之后的信号去哪」；人工发布闸门解决「起草不等于上线」。工单套件继续编排会话，Baklib Help Center 则守住可分级、可分发、可度量的内容真相源。两边对上了，坐席在工单里贴出的那篇说明，才配被看成现行知识，而不是又一次方便的复制。
想要了解更多?
数字内容新基建白皮书
常见问题
共享 Token 和按人登录差在哪？
共享 Token 通常让工单台里的每一位客服看到同一份「全部已发布内容」，搜索与 AI 用量也很难记到个人。按人登录（或企业 SSO）后，知识库侧的角色与读者权限可以在面板里生效，用量与审计才有归属。
Zendesk API Token 什么时候会彻底失效？
根据 Zendesk 2026-06-01 的公告与开发者迁移指南：2026-07-28 起闲置 30 天的 Token 会自动停用，2026-10-27 起已无法新建 Token，2027-04-30 起剩余 Support API Token 将被永久停用且不可恢复。范围覆盖 Ticketing、Help Center 与 Voice API。OAuth 与 Token 可并行到该截止日。
反馈 API 能替代知识门户里的 Feedback manager 吗？
不能完全替代。Document360 的 v3 API 可以把文章反馈拉进工单或项目管理工具，并回写状态、指派人，关闭时也可选通知读者；但关闭后的条目不能通过 API 更新或重新打开，讨论备注与批量操作也不在 API 范围内。重新打开仍需回到 Feedback manager。
为什么还要人来点「发布」？
eesel AI 在 2026-10-19 的对照中写明：主流帮助台最多做到「标记过时」或「起草修改」，不会自行把对现有文章的改动直接上线。Mintlify《2026 State of Knowledge》调查里，83% 的受访者表示会让 AI 起草文档更新，但只有 9% 允许智能体在无人审核的情况下发布。退款政策、权限说明这类高风险内容，保留人工发布闸门是默认正确的做法。
这篇是支柱还是簇内文？
簇内文（cluster），挂在支柱「帮助中心如何支撑 AI Agent」（/app/help-center/posts/540a）下，补充工单台侧的鉴权、Token 退役与反馈回流，不重写支柱里的工单反哺文章、评测与灰度上线框架。
