Harness 机制与通用 Agent 工作执行系统

0. 问题拆解与结论

Agent 如何通过 Harness，把模型能力变成可控、可验证、可复用的工作执行系统？

这个问题可以拆成三层：

  1. 架构层：Harness 位于模型与真实工作环境之间，负责上下文、工具、权限、执行、观察、恢复、验证和长期状态。
  2. 原理层：模型生成意图和动作，Harness 把动作变成受控工具调用，并用证据闭环约束结果。
  3. 工程层：不同产品把控制重点放在不同位置，Codex 偏工作区执行，Claude Code 偏团队执行链治理，OpenClaw 偏本地多渠道 Gateway，Hermes 偏长期记忆和 Skill 学习。

关键结论

Harness 不是单一权限拦截器。它是 Agent 和真实工作环境之间的控制系统。它让 Agent 能处理代码、文档、合同、数据、浏览器、消息平台、定时任务、企业系统和多工具工作流，同时把每一步变成可审计、可恢复、可复用的执行轨迹。

Harness 内部原理机制图

1. Harness ：工程控制系统原理

1.1 Harness 解决的问题

裸模型只能根据输入生成文本或结构化意图。真实工作执行需要进入文件系统、浏览器、命令行、API、数据库、消息平台、文档系统和企业后台。没有 Harness，系统会面临四类工程风险：

风险 具体表现 Harness 的控制方式
上下文失真 模型看不到关键文件、合同条款、历史消息或工具输出 Context Builder 选择材料并压缩噪声
副作用失控 删除文件、发送消息、提交代码、调用生产 API Permission / Sandbox / Approval 限制动作
执行不可证 只给结论，没有命令输出、diff、来源或 trace Observation 和 Verification 保留证据
经验不可复用 每次任务都从零开始 Memory 保存事实，Skill 沉淀流程

1.2 核心模块

模块 作用 适用任务
Context Builder 决定当前任务需要看哪些材料 代码、文档、合同、网页、消息记录
Memory 保存长期事实、偏好、环境状态 个人偏好、团队规则、项目状态、客户上下文
Skill 保存可复用操作流程 合同审查、周报生成、数据分析、代码修复
Tool Adapter 把外部工具包装成可控能力 shell、文件、浏览器、MCP、Slack、数据库
Permission / Sandbox 判断动作能否执行，限制副作用 删除、发送、提交、修改、联网、调用 API
Execution 执行工具调用 运行命令、读写文件、浏览网页、发消息
Observation 收集输出、日志、错误、结果 测试结果、审查结论、API 返回、工具日志
Recovery 失败重试、降级、请求人工介入 工具失败、权限不足、上下文缺失
Verification 证明任务完成 测试、diff、来源证据、审核记录、trace

1.3 执行循环

Harness 的执行循环不是“模型思考一次然后执行一次”，而是持续的控制闭环：

  1. 用户目标进入系统。
  2. Harness 组装 Context。
  3. Agent 基于 Context 生成动作。
  4. Harness 检查权限和风险。
  5. Tool Adapter 执行工具。
  6. Observation 收集结果。
  7. Recovery 处理失败。
  8. Verification 验证完成。
  9. Memory / Skill 记录可复用经验。
%%{init: {"theme":"base","themeVariables":{"background":"#f8fafc","fontFamily":"Arial","lineColor":"#334155"}}}%%
flowchart TD
  Title("通用 Harness 执行循环<br/>模型能力 → 受控工作执行"):::title

  subgraph Stage1["🎯 阶段1 任务与上下文"]
    Goal("用户目标<br/>代码/文档/合同/数据/消息"):::start
    Context("Context Builder<br/>选择材料与压缩噪声"):::process
    Memory("Memory<br/>长期事实与偏好"):::storage
    Skill("Skill<br/>可复用流程"):::storage
  end

  subgraph Stage2["🧭 阶段2 动作与权限"]
    Action("Agent 动作<br/>计划/工具调用/参数"):::process
    Permission("Permission / Sandbox<br/>审批与副作用边界"):::decision
    Blocked("阻断或请求人工介入"):::failure
  end

  subgraph Stage3["⚙️ 阶段3 执行与观察"]
    Adapter("Tool Adapter<br/>shell/文件/浏览器/MCP/API"):::process
    Execution("Execution<br/>执行工具调用"):::process
    Observation("Observation<br/>输出/日志/错误/结果"):::process
  end

  subgraph Stage4["✅ 阶段4 恢复与验证"]
    Recovery("Recovery<br/>重试/降级/补上下文"):::failure
    Verification("Verification<br/>测试/diff/来源/trace"):::success
    Update("Memory / Skill 更新<br/>沉淀经验"):::success
  end

  Title --> Goal
  Goal --> Context
  Memory -. "长期事实" .-> Context
  Skill -. "流程模板" .-> Action
  Context --> Action
  Action --> Permission
  Permission -- "允许" --> Adapter
  Permission -- "高风险/越权" --> Blocked
  Blocked --> Recovery
  Adapter --> Execution
  Execution --> Observation
  Observation --> Verification
  Verification -- "未通过" --> Recovery
  Recovery --> Context
  Verification -- "通过" --> Update
  Update -. "复用经验" .-> Memory
  Update -. "改进流程" .-> Skill

  classDef title fill:#0f172a,stroke:#0f172a,color:#ffffff,rx:10,ry:10;
  classDef start fill:#0f172a,stroke:#0f172a,color:#ffffff,rx:10,ry:10;
  classDef process fill:#dbeafe,stroke:#2563eb,color:#0f172a,rx:10,ry:10;
  classDef storage fill:#ffe4e6,stroke:#e11d48,color:#0f172a,rx:10,ry:10;
  classDef decision fill:#ffffff,stroke:#64748b,color:#0f172a,rx:10,ry:10;
  classDef success fill:#dcfce7,stroke:#16a34a,color:#0f172a,rx:10,ry:10;
  classDef failure fill:#fee2e2,stroke:#dc2626,color:#0f172a,rx:10,ry:10;
  style Stage1 fill:#eef6ff,stroke:#1e3a8a,stroke-dasharray:5 5
  style Stage2 fill:#fff7ed,stroke:#9a3412,stroke-dasharray:5 5
  style Stage3 fill:#f0fdf4,stroke:#166534,stroke-dasharray:5 5
  style Stage4 fill:#fdf2f8,stroke:#9d174d,stroke-dasharray:5 5

2. Codex：受控工作区执行范式

Codex 内部原理机制图

2.1 核心定位

Codex 仍然以代码仓库任务为核心，但它代表的技术范式不是“只会写代码”，而是受控工作区执行。工作区可以包含代码、配置、Markdown、测试、脚本、数据样例和项目规则。Codex 的强项是在可写根目录、沙箱、审批策略和验证命令约束下，完成文件型工作并给出可复查证据。

