定义¶

Agent = Model + Harness。Harness 是"模型之外的一切"——上下文管理、工具调度、错误恢复、安全保障、缓存共享、并行协调。是 Prompt Engineering → Context Engineering 之后的第三代 Agent 工程范式。

关键要点¶

• 范式递进：Prompt Engineering（问什么）⊂ Context Engineering（看什么）⊂ Harness Engineering（整个系统）
• 乘法关系：模型 × Harness，不换模型仅改 Harness 可实现准确率 52.8% → 66.5%（LangChain Terminal Bench 2.0）
• Harness 两大部分：
• Environment（能干事）：工具、上下文压缩、缓存经济学、记忆体系、Side Query
• 约束/验证/纠正（不出错）：Fail-closed 默认值、多层权限、熔断器、错误恢复
• Claude Code 实践（51 万行 TypeScript）：
• 五层上下文压缩管线：Tool Result Budget → HISTORY_SNIP → Microcompact → CONTEXT_COLLAPSE → Autocompact。前面能搞定就不触发后面
• Prompt Cache 是架构约束而非性能优化：缓存边界物理标记，子 Agent 字节级一致共享缓存
• Side Query：把 LLM 调用变成到处撒的轻量操作，权限/记忆/摘要并行执行，延迟藏在主模型推理时间里
• 投机执行：覆盖层文件系统，用户打字时预测执行，接受→提升，拒绝→删除
• 多 Agent 是能力分区而非角色扮演（Capability-based 身份定义比角色提示词更硬性、更可审计）
• 六条核心设计原则： 1. Cache 经济学是架构约束（→ 2026-04 OpenClaw 政策实证：第一方相对第三方的 prompt cache hit rate 优势是结构性成本差，决定了 Anthropic 必然撤销第三方 OAuth piggyback，详见 platform-layer-collapse "上游撤 OAuth piggyback"段） 2. 分层处理不同保质期信息 3. 并行化一切可并行的 LLM 调用 4. 熔断器要到处放 5. 错误不要过早暴露（静默升级、消息扣留、模型降级） 6. 安全默认值必须保守（Fail-closed）
• 记忆选 Markdown 而非向量数据库：透明可编辑、原生 Git、与文件系统总线天然集成——与 llm-wiki-pattern 的"人类可读优先"原则一致。写入边界见 auto-memory，长期维护见 auto-dream
• 生态护城河：定义范式 → 构建产品 → 产生数据 → 反馈模型 → 模型在自家范式下表现最好。"标准开放，最佳实现封闭"

实战案例：CREAO 全栈 Harness¶

CREAO（25 人 Agent 平台公司）用两个月实践了 Harness Engineering 的全部原则（见 ai-first-engineering）：

• 可读性即杠杆：统一为 monorepo，唯一原因是让 Agent 看到全部代码。碎片化代码库对 Agent 不可见，统一代码库是可读的
• 确定性流水线：六阶段 CI/CD 无可选步骤、无手动覆盖，Agent 可预测结果和推理失败
• 三通道 AI 审查：每个 PR 触发 Claude Opus 4.6 三次并行审查（质量/安全/依赖），审查门控而非建议
• 自愈循环：Claude Sonnet 每日查 CloudWatch → 分流引擎 9 维评分 → 自动 Linear 工单 → 修复后自动关闭
• 结果：99% 代码由 AI 编写，每天 3-8 次生产部署

OpenAI 2026-02 提出 Harness Engineering 概念时，CREAO 已独立到达同一结论：工程团队的首要工作不再是写代码，而是让 Agent 能有效工作。当出错时，修复不是"更努力"，而是"缺什么能力，如何让 Agent 可读可执行"。

Harness 两层定义（用户层 vs 平台层）¶

CREAO Peter 在 2026-04 Founder Park 访谈中给 Harness 加了一个分层框架：

很多公司停留在第一层——把 Harness 能力开放给用户去自定义。CREAO 主张第二层才是核心。

iOS vs Android 类比¶

• Android 模式（OpenClaw 等开源 agent 框架）：开放可自定义但高度碎片化——用户搭 agent 系统时太多选择（数据库选 SQL 还是非关系型？memory 用哪种？），结果每个人系统都不稳定
• iOS 模式（CREAO / Claude Code 后端）：掌控整个 agent 架构（数据库选择 / 文件系统设计 / memory 系统 / connector 与 agent 协议全部由我们定义）——不给用户随意自定义权限，但承诺结果可靠流畅可稳定复现

"做到最后就是对整个硬件系统的掌控（GPU / 推理速度优化）——封闭系统才有的优势。"

