第 35 章详细 Outline：企业级 Harness 架构

写作契约

本章要完成的学习目标

读者完成本章后应能：

1. 区分企业控制平面（Enterprise Control Plane）与执行平面（Execution Plane），说明策略允许、执行返回和业务效果为何是三种不同结论。
2. 为多业务单元的 Agent 请求写出租户、主体、目标资源、请求能力、预算、到期时间与人工升级条件，而不把网络位置或单一角色字段当作充分授权。
3. 用策略决定记录（Policy Decision Record）表达允许、拒绝或待批准的理由、限制和关联，而不把策略求值结果写成合规或审计结论。
4. 为跨控制与执行边界的工作设计关联观察记录（Correlated Observation Record），并说明关联标识能连接观察、不能证明记录完整或不可抵赖。
5. 为虚构知识助手从只读到有限工单更新的范围扩大定义分阶段门、预算边界和人工升级门（Human Escalation Gate）。

读者、前置与明确边界

• 读者： 已理解 Harness 的任务、工具、权限、审批和观察边界，且需要把一个团队内的受控流程扩展为组织级责任分工的工程读者。
• 前置： 第 12 章的环境与最小权限、第 14 章的人类参与、第 15 章的 Observation Record、第 26 章的多 Agent 协作、第 27 章的变更审查，以及第 28 至 34 章的最小 Harness、交付、测试、失败调查、项目记忆与团队 Skill 库。
• 本章负责： 用虚构企业内部知识助手说明企业控制平面、执行平面、租户与数据边界、策略决定、关联观察、预算和人工升级如何共同限制一次计划性工作。
• 本章不负责： 真实企业目录、身份提供方、Kubernetes 集群、OPA／Rego、OpenTelemetry Collector、云账户、队列、工单系统、知识库、日志平台、成本计费、审计保留、法规解释、合规认证、账户、凭证、网络、外部 API、真实审批或外部执行。

来源与本书模型的分层

使用位置	可归因材料	本章允许的有限陈述	本书原创内容
第 1、2 节	CH35-REF-01 / REF-110	NIST SP 800-207 在其零信任架构语境中，说明不应依据网络位置或资产所有权给予隐式信任，并将主体／设备的认证与授权放在资源会话前的离散功能中。	企业控制平面字段、能力准入、到期与升级条件。
第 2、5 节	CH35-REF-02 / REF-111	Kubernetes 共享集群多租户资料讨论安全、公平性与资源竞争挑战，且租户定义依使用场景而变。	租户与数据边界、共享例外、预算字段和本书隔离检查表。
第 3、4 节	CH35-REF-03 / REF-112	OPA 的哲学资料说明策略可与受其约束的服务解耦，服务可查询策略与数据以得到求值结果。	策略决定记录、允许／拒绝／待批准分支与执行器最小输入。
第 6 节	CH35-REF-04 / REF-113	OpenTelemetry trace 由关联的 span 表示，span context 含 trace ID 与 span ID，上下文传播可把不同位置产生的 span 关联为 trace。	关联观察记录、决定与执行的链接方式、观察限制和审查表。

正文必须使用“来源指出”“NIST／Kubernetes／OPA／OpenTelemetry 文档在其语境中说明”“本书工程模型”或“虚构教学案例”标记层次。不得把上述来源写成特定控制面字段、真实隔离、自动授权、完整审计、数据保留、合规状态或任何企业系统已运行的证据。

章节叙事与逐节蓝图

1. 企业规模改变的不是队列长度，而是责任边界

