主题
Harness 范式与责任边界
一句话：构建 Agent 的起点不是选框架，而是先回答三个问题——Harness 的通用行为由谁实现、运行环境由谁提供、企业还要补哪些责任。四类构建入口不是成熟度阶梯，差异只在责任归属。
对应原书：第 3 章《范式：Harness 的主流构建方式和责任边界》。
为什么需要
“用哪个框架”这个问题之所以问错了，是因为它把三件不同的事混成一件：
- 通用行为：循环怎么转、上下文怎么装、工具怎么注册、失败怎么恢复、完成怎么验证；
- 运行环境：进程在哪跑、状态存在哪、隔离到什么程度；
- 企业责任：身份怎么映射、业务状态归谁、谁审批、谁验收、出了问题谁兜底。
换框架只改变第一件事的写法，不改变后两件事的归属。很多项目先选框架、再补运行和治理，最后发现真正花时间的是后两件，而框架已经把手艺锁死了。
原书给出的解法是先定边界，再选载体。Harness 是模型之外、围绕 Agent Loop 组织上下文、能力、状态、环境与控制机制，并把模型判断转化为可执行、可恢复、可验证任务过程的代码、配置与执行逻辑。
这句话里有三个否定，值得逐条记住：
- 不是更长的 System Prompt——它还包括状态机、工具注册、权限检查、错误恢复、完成验证；
- 不是某个框架的同义词——框架、CLI、SDK、托管服务都只是载体；
- 不是 Runtime 或 Sandbox——Harness 决定下一步给模型什么，Runtime 承载过程，Sandbox 限制影响范围。
核心机制
一、五层责任：逻辑边界不必对应独立产品
这五层是逻辑切分，小团队完全可以把它们放在一个进程里。但架构图上不能省：省掉之后，故障时说不清是模型判断错、编排漏了一步、运行时丢了状态，还是沙箱没隔离住。责任边界一旦模糊，数据位置和最终责任也会跟着模糊。
二、八个构建对象收敛成三个能力域
开发阶段要回答的问题可以列成一张检查表：
| 构建对象 | 要回答的问题 | 归入能力域 |
|---|---|---|
| Agent Contract | 为谁工作、目标是什么、允许与禁止什么 | 执行与编排 |
| Execution | 循环、状态机、预算 | 执行与编排 |
| Context & State | 每轮看见什么、事实存在哪 | 上下文与状态 |
| Capability | Tool、MCP、Skill、Subagent 怎么组织 | 上下文与状态 |
| Environment | 在哪运行 | 行动与反馈 |
| Control | 以谁的身份执行、何时需要审批 | 行动与反馈 |
| Interaction | 如何看进度、如何干预 | 行动与反馈 |
| Quality | 如何证明完成 | 行动与反馈 |
这张表的用途是防遗漏，不是选型。三列收敛出的三个能力域，正好对应任务、信息、行动三条主线。
三、先判路径控制，再选入口
Workflow、Agent、Hybrid 说的是控制权：路径是预设的、运行时决定的，还是固定边界内做局部判断。它和应用形态（Single、Long-Horizon、Multi）是两个维度，经常被混着讨论。
判断顺序应当是：
- 这条链路的结果可不可预测？可预测就走 Workflow，确定性和成本都更好；
- 不可预测的部分是不是集中在少数环节？是就用 Hybrid，固定边界里放 Agent；
- 整条路径都需要动态决策？才考虑 Agent 主导。
四、四类入口：差异只在三问
| 入口 | 通用行为谁实现 | 运行谁承载 | 企业仍承担 |
|---|---|---|---|
| 高代码框架 | 企业自写 | 企业自建 | 几乎全部，包括数据与环境 |
| 产品化 Harness | 复用现成工作模式 | 复用或嵌入现有应用 | 业务状态、审批、验收 |
| 托管 Agent 服务 | 服务方在约定范围内托管 | 服务方 | 身份映射、业务状态、审批、数据边界、结果验收、退出机制 |
| 云平台 Agent 产品 | 平台预置 | 平台 | 业务正确性、验收 |
选择时问三件事就够了：是否必须改 Loop 与 Context、数据与执行环境能不能托管、团队愿不愿意长期维护状态恢复与沙箱。 三个答案组合起来，入口基本就定了。
最容易出错的是把“托管”理解成“交付”。托管只覆盖约定范围内的 Harness 与运行资源，验收责任不随托管转移——平台可以推进任务、产生事件，但不能替企业定义什么叫业务正确。
五、Agent Platform 的两条克制
当团队和 Agent 都多起来，各建各的模型接入、工具目录、凭证、沙箱和观测，就会形成孤岛。平台的作用是统一公共对象：Agent Definition、Task、Session、Event、Identity、State、Checkpoint、Artifact、Trace、Outcome，以及接入契约。
但平台有两条克制：
- 不抹平实现差异：自研、开源、SaaS 的 Harness 各自保留，平台只统一对象与契约；
- 不替业务定义正确性：平台汇聚证据，Verifier 由业务定义。
多源统一管理还需要三个条件：版本归属可追溯（事件能关联到 Task、Identity、Tenant）、远程 Agent 返回可验收的 Artifact 而不是只有自然语言、执行记录能被统一观测。
最小上手
yaml
entry_assessment:
path_predictability: deterministic | partially_dynamic | fully_dynamic
harness_choice: workflow | hybrid | agent_dominant
harness_responsibility:
seven_items:
loop: self_built | reused | hosted
context: self_built | reused | hosted
planning: self_built | reused | hosted
tools: self_built | reused | hosted
policy_hooks: self_built | reused | hosted
compaction_continuation: self_built | reused | hosted
verification: self_built | reused | hosted
runtime: self_built | hosted
state_location: process_local | external_store
credential_location: vault_side | env_side
enterprise_responsibilities: [identity_mapping, business_state, approval, acceptance, exit_mechanism]
build_objects: [contract, execution, context_state, capability, environment, control, interaction, quality]
platform_check:
duplicated: [model_access, tool_catalog, credentials, sandbox, observability]做一次”入口体检”，半小时能得出方向：写下链路的路径可预测性并标注哪些环节必须动态决策；对 Harness 的七件事逐项标注”自研/复用/托管”；对运行环境标注”自建/托管”并写下状态与凭证的位置；列出企业仍要承担的责任；用八个构建对象过一遍缺哪项就在对应能力域补设计；如果已有多个 Agent，检查是否在重复建设模型接入、工具目录与观测。
验收看四件事：路径可预测性与入口选择一致；Harness 七项责任归属清晰且无遗漏；企业责任清单写到”谁审批、谁验收、故障找谁”；多个 Agent 无重复建设的公共对象。
生产动作
- 先定责任表，再定技术栈。责任表要写到“谁审批、谁验收、故障找谁”这一级，否则托管边界会在事故里被重新解释。
- 把“可整体回退”作为发布单元。Harness 配置、Prompt、工具权限、运行环境要能一起退，否则会出现旧代码配新提示词的混合态。
- 平台只做对象与契约。强行统一 Harness 会在短期内降低接入成本，长期失去“按任务选最低充分方案”的能力。
- 接入远程 Agent 时，契约里必须有 Artifact。只有自然语言回复的远程 Agent，无法被验收，也无法进入统一观测。
边界
- 四类入口不是成熟度阶梯。高代码不等于落后，托管也不等于先进；差异只在责任归属。
- 路径控制不是应用形态。用 Workflow/Agent/Hybrid 讨论部署结构，会把两个维度搅在一起。
- 五层责任可以合并实现，但不能合并描述。描述合并了，故障定位就没有坐标系。
- 平台不解决正确性。它能统一身份、版本、Trace 和配额，但“任务算不算完成”仍然要业务侧给判据。
- 原书的入口分类偏静态。真实系统常常混用：核心链路自研 Harness，边缘能力接托管服务；这时要按任务分别做三问，而不是给整个团队定一个入口。
讲清楚
Harness 是模型之外的执行系统：它组织上下文、注册能力、保存状态、约束行动、验证结果。判断一个项目该从哪起步，看三件事——通用行为谁实现、运行谁承载、企业补哪些责任，而不是先选框架。
四类入口（高代码、产品化、托管、云产品）不是阶梯也不互斥，可以按任务混用。托管的只是约定范围内的 Harness 与运行资源，验收、业务状态和数据边界始终归企业。
多个 Agent 并存后，平台统一的是对象与契约（Task、Session、Event、Identity、State、Checkpoint、Artifact、Trace、Outcome），不是实现；它汇聚证据，但不下“业务正确”的结论。守住这条，平台才不会变成新的瓶颈。
适用：Agent 构建方式选型与平台边界设计 | 初稿 2026-10