如何基于Harness Engineering设计一个Agent OS

基于 Harness Engineering 的 Agent OS 设计

1. 结论先行

Harness Engineering 不是一个长期成熟的学术标准术语，而是 2026 年初在一线 agent 工程圈快速成形的实践概念。综合 OpenAI、Anthropic、Mitchell Hashimoto、LangChain 等一手材料，可以把它定义为：

不是只优化模型提示词，而是系统性地设计 agent 的运行环境、工具接口、状态结构、验证机制、反馈回路与约束边界，把"偶尔聪明"的模型改造成"持续可靠"的执行系统。

如果用一句话概括：

Prompt 决定 agent 说什么，context 决定 agent 知道什么，harness 决定 agent 如何稳定地完成任务。

因此，agent os 的核心不应该是"一个更强的模型外壳"，而应该是一个最小但完整的执行操作系统：

让 agent 永远在一个可观测、可回滚、可验证的环境里行动。
让 agent 尽量只接触"足够的上下文"，而不是"全部上下文"。
让每一次失败都沉淀成规则、工具、测试或记忆，避免重复犯错。
让人类从"直接写代码/做操作"升级为"定义目标、设置边界、批准关键决策"。

2. 全网调研后的定义与原理

2.1 术语来源与演进

2026-02-05，Mitchell Hashimoto 在《My AI Adoption Journey》中写到，他把这种做法称为 harness engineering：每当 agent 犯错，就工程化一个方案，让它不再重复同类错误。
2026-02-04，OpenAI 在《Unlocking the Codex harness》中把 Codex harness 定义为支撑不同客户端表面的同一套"agent loop and logic"。
2026-02-11，OpenAI 在《Harness engineering: leveraging Codex in an agent-first world》中进一步把重点从"写代码"转向"设计环境、表达意图、构建反馈回路"。
2025-09-29，Anthropic 在《Building agents with the Claude Agent SDK》中明确提出：give your agents a computer，并把文件系统、命令行、上下文压缩、工具调用视为 agent harness 的关键基础。
2026-02-17，LangChain 在《Improving Deep Agents with harness engineering》中给出量化证据：固定模型不变，仅改 harness，就把 deepagents-cli 在 Terminal Bench 2.0 上从 52.8 提升到 66.5。

2.2 我对"定义"的综合归纳

下面这段是基于上述来源的综合推断，不是单一原文表述：

Harness Engineering = Agent Runtime Engineering + Context Shaping + Verification Loops + Constraint Encoding + Operational Feedback

也就是说，harness 不是某一个提示词文件，也不是某一个工具调用层，而是 agent 的完整"执行骨架"：

任务如何进入系统
上下文如何被发现、压缩、淘汰
工具如何暴露、约束、回传结构化结果
执行动作后如何验证
失败后如何恢复、重试、升级
经验如何变成持久规则

2.3 共识最强的五条原理

原理 A：人类负责 steering，agent 负责 execution

OpenAI 在 2026-02-11 的文章里明确提出：Humans steer. Agents execute.

这意味着系统设计要默认：

人类定义目标、边界、验收条件、优先级
agent 做检索、计划、调用工具、生成变更、执行验证
只有高风险决策、权限升级、冲突裁决才升级给人

原理 B：给 agent 一个"电脑"，而不是只给它一个聊天框

Anthropic 的核心经验是：如果 agent 要像人一样工作，就要给它文件系统、终端、编辑能力、搜索能力和迭代空间。

因此，agent os 的底层单位不是"一次 completion"，而是"一次带工具、状态和副作用控制的执行回合"。

原理 C：上下文不是越多越好，而是越可导航越好

OpenAI 强调"agent legibility"，Anthropic 也把文件结构视作 context engineering 的一部分。真正重要的不是把所有文档塞给模型，而是让系统具备：

稳定入口
逐层发现
结构化索引
可压缩的历史
与任务相关的最小上下文集

原理 D：性能提升很多来自 harness，而不是模型更换

LangChain 的实验很关键：模型不变，只改 system prompt、tools、middleware、trace analysis 和验证逻辑，就能显著提升 benchmark 表现。

这说明对于 agent os 而言，最有复利的投资常常是：