核心结论

Codex 的优势是受控工作区内的可验证执行。代码是主要场景，但不是唯一可处理的文件型工作。

2.2 面向的工作类型

Codex 最适合结构化工作区中的任务：

工作类型 典型任务 技术原因
代码修改 修复 bug、实现小功能、重构局部模块 有文件、测试、diff、提交前检查
配置调整 修改构建、环境、CI 配置 文件边界清晰，验证命令可运行
文档修改 README、技术文档、迁移说明 可用 patch 精确修改
测试验证 运行单元测试、构建、lint 命令输出可作为完成证据
PR 前置检查 检查改动范围、测试残余风险 diff 和命令 trace 可审计
仓库知识整理 读取文件、总结模块、生成说明 上下文来自当前工作区

2.3 Harness 实现方式

Codex 的 Harness 控制面主要由工作区、文件系统、shell、apply_patch、沙箱策略、审批策略和会话上下文组成。它强调“先读取、再修改、再验证”，并且把用户/仓库规则作为执行约束。

技术点 Codex 体现
Context 当前工作区、AGENTS.md、读取文件、命令输出、测试结果、diff
Memory 项目规则和会话上下文，不以长期个人记忆为核心
Skill 更偏任务执行方法和仓库规则复用，不主打长期 Skill 学习
Tool apply_patch、shell、测试命令、文件系统
Permission sandbox、approval policy、可写根目录、网络限制
Verification test、diff、验证命令、残余风险说明

2.4 Context / Memory / Skill 机制

Codex 的 Context 构造从工作区开始：先读 AGENTS.md、README、配置、目标文件和测试，再根据命令输出继续补充材料。它适合“材料在仓库内或命令可观测”的任务。

Memory 更像项目规则和会话状态：AGENTS.md、当前对话、已读取文件、命令输出、失败记录和用户偏好会影响后续动作，但 Codex 不把长期个人记忆作为核心卖点。

Skill 更接近“执行方法复用”：例如先定位测试、再最小修改、再跑验证、最后说明风险。它也能使用已安装的本地 Skill，但核心产品优势仍然是工作区内的可控执行。

2.5 Tool / Permission / Verification

Tool Adapter 主要面向本地工作区：读文件、搜索、apply_patch、运行命令、测试和构建。权限边界由沙箱、可写根目录、网络限制和审批策略共同决定。验证不是口头判断，而是测试输出、构建结果、文件清单、diff 和残余风险说明。

实现细节可以压缩成“工作区材料 + 执行控制面”两部分：

1
2
3
4
workspace/
├── AGENTS.md                  # 仓库级规则、输出约束、测试要求
├── target files               # 代码、文档、配置等被修改对象
└── tests/                     # 验证命令的主要证据来源
1
2
3
4
5
Codex execution surface
├── apply_patch                # 以补丁方式写文件，便于审计改动范围
├── shell                      # 运行测试、构建、搜索等验证命令
├── sandbox                    # 限制可写目录、网络和高风险副作用
└── final report               # 汇总测试结果、diff、残余风险

其中，规划不是一次性生成完整方案，而是“任务拆解与下一步动作选择”的滚动过程：

1
2
3
4
5
6
7
8
9
10
11
12
13
Codex planning loop
├── intent_parse               # 输入：用户目标；输出：文件型任务目标和完成标准
│   └── 例：更新文档 + 调整配置 + 跑测试 → PR 前置准备
├── context_select             # 输入：AGENTS.md、目标文件、命令输出、diff；输出：本轮必要上下文
│   └── 避免一次性读取全仓库，只选和当前动作相关的材料
├── action_candidates          # 生成候选动作：读文件、搜索、apply_patch、运行测试、询问用户
│   └── 每个候选动作都要能产生 Observation
├── risk_check                 # 判断 sandbox、approval、网络、敏感路径、.git、密钥等边界
│   └── 高风险动作进入 ask / deny，不直接执行
├── next_action                # 选择当前最小可执行动作，而不是一次性执行完整计划
│   └── 例：先 rg 定位文件，再 patch，再 pytest
└── replan                     # 根据工具输出、错误、测试失败或 diff 更新下一步
    └── Observation 改变后，计划会收缩、重排或请求人工确认

其中，权限门与验证闭环可以用当前 harness-demo 的 Codex-style 策略说明。来源位置：harness_demo/harnesses/codex_style.py。

1
2
3
4
5
6
7
8
9
10
11
12
class CodexStyleHarness(HarnessStrategy):
    # 开启权限门：模拟 sandbox / approval 对危险操作的拦截
    permission_gate_enabled = True
    # 允许一次重试：模拟工具失败后的恢复路径
    retry_limit = 1

    def run_task(self, task: ExperimentTask) -> TaskResult:
        # 复用基类的工具执行、权限阻断、重试和指标记录逻辑
        result = self._run_with_retry(task)
        # 用 notes 标记 Codex-style 的关键机制：工作区、patch、验证闭环
        result.notes.extend(["workspace-scoped execution", "patch-oriented edits", "verification loop"])
        return result
%%{init: {"theme":"base","themeVariables":{"background":"#f8fafc","fontFamily":"Arial","lineColor":"#334155"}}}%%
flowchart TD
  Title("Codex 机制图<br/>工作区任务 → 规则 → patch → 验证"):::title

  subgraph Stage1["📁 阶段1 工作区入口"]
    Task("工作区任务<br/>代码/文档/配置/测试"):::start
    Agents("AGENTS.md<br/>项目规则与输出约束"):::storage
    Files("工作区材料<br/>源码/文档/配置/日志"):::storage
  end

  subgraph Stage2["🧠 阶段2 上下文构造"]
    Read("读取文件与命令输出"):::process
    Context("上下文<br/>目标/约束/已有变更/测试结果"):::process
    Plan("执行计划<br/>最小修改与验证路径"):::process
  end

  subgraph Stage3["🛡️ 阶段3 审批与执行"]
    Approval("审批与沙箱<br/>可写根目录/网络/高风险命令"):::decision
    Patch("apply_patch / 文件修改<br/>文档/配置/代码"):::process
    Shell("shell / 测试命令<br/>构建/lint/pytest"):::process
    Deny("阻断或请求批准"):::failure
  end

  subgraph Stage4["✅ 阶段4 验证与交付"]
    Verify("验证<br/>测试/构建/内容检查"):::success
    Diff("diff / 结果说明<br/>改动范围与残余风险"):::success
  end

  Title --> Task
  Task --> Agents
  Task --> Files
  Agents -. "规则" .-> Context
  Files -. "材料" .-> Read
  Read --> Context
  Context --> Plan
  Plan --> Approval
  Approval -- "允许" --> Patch
  Approval -- "需确认/越权" --> Deny
  Deny --> Approval
  Patch --> Shell
  Shell --> Verify
  Verify --> Diff

  classDef title fill:#0f172a,stroke:#0f172a,color:#ffffff,rx:10,ry:10;
  classDef start fill:#0f172a,stroke:#0f172a,color:#ffffff,rx:10,ry:10;
  classDef process fill:#dbeafe,stroke:#2563eb,color:#0f172a,rx:10,ry:10;
  classDef storage fill:#ffe4e6,stroke:#e11d48,color:#0f172a,rx:10,ry:10;
  classDef decision fill:#ffffff,stroke:#64748b,color:#0f172a,rx:10,ry:10;
  classDef success fill:#dcfce7,stroke:#16a34a,color:#0f172a,rx:10,ry:10;
  classDef failure fill:#fee2e2,stroke:#dc2626,color:#0f172a,rx:10,ry:10;
  style Stage1 fill:#eef6ff,stroke:#1e3a8a,stroke-dasharray:5 5
  style Stage2 fill:#f0f9ff,stroke:#075985,stroke-dasharray:5 5
  style Stage3 fill:#fff7ed,stroke:#9a3412,stroke-dasharray:5 5
  style Stage4 fill:#f0fdf4,stroke:#166534,stroke-dasharray:5 5