对 sentino-agent Standalone Agent 形态的直接含义：当前"用户填 prompt + 选工具 + 设触发条件"是第一层 Harness。如果要上规模可靠性，需要把 Standalone Agent 运行环境（sandbox / 工具版本 / memory / cache）都封闭定义——但与 agent-tool-design "逃生工具"原则有矛盾，需要权衡 iOS 风格的可靠性 vs Android 风格的灵活性。

"环境稳定 > 智商高" 核心论断¶

CREAO 给 Harness 价值的定量描述：

环境的稳定、基础设施的能力，基本上就可以把 AI 能力从 50 分提到 90 分。剩下那 10 分才是真正有追求的人才需要去做的事。

这条把 harness-engineering "Agent = Model × Harness"乘法关系给出了当前阶段的具体分量分配——Harness 占 50→90 那 40 分，模型才占最后 10 分。

含义： - 大多数 AI 产品的瓶颈不是模型不够智商，是环境不稳定（sandbox / 工具 / memory / 并发隔离） - 大多数普通人工作不复杂——文档高阶操作（总结 / 分类 / 打标 / 可视化，几乎就这四种类型）。这种任务对模型智商要求不高，对环境稳定性要求极高 - 商业化的甜蜜区已被收窄——基本是短暂但高频发生的重复性任务，需要稳定环境而非复杂智能 - 真正需要长时间执行的单一任务很少，更多是长时间的多次工作（投资人大汇报 = 拆解很多小任务）

"今天有多少人完全利用到了大模型所有的智商？很少。"

对 Sentino 的应用：Sentino 当前讨论 LLM 选型 / 模型质量比较时，应该意识到模型层差异在大多数任务上是 10 分之内的差异，Harness 层（环境稳定性 / 工具可靠性 / memory 质量）才是 40 分级的杠杆。这条与 sentino-memex "记忆质量直接决定用户留存"判断同源。

反向印证：vibe coding 缺 Harness 的症状¶

腾讯研究院 2026-04 vibe-coding-creator-motives 一线访谈给出了 Harness Engineering 必要性的反向实证——vibe coding 平台普遍缺 Harness 中后端环节：

• AI 单系统强、多系统弱：开发者反复反映"单个系统 AI 写得很好，但要把多个系统串联起来协同工作，AI 经常顾此失彼"——印证 Harness 不只是模型加 prompt，必须有 agent-runtime-architecture Layer 4-6（Tool Runtime / Permission / Task）的运行时抽象
• 80% 时间在 debug：反复跟 AI 说"那个功能没实现"或"你把上一个功能改坏了"——AI 搞出来的 bug 基本都是隐式的，需要丰富工程经验定位。这是缺 Harness 错误恢复 / 静默升级机制的具体后果
• 作品提交率 6%：测试阶段 AI 游戏开发平台上，最终提交完整作品的数量只有总人数的 6%。从"能跑通"到"能交付"中间整片是 Harness 工程能力——架构师 / 操作员分工（→ ai-first-engineering）在普通 vibe coder 身上没有，所以掉率极高

这条反向实证给 Harness Engineering 增加了一个推论：Harness 能力的有无决定 AI 创作能力的杠杆倍数。专业团队（CREAO）+ Harness = 99% 代码 AI 写、每天 8 次部署；普通用户没有 Harness 就只能停在玩具阶段。

"Thinking tools" 不是 "Mechanical tools"：AI 工具的新分类轴¶

Linear CEO Karri Saarinen 在 2026-04-26 X 长文《Some Notes on AI》给 Harness Engineering "工具影响工作流" 命题加了一层关键分类：

"Tools always steer and influence workflows. They always show you the path. AI tools are different because they are thinking tools, not just mechanical tools. Their ability to steer you and your work is greater than before."

双向 steer 关系：传统工具是 mechanical tools——你用 Photoshop 工具栏决定你怎么 P 图，但工具栏不会反过来"建议"你接下来想画什么。AI 工具是 thinking tools——你 prompt AI 决定 AI 输出什么，但 AI 输出反过来 steer 你接下来怎么想（你看到 AI 写的代码后会修改你下一步的设计判断）。

"There is a valid workflow where you do not fight the AI. You let it pull you. This is essentially what vibe coding done well can be: following the grain of the tool, moving quickly, accepting that the model has a direction and using that momentum."

Saarinen 给 vibe coding 一个不带贬义的合法定义——接受 AI 的方向使用其动能，而不是对抗它。但他立刻给反向警告：