• 要回答的问题： 为什么一个单团队可用的 Agent 流程，在多个业务单元、数据类别和审批责任出现后，不能只靠“内网账号”或“已经登录”继续运行？
• 场景输入： 虚构企业内部知识助手收到一项“汇总某业务单元已批准知识摘要并提交人工”的请求；请求有主体声明、租户候选、目标数据类别和期限，但没有真实身份、数据、系统或连接。
• 来源事实： REF-110 在零信任架构语境中不以网络位置或资产所有权给予隐式信任，并把认证／授权置于资源会话前的离散功能。
• 本书企业问题框架： 请求是否来自某个组织网络，不足以回答“谁以何种能力、对什么范围、在何时、以何种证据执行”；这些问题必须先形成计划性输入。
• 最小证据： 对照表区分 request_received、policy_allowed、execution_observed 与 business_effect_verified；后三者不得因前一项存在而自动成立。
• 失败分支： 主体、租户、目标、能力、期限或风险标签缺失时，不补猜字段，不进入策略判断，返回 insufficient_context 或 requires_approval。
• 预期验证： 读者能指出“有企业账号”只能是待核验输入，不能替代资源级范围、策略决定或结果观察。
• 过渡： 明确问题后，下一节先拆开负责准入与负责执行的两个平面，避免一个组件同时声明、批准、执行和证明自己正确。

2. 企业控制平面与执行平面：先分责，再连接

• 要回答的问题： 为什么企业 Harness 需要把决定“能否做什么”的控制职责，与承接“被允许工作”的执行职责分开？
• 来源事实： REF-110 支持资源会话前需要分开处理认证与授权的零信任背景。REF-111 支持多租户语义与安全、公平性、资源竞争目标必须依具体共享语境界定。
• 本书企业控制平面： 汇总租户定义、主体声明、任务分类、目标资源、请求能力、资源预算、到期时间和升级要求；它生成或限制计划，不能执行业务动作。
• 本书执行平面： 只接收任务引用、允许能力、资源上限、停止条件和观察要求；它不能因收到任务而扩展身份、数据或权限。
• 最小证据： 架构表为每个字段标出所有者、输入来源、可审查输出和“不得推导”的结论，例如预算上限不等于实际成本已被计量。
• 失败分支： 控制平面没有可审查输入、执行平面收到未绑定能力的任务，或任何平面试图自行提高权限时，保守停止并写入升级理由。
• 预期验证： 读者能将“控制平面允许”与“执行平面已完成”分为两个需要独立证据的状态。
• 过渡： 两个平面分开后，下一节为每次决定保留可解释的策略输入与输出，而不是把“准入”藏在执行器内部。

3. 策略决定记录：求值结果不是授权神谕

• 要回答的问题： 如何让允许、拒绝和待批准都可复查，而不把某个策略产品或一段规则文本写成自动正确的治理机制？
• 来源事实： REF-112 说明策略可以与受约束服务解耦，服务可查询策略和数据求值；该资料不承诺规则正确、数据新鲜、自动授权或具体部署方式。
• 本书策略决定记录： 每次决定至少包含输入摘要、规则版本引用、决定状态、限制、关联标识、到期、待补证项和升级原因；字段仅是本书模型，不是 OPA、Rego 或任意策略 API。
• 决策分支： allowed 仅把明确限制传给执行平面；denied 保留拒绝理由并停止；pending_approval 形成待审信息，不能悄悄降级为允许。
• 最小证据： 一张虚构记录展示“只读知识摘要”“禁止跨租户输出”“预算上限”“24 小时后失效”和“人工批准引用待补”如何被分别表示。
• 失败分支： 输入版本不明、规则与请求范围冲突、策略数据过期、决定缺限制或需要外部身份验证时，记录未知项并升级，不产生模拟的批准令牌。
• 预期验证： 读者能审查一次策略决定的理由和限制，同时说明该记录既不证明规则正确，也不证明外部效果发生。
• 过渡： 策略记录回答“在何种限度内可以继续”，下一节说明租户、数据和能力为何还需要独立边界。

4. 租户、数据与能力：隔离目标必须先被说清

