第 35 章 Research Brief：企业级 Harness 架构

要解决的工程问题

当一个 Agent 从单个团队的受控试验走向多个业务单元时，风险不再只来自某一次工具调用。身份从哪里来、策略由谁维护、不同租户如何隔离、一次任务消耗了什么资源、发生争议后怎样还原决策，都会跨越同一个执行循环。本章研究一个可审查的企业级 Harness 架构：它把准入、策略判断、执行边界、观察和人工升级放在可区分的责任面上，而不把任何单一产品、集群或审计系统误写成通用答案。

读者问题与范围

读者问题	本章研究的回答	本章不回答
多个团队共享 Harness 时，控制应放在哪里？	将租户上下文、身份声明、任务分类、策略决定、预算限制和审批要求汇入控制平面，再把被允许的工作交给执行平面。	某个 Kubernetes 集群、云账户或企业目录已经配置完成。
如何让“允许执行”可追溯？	为每次计划性决策保留输入摘要、规则版本、决定、限制、关联标识和升级原因；执行观察与策略决定分开记录。	这些记录已满足特定法律、审计、保留期限或取证要求。
隔离、成本与合规为何不能只由一个开关处理？	用租户边界、最小能力、资源预算、数据处理分类和人工升级组成多道约束，并分别说明责任。	任何容器、命名空间、配额或策略引擎天然提供充分隔离或合规。
怎样逐步扩大可操作范围？	从只读知识检索开始，先允许生成候选，再把有限、可回滚的工单动作置于显式批准与证据门之后。	虚构案例中的工单、身份、队列、日志或成本数据已经真实运行。

已核验的一手资料

本地键	来源明确表达的内容	允许用途	不可外推
CH35-REF-01	NIST SP 800-207 将零信任描述为从静态网络边界转向保护用户、资产与资源的安全范式；不因网络位置或资产所有权授予隐式信任，并把主体与设备的认证、授权视为建立资源会话前的离散功能。	解释企业 Harness 不应以“在内网”或“是公司账户”替代资源级判断。	固定控制平面字段、每次动作的具体认证流程、任何合规结论或本章系统已达零信任。
CH35-REF-02	Kubernetes 的多租户文档指出共享集群可能节省成本和简化管理，但同时有安全、公平性和 noisy-neighbor 挑战；租户定义依使用场景而变，RBAC、配额与网络策略出现在其共享集群语境。	说明多租户必须先明确租户语义、隔离目标与资源竞争，而不是把“tenant”当作单一技术字段。	Kubernetes 是 Harness 的必选运行时，或 RBAC、配额、网络策略对任意系统构成充分隔离。
CH35-REF-03	OPA 的哲学文档把策略描述为约束服务行为的规则，并说明可将策略与受其约束的服务解耦；服务通过查询让 OPA 对策略和数据求值。	说明策略决定可以与执行器实现分离，并需要可辨认的输入和返回决定。	本章采用 OPA、Rego、sidecar、远程加载或任何特定部署方式；策略引擎自动正确、安全或合规。
CH35-REF-04	OpenTelemetry 的 trace 由具有关联关系的 span 表示，span context 包含 trace ID 与 span ID；上下文传播使不同位置生成的 span 能被关联并组装为 trace。	说明跨控制与执行边界需要关联标识，便于把一次工作拆开的观察重新连回。	追踪等于审计、日志已完整、记录不可抵赖，或任何数据已被采集和导出。

访问日期均为 2026-07-16。CH35-REF-01 至 CH35-REF-04 已分别登记为 REF-110、REF-111、REF-112、REF-113；正式 URL、受限陈述和不可外推范围见本章参考资料。这些文档的版本、默认行为和部署选择可能变化；First Draft、Technical Review 与 Fact Check 必须在写作当天重新读取对应资料。

本书研究框架

下列术语是本书为教学案例提出的架构模型，不是 NIST、Kubernetes、OPA 或 OpenTelemetry 定义的产品接口。正文首次使用时应按术语表核对中文与英文名称，并由主线程决定是否登记到全局术语表。