2.6 特色优势、短板与适合场景

  • 优势
    • 工作区边界清晰，文件改动、命令输出和验证结果可复查。
    • apply_patch 适合精确修改代码、配置和 Markdown。
    • 沙箱、可写根目录和审批策略能限制高风险副作用。
  • 短板
    • 不以长期个人记忆、多渠道消息入口和跨系统自动化为核心。
    • 对浏览器、消息平台、企业系统的持续运行能力依赖外部连接器或自动化配置。
    • 适合文件型工作，不适合无工作区边界的泛化助理任务。
  • 适合场景
    • 仓库内代码修改、配置调整、文档改写、测试验证。
    • PR 前置检查、仓库知识整理、可通过命令验证的工程任务。
    • 结构化文件工作区内的合同、报告、说明文档修订。

3. Claude Code：团队执行链治理范式

Claude Code 内部原理机制图

3.1 核心定位

Claude Code 的强场景是 coding，但它的技术意义更大：它把团队规则、权限、Hooks、外部系统连接、MCP、Subagents、上下文压缩和 trace 放进 Agent 执行链。它代表的是团队执行链治理。

核心结论

Claude Code 的优势是团队执行链治理。coding 是强入口，但底层机制可迁移到更广义的团队工作流。

3.2 面向的工作类型

Claude Code 可扩展到：

工作类型 机制支撑 技术原因
代码开发 项目文件、命令、MCP、Subagents 工程上下文和工具链成熟
文档生成 CLAUDE.md、项目资料、Hooks 校验 团队模板和审查规则可注入
内部工具操作 MCP 和命令工具 外部系统可变成受控工具
数据查询 MCP 数据源、权限规则 查询前后可治理和审计
CI/CD 辅助 命令、Hook、trace 执行步骤可记录
企业知识库查询 MCP、团队规则、上下文压缩 大上下文可分段管理
工程流程自动化 settings permissions、Hooks 团队级安全边界可配置

3.3 Harness 实现方式

Claude Code 的 Harness 控制点不只在工具调用本身，而是在整个执行链：规则从 CLAUDE.md 和 settings 进入上下文，权限模式决定 allow / ask / deny，Hooks 在生命周期上阻断或校验动作，MCP 扩展企业工具，Subagents 隔离复杂任务，上下文压缩保留关键历史。

技术点 Claude Code 体现
Context 项目文件、CLAUDE.md、工具结果、MCP 返回数据、压缩后的会话上下文
Memory CLAUDE.md 和多层级配置承载项目规则、团队规则、用户偏好
Skill 可与插件、行业工作流、Subagents 配合形成可安装工作流
Tool 命令、文件、MCP、Hooks、Subagents
Permission settings permissions、allow / ask / deny、Hooks 阻断
Verification Hooks、tool trace、命令输出、上下文压缩后的证据保留

3.4 Context / Memory / Skill 机制

Claude Code 的 Context 来源比工作区更广：项目文件、CLAUDE.md、工具输出、MCP 返回、子代理结果和压缩后的会话摘要都会影响下一步动作。Context compaction 的价值在于把长任务中的历史变成可继续执行的摘要，而不是简单丢弃。

Memory 主要通过文件和配置承载：CLAUDE.md 可以保存团队规范、项目约束、常用命令和工作方式；settings 可以分层配置权限、工具和 Hooks。这里的 Memory 更偏组织规则和工作流规范，不是单纯个人偏好库。

Skill 可作为可安装流程使用，和插件、MCP、Hooks、Subagents 组合后，可以把行业流程固化为团队执行链，例如发布检查、合同条款审查、数据查询前置审批、文档格式校验。

3.5 Tool / Permission / Verification

Claude Code 的工具接入包括命令、文件、MCP 和 Subagents。权限控制不仅是工具调用前的 allow / ask / deny，还包括 Hooks 的生命周期拦截。验证也不只靠测试，而是靠 Hook 输出、命令日志、工具 trace、MCP 返回和交付检查共同形成证据链。

实现细节可压缩成“规则文件 + 权限配置 + Hook 门禁”：

1
2
3
4
5
project/
├── CLAUDE.md                  # 项目级 Memory：团队规范、常用命令、工作方式
├── .claude/
│   └── settings.json          # allow / ask / deny 权限与 Hooks 配置
└── .mcp.json                  # 外部系统工具入口，如数据库、知识库、CI
1
2
3
4
5
Claude Code control chain
├── permissions.allow          # 低风险工具自动执行
├── permissions.ask            # push、联网、生产查询等动作先询问
├── permissions.deny           # 删除、泄密、越权命令直接阻断
└── PreToolUse / PostToolUse   # 工具执行前后做策略检查、格式校验和审计

其中，Hook 门禁体现了“团队规则进入工具执行链”的方式。来源位置：Claude Code docs Hooks。以下是团队侧可实现的精简 Hook 脚本示例，用于说明机制，不作为官方源码。

1
2
3
4
5
6
7
8
9
10
11
12
13
#!/usr/bin/env bash
# scripts/check-command-policy.sh
# 输入：Claude Code 在 PreToolUse 阶段传入的工具调用上下文
# 目标：对高风险命令做确定性阻断，避免只依赖模型判断

command_text="${CLAUDE_TOOL_INPUT:-}"

if [[ "$command_text" == *"rm -rf"* ]]; then
  echo "deny: destructive command is not allowed"
  exit 1
fi

