第二十六章 下一代企业 Harness 参考架构

证据地位：本章为作者参考设计与工程推导，案例和阈值用于说明实现逻辑，不代表跨组织验证的通用标准。

企业接入一个 Agent 后，往往先遇到两个问题：谁有权让它操作业务系统，以及怎样判断它真的完成了任务。本章用六层结构安排这些责任，便于接入不同供应商或自研运行时。是否需要独立部署每一层，取决于风险、规模和现有平台能力。

1. 六层结构与权威状态

Experience       IDE / Web / CLI / API / business workflow
Control Plane    task contract / scheduler / identity / policy / approval
Agent Runtime    vendor adapter / loop / context / delegation
Execution Plane  workspace / sandbox / tool gateway / credential broker
Evidence Plane   artifacts / trace / verifier / effect ledger
Evolution Plane  eval registry / mutation / experiment / release / rollback

体验层收集意图，控制层持久化任务合同和权威状态。Agent运行层提出动作，执行层在授权范围内操作文件与外部系统；证据层保存产物、执行验证和对账；进化层提出并评估未来版本。进化层内部的提案者与发布者必须分权，不能因为画在同一行就共享权限。

第五章的三平面按管理与数据路径划分，本章六层按功能划分，第二十四章的候选域与治理域则按信任边界划分。三种视角的对应关系如下。

六层中的组件	三平面中的主要位置	信任与读写边界
体验入口、Agent运行层	数据面	提交请求和候选；不直接修改权威任务状态或授予权限
合同、调度、身份与策略	控制面；决策结果进入数据路径	治理主体持有合同、预算和授权状态
沙箱、工具网关、凭证代理	执行面	执行主体只获得当前动作所需权限
事件与产物存储、独立验证器	数据面承载证据；执行面提供隔离验证环境	执行者可按协议追加原始证据，不能覆盖；独立验证主体写判决
候选生成 worker	控制面发起实验，数据面和执行面运行候选	候选域只写提案，不能读封存测试或改裁判
实验服务、评测登记与发布控制器	控制面	治理域读取受控证据、批准发布，执行者不能自行晋级

候选域向治理域提交 proposal，执行层向证据层追加 raw evidence；发布批准只由治理域产生，执行环境只接受经验证的版本清单。高风险场景应通过独立身份、只读挂载、凭证与网络边界落实这些单向关系，不能只靠服务名。低风险小系统可以共用进程，但仍需明确哪个组件有权改合同、评价结果和发布状态。

另一个容易混淆的词是 runtime。Agent Runtime 指运行模型循环、上下文和委派的组件；Execution Runtime 指命令、浏览器或工具实际运行的环境。每个适配器都要声明接哪一端；把工具执行放进企业网络，并不能由此推出推理、工具输出或会话存储也留在企业网络。

采购或自建时，可用下面的责任表逐版本核实。这是待填写的设计记录，不是对任何厂商已验证能力的声明。

责任	需要明确的运行位置与权威主体	验收证据
模型循环与编排	企业进程或托管服务，谁能中断与恢复	能力协商、取消和恢复记录
会话持久化	内容、地域、保留期和导出责任	导出样本、删除与访问控制记录
凭证保管	长期凭证保管方、短期授权签发方	发放、到期和紧急撤销事件
工具执行	worker、沙箱及出网路径，输出回传位置	外部动作日志和数据流核对
业务验收与发布	领域负责人、独立验证器、提交主体	合同、回读、后置检查和批准记录

2. 统一契约与能力协商

平台按需要定义 Task、Attempt、Action、Observation、Artifact、PolicyDecision、Checkpoint、Delegation、VerificationResult 和 EvidencePackage。沿用第六章：Task是任务，Attempt是任务执行尝试，Action是一次逻辑动作，ToolTry是该工具动作的单次尝试；重试不应改变同一逻辑动作的幂等身份。适配器负责统一对象与产品协议的映射，保存原始载荷的摘要、位置与协议版本。下面是本书自定义接口草图，不能作为某个厂商 SDK 的原生方法表；字段转换示例见第二十七章。

