---
title: 业务能力与执行引擎边界
description: 区分业务对象、能力类型与分发包，明确 DSH 适配和后续引擎接入的责任。
lastVerified: 2026-09-24
---

# 6.2 业务能力与执行引擎边界

Teloa 在执行引擎之上组织业务。集成时先确定对象属于哪一层，再确定由谁保存状态、检查权限和报告结果。概念总览见[三层产品架构](https://docs.teloa.ai/markdown/concepts/layers.md)。

## 1. 产品三层与工程职责

**AI-Native Team Studio = AI Team + Agent Studio + Agent Harness**。这是产品架构，不是三套服务或三个代码包。

| 产品层 | 维护什么 | 集成约束 |
| --- | --- | --- |
| AI Team | 同事、业务、项目、群、任务、自动化、审批与成果 | 保留长期身份、业务归属、历史和交付判据 |
| Agent Studio | 岗位、知识、技能、工具 / MCP 与权限配置 | 说明资源来源、适用范围和所需授权；配置不自动提权 |
| Agent Harness | 模型、运行时、工具网关、沙箱、审批与可观测性 | 通过正式接口运行，核验权限，返回真实执行状态 |

Team 是产品，Agent 是工作单元，Harness 是运行底座。业务、能力与执行仍可用于描述工程职责，但不构成另一套产品三层。系统及代码包架构单独见[源码架构](https://docs.teloa.ai/markdown/develop/architecture.md)。扩展包是分发单位，可提供技能、连接和运行组件，不是第四层。

## 2. DSH 对象如何映射

当前适配以 DSH 为基础。下表约定产品概念与原生对象的边界；具体原生面板的可用版本见[原生运行能力](https://docs.teloa.ai/markdown/guides/native-capabilities.md)。

| 原生概念 | Teloa 如何使用 | 不能直接等同于 |
| --- | --- | --- |
| Plugin | 注册工具、服务、界面或配置等运行能力 | 一项业务技能或一个岗位 |
| Bundle | 组合插件与配置，记录分发来源 | Teloa 行业方案或业务资源包 |
| Agent preset | 选择模型与运行配置 | AI 同事的长期身份和授权 |
| Agent Team / teammate | 执行小组与临时执行助手 | 工作群与长期 AI 同事 |
| Session / job | 会话与运行事实 | 业务任务的完成判定 |
| Workspace / directory | 执行位置及文件边界 | Teloa 的业务项目 |

AI 同事可以选择运行配置，但职责、记忆和业务授权仍归同事所有。执行助手的名称不能成为身份凭据，也不能借用同名同事的权限。普通会话可以组织执行小组；它不会因此自动成为有负责人和验收判据的业务任务。

## 3. 分发、配置、运行与授权分别记录

不要用一个“已启用”字段覆盖以下事实，也不要把它们强行排成每项能力都必须经过的流程：

| 事实 | 要能回答的问题 |
| --- | --- |
| 来源与安装 | 哪个发布者、哪个包和版本提供了它？安装是否完成？ |
| 保存的配置 | 全局或哪个运行配置启用了它？是否等待重启？ |
| 实际运行 | 当前宿主是否加载成功？有无错误？ |
| 连接与凭据 | 外部服务是否连通，使用哪个已授权账号？ |
| 业务授权 | 哪位同事在什么业务或任务中可以使用哪些操作？ |

不适用的维度应明确省略。官方与第三方描述发布者，内置与自行安装描述交付方式；这些属性都不能单独决定组件是否可停用。

来自同一个扩展包的技能和连接，应保留包的来源关系。能力页可以投影这些条目，但不能把包内资源当成独立安装再重复卸载。引擎插件清单用于诊断全局和运行配置中的组件，不应把每个底层组件都包装成用户需要管理的业务能力。

Teloa 的待安装记录、包内容哈希、请求标识和安装回执用于审批与中断恢复。复用原生安装器时仍需保留这些业务记录；原生安装成功不能自动替代业务确认或授权。

## 4. 优先复用官方能力

引擎已经提供的执行、取消、会话读取和插件管理，优先调用正式服务。薄适配负责把它们映射到 Teloa 的任务、负责人、审批与成果，不复制一套引擎状态机。

受管任务以 Task/Run 保存业务归属，以引擎返回的会话、成员和后台工作标识关联执行事实。停止请求发出后，应等实际工作结束再报告已停止；断线或等待取消期间不能伪装成完成。执行成功也不等于业务成果通过验收。

界面职责保持一致：市场负责发现，能力页负责管理可用资源，设置负责运行参数，系统组件清单负责诊断。入口整合方向不代表所有页面已经改造，当前操作以[能力与连接指南](https://docs.teloa.ai/markdown/guides/capabilities.md)为准。

## 5. 说明具体接入方式

评估其他产品时，应写明是导入技能、连接 MCP、适配分发包格式，还是使用官方执行接口。某种资源能导入，不代表该产品已成为 Teloa 可切换的执行引擎。

各生态对包的定义不同，可参考 [Codex Plugins](https://developers.openai.com/plugins/concepts/plugins)、[Claude Code Plugins](https://code.claude.com/docs/en/discover-plugins)、[Cursor Plugins](https://cursor.com/docs/plugins)、[OpenCode Plugins](https://opencode.ai/docs/plugins/) 和 [Kiro Powers](https://kiro.dev/docs/powers/)。这些是概念参考，不是 Teloa 的兼容性清单；OpenCode 等产品的不同主版本也需单独验证。

## 6. 集成验收

1. 写明引擎版本、支持的接入方式和未支持的能力。
2. 明确业务身份、能力来源、运行配置和原生执行标识的映射。
3. 分别验证安装、配置生效、连接失败和授权拒绝；错误应能回到用户可操作的入口。
4. 验证主任务与子工作停止、断线重连和宿主重启，不丢失归属或虚报完成。
5. 用隔离数据库与真实宿主验证一条完整任务链路，再核对中英文界面的状态和提示。

现有代码职责见[源码架构](https://docs.teloa.ai/markdown/develop/architecture.md)，权限检查见[执行授权边界](https://docs.teloa.ai/markdown/develop/permissions.md)。本文是集成约定，不承诺稳定的第三方 Harness SDK。