一个会做事的 AI 产品，里面到底有哪些部分
把用户、界面、模型、工具、资料和外围运行系统放回同一张图，先看清谁负责什么。
第一次认识 Harness
每个新词先用一句人话、一个生活类比和同一个访谈任务解释；后文才会直接使用。
- 一句人话
- 围在模型外面，负责把一次聪明回答变成一段可控制、可继续、可检查工作的产品与工程系统。
- 生活类比
- 如果模型像一位聪明但刚入职的同事，Harness 就像他的工作台和公司制度：给材料与工具，限制权限，记录进度，并检查交付。
- 具体例子
- 用户说“分析 10 份访谈”时，模型负责判断主题；Harness 负责找到文件、逐份读取、记录出处、限制可访问目录、保存进度，并检查每条结论能否回到原文。
- 能解释 Model、Harness、Client 与 Environment 的责任边界
- 能按层定位失败
- 能判断升级模型还是改 Harness
为什么换一个更聪明的模型，不会自动得到更好用的产品？
把模型想成一个能够理解信息并提出下一步动作的决策部件。它可以生成文字，也可以生成结构化的工具请求，但它本身不会自动拥有你的文件、数据库或发送权限。真实动作由外围系统执行。
Harness 就是承接这段距离的运行与产品系统：它决定给模型什么上下文、暴露哪些工具、如何校验参数、何时请求审批、怎样保存状态、何时停止循环，以及如何把结果和证据交给用户。客户端负责协作界面，工具改变环境，用户仍负责目标与最终验收。
所以“更强模型”不自动等于“更好产品”。上下文漏了最新规则、工具把失败映射成成功、权限默认过宽、界面隐藏了未验证状态，都需要在模型之外修复。
先记住这句话“模型像发动机、Harness 像整车系统”可以帮助入门，但不是严格公式。真实 Agent 产品还需要任务定义、工具与环境、权限策略、客户端交互、验证和用户控制。任何一层失效，最终任务都可能失败。
先画出六个角色，而不是只记一个公式
User 定义目标并保留关键控制权；Client 收集输入、呈现计划、审批、进度和产物；Harness 编排状态、上下文、工具与策略；Model 解释当前输入并提出下一步；Tool 执行窄能力；Environment 保存被读取或改变的真实状态。
同一组件可以在工程实现中合并，但责任不能混在一起。比如客户端可以显示一张审批卡，却不能只靠隐藏按钮来阻止越权；真正的权限限制必须在 Harness、沙箱或工具边界执行。
跟着一次 Turn 走完全链路
用户提交“找出访谈中影响续费的前三个问题，并逐条引用原文”。Client 创建任务；Harness 加入研究规则、可用文档和工具说明；Model 请求搜索“续费、取消、价格”；Harness 校验为只读请求并执行；工具返回片段与来源 ID。
Model 根据观察请求读取六段上下文，再生成三条候选洞察。Harness 检查每条引用是否存在，Client 把洞察、反例和证据展示给用户。用户看到的最终结果来自多次模型判断和真实工具执行，不是一条 Prompt 的直接输出。
失败归因要找到第一个错误责任层
如果洞察引用不存在，可能是模型编造，也可能是工具结果没有保留 ID；如果模型读取了旧文档，可能是检索排序错误，也可能是最新文档没有版本标记。不要从最终症状直接跳到“换模型”。
最实用的归因方法是沿轨迹寻找首次偏离：当时每层得到了什么输入、做了什么决策、产生了什么状态。归因必须对应一个可观察信号、一个 Owner 和一个回归任务。
产品经理真正设计的是层与层之间的合同
模型需要清楚的工具描述，工具需要可验证回执，Harness 需要稳定事件，客户端需要能解释状态，用户需要能判断影响。每个接口都既是工程合同，也是产品体验。
当模型升级时，仍要用原任务集回归工具选择、参数、成本、权限和长任务行为。强模型可能减少旧脚手架，也可能更频繁地触发高风险能力。
模型越强，Harness 越需要重新分工
强模型可能自己完成过去由代码写死的分解、过滤和上下文选择，所以旧的复杂编排应当通过同一任务回归，能删就删。这是“减少过时脚手架”，不是“模型外什么都不需要”。
身份、凭证、权限、沙箱、持久会话、审计、恢复和真实结果验证仍然是生产责任。Anthropic 的 Managed Agents 把 Harness 与执行沙箱分开，并用追加式 Session 连接两者，恰好说明编排可以变薄，基础设施和治理不会凭空消失。
“Model + Harness = Agent”是入口公式。更完整的产品系统还包括承接协作的 Client、被工具改变的 Environment，以及始终负责目标与验收的 User。
接收任务、环境与用户控制
注入规则、历史、工具 Schema 和权限
返回工具调用或最终表达
校验、执行并把 Observation 回填
有术语没听懂？在这里用人话再看一遍7 个词＋
- Model
- 根据当前输入预测文字或结构化动作的模型；它只看到被送入本次调用的信息。
- Harness
- 连接模型和环境的运行系统，管理上下文、工具、状态、策略、循环和交付。
- Client
- 用户实际协作的 CLI、IDE、桌面、Web 或移动端界面。
- Tool
- 由 Harness 调用、能够读取或改变真实环境的窄能力合同。
- Environment
- 文件、代码仓库、数据库、业务系统、网页等任务发生的真实世界。
- Turn
- 一次用户驱动的工作单元，内部可以包含多次模型调用、工具执行和审批。
- Observation
- 工具执行后返回给模型的新事实，例如文件内容、错误、退出码或业务回执。
修复手机号校验 Bug
模型判断要搜索代码；Harness 决定允许哪些目录、如何调用搜索和测试；Client 展示计划、审批、Diff 与验证。
- 01
Model 请求 Search 并提出根因假设
- 02
Harness 在沙箱执行、裁剪工具结果并记录 Item
- 03
Model 生成修改，Harness 执行测试，Client 呈现证据
用户验收的是经过测试的代码改动，而不是模型最后一句“已完成”。
本章依据与证据边界6 条结论 · 8 份原始材料＋
正文已经把关键来源放在相关概念旁边。这里保留完整核验清单：每条材料能支持什么、不能支持什么；不要求离开本站才能继续学习。
- [1]
OpenAI 对 Codex Agent Loop 的公开拆解说明模型输入由 instructions、tools 与 input 组成，工具结果会回到后续循环。
官方事实OPUnrolling the Codex agent loop官方工程文章 · 核验 2026-07-14 - [2]
OpenAI App Server 将 Thread、Turn、Item、审批和事件作为 Codex Harness 的公开产品接口。
官方事实OPUnlocking the Codex harness: App Server官方工程文章 · 核验 2026-07-14 - [3]
Anthropic 强调工具设计、环境反馈与简单可组合模式对有效 Agent 的重要性。
官方事实ANBuilding effective agents官方工程文章 · 核验 2026-07-14 - [4]
本站的六层责任图与用户研究案例是为教学整理的通用分析框架，不代表所有 Agent 产品都采用同一工程模块。
本站推演OPUnrolling the Codex agent loop官方工程文章 · 核验 2026-07-14 - [5]
Anthropic 建议随模型能力提升持续检验并删除过时的编排假设，同时保留用于 UX、成本与安全的明确边界。
官方事实CLHarnessing Claude’s intelligence官方工程文章 · 核验 2026-07-14 - [6]
Anthropic 的 Managed Agents 案例将 Harness（Brain）与执行沙箱（Hands）解耦，并以持久 Session 连接；这是 Anthropic 的产品架构，不是所有 Agent 的唯一实现。
官方事实CLBuilding with Claude Managed Agents官方工程文章 · 核验 2026-07-14
查看全部一手材料与源码证据 8 条
这份材料区分了由预定义代码路径控制的 Workflow 与由模型动态控制过程的 Agent，并强调先采用能工作的最简单方案。它还给出 Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer 等组合模式，以及何时值得承担 Agent 的延迟、成本和复合错误。
官方产品实现 · 核验 2026-07-11How Claude Code worksAnthropic这份文档把 Claude Code 的 Agent Loop 描述为收集上下文、采取行动、验证结果三个相互交织的阶段，并说明模型与工具如何通过结果反馈持续调整。它还解释 Claude Code 作为 Harness 所承担的上下文管理、执行环境、会话、压缩、检查点和权限职责。
官方方法 · 核验 2026-07-11A practical guide to building agentsOpenAI这份指南面向产品与工程团队，给出 Agent 使用场景判断、Model/Tools/Instructions 基础结构、单 Agent 与多 Agent 编排和 Guardrail 设计。它支持从复杂决策、难维护规则和非结构化信息出发选择场景，并强调先强化单 Agent、从小范围真实用户验证开始。
官方产品实现 · 核验 2026-07-11Unrolling the Codex agent loopOpenAI这份材料逐步解释 Codex Harness 如何组装 instructions、tools 与 input，通过 Responses API 在一次 Turn 内循环完成模型推理和工具调用。它还说明对话增长、上下文窗口、Prompt Caching 与 Compaction 为什么属于 Harness 的核心工程责任。
固定提交源码 · 核验 2026-07-11Hermes Agent repository and architecture guidanceNous Research这份固定提交的仓库说明展示 Hermes Agent 如何用同一个窄腰核心服务 CLI、TUI、桌面与消息入口，并优先通过 Skills、Plugins 与 MCP 扩展。它还把 Prompt Cache、核心工具数量和扩展 Footprint 当成真实架构约束，说明工具越多并不自动更强。
官方方法 · 核验 2026-07-14Harnessing Claude’s intelligenceClaude by Anthropic这份官方设计说明展示 Claude Code 团队如何把模型能力放进工具、上下文、权限与反馈环境，并把 Harness 视为随模型变化而持续调整的产品系统。
证据边界：它解释团队经验，不代表每个领域都应复制 Claude Code 的产品结构。官方产品实现 · 核验 2026-07-14The evolution of agentic surfaces: building with Claude Managed AgentsClaude by Anthropic这份官方材料定义 Agent、Environment 与 Session 三类生产资源，并说明 Brain/Hands 分离、持久事件、凭证代理、可恢复状态和自托管执行环境。
证据边界：官方自测延迟和客户案例不能直接外推为所有 Agent 产品的 ROI。官方岗位原文 · 核验 2026-07-14AI 产品经理（Agent Harness 产品方向）DeepSeek官方岗位原文要求路线图、真实任务与用户反馈、模型行为判断、Vibe Coding、UI/UX、Harness 技术原理、数据研究和模型与 Harness 共同进化。
证据边界：公开 JD 不披露 DeepSeek 内部路线图、面试题、组织分工或唯一合格答案。