更好的工具接口
更严格的验证器
更细粒度的追踪
更稳定的失败恢复
更可积累的经验回写

原理 E：失败必须变成系统资产

Mitchell Hashimoto 的说法最直白：发现错误，就工程化修复，让系统以后不再犯。

所以一个成熟的 agent os 不应把失败仅视为日志，而应把失败转化为：

新的 guardrail
新的测试
新的 AGENTS 规则
新的工具 schema
新的 memory 条目
新的 escalation policy

3. 设计目标：一个"简约且强大"的 Agent OS

3.1 简约的含义

简约不是功能少，而是内核少、抽象稳、接口清晰。

我建议把 agent os 压缩为 6 个核心抽象：

Task：用户目标与验收标准
Context：本轮可见信息集合
Tool：可调用能力
Run：一次可追踪执行
Check：验证器/评审器/停止条件
Memory：沉淀后的长期经验

除了这 6 个抽象，其他东西都尽量作为插件或策略存在。

3.2 强大的含义

强大不是"能做很多事"，而是"在复杂任务里能持续收敛"。

所以强大要体现在 5 个能力：

长任务可持续执行
错误可诊断、可恢复
成本和权限可控
多 agent 可协作但不混乱
系统会越跑越稳

4. Agent OS 总体架构

User / Scheduler / API
Intent Gateway
Planner
Context Engine
Run Kernel
Tool Bus
Verifier Loop
Memory Engine
Human Escalation
Observability

5. 六大核心模块

5.1 Intent Gateway

职责：

接收用户请求、定时任务、外部事件
标准化为 TaskSpec
补齐目标、约束、预算、截止时间、风险级别

最小输入结构：

json 复制代码

{
  "goal": "要达成什么",
  "acceptance": ["如何算完成"],
  "constraints": ["权限/成本/时间/风格限制"],
  "budget": {"tokens": 0, "money": 0, "time_sec": 0},
  "risk": "low|medium|high",
  "escalation_policy": "何时找人"
}

设计原则：

不让模糊任务直接进入执行层
先把"做什么"和"做到什么程度算成功"说清楚

5.2 Planner

职责：

把目标拆成阶段
判断串行/并行
选择单 agent 还是多 agent
产出可验证的 Plan

关键点：

Planner 只做"足够计划"，不做过度预规划
每一步都必须绑定可验证产物

示例：

yaml 复制代码

steps:
  - id: discover
    output: problem_model
    check: source_coverage >= 0.8
  - id: design
    output: architecture_doc
    check: principles_mapped == true
  - id: prototype
    output: runnable_scaffold
    check: smoke_test_pass == true

5.3 Context Engine

职责：

动态装配当前步骤所需的最小上下文
管理短期记忆、工作记忆、长期记忆
处理摘要、压缩、淘汰、索引

我建议采用三层上下文：

Working Set
当前步骤必需的文件、网页、记录、变量
Episode Memory
当前任务已发生的重要决策、失败、产物
Semantic Memory
跨任务复用的规则、偏好、模式、历史坑点

核心规则：

默认拉最少，不默认拉全部
大上下文通过检索和摘要按需展开
历史对话不直接堆满窗口，而是压缩成结构化纪要

5.4 Tool Bus

职责：

统一注册工具
给每个工具定义 schema、权限、成本和副作用等级
返回结构化结果而不是自由文本

每个工具都应该有：

name
input_schema
output_schema
side_effect_level
timeout
retry_policy
compensation_action

工具按风险分三级：

Read
搜索、读取、查询、截图、解析
Write
写文件、发消息、创建工单、提交 PR
Critical
支付、生产变更、删库、发版、权限变更

系统默认：

Read 自动执行
Write 根据策略自动或半自动
Critical 必须人工批准

5.5 Run Kernel

这是整个 agent os 的内核。

职责：

驱动 agent loop
保存状态机
控制预算
管理暂停、恢复、取消、回滚
执行多 agent 调度

推荐状态机：

text 复制代码

READY
-> GATHER
-> PLAN
-> ACT
-> CHECK
-> REPAIR
-> COMPLETE
-> ESCALATE
-> ABORT

最小循环：

装配当前步骤上下文
选择一个动作
调用工具或产出变更
运行验证器
成功则推进，失败则修复或升级
记录轨迹和经验