echo "allow"
%%{init: {"theme":"base","themeVariables":{"background":"#f8fafc","fontFamily":"Arial","lineColor":"#334155"}}}%%
flowchart TD
  Title("Claude Code 机制图<br/>团队规则 → 权限 → Hooks → Tool/MCP → trace"):::title

  subgraph Stage1["📚 阶段1 团队规则"]
    Rules("团队规则<br/>安全策略/流程规范/知识沉淀"):::start
    ClaudeMd("CLAUDE.md<br/>项目规则与偏好"):::storage
    Settings("settings permissions<br/>allow / ask / deny"):::storage
  end

  subgraph Stage2["🧠 阶段2 上下文窗口"]
    Context("上下文<br/>项目文件/工具结果/MCP 数据"):::process
    Compaction("context compaction<br/>压缩长会话证据"):::process
  end

  subgraph Stage3["🛡️ 阶段3 治理链"]
    Permission("权限判断<br/>允许/询问/拒绝"):::decision
    PreHook("PreTool Hooks<br/>输入校验与风险阻断"):::decision
    Tools("Tool / MCP<br/>命令/文件/数据库/企业系统"):::process
    Subagents("Subagents<br/>隔离上下文并行处理"):::process
    PostHook("PostTool Hooks<br/>结果校验与审计"):::decision
    Deny("阻断并记录原因"):::failure
  end

  subgraph Stage4["🚚 阶段4 交付"]
    Trace("tool trace<br/>命令输出/MCP 返回/Hook 记录"):::success
    Delivery("交付<br/>代码/文档/查询结果/流程动作"):::success
  end

  Title --> Rules
  Rules --> ClaudeMd
  Rules --> Settings
  ClaudeMd -. "规则注入" .-> Context
  Settings -. "权限策略" .-> Permission
  Context --> Permission
  Permission -- "allow" --> PreHook
  Permission -- "ask/deny" --> Deny
  PreHook -- "通过" --> Tools
  PreHook -- "阻断" --> Deny
  Tools --> Subagents
  Subagents --> PostHook
  PostHook -- "通过" --> Compaction
  PostHook -- "失败" --> Deny
  Compaction --> Trace
  Trace --> Delivery

  classDef title fill:#0f172a,stroke:#0f172a,color:#ffffff,rx:10,ry:10;
  classDef start fill:#0f172a,stroke:#0f172a,color:#ffffff,rx:10,ry:10;
  classDef process fill:#dbeafe,stroke:#2563eb,color:#0f172a,rx:10,ry:10;
  classDef storage fill:#ffe4e6,stroke:#e11d48,color:#0f172a,rx:10,ry:10;
  classDef decision fill:#ffffff,stroke:#64748b,color:#0f172a,rx:10,ry:10;
  classDef success fill:#dcfce7,stroke:#16a34a,color:#0f172a,rx:10,ry:10;
  classDef failure fill:#fee2e2,stroke:#dc2626,color:#0f172a,rx:10,ry:10;
  style Stage1 fill:#fdf2f8,stroke:#9d174d,stroke-dasharray:5 5
  style Stage2 fill:#eef6ff,stroke:#1e3a8a,stroke-dasharray:5 5
  style Stage3 fill:#fff7ed,stroke:#9a3412,stroke-dasharray:5 5
  style Stage4 fill:#f0fdf4,stroke:#166534,stroke-dasharray:5 5

3.6 特色优势、短板与适合场景

  • 优势
    • 团队规则、权限策略、Hooks 和 MCP 可以进入同一执行链。
    • CLAUDE.md 与 settings 分层后，项目规则、团队规范和个人偏好可以分离。
    • Hooks 让安全、格式、审计和质量检查具备确定性门禁。
  • 短板
    • 配置复杂度高，需要维护权限矩阵、Hook 脚本和 MCP 服务。
    • 治理过重会增加执行摩擦，降低小任务效率。
    • 外部系统接入越多，审计、密钥和工具输出一致性压力越大。
  • 适合场景
    • 团队代码开发、工程流程自动化、CI/CD 辅助。
    • 企业知识库查询、内部工具操作、数据查询前置审批。
    • 需要工具 trace、权限审计和团队规范复用的工作流。

4. OpenClaw：多渠道本地 Gateway 范式

OpenClaw 内部原理机制图

4.1 核心定位

OpenClaw 不应按 coding agent 理解，更合理的定位是本地常驻个人工作助手。它的关键不是仓库 patch，而是把聊天平台、本地工具、浏览器、插件、MCP 和定时任务接入同一个 Gateway，让用户可以从多渠道触发个人自动化。

核心结论

OpenClaw 的优势是把聊天平台、本地工具、浏览器、插件和定时任务接入同一个个人 Gateway，适合非编程类个人工作自动化。

4.2 面向的工作类型

工作类型 OpenClaw 适配方式 技术原因
消息平台任务 channel 输入输出 用户可以在聊天中发起和确认任务
个人自动化 Gateway + plugins + cron 本地常驻进程可持续接收触发
浏览器操作 browser 工具和 profile 可使用用户浏览器状态处理网页任务
定时提醒 cron 周期性触发并回传渠道
文件处理 workspace + tool adapter 本地文件可被读取、整理、改写
多渠道入口 message channels 同一 Agent 可以接 Slack、Telegram、Webhook 等
轻量工作流编排 skills + plugins 可把常用流程沉淀为工具链

4.3 Harness 实现方式

OpenClaw 的 Harness 控制重点在 Gateway。用户消息、浏览器事件、定时任务和插件能力进入 Gateway 后，由 Agent Routing 选择模型、Skill、插件和工具。权限通过 approvals、exec-policy 和 sandbox 控制，结果通过 tool-result middleware 清洗后返回原渠道。

技术点 OpenClaw 体现
Context channel 消息、workspace、memory、skills、plugins、浏览器和工具结果
Memory 个人助手长期状态、workspace 状态、channel 上下文
Skill 个人自动化能力扩展，与 plugins 配合
Tool Gateway、browser、cron、MCP、plugins、message channels
Permission approvals、exec-policy、sandbox
Verification tool-result middleware、channel 回传、任务状态

4.4 Context / Memory / Skill 机制

OpenClaw 的 Context 不是单个仓库，而是“渠道 + 工作区 + 工具结果”：一次 Slack 消息、一次浏览器操作、一个本地目录和一次 cron 触发都可以成为任务上下文。Memory 更偏个人助手状态，例如频道会话、偏好、长期任务状态和 workspace 信息。

Skill 与 plugins 共同扩展能力：Skill 保存流程，plugin 提供工具接入。两者组合后，OpenClaw 更像个人工具箱，而不是一个只对代码仓库工作的执行器。

4.5 Tool / Permission / Verification

OpenClaw 的 Tool Adapter 覆盖浏览器、MCP、cron、插件和消息平台。Permission 依赖 approvals、exec-policy 和 sandbox，适合处理“发消息、执行命令、访问网页、调用插件”这类个人侧副作用。Verification 通过 tool result middleware、任务状态和 channel 回传完成。