"Without thinking, direction, or a plan for what you actually want to achieve, you may end up doing whatever comes easily. ... potentially let the AI steer you toward what is easiest rather than what matters."

对 Harness 设计的具体含义：Harness 设计 thinking tools 时必须主动决定"工具应该 steer 用户朝哪个方向"——这不是中立设计选择，是产品哲学决定。Claude Code 给 todo 工具默认任务清单格式 = steer 用户朝结构化思考方向；Linear 给 issue 默认 acceptance criteria = steer 用户朝"先想清楚成功标准"方向。Tool default 不是 default 而是 steering。

这与 agent-tool-design "工具必须跟随模型能力演进"是同一原则的两面——工具既影响模型行为（agent 视角），也影响人类用户行为（thinking tools 视角）。

从 CLI 工具到应用平台：层级坍缩的技术基础¶

Claude Code 的工程架构不只是"更好的编程助手"，而是层级坍缩的技术基础设施：

• 执行层完整：文件编辑、命令执行、Git 操作、任务编排——完整开发流程能力，不是代码生成
• 常驻 Agent 方向：KAIROS（后台守护进程 + 内存整合）、ULTRAPLAN（云端规划卸载）指向"持续运行的 Agent 计算模型"
• 2026-04 泄露：全栈 Vibe Coding 平台——文本构建应用 + 实时预览 + 一键部署 + 数据库/认证/分析内置
• 战略含义：Anthropic 的产品演进路径（Model → Code → Cowork → Computer Use → Multi-agent）本质上是在重建"AI 原生的软件执行环境"，而非增强现有软件

这解释了生态护城河策略的终局：当 Harness 本身成为完整的应用构建与运行系统，中间层平台（Lovable、Bolt、Base44）的价值被压缩为纯 UI 封装。

相关概念¶

• auto-memory — 记忆系统的写入边界（什么跨会话才值得留下）
• auto-dream
• llm-wiki-pattern
• agent-tool-design
• seal-architecture
• 人机协作
• orchestration-free-agents — 文件系统 + Git 替代编排框架的实战案例
• mcp-protocol — MCP 是 Harness 工具层的标准化实现
• ai-agent-moats — 数据飞轮正是生态护城河策略的商业表达
• platform-layer-collapse — Harness 架构是层级坍缩的技术基础
• individual-vs-institutional-ai — Context Engineering 在组织视角的表达
• ai-first-engineering — CREAO 全栈实战：Harness Engineering 原则的完整落地
• claude-agent-sdk — Claude Agent SDK：Harness 的产品化交付物，将 Claude Code 运行时封装为可嵌入库
• agent-runtime-architecture — 七层三链模型：Harness 内部架构的源码级验证
• palantir-ontology — Palantir Ontology：Harness 的企业级实现（语义层=上下文，动力层=工具，治理层=权限）
• cloudflare-mesh — Cloudflare Mesh：Harness Environment 层的网络基础设施，Agent 安全访问私有资源
• vibe-coding-creator-motives — 反向实证：缺 Harness 时 AI 创作的卡点（单系统强多系统弱 + 80% 时间 debug + 6% 完成率）
• pivot-speed-as-moat — Harness 是组织效率的工程基础，pivot 速度是组织效率的输出
• agora-rtsa-sdk — Environment 层工具边界设计的范例：把"网络抗弱网"封进 SDK，把"采集 + 编解码"留给设备，是 Tool/Environment 边界划分的工程样本
• embedded-firmware-layering — Sentino 嵌入式领域同构应用：rino_interface 适配层 import/export = Driving/Driven Port，把核心做成黑盒、把环境做成可替换层。组织级架构判断的一致性证据
• process-data-vs-output-data — Harness 是基础设施层（让 agent 跑起来），过程数据是训练层（教 agent 怎么用环境）——agent 工程的两面
• amphiflow-pattern — iOS 外壳 + Android 内核的混合形态，给 Harness 两层定义之外加了"workflow + agent 自动切换" 第三种取舍维度
• research-preview-pattern — Anthropic Kat Wu 视角："大部分加速来自流程和团队文化"——Harness 原则在产品发布层的延伸（"移除一切阻碍"从模型运行扩展到功能上线）
• expertise-paradox — Saarinen 视角：AI 工具是 thinking tools 不是 mechanical tools，且专家 vs novice 看到的 Harness 是不同的——专家看到 slop 与 steering 需求，novice 看到 magic
• individual-vs-institutional-ai — Saarinen "AI 公司是 backend 类、UNIX 风格 composability" 给 Harness 在不同 domain 的形态判断加了取舍维度