企业官网建设流程全解析

02 · 第二层：评估模型（agent-work-loop）

Better Harness 的"宪法层"。Agent Work Loop 模型定义了：评审单元是什么、证据有哪些状态、检查怎么判、分数怎么封顶、finding 怎么立。所有评分和结论的合法性都来自这一层。

解决什么问题

“AI 工作流健康度"是个模糊话题——如果让 AI 自己评，它会刷分；如果让人拍脑袋，没有可复核性。Better Harness 把它变成可复核的评审协议：每个分数能回答"你凭什么”，每个 finding 能回答"证据在哪、谁修、怎么验"。它从根上拒绝了两种行业通病——配置刷分（装了一堆 hooks 就高分）和自证改进（自己修自己打分说有效）。

怎么工作

评审单元：Task Episode

模型拒绝"给仓库打分"，评审单元是Task Episode——一个用户目标 + 一条验收边界。它可以跨多轮对话、多个会话，但每条结论必须绑定同一个 goal、target、action、result。两条纪律：不因"恰好在一个会话里"就合并无关工作；不把聚合计数（跑了多少次测试、用了几个 Skill）冒充任务行为。

会话证据不可得时，行为保持Unobserved，只用项目证据支撑机制层面的结论——这叫session-limited评审，不切换模型，也不伪造已完成的行为。会话可得性决定证据丰富度，不决定模型选择；默认模型永远是 Agent Work Loop。

五维 × 十五检查

五个维度是稳定的评审身份，每维三个检查（check id 机器稳定，读者标签只解释能力）：

Task Understanding（任务理解）——代理理解预期结果、应用相关权威上下文、并把工作保持在显式范围与影响边界内吗？三个检查：目标与验收边界是否作为可恢复记录保存（goal-understanding）、决策用上下文是否来自权威源而非宽泛无关（relevant-context）、预期影响范围是否显式可追溯且扩容有批准（scope-boundary）。

Controlled Execution（受控执行）——代理能通过受支持的路径启动和操作项目，同时留在强制权限边界内吗？三个检查：干净初始态能通过项目自有非交互路径变可用（instruction-led-start）、目标行为可通过项目自有工作流发现并调用（supported-operation）、文件系统/网络/凭据/外部写留在强制授权与清理边界内（permission-boundary）。

Change Validation（变更验证）——代理对最终变更跑了相关验证、用可用可观测性诊断修复失败、并复验了修复结果吗？三个检查：每个实质性修改映射到直接覆盖其行为的最小目标自有检查且在最后一次编辑后运行（relevant-check）、要求有序链failure → reproduction → diagnosis → bounded repair且重试通过不算修复证据（failure-repair）、修复后在最终状态重跑同一检查（validate-again）。

Reliable Delivery（可靠交付）——当前结果在真实交付边界被接受、有风险相称的审批、有可用的回滚/恢复路径吗？三个检查：真实评审/CI/合并/发布决策绑定到当前 revision 且本地测试和代理说"完成了"不算交付（acceptance-evidence）、破坏性/特权/不可逆动作在生效前拿到必需决策（high-risk-approval）、实际副作用有回滚/恢复路径且不得为提高证据强度而真跑破坏性回滚（rollback-recovery）。

Learning Capture（学习沉淀）——Harness 能检测重复/维护机会、变成可复用改进、并长期保持有效吗？三个检查：区分当前能力缺口/受支持的重复机会/熵驱动的维护机会/证据不足（lifecycle-repeat-detection）、机会经覆盖梯子 + Loop Discovery 路由到最小持久 owner（loop-engineering）、改进通过"可比的后续结果评估"或"对照规范真理的周期性维护检查"保持问责（later-validation）。

证据状态阶梯：模型的心脏

七个状态描述一个机制被证据支撑到什么程度：