RuntimeAdapter {
  negotiate(capability_requirements) -> CapabilitySet
  start(task, workspace, policy_profile) -> Attempt
  stream_events(attempt_id, after_offset)
  respond_to_request(request_id, approval_or_input)
  checkpoint(attempt_id)
  cancel(attempt_id, reason)
  collect_artifacts(attempt_id)
}

适配只需要动作、结果、批准、产物和生命周期，不要求供应商暴露私有推理。缺少恢复或结构化补丁能力时，协商结果必须明确返回缺失；调度器据此降低自治范围、选择替代实现或转人工。能够导出对话不等于能够恢复外部动作。

3. 身份、租户与凭证

用户、平台、运行时、子代理、工具与外部服务具有可区分的身份。能力租约绑定租户、资源、动作、用途和有效期，凭证代理只在执行时向受控工具注入短期凭证，模型上下文与长期日志不保存密钥。转授父主体权限时，不得超过其可转授范围，并按子任务收窄。专家使用独立执行身份时，由可信策略服务另行签发，同时核对调用者的委派权、用途和结果信息流；不因此赋予父模型读取专家全部数据的权限。缓存、记忆和工具结果进入上下文前完成数据分类与租户检查。

短有效期不能代替撤销检查。每次动作，尤其提交前，都要重验当前授权、租约、撤销版本和取消状态；无法确定权限有效时停止。模型、工具视图和输入版本可以固定以便复现，旧授权不能因版本粘性继续有效。紧急撤权应暂停受影响任务、阻止新副作用并回收能力；已经进入上下文的有害内容需要隔离后重建上下文或创建新 attempt，不能只删除登记表中的条目。

4. 持久执行与副作用

任务与尝试状态持久化，事件按约定排序；外部状态变更记录意图、幂等键、参数摘要、策略决定和结果。崩溃后只能从受支持的检查点恢复，取消和已终止任务不能自动回到运行中。未知结果先对账，查询暂不可见也不能直接推断未提交；安全重试所需的下游幂等保证见第六章。调度器另行管理预算、并发、截止时间和取消树。

例如邮件发送超时，第一封可能已经送达。网关应凭稳定业务标识查询权威记录；若目标系统无法确认，就保持结果未知并升级处理。另发一封“补偿邮件”并不能撤回第一封，登记了补偿函数也不构成安全重试条件。

5. 以证据判定完成

运行时只能提出候选。适配器将Task的 checks 解析为完整合同的 pre_commit_checks，独立验证器针对封存候选执行这些检查，生成绑定产物摘要的结果。若合同仅要求交付待审补丁，验收和交付完成即可结束，不人为增加外部提交；若要求发送、合并或部署，候选通过只是前置门，还要由提交控制器重验当前授权、候选摘要和目标版本，再按幂等协议提交、回读权威结果并执行 post_commit_checks。

“部署接口已确认”不等于“部署后健康检查通过”。状态沿用第十章：effect confirmed → VERIFYING_POSTCONDITIONS；后置检查失败或未知进入 COMMITTED_BUT_UNVERIFIED，保留已发生的副作用，不计为可信完成。回执丢失则先保持结果未知，不能伪造确认或直接重试。审批后候选或目标版本变化，原验证与批准不能直接复用。

证据包连接合同版本、输入、封存候选、验证器、策略、批准、实际提交目标和回读结果。它用于审计与核验，不需要保存私有推理。取回产物并核验摘要、重跑确定性检查、重放生成过程是三种能力：前两项可有明确记录，第三项仍受模型版本与外部环境可用性限制。

6. 七类 SLI 与 SLO 设定方法

SLI 是测量值，SLO 才是某个窗口内希望达到的目标。下表先定义测量方法，阈值由风险、历史基线和业务负责人确定。每项还要登记窗口、任务资格、观察期、目标值和误差预算，不能仅填一个百分比。