5.6 Verifier Loop

这是 harness engineering 最关键、也最容易被低估的部分。

验证器至少分四类：

Syntax Checks
schema 校验、格式检查、类型检查
Execution Checks
单测、集成测试、命令执行、页面驱动
Semantic Checks
是否满足需求、是否覆盖边界条件、是否引用充分
Policy Checks
权限、隐私、预算、合规、风格、架构边界

原则：

先机器验证，再人工评审
每一步都应有 cheap check
高成本验证只在必要节点执行

6. Memory Engine：让系统越跑越稳

内存不是聊天记录仓库，而是"可操作的经验系统"。

我建议只保留四类长期记忆：

Rules
明确规则，例如"遇到生产写操作必须审批"
Patterns
成功做法，例如"调研类任务先收集来源，再出结构化综述"
Pitfalls
已知坑点，例如"某 API 返回分页字段不稳定"
Preferences
用户和团队偏好，例如"答案默认中文、文档优先 Markdown"

经验回写规则：

高频错误，升级为 rule
高频修复，升级为 pattern
高损失事故，升级为 guardrail + check
个人习惯，升级为 preference

7. 最小但强的多 Agent 协作模型

不要一开始就做复杂 agent society。

最小可行模型建议只有四种角色：

Conductor
总控，负责任务分解、调度和升级
Worker
执行具体子任务
Verifier
对输出做检查、复核和对抗评估
Curator
负责把经验沉淀进 memory/rules/tests

最重要的约束：

Worker 不直接改系统规则
Verifier 不直接批准 critical action
Curator 不直接执行高风险动作
Conductor 只掌控流程，不吞掉全部执行细节

8. 一套真正简约的内核 API

如果我要把它做成一个可实现的 agent os，我会把核心 API 收敛到下面这些：

ts 复制代码

type TaskSpec = {
  goal: string;
  acceptance: string[];
  constraints: string[];
  risk: "low" | "medium" | "high";
  budget: { tokens: number; money: number; timeSec: number };
};

type PlanStep = {
  id: string;
  instruction: string;
  expectedArtifact: string;
  checks: string[];
};

type ToolCall = {
  tool: string;
  input: unknown;
  risk: "read" | "write" | "critical";
};

type CheckResult = {
  pass: boolean;
  score?: number;
  issues: string[];
  nextAction: "proceed" | "repair" | "escalate" | "abort";
};

interface AgentOS {
  submitTask(task: TaskSpec): Promise<string>;
  getRun(runId: string): Promise<RunState>;
  approve(runId: string, actionId: string): Promise<void>;
  resume(runId: string): Promise<void>;
  abort(runId: string): Promise<void>;
}

这套 API 刻意不复杂，因为真正复杂的地方应放在策略层，而不是内核接口层。

9. 推荐的默认运行策略

9.1 默认执行公式

Goal -> Plan -> Minimal Context -> Action -> Check -> Repair -> Learn

9.2 默认升级条件

以下情况直接人工升级：

触发 critical 工具
连续 3 次修复失败
预算超 80%
检测到高不确定性但高影响决策
目标和约束发生冲突

9.3 默认记忆写入条件

同类错误出现 2 次以上
某个人工评审意见可泛化
某条验证逻辑能防止未来事故

10. 为什么这个设计"简约且强大"

简约

只有 6 个核心抽象
单一主循环，避免分散执行模型
策略与内核分离，便于迭代
高风险能力统一走工具风险分级

强大

通过 verifier loop 把输出变成可收敛系统
通过 memory engine 把失败转成复利资产
通过 context engine 支撑长任务而不被上下文拖垮
通过 run kernel 支撑暂停、恢复、多 agent、审批、回滚

11. 落地顺序

不要一口气做完全部模块。推荐分四阶段：

阶段 1：单 agent 内核

只做：

TaskSpec
Planner
Context Engine 基础版
Tool Bus 基础版
Run Kernel
Verifier Loop 基础版

目标：

让一个 agent 稳定完成研究、写作、代码修改这三类任务

阶段 2：经验沉淀

增加：

Rules / Pitfalls / Preferences memory
自动摘要与失败归因
规则命中与检查器联动

目标：

让系统开始"少犯重复错误"

阶段 3：多 agent 协作