实现细节可以选取 Exec approvals 来看。官方文档将它定义为 companion app / node host guardrail：沙箱内 Agent 想在真实 host 上执行命令时，必须同时满足工具策略、host 本地审批策略、allowlist 和可选人工确认。来源位置：OpenClaw docs Tools > Exec Approvals。

1
2
3
4
5
OpenClaw Exec approvals
├── exec-approvals.json        # host 本地审批状态：security / ask / fallback / allowlist
├── approval socket            # Gateway、审批 UI、node host 之间的本地 IPC 通道
├── allowlist matcher          # 命中可信命令则放行，未命中进入 ask / deny 分支
└── canonical systemRunPlan    # 绑定 command、cwd、argv、env，防止审批后参数被替换

其中，host exec 审批决策体现了 OpenClaw 对本地副作用的控制方式。来源位置：OpenClaw docs Tools > Exec Approvals。以下是按文档机制抽象的精简伪代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
function decideHostExec(plan, policy) {
  // deny：默认拒绝，适合最小权限模式
  if (policy.security === "deny") return "deny";

  // full：完全放行，风险最高，通常只用于高度可信环境
  if (policy.security === "full") return "allow";

  // allowlist：只放行命中白名单的 canonical plan
  if (matchesAllowlist(plan.command, policy.allowlist)) return "allow";

  // 未命中白名单时，按 ask 策略转人工确认或直接拒绝
  return policy.ask === "on-miss" ? "ask-human" : "deny";
}
%%{init: {"theme":"base","themeVariables":{"background":"#f8fafc","fontFamily":"Arial","lineColor":"#334155"}}}%%
flowchart TD
  Title("OpenClaw 机制图<br/>channels → Gateway → Skills/Plugins → channel"):::title

  subgraph Stage1["💬 阶段1 多渠道入口"]
    Channels("channels<br/>Slack/Telegram/Discord/Email/Webhook"):::start
    Browser("浏览器<br/>网页访问与自动化"):::process
    Cron("cron<br/>定时任务与提醒"):::process
    Workspace("workspace<br/>文件/数据/笔记"):::storage
  end

  subgraph Stage2["🧭 阶段2 Gateway 路由"]
    Gateway("Gateway<br/>本地常驻进程"):::process
    Routing("Agent Routing<br/>选择模型/Skill/工具链"):::process
    ChannelContext("channel 上下文<br/>会话/身份/任务状态"):::storage
  end

  subgraph Stage3["🧩 阶段3 能力扩展"]
    Skills("Skills<br/>个人自动化流程"):::storage
    Plugins("Plugins<br/>浏览器/MCP/本地工具"):::process
    Approval("approvals / sandbox<br/>exec-policy 与风险控制"):::decision
    Deny("拒绝或风险提示"):::failure
  end

  subgraph Stage4["📣 阶段4 结果回传"]
    ToolResult("tool-result middleware<br/>清洗/格式化/结构化"):::success
    Return("返回原渠道<br/>状态/结果/后续问题"):::success
  end

  Title --> Channels
  Browser --> Gateway
  Cron --> Gateway
  Workspace -. "本地材料" .-> Gateway
  Channels --> Gateway
  Gateway --> Routing
  Routing --> ChannelContext
  ChannelContext -. "会话状态" .-> Skills
  Skills --> Plugins
  Plugins --> Approval
  Approval -- "通过" --> ToolResult
  Approval -- "拒绝/高风险" --> Deny
  Deny --> Return
  ToolResult --> Return
  Return --> Channels

  classDef title fill:#0f172a,stroke:#0f172a,color:#ffffff,rx:10,ry:10;
  classDef start fill:#0f172a,stroke:#0f172a,color:#ffffff,rx:10,ry:10;
  classDef process fill:#dbeafe,stroke:#2563eb,color:#0f172a,rx:10,ry:10;
  classDef storage fill:#ffe4e6,stroke:#e11d48,color:#0f172a,rx:10,ry:10;
  classDef decision fill:#ffffff,stroke:#64748b,color:#0f172a,rx:10,ry:10;
  classDef success fill:#dcfce7,stroke:#16a34a,color:#0f172a,rx:10,ry:10;
  classDef failure fill:#fee2e2,stroke:#dc2626,color:#0f172a,rx:10,ry:10;
  style Stage1 fill:#fdf2f8,stroke:#9d174d,stroke-dasharray:5 5
  style Stage2 fill:#eef6ff,stroke:#1e3a8a,stroke-dasharray:5 5
  style Stage3 fill:#fff7ed,stroke:#9a3412,stroke-dasharray:5 5
  style Stage4 fill:#f0fdf4,stroke:#166534,stroke-dasharray:5 5

4.6 特色优势、短板与适合场景

  • 优势
    • 同一个 Gateway 可以接收聊天、浏览器、cron、Webhook 和插件触发。
    • 结果可以回传原渠道，审批也可以发生在用户当前聊天环境中。
    • 本地运行和独立浏览器 profile 适合个人隐私与个人工具箱场景。
  • 短板
    • 治理粒度偏个人和本地，团队级规则分层、集中审计需要额外建设。
    • 插件和渠道越多，权限误配、密钥泄露和误发送风险越高。
    • 长期 Skill 学习和组织级知识沉淀不是其最核心优势。
  • 适合场景
    • 消息处理、个人提醒、网页操作、文件整理。
    • 日程、邮件、浏览器、轻量数据分析和个人多渠道自动化。
    • 需要本地 Gateway 统一接入多个个人工具的工作流。

5. Hermes：长期运行、自我改进的通用 Agent 系统

Hermes 内部原理机制图

5.1 核心定位

Hermes 更适合写成长期运行、自我改进的通用 Agent 系统。它不是只围绕代码仓库，而是围绕长期助手能力：多渠道入口、Provider 抽象、持久记忆、Skill 索引、执行轨迹、上下文压缩和 Learning Loop。

核心结论

Hermes 的优势是把多类型工作中的执行经验资产化，适合长期运行、经验复用和自我改进场景。

5.2 面向的工作类型

工作类型 Hermes 适配方式 技术原因
研究任务 会话搜索、长期记忆、工具轨迹 需要跨会话复用事实和过程
文档处理 文件工具、Skill、记忆 可沉淀固定审查和生成流程
企业流程 Gateway、MCP、Provider 可接入外部系统和多终端后端
定期监控 cron + gateway 回传 长期运行比一次性 CLI 更适合
数据整理 工具集合、Provider、后端隔离 数据管线可固化为 Skill
多工具任务 Skill activation + trace 执行轨迹可学习与复盘
个人 / 团队长期助手 persistent memory 偏好、状态和历史可积累

5.3 Harness 实现方式

