Arkon：将 Claude 从个人聊天机器人转变为受管理的组织资源

分享一个我一直在构建的项目。不寻求任何特定的东西——只是觉得这个问题和解决方法可能对这里的一些人感兴趣。# 问题大多数采用 LLM 的公司都会遇到同样的瓶颈：每个员工都单独使用 ChatGPT 或 Claude，将机密文档复制粘贴到随机聊天中，而组织对这一过程毫无可见性或控制权。“AI 部署”实际上只是购买许可证加上祈祷。另一方面，重型企业解决方案（定制 RAG 平台、类似 Glean 的工具）昂贵、复杂，对于大多数中型团队来说是大材小用。这里存在一个缺失的中间地带：小型至中型组织希望员工能够高效地使用 Claude，但需要适当的访问控制、共享知识，并且每次都不需要手动复制上下文。# 方法 Arko 位于组织和 Claude 之间。管理员集中管理知识。员工通过 MCP（Model Context Protocol）连接到 Arkon，并根据其身份自动获得正确的上下文，无需进行任何配置。两个领域：**全局知识** \- 组织范围的文档和 Wiki，按部门划分。财务人员看到财务文档，工程师看到工程文档。管理员决定谁可以看到什么。**工作区** \- 用于项目、团队或跨职能计划的较小范围。成员身份限制。您的全局角色不会渗透到工作区中——您只能看到自己是成员的工作区。MCP 集成意味着员工可以继续以他们已经习惯的方式使用 Claude（Claude Desktop、Claude Code，或者他们喜欢的任何客户端）。他们不需要学习新工具。他们只是突然在需要时拥有了组织上下文。# Wiki 生成实际如何运作我认为这部分有趣且与典型的 RAG 设置略有不同。Arkon 不是一个检索增强型聊天机器人。它是一个 LLM 生成的 Wiki 层。当您上传一个文档——例如一本 300 页的手册——Arkon 使用 LLM 分析结构并生成层级式的 Wiki。如果源文档有清晰的标题，Wiki 会遵循它们。如果没有，LLM 会按主题语义聚类内容。输出是一个可浏览、有组织的内部参考，而不是线性摘要。我对用户诚实地说明了权衡：LLM 生成的内容无法保证准确性，尤其是对于深度领域材料。因此，路线图里有一个“人在回路”层——员工可以标记、注释和编辑 Wiki 内容。LLM 做组织方面的大量工作；人类负责最终的正确性。# 权限管理的经验教训迄今为止最大的设计转变：最初我把角色分为两种——*你能做什么* 和 *你能对什么做* 放在一起。这导致了一个经典的错误——给用户“读取文档”权限，突然他们可以读取组织中的每个文档，忽略了部门范围。通过清晰分离解决了这个问题：* 权限是有范围的字符串：`doc:read:own_dept` 与 `doc:read:all` * 工作区是纯粹的成员身份检查——全局角色永远不能授予工作区访问权限 * 两个领域，完全独立如果有人正在构建组织级权限系统，尽早正确分离这一点是值得的。后期重构会很痛苦。欢迎回答关于架构、MCP 集成或权限模型的问题。反馈和批评欢迎——特别是来自任何构建或使用过内部知识系统并了解哪些有效、哪些无效的人。