增加：

Conductor / Worker / Verifier / Curator
子任务并行
结果汇总与冲突消解

目标：

提升复杂任务吞吐

阶段 4：自治运营

增加：

周期性巡检 agent
文档清理 agent
回归测试 agent
成本和性能观测面板

目标：

让系统具备"后台常驻运维"能力

12. 对项目的直接建议

如果你要做一个真正好用的 agent os，我建议你坚持三条铁律：

不要先做"万能 agent"，先做"可验证 agent"。
不要先堆 memory，先定义什么信息值得长期保留。
不要先优化 prompt，先补齐工具、检查器和失败回写。

换句话说：

agent os 的第一性原理不是"生成"，而是"受控执行"。

13. 可直接作为产品宣言的一句话

Agent OS 是一个把目标、上下文、工具、验证与经验沉淀编织成闭环的执行系统；它让人负责方向，让 agent 负责推进，让失败负责进化系统。

14. 结合 CoPaw 工程代码的补充设计样例

CoPaw 很适合作为一个接近真实产品形态的参照物，因为它不是只做"单回合 agent demo"，而是在工程上把 hook、memory、tool guard、skills、multi-agent communication 串起来了。

这里我不把 CoPaw 当作唯一标准，而是把它视作一个很好的"中间样本"：

它已经体现了 harness engineering 的多个关键思想
它的实现仍然相对简洁，容易抽象成 agent os 模式
它更偏"可运行产品"而不是"论文式框架"

14.1 从 CoPaw 可提炼出的 5 个工程模式

模式 1：用 Hook 做"轻量内核扩展"，而不是把逻辑全塞进主循环

CoPaw 在 react_agent.py 里注册了至少两类关键 hook：

BootstrapHook
MemoryCompactionHook

对应代码：

src/copaw/agents/react_agent.py
src/copaw/agents/hooks/bootstrap.py
src/copaw/agents/hooks/memory_compaction.py

这说明一个很重要的设计原则：

主循环要稳定，策略性增强尽量通过 hook 挂载。

对 agent os 的启发是：

Run Kernel 只负责状态推进
Hook 负责把"启动引导""上下文压缩""安全预检查""失败归因"等横切逻辑插入执行点

我建议在 agent os 里预留四类 hook：

ts 复制代码

type HookType =
  | "pre_plan"
  | "pre_reason"
  | "pre_act"
  | "post_check";

这样能把系统做得既简洁又可演化。

模式 2：把"首次启动引导"做成显式引导机制

CoPaw 的 BootstrapHook 会在首次交互时检查工作目录中的 BOOTSTRAP.md，然后把引导内容 prepend 到第一条用户消息中，并写入 .bootstrap_completed 防止重复触发。

这背后的原理非常值得借鉴：

用户偏好和 agent 身份不是天然存在的
如果不显式建立，系统会长期处于"弱个性、弱边界、弱协作"的状态

因此在 agent os 里，我建议引入：

Bootstrap Contract

最小样例：

yaml 复制代码

bootstrap:
  identity:
    role: "Research OS"
    tone: "concise, analytical"
  user_preferences:
    language: "zh"
    output_default: "markdown"
  operating_rules:
    - "高风险写操作先审批"
    - "先检索再结论"

运行逻辑：

新 workspace 首次运行时加载 BOOTSTRAP.md
生成 BootstrapState
将稳定偏好写入 Preferences Memory
只把本轮相关部分注入上下文

这会比"把所有偏好直接塞进 system prompt"更稳。

模式 3：把"上下文过长"当成操作系统问题，而不是模型问题

CoPaw 的 MemoryCompactionHook 不是等模型失败后再处理，而是在 pre_reasoning 阶段提前计算 token 使用情况，并在接近阈值时：

保留 system prompt
保留 recent messages
压缩更早的历史
更新 compressed summary
只在必要时触发

这正是一个成熟 agent os 该有的姿势：

大上下文不应该靠"更大的窗口"硬扛，而要靠分层记忆和自动压缩。

基于 CoPaw，我建议把 Context Engine 细化为：

yaml 复制代码

context_layers:
  - system_contract
  - active_step_context
  - recent_dialogue
  - compressed_episode_summary
  - retrievable_long_term_memory