本地 hermes-agent 源码显示，Hermes 通过 MemoryManager 编排内置 Memory Provider 与一个外部 Memory Provider；Skill 通过 SKILL.md、skill index 和 slash command 加载；Gateway 支持消息平台入口；执行环境通过 local、Docker、SSH、Daytona、Singularity、Modal 等后端抽象；运行过程可保存 trajectory，并在 Learning Loop 中推动 Skill 和 Memory 更新。

技术点 Hermes 体现
Context gateway 消息、persistent memory、Skill 索引、任务轨迹、工具结果
Memory 保存长期事实、偏好、环境状态
Skill 通过索引、触发条件、执行轨迹和 Learning Loop 持续沉淀
Tool Provider 抽象、多终端后端、MCP、工具集合
Permission authorization、command approval、backend isolation
Verification execution trace、learning feedback、Skill/Memory 更新记录

5.4 Context / Memory / Skill 机制

Hermes 的 Context 包含当前消息、Gateway 平台信息、会话历史、压缩摘要、Memory Provider 召回、Skill 内容、工具输出和任务轨迹。源码中的 MemoryManager.prefetch_all() 会在 turn 前从各 provider 收集回忆上下文，sync_all() 在 turn 后同步新信息，on_pre_compress() 在上下文压缩前提取信息，避免长期任务中关键事实丢失。

Memory 是显式插件体系：内置 Memory Provider 始终存在，外部 provider 通过 plugins/memory/<name>/ 接入。MemoryProvider 抽象定义了 initialize()、prefetch()、sync_turn()、get_tool_schemas()、handle_tool_call()、on_session_end()、on_memory_write() 等生命周期。技术结果是长期事实、用户偏好、环境状态和会话知识可以跨任务使用。

Skill 是程序化经验资产：Skill 由 SKILL.md 描述，slash command 可以在 CLI 与 Gateway 中加载，内容支持变量替换、配置注入和辅助文件。Hermes 的 README 明确强调它会从经验中创建和改进 Skills，并通过 session search、memory 和 learning loop 形成长期复用。

5.5 Tool / Permission / Verification

Hermes 的工具接入更像 Provider 层：模型 provider、工具 provider、终端后端、MCP、浏览器、文档、数据和消息平台都可以成为能力。权限控制依赖 authorization、command approval、消息平台身份控制和后端隔离。验证不是单点测试，而是执行 trace、trajectory、工具输出、学习反馈和 Skill/Memory 更新记录。

本地 Hermes 源码副本中可以看到较清晰的实现模块边界。下方用 $HERMES_REPO 表示 Hermes 源码根目录，避免暴露本机用户目录。

1
2
3
4
5
6
7
8
9
$HERMES_REPO/
├── agent/
│   ├── memory_manager.py                # Memory Provider 编排
│   ├── memory_provider.py               # Memory Provider 抽象接口
│   ├── skill_commands.py                # Skill slash command 加载
│   └── skill_preprocessing.py           # SKILL.md 变量替换与预处理
├── gateway/                             # 消息 Gateway 与平台适配
├── tools/environments/base.py           # local / Docker / SSH / Modal 等后端抽象
└── skills/                              # 内置 Skill：可被 slash command 激活

其中，Memory Provider 召回编排体现了 Hermes 如何把长期记忆注入当前任务。来源位置：$HERMES_REPO/agent/memory_manager.py 的 prefetch_all()。

1
2
3
4
5
6
7
8
9
10
11
12
13
def prefetch_all(self, query: str, *, session_id: str = "") -> str:
    # 逐个调用已注册的 Memory Provider，召回和当前用户消息相关的长期上下文
    parts = []
    for provider in self._providers:
        try:
            result = provider.prefetch(query, session_id=session_id)
            if result and result.strip():
                parts.append(result)
        except Exception:
            # 单个记忆后端失败不应阻断主 Agent 执行
            logger.debug("memory provider prefetch failed", exc_info=True)
    # 合并后的记忆上下文再进入下一轮模型输入
    return "\n\n".join(parts)
%%{init: {"theme":"base","themeVariables":{"background":"#f8fafc","fontFamily":"Arial","lineColor":"#334155"}}}%%
flowchart TD
  Title("Hermes 机制图<br/>Gateway → Memory/Skill → Provider → Learning Loop"):::title

  subgraph Stage1["📨 阶段1 消息入口"]
    Gateway("Message Gateway<br/>Telegram/Discord/Slack/CLI/cron"):::start
    ContextBuilder("Context Builder<br/>消息/平台/任务/历史"):::process
  end

  subgraph Stage2["🧠 阶段2 长期状态"]
    Memory("Persistent Memory<br/>事实/偏好/环境状态"):::storage
    SkillIndex("Skill Index<br/>SKILL.md/触发条件/版本"):::storage
    SessionSearch("Session Search<br/>历史会话检索"):::storage
  end

  subgraph Stage3["🧩 阶段3 Skill 与工具"]
    Activation("Skill Activation<br/>匹配流程与参数"):::process
    Provider("Tool / Provider<br/>MCP/浏览器/文件/数据/消息"):::process
    Backend("Execution Backend<br/>local/Docker/SSH/Modal/Singularity"):::process
    Approval("Authorization<br/>命令审批/后端隔离"):::decision
    Deny("拒绝或降级"):::failure
  end

  subgraph Stage4["🔁 阶段4 轨迹与学习"]
    Trace("Execution Trace<br/>工具结果/日志/状态"):::success
    Learning("Learning Loop<br/>反馈/经验提炼/失败归纳"):::success
    Update("Skill / Memory Update<br/>写入长期经验"):::success
  end

  Title --> Gateway
  Gateway --> ContextBuilder
  Memory -. "召回" .-> ContextBuilder
  SessionSearch -. "历史证据" .-> ContextBuilder
  SkillIndex -. "可用技能" .-> Activation
  ContextBuilder --> Activation
  Activation --> Approval
  Approval -- "通过" --> Provider
  Approval -- "拒绝/越权" --> Deny
  Deny --> ContextBuilder
  Provider --> Backend
  Backend --> Trace
  Trace --> Learning
  Learning --> Update
  Update -. "事实更新" .-> Memory
  Update -. "流程改进" .-> SkillIndex

  classDef title fill:#0f172a,stroke:#0f172a,color:#ffffff,rx:10,ry:10;
  classDef start fill:#0f172a,stroke:#0f172a,color:#ffffff,rx:10,ry:10;
  classDef process fill:#dbeafe,stroke:#2563eb,color:#0f172a,rx:10,ry:10;
  classDef storage fill:#ffe4e6,stroke:#e11d48,color:#0f172a,rx:10,ry:10;
  classDef decision fill:#ffffff,stroke:#64748b,color:#0f172a,rx:10,ry:10;
  classDef success fill:#dcfce7,stroke:#16a34a,color:#0f172a,rx:10,ry:10;
  classDef failure fill:#fee2e2,stroke:#dc2626,color:#0f172a,rx:10,ry:10;
  style Stage1 fill:#eef6ff,stroke:#1e3a8a,stroke-dasharray:5 5
  style Stage2 fill:#fdf2f8,stroke:#9d174d,stroke-dasharray:5 5
  style Stage3 fill:#fff7ed,stroke:#9a3412,stroke-dasharray:5 5
  style Stage4 fill:#f0fdf4,stroke:#166534,stroke-dasharray:5 5

