跳到主要内容

发布到组织

个人插件只保存在你自己的电脑上。要让同事使用，或者从任务、自动化里运行它，需要把它上传到组织。管理员审查通过后，其他人才能看到。

在客户端创建 → 本机预检 → 私人安装和试用
  → 上传到企业（可选）
  → 隔离区 → 管理员审查与发布
  → 全公司或指定成员在目录中找到并安装
  → 管理员把它绑定到项目或组织，供任务和自动化使用

哪些内容仍然是个人的​

  • 个人插件保存在客户端的数据目录里，身份为 local:<uuid>，离线也能使用。
  • 删除或停用本机版本，不影响已发布的组织版本；组织发布也不会覆盖你的草稿。
  • 上传不会把个人插件的数据同步给组织。

1. 上传​

在客户端打开插件，点 上传到企业，选择可见范围：全公司，或者本组织里的指定成员。

在一台电脑上第一次上传时，客户端会用保存在系统安全存储里的 Ed25519 私钥给不可变的包签名，并把公钥随候选版本一起提交。

2. 隔离区​

Hub 会重新执行预检，生成一个不可变的候选版本，放进隔离区。此时不会执行、信任或绑定任何内容。

3. 审查​

在管理端打开 插件与应用。插件管理员需要：

  • 核对签名密钥的 Key ID 和 SHA-256 指纹，并明确登记发布者，Hub 随后用它验证包。登记发布者本身不会发布任何插件；
  • 阅读自动生成的报告：组件、依赖、权限摘要和调用入口；
  • 如果版本声明了发布评测，运行这些评测；
  • 发布这个版本。

管理员也可以用 导入并送审 直接导入插件包。管理端负责审查和治理插件，它不是插件编辑器。

发布评测​

清单最多可以声明 20 个 evaluations。每个包含一条代表性的 instruction、不含凭据的 inputs、可以判断的 criteria 和 expectedOutputs。它们随版本一起保存，修改后需要重新审查。

  • 管理员为评测选择底座、模型、执行机标签和密钥引用，评测在隔离的工作目录中运行。
  • Hub 会保存每个用例的快照、实际执行位置，以及每个产物的大小和 SHA-256。
  • 产出满足结果契约之后，仍需要人给出通过的结论。重新运行某个用例，会替换它之前的结论。
  • 声明了评测的版本，必须全部通过才能启用。没有声明评测的版本，只有管理员明确确认风险后才能发布。员工看到的目录会区分 已验证 和 已审查。
  • 评测在无副作用的条件下运行，产出优先使用 file、evidence 和 decision。如果把 git 或 url 设为必交，又没有沙箱能产生真实证据，门禁会阻断；"没有执行"永远不算通过。

4. 安装与绑定​

  • 员工在公司目录里找到已发布的版本，安装到自己的对话工具箱。安装状态随账号在各客户端同步，并固定在本人接受的版本上。公司切换版本后，需要本人确认升级。
  • 任务和自动化使用管理员绑定到项目或组织的版本，不受员工个人安装的影响。

上级组织发布并绑定的插件，下属部门可以在授权范围内使用。项目限制、指定的可见范围，以及不同公司之间的隔离仍然有效。

5. 运行前模拟​

绑定模拟会针对真实项目检查仓库、环境、密钥引用、在线执行机，以及每个 AI 节点的路由。配置还没准备好时也可以先保存绑定，模拟会列出阻断项。运行到缺少配置的步骤时会停下；补好配置后，从这一步继续，不会重复前面的 AI 工作。

运行开始时会锁定插件版本、绑定、节点设置和输入。之后的升级不会改变正在运行的流程。

上传前检查清单​

  • key 保持不变，内容有变化时 version 已经升级。
  • 每个 AI 节点都有清楚的提示词、60～86,400 秒的运行上限，以及显式的最小 capabilities。
  • Agent 之间的信息通过 outputs 和 inputs 交接，而不是靠"记住前面的对话"。
  • 工程成果声明为 git，文件成果写了准确的相对路径。
  • AI 审查和实现是两个独立的节点；人只负责业务验收或授权高风险步骤。
  • 没有写死环境、端口、机器、模型、账号或密钥。
  • 质量命令使用 argv 数组，工作目录在仓库内。
  • 预检全部通过，在真实项目上的模拟没有阻断项。
  • 已检查升级现有绑定会产生的影响。
  • 至少完整跑通一次，并且做过一次"失败、修复、继续"的验证。
harness harnesses runtime runtimes 底座
编辑此页