Level 0导学：Agent Harness 与职业转型免费

Pi、Hermes、Fiitx、OpenClaw 的角色分工

理解 prompt 使用者、应用开发者和 Agent 工程师之间的能力边界。

讲解

Pi、Hermes、Fiitx、OpenClaw 的角色分工

「Pi、Hermes、Fiitx、OpenClaw 的角色分工」可以理解为：把 Pi Core、Hermes Worker、Fiitx Workbench、OpenClaw 入口和 Agent 工程师之间的能力边界写成可执行、可观察、可恢复、可验收的 Harness 单元。它的直接产物不是一段 prompt，而是角色矩阵、handoff contract 和责任冲突测试。这一讲的目标，是把概念落到边界、架构图、工程对象、代码对比和验收证据。

一句话定义本讲是什么

边界角色责任

它不负责替模型“想得更聪明”，也不把所有逻辑塞进 chat wrapper。它负责划清角色责任，让学习目标到工程任务的转换、Agent Harness 控制面和角色矩阵、交付物清单、验收证据都能被追踪。

反例把 prompt、App UI 和 Agent Runtime 混成一个概念

如果实现会导致「把 prompt、App UI 和 Agent Runtime 混成一个概念」，说明边界没有建立起来，需要回到输入合同、policy 或 runtime 重新切分。

验收角色矩阵、handoff contract 和责任冲突测试

完成标准是交付角色矩阵、handoff contract 和责任冲突测试，留下角色矩阵、交付物清单、验收证据，并能用能否清楚说明谁拥有上下文、工具、权限和交付复盘。

可以这样理解它不负责替模型“想得更聪明”，也不把所有逻辑塞进 chat wrapper。它负责划清角色责任，让学习目标到工程任务的转换、Agent Harness 控制面和角色矩阵、交付物清单、验收证据都能被追踪。程序员在这一讲要完成的转变是：从“我会调用模型或工具”转到“我能设计 Agent Harness 控制面，并用能否清楚说明谁拥有上下文、工具、权限和交付判断它是否真的完成”。

角色分工架构图

Rendering Mermaid...

Mermaid 源码

flowchart LR
  input["输入合同"] --> boundary["角色责任"]
  boundary --> route["学习目标到工程任务的转换"]
  route --> runtime["Agent Harness 控制面"]
  runtime --> policy{"策略/权限"}
  policy -->|allow| tool["模型与工具"]
  policy -->|block| blocked["把 prompt、App UI 和 Agent Runtime 混成一个概念"]
  tool --> state["状态与事件"]
  runtime --> state
  state --> evidence["角色矩阵、交付物清单、验收证据"]
  evidence --> artifact["角色矩阵、handoff contract 和责任冲突测试"]
  artifact --> eval["验收"]

  classDef inputNode fill:#eef4ff,stroke:#4664ff,color:#0b1220;
  classDef runtimeNode fill:#ecfdf5,stroke:#10b981,color:#0b1220;
  classDef gate fill:#fff7ed,stroke:#f59e0b,color:#0b1220;
  classDef stop fill:#fee2e2,stroke:#ef4444,color:#0b1220;

  class input,boundary,route inputNode;
  class runtime,tool,state,evidence,artifact,eval runtimeNode;
  class policy gate;
  class blocked stop;

Hermes / Pi / Fiitx 关系

框架	可借鉴的设计	本讲怎么用
Hermes	入口、AIAgent、工具分发、Session Storage、Gateway/Cron	判断学习目标到工程任务的转换是否具备长期运行和交付边界
Pi Agent Core	AgentSession、事件流、resource loader、compaction、save point	实现 Agent Harness 控制面和可恢复 turn lifecycle
Fiitx	Workbench、进度流、审批 UI、模型路由、历史回放	把角色矩阵、交付物清单、验收证据做成用户可见的控制面
Eval	done criteria、trace、failure case、regression	证明角色矩阵、handoff contract 和责任冲突测试满足验收标准

代码对比从 LLM 调用到 Harness 运行

普通 LLM 调用只返回回答。Harness 运行必须把目标、边界、工具、策略和验收写成参数。

// 普通 LLM 写法：只拿到一段回答，缺少边界、状态和验收
const answer = await model.generate({
  prompt: "实现：Pi、Hermes、Fiitx、OpenClaw 的角色分工"
});

// Agent Harness 写法：把目标、工具、策略、状态和验收写进运行合同
const result = await harness.runHarnessOrientation3({
  lesson: "0.3 Pi、Hermes、Fiitx、OpenClaw 的角色分工",
  goal: "实现：Pi、Hermes、Fiitx、OpenClaw 的角色分工",
  boundary: "角色责任",
  runtime: "Agent Harness 控制面",
  route: "学习目标到工程任务的转换",
  tools: runtime.tools.forBoundary("角色责任"),
  policy: {
    watch: "把 prompt、App UI 和 Agent Runtime 混成一个概念",
    requireEvidence: true
  },
  eval: [
    "trace_complete",
    "artifact_exists",
    "policy_checked",
    "harness_orientation_3_accepted"
  ]
});

assert(result.artifact === "角色矩阵、handoff contract 和责任冲突测试");
assert(result.evidence.includes("角色矩阵、交付物清单、验收证据"));

关键点

1
定义：「Pi、Hermes、Fiitx、OpenClaw 的角色分工」可以理解为：把 Pi Core、Hermes Worker、Fiitx Workbench、OpenClaw 入口和 Agent 工程师之间的能力边界写成可执行、可观察、可恢复、可验收的 Harness 单元。它的直接产物不是一段 prompt，而是角色矩阵、handoff contract 和责任冲突测试。
2
边界：它不负责替模型“想得更聪明”，也不把所有逻辑塞进 chat wrapper。它负责划清角色责任，让学习目标到工程任务的转换、Agent Harness 控制面和角色矩阵、交付物清单、验收证据都能被追踪。
3
代码：普通调用只拿 answer，Harness 调用必须返回 artifact、evidence 和 trace。
4
验收：交付角色矩阵、handoff contract 和责任冲突测试，留下角色矩阵、交付物清单、验收证据，并防住「把 prompt、App UI 和 Agent Runtime 混成一个概念」。