03 / 能力 HARNESS
让通用 AI 理解业务、调用获批工具，并在明确边界内工作。
Prompt 只能表达一次请求。一个可运行的业务 AI 能力还需要业务上下文、任务方法、获批工具、必要的协调与编排、评测、治理，以及进入日常工作的使用路径。
拆解七项 Harness 责任 ↓缺失的能力层
业务 AI 能力是一套责任系统，而不是一条 Prompt。
Harness 将五个工作层与两个横向保障层分开。每项责任都必须被考虑，但实施深度取决于真实任务、风险、平台和获批范围。
逻辑剖面 · 不是流程、成熟度模型、固定产品栈，也不要求新建七套系统。
L1工作层业务上下文
- 责任说明
- 企业术语、规则、政策、案例、知识和适用边界。
- 设计问题
- 哪些业务知识在范围内，拥有来源、足够新鲜且允许使用？
- 代表性设计资产
- 术语表
- 政策边界
- 案例
- 业务本体
- 知识边界
L2工作层任务方法
- 责任说明
- 角色、SOP、判断原则、Skill、Prompt 和完成标准。
- 设计问题
- 哪套方法、判断原则和完成标准用于指导任务？
- 代表性设计资产
- SOP
- Skill 候选
- 系统 / 项目指令
- Prompt 模板
- 完成标准
L3工作层工具连接
- 责任说明
- 经过批准的文件、CLI、API、MCP、数据库和业务系统。
- 设计问题
- 哪些读取与写入动作获得了明确授权？
- 代表性设计资产
- 获批文件
- CLI
- API
- MCP
- 连接器
- 数据库适配层
L4工作层工作编排
- 责任说明
- 在任务确有需要时，定义步骤、状态、触发、人工批准、重试、异常和恢复。
- 设计问题
- 工作是否需要持续状态、多角色、审批、恢复或监控？
- 代表性设计资产
- 获得授权时的 Workflow 规格
- 状态模型
- 审批点
- 重试与恢复规则
L5横向保障评测
- 责任说明
- 黄金样本、评测标准、回归检查和验收阈值。
- 设计问题
- 哪些代表性案例、评测维度、阈值和验收权限决定是否发布？
- 代表性设计资产
- 黄金样本
- 评测表
- 回归套件
- 发布阈值
- 验收负责人
L6横向保障治理
- 责任说明
- 权限、日志、数据边界、版本、升级、回退和责任。
- 设计问题
- 谁可以访问、批准、审计、停止、恢复并拥有这个能力？
- 代表性设计资产
- 权限矩阵
- 日志
- 升级机制
- 数据边界
- 回退方案
- 版本管理
L7工作层使用体验
- 责任说明
- 用户入口、交互方式、反馈、指导、培训和支持。
- 设计问题
- 用户如何进入、理解、纠正并获得能力使用支持？
- 代表性设计资产
- 使用入口
- 交互模式
- 反馈路径
- 用户指南
- 培训
- 支持
可见语义等价文本
- L1
工作层
业务上下文- 责任说明
- 企业术语、规则、政策、案例、知识和适用边界。
- 设计问题
- 哪些业务知识在范围内，拥有来源、足够新鲜且允许使用？
- 代表性设计资产
- 术语表 · 政策边界 · 案例 · 业务本体 · 知识边界
- L2
工作层
任务方法- 责任说明
- 角色、SOP、判断原则、Skill、Prompt 和完成标准。
- 设计问题
- 哪套方法、判断原则和完成标准用于指导任务？
- 代表性设计资产
- SOP · Skill 候选 · 系统 / 项目指令 · Prompt 模板 · 完成标准
- L3
工作层
工具连接- 责任说明
- 经过批准的文件、CLI、API、MCP、数据库和业务系统。
- 设计问题
- 哪些读取与写入动作获得了明确授权？
- 代表性设计资产
- 获批文件 · CLI · API · MCP · 连接器 · 数据库适配层
- L4
工作层
工作编排- 责任说明
- 在任务确有需要时，定义步骤、状态、触发、人工批准、重试、异常和恢复。
- 设计问题
- 工作是否需要持续状态、多角色、审批、恢复或监控？
- 代表性设计资产
- 获得授权时的 Workflow 规格 · 状态模型 · 审批点 · 重试与恢复规则
- L5
横向保障
评测- 责任说明
- 黄金样本、评测标准、回归检查和验收阈值。
- 设计问题
- 哪些代表性案例、评测维度、阈值和验收权限决定是否发布？
- 代表性设计资产
- 黄金样本 · 评测表 · 回归套件 · 发布阈值 · 验收负责人
- L6
横向保障
治理- 责任说明
- 权限、日志、数据边界、版本、升级、回退和责任。
- 设计问题
- 谁可以访问、批准、审计、停止、恢复并拥有这个能力？
- 代表性设计资产
- 权限矩阵 · 日志 · 升级机制 · 数据边界 · 回退方案 · 版本管理
- L7
工作层
使用体验- 责任说明
- 用户入口、交互方式、反馈、指导、培训和支持。
- 设计问题
- 用户如何进入、理解、纠正并获得能力使用支持？
- 代表性设计资产
- 使用入口 · 交互模式 · 反馈路径 · 用户指南 · 培训 · 支持
逻辑关系
- 业务上下文为任务方法与评测提供依据。
- 任务方法指导获批工具与任何必要的工作编排。
- 工具只有在获得授权时才支持有边界的读写动作。
- 只有任务触发需要时，工作编排才协调步骤。
- 评测跨越整个能力检验行为。
- 治理跨越整个能力约束权限。
- 使用体验把用户、反馈和支持连接到能力。
按需设计
七项责任不等于七套新系统。
每项责任都必须有答案，但答案可以是现有平台能力、一项配置、一条短政策、一组测试、一个人工检查点，或一项明确排除。FDE Delta 只设计让所选业务能力可使用、可评测、受控制所必需的深度。
- 01复用
使用客户获批环境中已经存在的能力。
- 02配置
在定制开发之前，优先使用平台原生配置。
- 03构建
只创建由业务任务和证据证明必要的最小缺失组件。
- 04集成
只有价值、权限、失败和所有权条件明确时才连接系统。
- 05排除
明确写出不支持的动作、数据、用户或环境，而不是隐藏缺口。
每项责任都要考虑，只实施获批能力真正需要的部分。
可移植核心 · 明确适配
先定义业务能力，再适配客户获批的 AI 环境。
Skill、Workflow、Prompt、MCP Server、连接器、CLI、自动化或平台配置是实现形式，不是业务能力本身。将长期有效的能力规格与平台适配层分离，可以减少不必要的锁定，并让能力所有权更清楚。
业务 AI 能力规格
业务上下文包
质量与治理包
- Codex
- Claude Code
- WorkBuddy
- 私有化或其他获批环境
厂商中立不等于无需适配，也不保证同一资产可以零成本、不经修改或以相同行为跨平台运行。
WORKFLOW 必要性 GATE
不是每个能力都需要 Workflow。
简单任务不应该为了技术展示而被强行设计成复杂 Agent 系统。当能力涉及以下任一触发条件时，必须先决定角色、状态、权限、审批、恢复和运营责任，再讨论实施建议。
- 01多角色
- 02持久状态
- 03重复或定时运行
- 04外部系统或数据连接
- 05重要权限
- 06审批步骤
- 07重试、恢复或监控
否
直接任务、指令、Skill 或简单配置可能已经足够
是
WORKFLOW_DECISION_REQUIRED先定义角色、状态、权限、审批、恢复、监控和所有权
“可能已经足够”只是设计选项，不构成实施或创建 Skill 的授权。
主张与设计状态
图中说明的是设计责任，不是 Harness 已经被构建、集成、验收或运营的证据。
- 事实 / FACT
- 对 FDE Delta 通用方法或当前页面模型的已接受描述。
- 假设 / HYPOTHESIS
- 在验证之前，客户特定的层级深度、平台适配、价值、可移植性和运营设计。
- 未知 / UNKNOWN
- 在确认之前，数据、访问、权限、权责、用户、验收和支持条件仍然未知。
- 建议 / RECOMMENDATION
- 有边界的下一项设计决策，不是部署结果、批准或承诺。
输出
- 01业务 AI 能力规格
- 02能力 Harness 架构
- 03目标平台映射
- 04业务上下文包设计
- 05评测与验收计划
- 06权限与人工控制设计
- 07失败、回退与恢复设计
- 08可移植性与所有权设计
每项输出都是设计或决策产物，并不证明实现、集成、Skill、Workflow、评测或客户能力已经存在。
GATE 03 / 是否定义能力交付包？
- 已接受的业务能力规格
- 最小必要 Harness 决策
- 获批平台和数据边界
- 人工控制与验收权限
- 评测与失败路径
- 触发时已完成 Workflow 决策
只有当长期有效的业务能力、最小平台实现、评测、权限、失败路径、所有权和排除项都足够明确时，Harness 才可以进入能力交付包定义。
通过这个 Gate 不构成构建、集成、生产发布、客户访问、创建 Skill 或激活 Workflow 的授权。
开启对话
构建值得验证的事物。
关于 AI 原生产品、全球 GTM 或独立项目，可以通过以下方式联系我。