Present（存在） 有 owner 的机制或评审契约存在 Wired（接线） 相关任务/触发器/owner 路由能够到它 Exercised（演练过） 有链接的 episode 或检查用过它并留下了结果 Outcome-supported 可比的后续结果支持所声称的效果 Missing 检查过的证据确认必需机制/结果缺失 Unobserved 可用观测边界无法判定 Not applicable 检查过的任务和项目证据证明不适用

证据状态 ≠ 通过/失败。演练过的操作可能暴露缺陷；安全拒绝可能是正确行为；不可达的外部边界是Unobserved而非Missing。静态配置最多证明它包含的机制。

评分规则：证据封顶制

前四个维度用证据上限限制分数置信度——这是防"配置刷分"的关键设计：

这是上限不是公式；必需/已触发的检查缺失、未解决、被阻塞 → 该维度压在 59 以下。超过 75 分还要求：检查过的源码或测试 ownership + 已执行或显式提供的验证路径。每维独立打分，绝不从 finding 数量推导分数。

Learning Capture 特殊：Agent 给出 35–100 的整数；35 仅表示完成了一次有界评审。未覆盖的重复程序/知识需求压 ≤59；有 owner ≤74；接线 ≤84；当前任务演练但无后续对比 ≤74；后续演练对比 ≤94；只有后续可比且改善的结果才允许 100。一个"评审充分、确无候选"的干净窗口可以到 94，且不强制造 Memory 或 Skill。

Finding 纪律：证据进，证据出

• 分数永不创造或压制 finding。finding 需要四要件：检查过的缺口、有界影响、最小 owner 对齐的修复、验证路径。四要件齐了就发，不管报告好不好看。
• 一个 finding 只映射一个主检查（ownership 规则，不是数量上限）；不同原因/owner/验证路径必须分开。
• 计数、文件名、资产存在、严重度、年龄、churn、分数本身都不是 finding。
• 每个检查的 “Typical findings” 给出发射条件（Emit only when）：例如"任务没有可恢复的验收边界"，只有当打开的请求/修正/issue/Spec 证据显示冲突或缺失的完成标准实质影响了结果时才能发——模糊 prompt 本身不够。
• 严重度三档 High / Medium / Low（代码校验器强制此枚举）。

修复进度与 Loop Effectiveness 的分离

模型里最精妙也最诚实的部分：

• finding 绑定的修复通过目标检查后，由一个独立评审者从锁定的修复前报告、实际输出、修复后验证判定verified / partial / blocked——只更新 Repair Progress。
• 五个维度分数（对读者叫Loop Effectiveness）不变，除非一个可比的后续 Task Episode证明：修复的机制被路由了、被应用了、改善了结果、且没有护栏回归。
• 同一窗口的验证只证明"修复状态"，不证明"后续有效性"。

换句话说：改了 AGENTS.md 并通过检查 ≠ 工作循环变好了；只有下一次同类任务真的更顺，才有资格动 Loop Effectiveness 分数。

投影边界：什么证据能支撑什么结论

模型给出一条硬边界链，防止证据越权：

打开的项目和代理资产 → repositoryEvidence（机制存在） 有界的相关任务事件 → taskEpisodes（行为） 相关变更 + 最终验证 → Change Validation 验收/批准/回滚/恢复结果 → Reliable Delivery 受支持的重复机会 → Loop Discovery → 持久 owner 评审过的持久 owner + 演练路径 → 可复用的 Learning Capture 证据 后续可比结果 → outcome-supported 证据

归属或链接缺失时，保留Unobserved / Missing / Not applicable，不用聚合计数或散文填空。

为什么这么设计