并定义一个压缩策略样例：

yaml 复制代码

compaction_policy:
  trigger:
    token_usage_ratio_gte: 0.72
  preserve:
    - system_contract
    - latest_8_messages
    - open_approvals
    - unresolved_failures
  compact:
    - old_dialogue
    - verbose_tool_results
  produce:
    - episode_summary
    - pending_threads
    - known_constraints

这类策略比"超过上限就摘要"更接近操作系统级设计。

模式 4：把工具安全做成 Guard + Approval Queue，而不是一句"请谨慎"

CoPaw 的 ToolGuardMixin 很有代表性。它在 _acting 阶段拦截工具调用，并区分：

denied：直接拒绝
guarded：进入 guardian 检查
preapproved：已批准则跳过二次审查
always_run guardians：即使不是高风险工具也可执行通用安全检查

同时，它还有：

pending approval 状态
/approve 人工批准入口
sibling tool calls replay queue
denied tool_result 写回 memory，保证 agent 看到"为什么没执行"

这对 agent os 很关键，因为它说明：

真正可靠的权限控制，不是"调用前弹窗"，而是"把安全判断嵌进 agent loop"。

我建议直接借鉴成如下内核设计：

ts 复制代码

type GuardDecision =
  | { kind: "allow" }
  | { kind: "deny"; reason: string }
  | { kind: "approval"; queueId: string; reason: string };

type Guardian = {
  name: string;
  appliesTo: string[];
  evaluate(call: ToolCall, ctx: RunContext): Promise<GuardDecision | null>;
};

典型 guardian：

PathGuardian
检查是否命中敏感目录
CommandGuardian
检查 shell 是否包含危险命令
BudgetGuardian
检查是否超 token/金钱/时间预算
PolicyGuardian
检查是否违反隐私/合规/团队约束

模式 5：把能力扩展做成 skill 目录，而不是内嵌大而全工具集

CoPaw 的 agent 会从 workspace 中发现并注册 skills，同时内置 skill 目录也提供了：

cron
browser_*
guidance
multi_agent_collaboration
各种 channel / document / office 类 skill

这件事的意义是：

系统核心不需要知道所有能力
能力通过 skill package 以工作区方式生长
不同 agent 可以加载不同 skill 集合，形成职责分化

所以 agent os 更合理的形式不是"大工具箱"，而是：

Kernel + Tool Bus + Skill Runtime

最小 skill manifest 样例：

yaml 复制代码

name: multi_agent_collaboration
description: "Route tasks to specialized agents when needed"
entry: "./SKILL.md"
permissions:
  - "agent.chat"
  - "agent.list"
triggers:
  - "need_external_expertise"
  - "explicit_delegate_request"

14.2 可直接映射到 Agent OS 的设计样例

下面这些样例不是对 CoPaw 的复述，而是把 CoPaw 的工程做法转成 agent os 可直接采用的规格。

样例 A：Bootstrap Contract

用途：

初始化 agent 身份
建立用户偏好
固化高层行为规则

yaml 复制代码

bootstrap_contract:
  files:
    - "BOOTSTRAP.md"
    - "AGENTS.md"
  on_first_run:
    - load_bootstrap
    - derive_preferences
    - persist_preferences
    - set_bootstrap_completed

对应 CoPaw 参照：

src/copaw/agents/hooks/bootstrap.py

样例 B：Context Compaction Pipeline

用途：

长任务中自动压缩上下文
保留最近动作和系统约束
把旧历史转成结构化 summary

yaml 复制代码

pipeline:
  when: "before_reasoning"
  check:
    token_ratio_gte: 0.72
  preserve:
    - system_prompt
    - recent_messages
    - pending_approvals
  compact:
    - tool_results
    - aged_dialogue
  output:
    compressed_summary:
      sections:
        - decisions
        - artifacts
        - failures
        - open_questions

对应 CoPaw 参照：

src/copaw/agents/hooks/memory_compaction.py
src/copaw/agents/memory/memory_manager.py

样例 C：Guarded Tool Execution

用途：

为高风险动作加审批
让 agent 理解"为何被拒绝"
避免并行工具调用时的状态竞争

yaml 复制代码