指标	定义与分母	窗口及验收点	可能的指标博弈
可信完成率	成品交付和业务提交两类分别计算：截止内达到各自终点的任务／该类入口登记的全部合格任务	按合同冻结批次统计；交付类验收并交付，提交类还须权威回读和后置检查	降低验收、删除超时或未激活任务
错误完成率	观察期内被证伪的已宣告完成任务／已走满同一观察期的完成任务	按完成批次回标，另报未成熟样本与抽检覆盖；抽样时声明估计方法	隐藏返工、延迟登记事故
证据完整率	必需证据可访问、摘要相符且与合同及提交绑定的完成任务／全部宣告完成任务	完成时检查，并按保留期限抽查可取回性	只填字段，留下失效链接或不相关日志
恢复成功率	在恢复预算内达到合同终点且无重复副作用的事件／全部应恢复中断事件	中断时登记分母；未尝试也保留，并报告原因	只统计已启动恢复的容易事件
最大副作用	故障或失控窗口内，同一任务及其后代可累计影响的金额、对象和资源上界	同报实际暴露次数、观察最大值和配置上界；无事件不表示上界为零	拆动作或子任务规避额度
单位可信完成成本	同一任务批次的模型、计算、工具、验证、重试和人工总成本／可信完成数	固定成本按公开规则摊销，事故费用另列归属；零完成记为不可估计或无穷	只计成功调用，忽略失败与人工处置
完成时延分布	两类任务分别从合同冻结计到各自终点；仅完成者的P95另标为条件统计	同报每类全部合格任务的成功、失败、超时、取消、进行中数量及截止内完成比例	丢弃长尾，把候选通过当业务提交完成

两类分母在入口冻结：N_deliverable 是合格成品交付任务数，N_business_commit 是合格业务提交任务数，二者分别包含各自的成功、失败、超时和取消任务。分子分别为验收并交付的成品，以及提交确认且 post_commit_checks 通过的业务任务；COMMITTED_BUT_UNVERIFIED 留在后者分母中而不进入分子。不能因提交失败把任务改列为交付成功。确有获批合同修订时，保留原批次和修订事件，按预定迁移规则报告；不得覆写历史分类。综合指标可以另报，但须保留两类的数量和结果。

例如，可将一个自然周冻结的合同作为任务批次，并在各自截止期后结算可信完成；错误完成率另用预先选定的30日观察期回标。这里的周与30日仅为设计示例。未到截止期的任务、未走满观察期的完成任务单列，不能暗中移出历史分母；超时、基础设施失败和取消按预先声明的口径保留并分型报告。入口资格不应随候选表现修改，拒绝接纳的数量也要公开给运营负责人。

候选验证通过率可以作为诊断指标，分母是全部提交候选，不能替代任务可信完成率。每个SLO需要负责人、数据来源、告警和例外流程；高风险切片单列，严重违规按事件与暴露量报告，不能被总体平均分抵消。

7. 多运行时数据流

request → contract compiler → scheduler → runtime adapter
   → policy-mediated tool gateway → sandbox/external systems
   → event + effect ledger → candidate seal
   → candidate verifier → current authorization → commit if required
   → authoritative readback + postconditions → EvidencePackage
   → telemetry/eval → governed evolution release

最容易遗漏的是适配器之外的旁路：运行时直接出网、插件自行持有密钥、界面直接调用供应商接口，以及宿主执行不经过模型的生命周期 hook。应核对实际网络流、执行身份、凭证发放与外部审计日志，不能只凭架构图认定所有动作受控。

8. 构建顺序与替代方案

先选一个任务族，明确合同、权限、产物、验证和业务终点，再决定是否接第二种运行时。只有一个低风险 Agent 时，可采购沙箱与日志服务，保留任务和证据的导出能力；进入高风险域后再按隔离需求拆分部署。若流程稳定且便宜代码已能完成，确定性工作流也是有效选择，没有必要为采用此架构而扩大模型权限。

接入能力是否足够，应由取消、撤权、恢复、候选重验和退出演练证明。图中的六层是核对责任的工具，不是采购六套系统的清单。