工件或边界	要解决的问题	最小内容	关键限制
企业控制平面（Enterprise Control Plane）	在执行前汇总准入、责任与资源限制。	租户、主体、任务分类、目标资源、请求能力、预算与到期时间。	是本书模型；不是网络边界，也不执行业务动作。
策略决定记录（Policy Decision Record）	让允许、拒绝、待批准的理由可审查。	规则版本、输入摘要、决定、限制、关联标识与升级原因。	记录不保证规则正确、覆盖完整或满足法定审计。
执行平面（Execution Plane）	将已获准的工作限制在可识别的执行边界内。	任务引用、允许能力、资源上限、停止条件与结果引用。	不因收到任务而获得额外身份、数据或权限。
租户与数据边界（Tenant and Data Boundary）	让团队、业务单元或外部客户的隔离目标显式化。	租户定义、可见数据类别、共享例外与跨边界升级条件。	不预设一个 tenant 字段即可满足所有组织或法律定义。
关联观察记录（Correlated Observation Record）	在控制决定、执行尝试、人工审批和结果之间保留关联。	决定 ID、任务 ID、追踪关联标识、时间窗、观察摘要与限制。	不是完整日志、账本、监控平台或取证系统。
人工升级门（Human Escalation Gate）	在高风险、跨租户、超预算或证据不足时停止自动扩大权限。	触发条件、待审信息、可批准范围、拒绝/过期结果。	审批本身不验证业务结果，也不替代责任分配。

本书模型的核心约束是：控制平面能提出或限制工作，但不能把“策略允许”写成“效果已发生”；执行平面能返回观察，但不能把“返回成功”写成“合规已证明”。成本在本章中也是资源预算与观测字段，不是价格、费率、节省比例或采购建议。

教学案例、图示与示例计划

教学案例是虚构的企业内部知识助手。第一阶段只读取已批准的内部知识摘要，并把答案提交给人工；第二阶段允许它生成工单草稿，仍由人工提交；第三阶段才讨论有限的、可回滚的工单状态更新。每一阶段都要求控制平面重新表达允许能力、租户边界、预算、到期时间和人工升级条件。案例不包含真实企业、身份提供方、工单系统、知识库、队列、日志、成本数据或合规结论。

后续图示应从“请求进入”开始，分出企业控制平面与执行平面：身份与租户上下文先进入策略决定记录；允许、拒绝和待批准分别流向受限执行、保守停止和人工升级；关联观察记录再连接计划性决定与执行结果。图中必须保留“策略决定”到“真实外部效果”之间的断点，也要保留“trace 关联”到“审计充分性”之间的断点。

后续最小示例应只评估注入的企业架构计划，例如以 assessEnterpriseHarnessPlan 检查租户定义、能力边界、策略记录、预算、升级条件和观察关联是否齐备。Example Implementation 阶段才决定是否建立纯内存模块与测试；本 Research Brief 没有调用身份服务、策略引擎、队列、工单系统、云资源、日志平台或外部网络，也没有执行任何云、身份、策略、审计或外部系统动作。

风险、非范围与后续核验

• 不将 NIST 的零信任背景写成部署清单、合规认证或“内网不可信”的单一实现方案。
• 不将 Kubernetes 的集群多租户讨论写成业务租户的唯一模型，也不将 RBAC、配额或网络策略写成充分隔离证明。
• 不将 OPA 的策略解耦能力写成自动授权、正确规则、数据新鲜度、策略测试或变更审批已经实现。
• 不将 OpenTelemetry trace、trace ID、span ID 或上下文传播写成完整审计、不可篡改记录、数据保留或法律取证。
• 不记录真实租户标识、员工信息、客户数据、角色、凭证、策略内容、工单、资源用量、价格、日志、追踪或审批结果。
• TODO(verify)： First Draft 写作当天重读四项资料，并根据届时的章节术语和全局引用登记，核对 NIST 发布状态、Kubernetes 多租户指导、OPA 部署/查询边界与 OpenTelemetry trace 术语；未核验前不得写入版本、默认值、产品配置或运行事实。
• TODO(verify)： Example Implementation 前确认本仓已有的 Node 运行环境和示例约定；没有受控对象时，只能创建纯内存架构评估器，并明确其不代表身份、策略、审计或外部执行。

下一阶段

Chapter Outline 应把控制平面、执行平面、租户定义、身份与能力、策略决定记录、数据隔离、关联观察、成本预算、人工升级和分阶段上线拆成逐节问题。每节都应标出可使用的四项来源、对应的本书模型、最小证据以及不能写成真实部署或合规结论的边界。