• 为什么证据状态 ≠ 通过/失败？演练过的操作可能暴露缺陷（Exercised 但 fail），安全拒绝可能是正确行为（fail 但对），不可达的外部边界是 Unobserved 而非 Missing。如果把"演练过"等于"通过"，就会把暴露问题的证据变成掩盖问题的分数。
• 为什么用上限而不是公式？公式可以被刷——多配几个 hooks 就凑够分数项。上限是从天花板往下压：静态配置最多 74，因为"存在"只证明机制在那，不证明被用过。只有 Exercised（演练过有结果）才到 94，只有后续可比改善结果才到 100。
• 为什么修复完分数不能动？这是防"自证改进"的命门。改了配置通过检查，只能说"修复状态"变了；工作循环是否真变好，要等下一个可比任务证明。同一窗口的验证只证明"修复状态"，不证明"后续有效性"。
• 为什么 Learning Capture 只有后续可比结果才到 100？学习沉淀的本质是"下次能用上"。如果只有当前任务演练过、没有后续对比，最多 94——因为你还没证明它真的复用了。强制要求后续可比结果，就是逼"学习"这个词名副其实。

模型的理论来源

模型公开了五维各自的"第一性来源"：Task Understanding 和 Controlled Execution 借鉴 OpenAI《Harness Engineering》（规约意图、隔离启动、agent 可及工具、机械强制边界）；Change Validation 借鉴 Google SWE Book 测试章 + OpenTelemetry Logs 规范（行为导向测试、跨执行上下文关联）；Reliable Delivery 借鉴 GitHub Protected Branches 契约（当前 revision 的必需检查、评审门、受控绕过）；Learning Capture 借鉴 Google SRE Postmortem Culture（复发证据、贡献原因、有 owner 的预防行动、后续有效性）。这些来源解释模型的形状，不冻结术语、运行时、厂商特性或数字分数。

模型的所有权地图

模型末尾显式声明分工：五张定义表拥有读者问题和能力含义；Look for/Typical findings拥有适用性和判定条件；证据怎么采集归 references 各域。Overlay 可以增加证据源或更严的本地闸门，但不得改五维名称、加第十六个检查、把已配置资产冒充行为、或弱化任何判定条件。

面试表述

• Q：证据上限怎么防配置刷分？这是整个设计最关键的一招。分数不靠公式累加，而是被证据状态从天花板往下压：静态配置（Present）最多 74 分，因为"配置存在"只证明机制在那，不证明被用过；只有 Exercised（演练过有结果）才到 94；只有 Outcome-supported（后续可比改善结果）才到 100。你装了 100 个 hooks，分数天花板还是 74——想上 94 必须拿出演练证据，想上 100 必须拿出后续同类任务真的变好了的证据。
• Q：证据状态为什么不等于通过/失败？因为它们回答的是不同的问题。证据状态回答"这个机制被证据支撑到什么程度"，通过/失败回答"这次操作的结果是什么"。演练过的操作可能暴露缺陷（Exercised 但 fail），安全拒绝可能是正确行为（fail 但对）。如果把"演练过"等于"通过"，就把暴露问题的证据变成了掩盖问题的分数。
• Q：修完一个 finding，分数为什么不能立即涨？因为修复状态和后续有效性是两件事。改了 AGENTS.md 并通过检查，只证明"修复状态"变了——Repair Progress 更新为 verified。但工作循环是否真变好（Loop Effectiveness），要等下一个可比的同类任务证明：修复的机制被路由了、被应用了、改善了结果、且没有护栏回归。同一窗口的验证只证明"修复状态"，不证明"后续有效性"。这就是防"自证改进"的命门。
• Q：Unobserved 和 Missing 有什么区别？Unobserved 是"可用观测边界无法判定"——证据不够，什么也没证明；Missing 是"检查过的证据确认必需机制/结果缺失"——有证据，证明它确实缺。前者不证明任何事，后者证明缺了东西。把 Unobserved 当 pass 是铁律禁止的。

记忆点：评估模型的本质是——分数被证据状态从天花板往下压，配置存在最多 74 分，演练过最多 94，只有后续可比改善结果才到 100；修完只动修复进度，维度分数要等下一个可比任务才有资格动。

上一篇：01 · 工程实践层 ｜ 下一篇：03 · 可运行实现层