• 要回答的问题： 为什么 tenant 字段、角色、命名空间或单次配额都不足以单独表达组织级隔离？
• 来源事实： REF-111 在共享集群语境中指出多租户会面对安全、公平性与 noisy-neighbor 挑战，且租户定义取决于使用场景；文档提及的 RBAC、配额和网络策略不能外推为任意 Harness 的充分隔离。
• 本书租户与数据边界（Tenant and Data Boundary）： 显式定义谁被视为同一租户、哪些数据类别可见、哪些能力可申请、共享例外由谁批准，以及跨边界何时必须升级。
• 最小能力： 将“读取已批准摘要”“生成工单草稿”“提交有限可回滚状态更新”列为不同能力；每项要绑定目标、期限、预算、停止条件和观察要求。
• 最小证据： 矩阵以租户定义、数据类别、能力、目标范围、共享例外和升级条件为列，不出现真实客户、员工、项目、角色、数据标签或凭证。
• 失败分支： 租户语义未定义、数据分类冲突、能力超出已批准范围或共享例外没有责任人时，不把任务拆小来规避边界，直接路由至人工升级门。
• 预期验证： 读者能说明“隔离”是多个明确边界的组合目标，不把任何产品机制、逻辑字段或规则评估等同充分隔离。
• 过渡： 范围清楚后，控制面还要把资源消耗和时效纳入同一决策，避免低权限任务无限扩张。

5. 预算、到期与停止条件：成本也是受限资源

• 要回答的问题： 在不引入价格、计费或采购结论时，如何让资源消耗成为可审查的约束？
• 来源事实： REF-111 的共享集群资料为资源公平性和竞争风险提供受限背景；它不提供本章的预算字段、阈值、单位或成本控制算法。
• 本书资源预算： 对每次计划声明可使用资源类别、上限、到期、观察频率和达到上限后的停止／升级路径；预算是计划性限制，不是已记录费用或节省证据。
• 本书停止条件： 时间到期、能力不再匹配、观察无法关联、预算将耗尽、数据边界不清或需要不可逆动作时，执行平面必须停止并返回可审查原因。
• 最小证据： 虚构计划中仅使用 budgetLimit、expiresAt、stopCondition 和 observationRequired 等教学字段，且明确没有真实货币、token、账单、配额或用量读取。
• 失败分支： 缺少单位、上限来源、到期计算依据或消耗观察时，不制造数值或把未观测的消耗写成“在预算内”。
• 预期验证： 读者能为低风险只读试点和高风险状态更新写出不同的预算与停止条件，并保留超限后的人工决定。
• 过渡： 即使计划与资源限制充分，仍需把控制决定、执行尝试和结果观察连接起来；下一节只讨论可关联性，不把它夸大为审计。

6. 关联观察记录：连接事件，不替代审计

• 要回答的问题： 分布在控制、执行和人工审批边界上的观察，如何被限定地关联回同一次工作？
• 来源事实： REF-113 说明 trace 由关联的 span 组成，span context 含 trace ID 和 span ID，上下文传播能关联不同位置的 span；该语境不等于日志完备、审计充分或不可抵赖。
• 本书关联观察记录： 关联决定 ID、任务 ID、关联标识、时间窗、观察摘要、来源、状态、新鲜度和限制；它连接“发生过何种可见观察”，不替代事实核验或业务验收。
• 读法： 策略决定记录表明计划性限制；执行观察说明受限工作返回的材料；人工批准记录说明责任人做出的决定；三者须经关联才能讨论同一任务，但仍需保留各自的不确定性。
• 最小证据： 一组虚构记录用同一关联标识串起 pending_approval、allowed_with_limits、execution_stopped 和 human_review_requested，不生成 trace、span、日志、Collector 配置或遥测导出。
• 失败分支： 关联缺失、时间窗重叠、来源不明或观察过期时，状态为 unlinked／insufficient_evidence，不得把相似文本拼成完整故事。
• 预期验证： 读者能说明关联标识帮助找回同一次工作的上下文，却不能证明所有动作、数据或审计义务都已覆盖。
• 过渡： 当关联材料不足、范围提高或结果可能跨越组织边界时，自动系统不能自行扩权，下一节定义人工升级门。

7. 人工升级门与分阶段上线：扩大能力必须重新取证

• 要回答的问题： 如何把从只读试点到有限、可回滚动作的能力扩大，变成一系列可拒绝、可过期的决策？
• 本书人工升级门： 输入为触发条件、已有证据、未知项、请求范围、可批准上限、拒绝／过期处理和责任人；门的输出只能是明确的批准范围、拒绝或待补证，不验证业务结果。
• 教学案例阶段：