5.6 特色优势、短板与适合场景

  • 优势
    • Memory 保存事实，Skill 保存流程，trace 保存执行证据。
    • Learning Loop 可以把多次工作结果反哺为长期能力。
    • Provider 和终端后端抽象适合长期运行、多环境执行和跨渠道接入。
  • 短板
    • 系统复杂度高，长期运行需要处理权限、隐私和记忆污染。
    • Skill 自动沉淀需要质量控制，否则会出现流程退化和重复 Skill。
    • 多后端、多 Provider、多渠道会增加一致性和故障恢复成本。
  • 适合场景
    • 长期研究、跨会话文档处理、周期监控、企业流程。
    • 数据整理、多工具任务、个人或团队长期助手。
    • 需要把经验沉淀为 Memory / Skill / trace 的持续型工作。

6. 四类产品总对比

维度 Codex Claude Code OpenClaw Hermes
工作类型 代码、配置、文档、测试、仓库知识 代码、文档、内部工具、数据查询、CI/CD、知识库 消息、浏览器、文件、定时任务、个人自动化 研究、文档、企业流程、定期监控、数据整理、多工具长期任务
Harness 控制重点 工作区 团队执行链 本地 Gateway 长期学习
Context 管理 当前工作区、AGENTS.md、命令输出、diff 项目文件、CLAUDE.md、MCP、工具结果、压缩上下文 channel + workspace + plugins + 浏览器结果 gateway 消息 + memory + skill index + 任务轨迹
Memory 管理 项目规则和会话上下文 CLAUDE.md、多层级配置、团队规则 个人状态、workspace、channel 上下文 persistent memory、user profile、session search
Skill 机制 执行规则复用 插件工作流、Subagents、行业流程 skills + plugins Learning Loop、Skill 索引、自我改进
工具接入 shell + patch + 文件系统 MCP + Hooks + 命令 + 文件 + Subagents Gateway + plugins + browser + cron + MCP Provider + terminal backends + MCP + tools
权限边界 sandbox + approval + 可写根目录 allow/ask/deny + Hooks + settings approvals + exec-policy + sandbox authorization + command approval + backend isolation
结果验证 test + diff + 命令输出 Hooks + tool trace + 命令输出 middleware 回传 + channel 状态 execution trace + learning feedback + Skill/Memory 更新
主要优势 可验证工作区执行 团队流程治理 个人多渠道自动化 长期经验资产
主要风险 不擅长全域长期个人状态 配置和治理复杂度高 企业级审计和团队规则弱 记忆污染、长期权限和系统复杂度

7. 当前项目 harness-demo 设计与评估

7.1 Demo 定位

当前项目 harness-demo 是一个 Python CLI 最小实验，用确定性任务模拟 Harness 的核心机制。它以代码任务为主线，但只覆盖受控工作区执行的一部分：工具调用、权限阻断、失败重试、上下文消耗、验证结果和聚合指标。

它不能代表 Codex、Claude Code、OpenClaw 或 Hermes 的真实产品性能，也不能外推到所有 Agent 工作类型。它的价值是用可运行代码解释 Harness 的最小闭环。

7.2 Demo 模块