guard_flow:
  on_tool_call:
    - classify_risk
    - run_guardians
    - if deny: return_guarded_tool_result
    - if approval: enqueue_pending_action
    - if approved: replay_tool_call
    - write_result_to_memory

对应 CoPaw 参照：

src/copaw/agents/tool_guard_mixin.py

样例 D：Multi-Agent Delegation as Skill

CoPaw 的 multi_agent_collaboration skill 没有把多 agent 变成重型编排系统，而是采用非常实用的模式：

先列出可用 agents
再显式指定 from-agent 和 to-agent
用 session-id 保留双边上下文
避免消息回环

这给 agent os 的启发是：

多 agent 协作的第一步不是复杂调度器，而是显式、可追踪、可复用会话的委派协议。

可直接设计成：

ts 复制代码

type AgentDelegation = {
  from: string;
  to: string;
  task: string;
  sessionId?: string;
  reason: string;
  expectedReturn: "answer" | "artifact" | "review";
};

委派规则：

默认不委派
只有能力不匹配、上下文不在本 agent、或用户明确要求时才委派
委派必须有 expectedReturn
同一 agent 不要形成消息循环

对应 CoPaw 参照：

src/copaw/agents/skills/multi_agent_collaboration/SKILL.md

样例 E：Hybrid Memory Search

CoPaw 的 MemoryManager 同时支持：

message compaction
summary generation
vector search
full-text search

这说明长期记忆系统不应只有一种检索方式。

因此 agent os 可采用：

yaml 复制代码

memory_search:
  hot_path:
    source: in_memory
    use_for: current_run
  semantic_path:
    source: vector_index
    use_for: related_cases
  lexical_path:
    source: full_text_index
    use_for: exact_fact_lookup

这样可以避免"语义检索找不到精确命令"和"全文检索找不到近义经验"的问题。

14.3 基于 CoPaw，我会如何修正前面的 Agent OS 设计

经过对 CoPaw 代码的补充观察，我会对前文方案做 4 个增强：

增强 1：在 6 核心抽象之外，增加 `Hook`

之前的 6 个抽象已经足够简约，但如果完全不显式建模 Hook，很多横切能力会被迫塞进 Run 或 Tool。

所以我建议把内核抽象升级为 7 个：

Task
Context
Tool
Run
Check
Memory
Hook

增强 2：把 `Approval Queue` 升级成一等公民

CoPaw 的经验说明，审批不是 UI 层附属功能，而是运行时的一部分。

因此 agent os 应有独立状态：

text 复制代码

ACT -> GUARD -> PENDING_APPROVAL -> REPLAY -> CHECK

这比简单的 ACT -> CHECK 更真实。

增强 3：把 Skill Runtime 放到 Tool Bus 旁边

前文提到插件化，但 CoPaw 提醒我们，skill 不只是"额外工具"，它还是：

行为约定
使用说明
工作流模板
跨 agent 协作协议

所以系统拓扑更合理的写法是：
User / Event
Intent Gateway
Planner
Context Engine
Run Kernel
Hook Runtime
Tool Bus
Skill Runtime
Verifier Loop
Memory Engine
Approval Queue

增强 4：把"上下文压缩"定义成默认后台能力

CoPaw 不是在用户命令 /compact 时才压缩，而是支持自动 compaction。

这对 agent os 的启发很明确：

memory compaction 应是后台默认能力
手动 /compact 只是显式入口，不应是唯一入口

14.4 最终补充结论

如果说前半篇文档给的是 Harness Engineering -> Agent OS 的原理抽象，那么 CoPaw 补上的，是"这些原理如何在真实工程里长成产品骨架"。

从 CoPaw 可以得到一个非常实用的判断：

一个好用的 agent os，不是把所有能力塞进模型，而是把启动引导、上下文压缩、技能加载、权限审批和多 agent 委派都做成运行时机制。

换句话说，真正值得抄的不是某个 prompt，而是这些机制：

Bootstrap Contract
Hook Runtime
Compaction Pipeline
Guard + Approval Queue
Skill Runtime
Delegation Protocol
Hybrid Memory Search

15. 主要来源

以下为本次调研直接参考的一手或近一手来源：

