6.11 业务能力与执行引擎边界
Teloa 在执行引擎之上组织业务。集成时先确定对象属于哪一层，再确定由谁保存状态、检查权限和报告结果。概念总览见三层产品架构。
1. 产品三层与工程职责
AI-Native Team Studio = AI Team + Agent Studio + Agent Harness。这是产品架构，不是三套服务或三个代码包。
| 产品层 | 维护什么 | 集成约束 |
|---|---|---|
| AI Team | 员工、业务、项目、群、任务、自动化、审批与成果 | 保留长期身份、业务归属、历史和交付判据 |
| Agent Studio | 岗位、知识、技能、工具 / MCP 与权限配置 | 说明资源来源、适用范围和所需授权；配置不自动提权 |
| Agent Harness | 模型、运行时、工具网关、沙箱、审批与可观测性 | 通过正式接口运行，核验权限，返回真实执行状态 |
Team 是产品，Agent 是工作单元，Harness 是运行底座。业务、能力与执行仍可用于描述工程职责，但不构成另一套产品三层。系统及代码包架构单独见源码架构。扩展包是分发单位，可提供技能、连接和运行组件，不是第四层。
2. DSH 对象如何映射
当前适配以 DSH 为基础。下表约定产品概念与原生对象的边界；具体原生面板的可用版本见原生运行能力。
| 原生概念 | Teloa 如何使用 | 不能直接等同于 |
|---|---|---|
| Plugin | 注册工具、服务、界面或配置等运行能力 | 一项业务技能或一个岗位 |
| Bundle | 组合插件与配置，记录分发来源 | Teloa 的 AI 团队模板 |
| Agent preset | 选择模型与运行配置 | AI 员工的长期身份和授权 |
| Agent Team / teammate | 执行小组与临时执行助手 | 工作群与长期 AI 员工 |
| Session / job | 会话与运行事实 | 业务任务的完成判定 |
| Workspace / directory | 执行位置及文件边界 | Teloa 的业务项目 |
AI 员工可以选择运行配置，但职责、记忆和业务授权仍归员工所有。执行助手的名称不能成为身份凭据，也不能借用同名员工的权限。普通会话可以组织执行小组；它不会因此自动成为有负责人和验收判据的业务任务。
3. 分发、配置、运行与授权分别记录
不要用一个“已启用”字段覆盖以下事实，也不要把它们强行排成每项能力都必须经过的流程：
| 事实 | 要能回答的问题 |
|---|---|
| 来源与安装 | 哪个发布者、哪个包和版本提供了它？安装是否完成？ |
| 保存的配置 | 全局或哪个运行配置启用了它？是否等待重启？ |
| 实际运行 | 当前宿主是否加载成功？有无错误？ |
| 连接与凭据 | 外部服务是否连通，使用哪个已授权账号？ |
| 业务授权 | 哪位员工在什么业务或任务中可以使用哪些操作？ |
不适用的维度应明确省略。官方与第三方描述发布者，内置与自行安装描述交付方式；这些属性都不能单独决定组件是否可停用。
来自同一个扩展包的技能和连接，应保留包的来源关系。能力页可以投影这些资源，但不能把包内资源当成独立安装再重复卸载。引擎插件清单用于诊断全局和运行配置中的组件，不应把每个底层组件都包装成用户需要管理的业务能力。
Teloa 的待安装记录、包内容哈希、请求标识和安装回执用于审批与中断恢复。复用原生安装器时仍需保留这些业务记录；原生安装成功不能自动替代业务确认或授权。
4. 优先复用官方能力
引擎已经提供的执行、取消、会话读取和插件管理，优先调用正式服务。薄适配负责把它们映射到 Teloa 的任务、负责人、审批与成果，不复制一套引擎状态机。
受管任务以 Task/Run 保存业务归属，以引擎返回的会话、成员和后台工作标识关联执行事实。停止请求发出后，应等实际工作结束再报告已停止；断线或等待取消期间不能伪装成完成。执行成功也不等于业务成果通过验收。
界面职责保持一致：市场负责发现，能力页负责管理可用资源，设置负责运行参数，系统组件清单负责诊断。入口整合方向不代表所有页面已经改造，当前操作以能力与连接指南为准。
Workflow、PTC 与 Ralph 的适配
社区版 0.2.10 固定使用 DSH 0.2.1-rc.2。运行预设决定可用执行方式，岗位授权决定员工能否使用；两者不能互相替代。
- Workflow / Ralph：复用官方
workflowEngine、spawn与迭代实现。在受管任务中，teloa-workflow-spawn先预留子运行额度，再委托官方 provider；绑定完成前，子级首个工具调用等待身份核对，子级和后台 job 关联原 Task/Run。普通会话直接委托官方 provider，不创建业务 Run 或写岗位额度。 - PTC：复用官方 Node PTC 运行器与工具 SDK。程序整体经原生审批，SDK 内每次调用仍经过工具名称、参数与当前岗位授权校验。批准代码不等于授予其任意工具权限。
- 逐次确认：
tools/pre-execute保留官方拒绝并要求确认，tools/execute在确认后重新核对工具定义、归属、停止状态及授权，防止等待期间状态变化。使用不会询问人的权限模式时，明确拒绝并提示切换。 - 结构化交接：只为已绑定子级及其声明的输出 schema 放行原生
structured_output；不能仅凭工具名豁免其他调用。Ralph 仅在本人明确要求时使用；每轮使用新助手，继承实际父预设，不继承父会话或上一轮的对话历史，也不受个人后来修改默认模式的影响。 - 生命周期：受管子工作与执行小组共用数据库额度；当前组合的 Ralph 最多 6 轮。Workflow、PTC 与 Ralph 在审批后开始执行计时，达到 10 分钟时请求取消；原生运行器的更短超时仍生效，退出收尾可能超过该时间。父会话结束时仍核对后台 job，停止时请求取消关联子级与后台工作，并等待实际退出；不提供重启后自动续跑。
脚本中的直接 Node 文件或网络访问由原生进程和沙箱边界约束，不经过工具 SDK 的岗位白名单；网页工具的域名限制也不是整台运行主机的网络防火墙。部署要求强隔离时，应额外配置运行环境和网络隔离，不能把逐工具授权描述成任意代码的完整隔离。
官方 standard 预设只覆写 Workflow 的 spawn provider；其余声明由固定版本确定性生成并校验摘要。PTC、minimal、cordis 保持官方定义。创造模式包含扩展开发能力，仅供本人使用；历史受管配置若指向创造模式，同样拒绝执行。这里没有新增用户可编辑的 Workflow 图形设计器，Workflow 仍是官方脚本编排工具。
5. 说明具体接入方式
评估其他产品时，应写明是导入技能、连接 MCP、适配分发包格式，还是使用官方执行接口。某种资源能导入，不代表该产品已成为 Teloa 可切换的执行引擎。
各生态对包的定义不同，可参考 Codex Plugins、Claude Code Plugins、Cursor Plugins、OpenCode Plugins 和 Kiro Powers。这些是概念参考，不是 Teloa 的兼容性清单；OpenCode 等产品的不同主版本也需单独验证。
6. 集成验收
- 写明引擎版本、支持的接入方式和未支持的能力。
- 明确业务身份、能力来源、运行配置和原生执行标识的映射。
- 分别验证安装、配置生效、连接失败和授权拒绝；错误应能回到用户可操作的入口。
- 验证主任务与子工作停止、断线重连和宿主重启，不丢失归属或虚报完成。
- 用隔离数据库与真实宿主验证一条完整任务链路，再核对中英文界面的状态和提示。