阶段	可申请能力	必须的新证据或约束	保守出口
1：只读试点	读取已批准的知识摘要并提交人工。	明确租户、数据类别、只读目标、到期和观察要求。	范围不清、摘要未批准或关联不足时停止。
2：候选生成	生成工单草稿，仍由人工提交。	草稿与最终提交分离、目标范围、审阅责任和预算。	不把草稿当作工单已创建。
3：有限更新	请求可回滚的工单状态更新。	显式批准、最小能力、回滚假设、结果观察和超限升级。	不可逆、跨租户、缺观察或超预算时拒绝自动执行。

• 来源边界： 此阶段表是本书模型；REF-110 至 REF-113 均不证明某个上线流程、审批阈值、回滚方案、法规状态或外部系统已经存在。
• 最小证据： 每个阶段都以新的 Policy Decision Record 和关联观察要求重新审查，不复用旧批准来覆盖更高风险能力。
• 失败分支： 人工拒绝、批准到期、补证失败、任务范围改变或新能力不可回滚时，保持原阶段或停止，不以“效率”跳过控制。
• 预期验证： 读者能指出“上一阶段稳定”不自动授权下一阶段，并能写出每一步的新边界。
• 过渡： 下两节把上述分责转化为之后可测试的纯内存计划与图示；它们仍不是任何生产部署。

8. 最小示例：纯内存企业架构计划评估器

• 要回答的问题： 如何检查企业 Harness 计划的必要边界，而不连接企业系统或假装做出真实策略决定？
• 示例边界： 后续 assessEnterpriseHarnessPlan(plan) 只评估注入的教学对象；不得调用身份服务、策略引擎、Kubernetes、OpenTelemetry、队列、工单系统、云资源、文件、网络、账户、凭证、外部 API 或真实审批。
• 计划输入： tenantDefinition、subjectClaim、requestedCapability、targetBoundary、policyDecisionRecord、budgetLimit、expiresAt、stopCondition、observationRequirement 与 escalationGate。
• 计划返回： 边界齐备时只返回 ready 和“在隔离示例中实现”；租户／目标不清、能力超范围、决定缺限制、预算或到期缺失、观察无法关联、升级条件不足或要求执行外部动作时返回 stopped／requires_approval。
• 计划测试： 完整只读计划、缺租户定义、主体未声明、策略决定缺版本或限制、草稿被误当执行、预算缺失、到期失效、跨边界请求、无观察关联和外部执行请求。
• 预期验证： Example Implementation 阶段先记录模块不存在的红灯，再用实际 Node 测试与演示验证纯函数；本 Outline 不把计划、命令、测试或结果写成已执行事实。
• 过渡： 纯内存示例检查字段完整性，图示则要让读者看见哪些状态可流动、哪些状态必须中断。

9. 图示、完整教学案例与逐步增强

• 要回答的问题： 怎样让一个架构图既说明控制流，又不把关联或批准误画成真实效果与合规证明？
• 图示内容： Request Intake → Enterprise Control Plane → Policy Decision Record 后分为 allowed_with_limits → Execution Plane、denied → Conservative Stop 与 pending_approval → Human Escalation Gate；关联观察记录连接决定、执行尝试和人工结果。图中必须显式保留“策略允许 ≠ 外部效果”和“关联 trace ≠ 审计充分性”两个断点。
• 关键箭头解释： 执行平面只能接收限制后的能力与停止条件；观察记录回到控制面用于后续判断，不倒流为权限；任何跨租户、超预算或证据不足请求都离开自动路径。
• 完整教学案例： 虚构知识助手在同一租户内先读取批准摘要、再生成工单草稿、最后申请有限状态更新。案例分别展示控制平面输入、策略决定、执行范围、观察关联、未覆盖项和人工责任，不展示企业名称、用户、工单、云资源、日志、追踪、成本或合规报告。
• 渐进表：

