# 改善我们支持类别的体验 **URL:** \ **Category:** Site feedback\ **Created:** [2026年三月5日 14:45 UTC](https://meta.discourse.org/t/improving-the-experience-in-our-support-categories/397742 "2026-03-05T14:45:17Z")\ **Posts on this page:** 6\ **Page:** 2
**Author:** ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\ **Post date:** [2026年三月6日 11:06 UTC](https://meta.discourse.org/t/improving-the-experience-in-our-support-categories/397742/21 "2026-03-06T11:06:15Z")
> [@noahl](#): > > 将 AI 代理与 MCP 结合，为您开启了无限可能： 是的，当然，但这会增加交易成本（尤其是考虑到 MCP 的效率低下！） ---
**Author:** ![noahl](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/noahl/32/552343_2.png) [@noahl](https://meta.discourse.org/u/noahl)\ **Post date:** [2026年三月6日 11:21 UTC](https://meta.discourse.org/t/improving-the-experience-in-our-support-categories/397742/22 "2026-03-06T11:21:33Z")
我理解您对成本的顾虑，但我认为这必须与当前人工园艺的“人力成本”以及缺乏上下文的提示可能带来的挫败感进行权衡。传统的工作流程在向尚未找到解决方案的用户发送提示时，通常会导致“通知疲劳”。 MCP 目前确实有一些开销——但人工智能的效率只会随着时间的推移而提高，利用它来提供有意义、准确的解决方案指标，可能比要求员工手动分类每一个积压的主题更具可扩展性。 ---
**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\ **Post date:** [2026年三月8日 01:17 UTC](https://meta.discourse.org/t/improving-the-experience-in-our-support-categories/397742/23 "2026-03-08T01:17:16Z")
我们在 discourse ai 中已经支持极其复杂的智能体 我想知道我们如何才能暴露它，以便像这样复杂的工件可以轻松配置:thinking: 很想聊聊 ---
**Author:** ![noahl](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/noahl/32/552343_2.png) [@noahl](https://meta.discourse.org/u/noahl)\ **Post date:** [2026年三月8日 18:01 UTC](https://meta.discourse.org/t/improving-the-experience-in-our-support-categories/397742/24 "2026-03-08T18:01:45Z")
我很乐意聊聊！我知道这个话题与原帖略有偏离。但要回答关于设置此类工作流程的难易程度的问题——这在很大程度上取决于 Discourse 中自动化机制的工作方式——它不像允许管理员设置步骤那样，开箱即用的选项严重依赖于预定义的流程。将其拆分为“触发器”和“操作”，并允许管理员根据社区的需要进行配置，将大有帮助。这是我为此发起的一个功能请求 - [Feature Request - Split Automations into Triggers and Actions](https://meta.discourse.org/t/feature-request-split-automations-into-triggers-and-actions/384262) ---
**Author:** ![Lilly](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/lilly/32/575047_2.png) [@Lilly](https://meta.discourse.org/u/Lilly)\ **Post date:** [2026年四月21日 11:30 UTC](https://meta.discourse.org/t/improving-the-experience-in-our-support-categories/397742/25 "2026-04-21T11:30:37Z")
标记为解决方案毫无意义，因为一半的时候标记的是错误的帖子，或者根本没被勾选，或者原帖作者直接在回复中把它标记给自己。通常最好的回复被埋没，并未被标记为解决方案。 ---
**Author:** ![Andrew\_Rowe](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/andrew_rowe/32/445877_2.png) [@Andrew\_Rowe](https://meta.discourse.org/u/Andrew_Rowe)\ **Post date:** [2026年四月21日 13:47 UTC](https://meta.discourse.org/t/improving-the-experience-in-our-support-categories/397742/26 "2026-04-21T13:47:35Z")
> [@Lilly](#): > > “标记为解决方案”毫无意义，因为有一半的情况是标记了错误的帖子，或者根本没被勾选，或者原帖作者直接把它标记成自己的。 我觉得“毫无意义”这个词有点重，但我同意“标记为解决方案”这个功能经常无法准确反映哪条回复真正提供了答案。这是我在本论坛以及其他使用过的 Discourse 论坛中的观察。原帖作者将自己帖子标记为解决方案的情况尤为常见，而实际上往往是另一位用户（有时甚至是上一条回复）给出了答案。 禁止原帖作者将自己的帖子标记为解决方案，或许能解决这一问题。但我观察到，偶尔原帖作者确实是自己找到了答案，并在主题中分享，以便其他可能遇到同样问题的人参考。 [上一頁](https://meta.discourse.org/t/improving-the-experience-in-our-support-categories/397742.md?page=1)