OpenAI, Harness engineering: leveraging Codex in an agent-first world, 2026-02-11
https://openai.com/index/harness-engineering/
OpenAI, Unlocking the Codex harness: how we built the App Server, 2026-02-04
https://openai.com/index/unlocking-the-codex-harness/
Anthropic, Building agents with the Claude Agent SDK, 2025-09-29
https://claude.com/blog/building-agents-with-the-claude-agent-sdk
Mitchell Hashimoto, My AI Adoption Journey, 2026-02-05
https://mitchellh.com/writing/my-ai-adoption-journey
LangChain, Improving Deep Agents with harness engineering, 2026-02-17
https://blog.langchain.com/improving-deep-agents-with-harness-engineering/
AgentScope AI, CoPaw GitHub repository, accessed 2026-03-26
https://github.com/agentscope-ai/CoPaw

16. 哪些内容是事实，哪些是我的设计推断

事实层：

Harness engineering 一词在 2026 年 2 月前后被明确提出并迅速传播。
OpenAI、Anthropic、LangChain 都在强调：agent 的效果高度依赖运行环境、工具、反馈与验证。
LangChain 提供了"只改 harness、不换模型也能大幅提分"的量化案例。

我的设计推断：

我把这些共识收敛成了一个 6 抽象、6 模块的 agent os 内核。
我主张以 Verifier Loop 和 Memory Engine 作为系统核心，而不是把模型或 prompt 放在中心。
我提出的角色分工、状态机、API 和 MVP 路线，是基于上述原理做的工程设计，不是现成标准。

如何基于Harness Engineering设计一个Agent OS

基于 Harness Engineering 的 Agent OS 设计

1. 结论先行

2. 全网调研后的定义与原理

2.1 术语来源与演进

2.2 我对"定义"的综合归纳

2.3 共识最强的五条原理

原理 A：人类负责 steering，agent 负责 execution

原理 B：给 agent 一个"电脑"，而不是只给它一个聊天框

原理 C：上下文不是越多越好，而是越可导航越好

原理 D：性能提升很多来自 harness，而不是模型更换

原理 E：失败必须变成系统资产

3. 设计目标：一个"简约且强大"的 Agent OS

3.1 简约的含义

3.2 强大的含义

4. Agent OS 总体架构

5. 六大核心模块

5.1 Intent Gateway

5.2 Planner

5.3 Context Engine

5.4 Tool Bus

5.5 Run Kernel

5.6 Verifier Loop

6. Memory Engine：让系统越跑越稳

7. 最小但强的多 Agent 协作模型

8. 一套真正简约的内核 API

9. 推荐的默认运行策略

9.1 默认执行公式

9.2 默认升级条件

9.3 默认记忆写入条件

10. 为什么这个设计"简约且强大"

简约

强大

11. 落地顺序

阶段 1：单 agent 内核

阶段 2：经验沉淀

阶段 3：多 agent 协作

阶段 4：自治运营

12. 对项目的直接建议

13. 可直接作为产品宣言的一句话

14. 结合 CoPaw 工程代码的补充设计样例

14.1 从 CoPaw 可提炼出的 5 个工程模式

模式 1：用 Hook 做"轻量内核扩展"，而不是把逻辑全塞进主循环

模式 2：把"首次启动引导"做成显式引导机制

模式 3：把"上下文过长"当成操作系统问题，而不是模型问题

模式 4：把工具安全做成 Guard + Approval Queue，而不是一句"请谨慎"

模式 5：把能力扩展做成 skill 目录，而不是内嵌大而全工具集

14.2 可直接映射到 Agent OS 的设计样例

样例 A：Bootstrap Contract

样例 B：Context Compaction Pipeline

样例 C：Guarded Tool Execution

样例 D：Multi-Agent Delegation as Skill

样例 E：Hybrid Memory Search

14.3 基于 CoPaw，我会如何修正前面的 Agent OS 设计

增强 1：在 6 核心抽象之外，增加 Hook

增强 2：把 Approval Queue 升级成一等公民

增强 3：把 Skill Runtime 放到 Tool Bus 旁边

增强 4：把"上下文压缩"定义成默认后台能力

14.4 最终补充结论

15. 主要来源

16. 哪些内容是事实，哪些是我的设计推断

增强 1：在 6 核心抽象之外，增加 `Hook`

增强 2：把 `Approval Queue` 升级成一等公民