新需求	必须新增的控制	升级触发	本章为何不实现
连接真实身份来源	身份协议、凭证存储、验证、撤销、审计和安全审查。	要将主体声明用于真实资源会话。	本章不连接身份提供方。
在共享集群执行工作	具体隔离设计、资源配置、网络与运行时安全验证。	要主张实际隔离或公平性。	本章不部署 Kubernetes 或工作负载。
让策略影响真实工具	规则测试、策略数据新鲜度、变更审批、失败恢复和权限验证。	要把决定用于外部动作。	本章不部署策略引擎或调用工具。
输出可审计或合规结论	适用制度、保留与完整性要求、独立审查和真实证据。	要主张审计／法规满足。	关联观察记录不是审计系统。

• 预期验证： Diagram Review 阶段导出并核对 Mermaid 源码；无图可以从 allowed 直接指向“已完成”，无图可以从 trace 直接指向“合规”。
• 过渡： 图与案例说明结构，最后一节把读者应保留的治理问题、常见误判和后续章节关系收束为可检查清单。

10. 治理清单、常见误判与后续连接

• 要回答的问题： 一份企业 Harness 设计在进入实现前，至少应问清哪些问题，哪些回答仍必须留给安全、法务、平台或业务责任人？
• 本书治理清单：
  1. 谁定义租户、数据类别、共享例外和责任边界？
  2. 主体、目标、能力、预算和到期从何而来，何时需要重新验证？
  3. 策略决定记录缺什么信息时必须拒绝或升级？
  4. 执行平面如何避免从任务文本、观察或工具返回中自行扩大能力？
  5. 关联观察能支持什么，哪些审计、保留、完整性和业务效果仍未证明？
  6. 每次阶段扩大需要哪些新的证据、批准、停止条件和回滚假设？
• 常见误判：

误判	表现	根因	修复方向
将网络位置写成充分信任	“在企业网络内”就跳过目标与能力检查。	把来源背景误当实现结论。	为每次资源会话保留范围、限制和可审查决定。
将策略允许写成业务完成	allowed 后直接报告工单已更新。	混淆计划性决定、执行尝试和观察。	分开记录决定、执行观察与业务验收。
将 trace 写成审计	有关联 ID 就声称完整记录和合规。	混淆关联能力与记录完整性。	明确来源、时间窗、缺口和独立审计要求。
将低风险试点批准复用到高风险动作	只读允许被当成写入许可。	忽略能力、数据和不可逆性变化。	每次扩大范围重新进入策略与人工升级门。

• 章节总结： 企业级 Harness 的可扩展性来自责任面可分、限制可表达、决定可关联和风险可升级，而不是把集群、策略或追踪工具拼成一个“自动合规”的黑盒。控制平面限制计划，执行平面限制动作，观察记录限制结论，人工升级门限制自动扩权。
• 练习： 要求读者为一个虚构跨部门知识助手写出租户与数据边界、只读阶段的 Policy Decision Record、两条必须进入 Human Escalation Gate 的条件，并解释为什么关联标识不能替代审计。
• 后续连接： 第 36 章从案例归纳控制流设计模式；第 37、38 章分别处理记忆／Skill 与反思／评估／审批模式；第 39 至 42 章再讨论测试、成本、安全和版本治理。它们都不得倒过来把抽象模式或指标写成第 35 章的真实企业部署结论。

后续工件与验收边界

阶段	计划交付物	本阶段不得声称
First Draft	原创正文、术语首现、虚构案例和受限来源陈述。	企业目录、集群、策略、遥测、工单、成本或合规已运行。
Technical Review	对 REF-110 至 REF-113 的当日重读、来源／模型分层和术语检查。	四项资料支持具体配置、默认值、审计或法规结论。
Example Implementation	纯内存 assessEnterpriseHarnessPlan、最小测试和无副作用演示。	身份、策略、队列、云或外部执行已经调用。
Diagram Review	可 diff 的 Mermaid 源、导出图、正文图块一致性与可读性检查。	图代表真实架构已部署或通过安全审查。
Fact Check 与 Language Editing	事实映射、时态、主体、术语、范围与交叉章节检查。	未重读的一手资料或未运行外部系统已被核验。

本 Outline 只提供第 35 章的写作蓝图，不构成系统设计批准、部署计划、合规意见或任何外部操作授权。