文件 功能
harness_demo/cli.py CLI 入口，支持 python -m harness_demo.cli run --scenario all
harness_demo/tasks.py 定义确定性任务集
harness_demo/tools.py 模拟工具注册表、权限阻断和工具失败
harness_demo/harnesses/base.py 共享 Harness 策略、重试和指标计算
harness_demo/harnesses/*.py 模拟 none、generic、codex_style、claude_code_style、openclaw_style、hermes_style
harness_demo/metrics.py 聚合成功率、平均耗时、重试、上下文、阻断和可复现分数

7.3 Demo 架构图

%%{init: {"theme":"base","themeVariables":{"background":"#f8fafc","fontFamily":"Arial","lineColor":"#334155"}}}%%
flowchart TD
  Title("harness-demo 最小实验<br/>用确定性代码模拟 Harness 控制闭环"):::title

  subgraph Stage1["🎯 阶段1 输入"]
    CLI("CLI 命令<br/>python -m harness_demo.cli run --scenario all"):::start
    Tasks("任务集<br/>读工作区/恢复失败/阻断危险命令/上下文压力/验证 patch"):::storage
  end

  subgraph Stage2["🧪 阶段2 策略执行"]
    Factory("Scenario Factory<br/>none/generic/codex/claude/openclaw/hermes"):::process
    Harness("HarnessStrategy<br/>权限门/重试/上下文倍率/耗时倍率"):::process
    Registry("SimulatedToolRegistry<br/>read_workspace/run_command/apply_patch/run_tests"):::process
    Permission("Permission Gate<br/>阻断 rm -rf"):::decision
  end

  subgraph Stage3["📊 阶段3 观察与验证"]
    Result("TaskResult<br/>成功/工具调用/重试/阻断/上下文"):::success
    Metrics("ScenarioReport<br/>成功率/平均耗时/恢复率/可复现分数"):::success
    Boundary("边界<br/>模拟指标不是产品性能"):::failure
  end

  Title --> CLI
  CLI --> Tasks
  Tasks --> Factory
  Factory --> Harness
  Harness --> Registry
  Registry --> Permission
  Permission -- "安全" --> Result
  Permission -- "危险命令" --> Result
  Result --> Metrics
  Metrics --> Boundary

  classDef title fill:#0f172a,stroke:#0f172a,color:#ffffff,rx:10,ry:10;
  classDef start fill:#0f172a,stroke:#0f172a,color:#ffffff,rx:10,ry:10;
  classDef process fill:#dbeafe,stroke:#2563eb,color:#0f172a,rx:10,ry:10;
  classDef storage fill:#ffe4e6,stroke:#e11d48,color:#0f172a,rx:10,ry:10;
  classDef decision fill:#ffffff,stroke:#64748b,color:#0f172a,rx:10,ry:10;
  classDef success fill:#dcfce7,stroke:#16a34a,color:#0f172a,rx:10,ry:10;
  classDef failure fill:#fee2e2,stroke:#dc2626,color:#0f172a,rx:10,ry:10;
  style Stage1 fill:#eef6ff,stroke:#1e3a8a,stroke-dasharray:5 5
  style Stage2 fill:#fff7ed,stroke:#9a3412,stroke-dasharray:5 5
  style Stage3 fill:#f0fdf4,stroke:#166534,stroke-dasharray:5 5

7.4 运行方式

1
python -m harness_demo.cli run --scenario all

7.5 真实运行评估结果

运行时间：2026-05-13，本地命令真实执行得到以下输出。指标来自 Demo 的确定性模拟逻辑，不代表任何真实产品性能。

scenario success_rate avg_ms avg_tools retries recovery_rate context blocks repro_score
none 0.600 70.55 1.40 0 0.000 267 0 1.000
generic 1.000 91.00 1.60 1 1.000 222 1 0.950
codex_style 1.000 98.28 1.60 1 1.000 208 1 0.950
claude_code_style 1.000 101.92 1.60 1 1.000 198 1 0.950
openclaw_style 1.000 95.55 1.60 1 1.000 214 1 0.950
hermes_style 1.000 100.10 1.60 1 1.000 193 1 0.950

7.6 Demo 结果解释

none 没有权限门和恢复能力，因此遇到不安全命令或瞬时失败时成功率较低。generic 之后的 Harness 风格都开启权限门和一次重试，因此成功率达到 1.000，并且会记录一次危险命令阻断。

不同产品风格的差异来自 Demo 中配置的 duration_multiplier 和 context_multiplier，用于教学比较，不是实测产品性能。例如 hermes_style 的 context 最低，是因为示例里给了更低的 context_multiplier，表达“长期记忆/Skill 索引可能降低重复上下文”的教学假设，而不是 Hermes 真机基准。

7.7 Demo 边界与风险

这个 Demo 只覆盖 Harness 的最小机制：工具调用、权限阻断、重试、上下文估算和验证指标。它没有实现真实浏览器、消息平台、合同审查、企业系统、长期 Memory Provider、真实 Skill 学习、MCP 服务和多后端隔离。因此它适合作为 Harness 核心机制实验，不适合作为产品性能或全场景能力评测。

8. 工程落地建议

落地通用 Agent 工作执行系统时，应先决定 Harness 控制重点，而不是先决定模型：

目标 推荐范式 设计重点
仓库内可验证任务 Codex 式工作区执行 文件边界、patch、测试、diff、审批
团队流程和外部系统治理 Claude Code 式执行链治理 规则分层、Hooks、MCP、权限矩阵、trace
个人多渠道自动化 OpenClaw 式本地 Gateway channel、browser、cron、plugin、同渠道审批
长期助手和经验复用 Hermes 式长期学习 persistent memory、Skill index、trajectory、Learning Loop

工程上应优先实现五件事：

  1. 明确 Context Builder 的材料选择规则，避免把所有数据都塞进模型。
  2. 对所有有副作用的动作做权限分级，包括删除、发送、提交、联网、支付、生产 API。
  3. 让每个 Tool Adapter 输出结构化 Observation，保留日志、错误和状态。
  4. 把 Verification 设计成必经节点，使用测试、来源、审核、diff、trace 或人工确认。
  5. 将 Memory 和 Skill 分离：Memory 保存事实，Skill 保存流程，避免把个人偏好混入可执行流程。

9. 风险与边界

风险 影响 控制方式
上下文污染 错误材料进入决策 来源标注、上下文分层、压缩前抽取
记忆污染 过期或错误事实长期影响任务 Memory 写入审批、过期策略、可撤销
Skill 退化 错误流程被持续复用 Skill 版本、评审、回滚、执行指标
权限越界 删除、发送、提交、调用敏感 API allow/ask/deny、沙箱、审批、最小权限
工具输出不可控 API 错误、网页变更、命令失败 Observation 标准化、Recovery、重试上限
验证缺失 任务看似完成但无证据 强制 Verification 和 trace
长期运行安全 后台任务持续产生副作用 定时任务审计、身份绑定、密钥隔离

10. 参考文献

  1. OpenAI Codex overview：https://platform.openai.com/docs/codex/overview
  2. OpenAI AGENTS.md guide：https://developers.openai.com/codex/guides/agents-md
  3. OpenAI Codex sandboxing concept：https://developers.openai.com/codex/concepts/sandboxing
  4. OpenAI Codex agent approvals and security：https://developers.openai.com/codex/agent-approvals-security
  5. Claude Code docs：https://code.claude.com/docs/en/how-claude-code-works
  6. Claude Code memory docs：https://code.claude.com/docs/en/memory
  7. Claude Code settings docs：https://code.claude.com/docs/en/settings
  8. Claude Code hooks docs：https://code.claude.com/docs/en/hooks
  9. Claude Code MCP docs：https://code.claude.com/docs/en/mcp
  10. Claude Code subagents docs：https://code.claude.com/docs/en/sub-agents
  11. Claude Code skills docs：https://code.claude.com/docs/en/skills
  12. OpenClaw exec approvals docs：https://docs.openclaw.ai/tools/exec-approvals
  13. OpenClaw browser docs：https://docs.openclaw.ai/browser
  14. OpenClaw skills docs：https://docs.openclaw.ai/tools/skills
  15. OpenClaw MCP docs：https://docs.openclaw.ai/cli/mcp
  16. Hermes Agent GitHub：https://github.com/NousResearch/hermes-agent
  17. Hermes Agent README：$HERMES_REPO/README.md
  18. Hermes Memory 实现：$HERMES_REPO/agent/memory_manager.py、$HERMES_REPO/agent/memory_provider.py
  19. Hermes Skill 实现：$HERMES_REPO/agent/skill_commands.py、$HERMES_REPO/agent/skill_preprocessing.py
  20. Hermes Provider / Backend 实现：$HERMES_REPO/tools/environments/base.py
  21. 当前 Demo 分支：https://github.com/bujiuzhi/ai-demo-lab/tree/harness-demo，目录：harness_demo/、README.md、pyproject.toml
  22. dotey X thread：https://x.com/dotey/status/2054383106115678639?s=46
  23. dotey X thread：https://x.com/dotey/status/2053601852261110201?s=20
  24. 一文搞懂 Hermes：新顶流 Agent 如何从经验中自我进化：https://mp.weixin.qq.com/s/yHva-zLaRTxe8b4HSUr86Q
  25. 微信公众号文章：https://mp.weixin.qq.com/s/8PwDQSX7ZX6HdDiW-H9Dzg
  26. 微信公众号文章：https://mp.weixin.qq.com/s/NtsksL2gkMtMqkILi4xvRg
  27. 微信公众号文章：https://mp.weixin.qq.com/s/_Yn-PRW2kmoOusUbTbi3vQ
  28. 关于 Harness 如何构建 Harness 六大组件全解析：https://mp.weixin.qq.com/s/HwqEaXSGkcYgUNrzB2okuA
  29. 微信公众号文章：https://mp.weixin.qq.com/s/qdycBcCUujnVBkO4vky0wA?scene=334
  30. 微信公众号文章：https://mp.weixin.qq.com/s/JPhcyDc4JwRmnMQ-76A-FQ?scene=334