Leina 的安全连接与开源承诺

概念插图：团队任务通过授权连接访问业务应用。

让 AI 整理邮件、查找文档或更新业务记录之前，团队需要明确访问边界：使用哪个账号，允许执行哪些操作，哪些成员可以使用连接，结果交给谁。

Leina 通过已授权的连接访问业务应用，并结合成员和群组权限管理可用范围。应用连接由 OpenConnector 处理，原始账号凭证保留在连接运行时内，Agent 使用完成任务所需的操作与结果。连接架构

我们公开关键组件的代码与文档，供开发者检查凭证处理、权限声明和调用逻辑，并与社区共同改进。公开项目提供的是实现和协作记录；账号凭证与业务数据的访问仍由授权连接和权限配置管理。

让安全边界可以被检查

一项安全设计应有具体的实现依据。通过公开源码，开发者可以检查：

• 凭证怎样处理： 原始凭证保存在什么运行时边界内，哪些调用路径使用它们。
• 操作需要哪些权限： 连接器声明了哪些权限，读取和写入分别需要什么授权。
• 改动怎样验证： 修复解决了什么问题，增加了哪些回归检查，谁参与了贡献。

这为社区审查提供了公开入口。开发者和安全研究者可以检查实现、提出问题，并按照安全政策私下报告潜在漏洞。团队使用时，仍需根据任务配置账号授权和访问范围。

在维护这些能力的同时，我们也让其他开发者能够复用相关项目，把已经公开的连接、工作流和客户端工具用于自己的产品。

从一项团队任务，明确授权范围

假设团队交给 Leina 一项任务：

读取本周的客户邮件，整理需要跟进的事项，附上原邮件链接，先给我一份草稿。

这是一个说明连接关系的示例，实际可用的操作取决于连接器支持、账号授权和团队设置。

Leina 需要理解“本周”“客户邮件”和“跟进事项”的含义，选择读取邮件的操作，再组织结果。OpenConnector 为这些应用操作提供连接与执行能力：使用已授权的账号，检查相应访问范围，并调用业务应用。

flowchart TB
  accTitle: 从任务到已授权的应用
  accDescr: 团队在聊天中提出任务，Leina 选择所需操作，通过 OpenConnector 的鉴权与访问控制使用已授权的业务应用。
  T(团队任务):::channel --> L(Leina):::agent
  L --> G("OpenConnector\n鉴权与访问控制"):::gateway
  G --> A("已授权应用\n邮件、文档、业务记录"):::resource

Leina 提供面向团队的 AI 工作体验；OpenConnector 提供应用连接基础设施。 这套网关可以独立使用，支持 SDK、CLI、MCP 和 HTTP/OpenAPI 接入。其他开发者能够把它接入自己的 Agent 或应用。OpenConnector 的架构与接入方式

凭证、操作与数据访问怎样分工

业务应用有不同的授权方式、权限定义、输入输出和错误处理。读取一封邮件与修改一条客户记录，需要的访问范围也不同。随着应用和任务增加，这些差异会直接影响 Agent 能否可靠地完成工作。

我们把连接能力放在一个独立的网关里维护。调用方可以发现可用操作，检查输入输出结构和所需权限，再选择连接执行。账号的原始凭证留在运行时边界内，Agent 获取执行所需的元信息与结果。网关提供的能力

这种分工也让改进有了明确的位置。一个应用需要增加只读权限声明，一项操作需要修正输入结构，或文件下载需要更合适的处理方式，都可以在连接层中检查和修改，并留下公开记录。

同一套 provider 标识、action 标识和操作契约，可以被不同接入方式使用。开发者可以围绕自己的产品组织任务，复用连接层的工作。开发者工具

我们贡献给社区的项目

我们对开源社区的贡献，包括可独立使用的网关、调用工具，以及持续维护这些项目的协作空间。

开发者可以检查连接器的权限声明、操作结构和执行代码，也可以运行自己的 OpenConnector。自部署运行方需要配置存储、鉴权和自己的 OAuth 应用，并按照部署文档维护运行环境。独立部署说明

OpenFlow 将工作步骤放在可检查的画布中，可以独立部署，并通过 OpenConnector 等连接运行时发现和执行应用操作。账号凭证保留在连接层，工作流引用连接标识。项目目前处于 Beta 阶段。OpenFlow 的应用连接方式

这些项目分别提供连接、工作流和客户端接入能力。各仓库的许可证说明开源适用范围，第三方服务与素材仍遵循各自的条款。你可以在开源专页查看项目入口、Star 数量和参与方式。

与社区一起改进授权与连接安全

一项开源贡献是否有价值，可以从它解决的具体问题来判断。下面两个已合并的社区 PR，分别涉及权限声明和连接生命周期。它们展示的是公开仓库中的改进，不作为 Leina 当前线上版本已部署这些改动的证明。

Gmail：为只读任务申请合适的权限

在原来的 Gmail 权限声明中，服务账号与用户 OAuth 使用同一个列表。这个列表适合服务账号，但缺少用户 OAuth 可以申请的 gmail.readonly。只需要读取邮件的集成，因此无法通过这份声明单独申请只读权限。

贡献者 @bakey 在 PR #586 中把两份列表分开：用户 OAuth 声明加入只读权限，服务账号继续使用原有权限列表。这样既让只读集成可以选择更合适的授权，也保留了现有服务账号的授权范围。PR 同时补充了对应的回归检查。

对一个整理邮件的任务来说，这类细节影响的是它需要申请多大的权限。把权限声明和修改过程公开，开发者就能够检查这个边界，并为自己的集成选择适合的范围。

OAuth：断开连接之后，保持断开状态

授权过程可能与其他操作同时发生。一条尚未完成的 OAuth 回调，在用户断开连接后继续运行，就可能重新写入凭证。

贡献者 @powerfulZ 在 PR #698 中修复了这个并发问题：断开连接会更新持久化的退役代次，授权流程在写入凭证前检查自己捕获的代次是否仍然有效。过期的授权流程因此不能恢复已断开的连接；新的明确授权可以重新建立连接。

PR 的验证记录覆盖 SQLite、D1 和 PostgreSQL 的相关存储路径。这类改进让“断开连接”对应的状态变化更完整，也让维护者能够通过公开回归验证继续检查它。

这些成果来自项目维护与社区贡献的共同工作。我们保留贡献者署名，并通过 发布记录公开新增能力、修复和参与者。

根据公开依据检查连接，按实际任务分配权限

源码公开之后，用户和开发者可以获得具体的检查入口：连接器声明了哪些权限，一项操作接受什么输入，执行代码怎样访问上游应用，问题修复又增加了哪些验证。

使用时仍需核对具体应用、账号和操作。OpenConnector 明确区分目录中存在的操作、本地可执行的操作，以及有真实上游 API 验证证据的操作。连接数量描述覆盖范围，具体任务是否可用需要进一步确认。项目的验证口径

对团队用户，建议通过 Leina 从一个明确的只读任务开始，检查结果与来源，再按工作需要扩大访问范围。关于账号授权和第一个任务，可以继续阅读安全连接业务应用；关于多人使用的边界，可以阅读团队 Agent 的权限与数据访问。

对开发者，可以先运行 OpenConnector，检查所需操作，再接入自己的 Agent 或产品。发现问题时，提供可复现的步骤；新增能力时，按贡献指南提交代码、文档和检查结果。涉及凭证或潜在漏洞的问题，请按安全政策私下报告。

我们把关键组件的实现开放给开发者审查，并通过公开协作持续改进授权与连接能力。团队可以据此了解 Leina 的技术基础，其他开发者也能够复用这些项目，把改进带回社区。