84 lines
5.7 KiB
Markdown
84 lines
5.7 KiB
Markdown
---
|
||
title: "Zleap-Agent：Workspace-first 的 Agent Harness 设计"
|
||
created: 2026-07-03
|
||
updated: 2026-07-03
|
||
type: article
|
||
tags: ["agent", "harness", "workspace", "memory", "context-management", "local-model"]
|
||
sources: ["https://mp.weixin.qq.com/s/iiTmgbtrYHMMjQ7dn7CDrg"]
|
||
---
|
||
|
||
# Zleap-Agent：Workspace-first 的 Agent Harness 设计
|
||
|
||
> 作者：陈思州 (Datawhale) | 来源：[原始存档](raw/articles/zleap-workspace-harness-2026.md) | 代码仓库：[Zleap-AI/Zleap-Agent](https://github.com/Zleap-AI/Zleap-Agent)
|
||
|
||
## 核心命题
|
||
|
||
Agent 圈正经历从 **Prompt Engineering** → **Loop Engineering** → **Harness Engineering** 的范式演进。单轮提示词已不够用，接下来要处理的是「循环怎么跑、系统怎么撑住这些循环」。Zleap-Agent 提供了一套以 **[[workspace-first-architecture|Workspace-first]]** 为核心的 Harness 设计方案——专为本地小模型设计的 Agent 执行骨架。
|
||
|
||
## 核心思想：Workspace-first
|
||
|
||
```
|
||
不要先问 Agent 能接多少工具，而是先问当前任务应该发生在哪个工作区。
|
||
```
|
||
|
||
写代码、查资料、处理文件、做销售复盘——本来就不应该共享同一个上下文空间。Zleap 的解法是把 Agent 运行环境切成不同工作区，每个工作区有自己的 prompt、tools、memory、history、model 和 permission。Agent 进入哪个 Workspace，就只加载当前工作区需要的内容。
|
||
|
||
**Workspace vs 子 Agent vs 工具分组**：子 Agent 是临时找人帮忙（有独立角色和上下文），Workspace 是同一个人切换工作台（软件、资料、工具变了，但人没变），工具分组只是工具层面的归类。
|
||
|
||
## 五维度 Harness 设计
|
||
|
||
### 1. Context：上下文装配
|
||
|
||
Context = System Prompt + Workspace Prompt + Tools + Memory + History
|
||
|
||
Main Workspace 只做调度，不承载所有上下文。进入具体 Workspace 后，模型只看到当前工作区的 prompt、工具、记忆和历史。Harness 提前把信息范围收窄，而非靠模型在长上下文里自行筛选。
|
||
|
||
加载方式分两层：[[context-prefetch-vs-agentic|Prefetch（提前带入）vs Agentic（按需读取）]]。Prefetch 要短、准、可控（用户偏好、工作区最新事件、常用经验）；Agentic 是模型看到摘要后追问详情时再读取完整内容。
|
||
|
||
### 2. Tools：工具-工作区绑定
|
||
|
||
[[tool-workspace-binding|工具不再全局暴露]]——Main Workspace 只保留调度/记忆/交付工具，CLI Workspace 才能读写文件、执行命令，Web Search Workspace 才能搜索网页。模型在每个空间里只面对一组更小、更明确的动作集合，tool schema 成本、误调用概率和权限审计压力都下降。
|
||
|
||
### 3. Memory：记忆三分区
|
||
|
||
记忆被分成两条线：A 线 **people notes**（用户偏好、稳定画像）和 B 线 **core records**（工作事件 + 可复用经验）。本质上是一种 [[memory-tripartite-partition|人/事/经验三分区]]——用户偏好绑定人，项目事实绑定工作区和客户，可复用方法脱敏后共享。
|
||
|
||
- **[[memory-dream|Memory Dream]]**：离线记忆整理器，不在实时对话里抢上下文，而是在后台从会话材料中提取稳定画像和可复用经验
|
||
- **[[memory-recall-fast-slow|快慢召回]]**：prefetch 用 fast 模式（不走 LLM），主动 recall 走精细检索和 rerank
|
||
- 经验记忆准入规则：只记录可复用流程、失败模式、验证习惯和恢复策略；业务隐私和临时事实不入经验库
|
||
- **reconcile 机制**：新记忆入库时与旧记忆比对，判断跳过 / 并存 / 替换 / 保留旧记忆
|
||
|
||
引用了 [[channel-fracture|Hermes Agent Channel Fracture]] 案例——记忆写入需验证完整通道，不能只看"有没有存储"。
|
||
|
||
### 4. Runtime：运行轨迹持久化
|
||
|
||
[[agent-runtime-trace|每次循环都留下可复盘的轨迹]]——运行状态和记忆共用 PostgreSQL 持久化。出问题时可以倒回去看某一步读了什么、调了什么工具、拿到什么结果。对应的实验证据：WildClawBench 中同一模型切换 harness 表现差 18 个百分点，Agentic Harness Engineering 实验通过 harness 演化使 Terminal-Bench 2 pass@1 从 69.7% 提升到 77.0%。
|
||
|
||
### 5. Boundary：边界控制
|
||
|
||
[[agent-boundary-design|数据边界、工具边界、模型边界、记忆边界]]——企业场景中数据不能随便出内网，记忆不能在用户之间串。Zleap 的 Workspace 设计天然支持 [[multi-model-routing|多模型路由]]：不同工作区可绑定不同模型，敏感数据走本地模型，复杂分析走强模型，同时控制成本、延迟和数据边界。
|
||
|
||
## 关键洞察
|
||
|
||
> 「模型层做稀疏注意力，是为了让模型不要看所有 token；Harness 层做 Workspace，是为了让 Agent 不要加载所有上下文。」
|
||
|
||
Workspace-first 是一个可以脱离 Zleap-Agent 单独使用的设计范式：不管用什么模型、什么框架，先切工作区、再组装上下文，都是一个值得参考的起点。
|
||
|
||
## 相关概念
|
||
|
||
- [[harness-engineering|Harness Engineering]] — 学科定位
|
||
- [[agent-harness-engineering|Agent Harness Engineering]] — 七维度框架
|
||
- [[loop-engineering|Loop Engineering]] — 循环工程
|
||
- [[prompt-engineering|Prompt Engineering]] — 提示工程
|
||
- [[context-management|上下文管理]]
|
||
- [[workspace-first-architecture|Workspace-first 架构]]
|
||
- [[tool-workspace-binding|工具-工作区绑定]]
|
||
- [[memory-tripartite-partition|记忆三分区]]
|
||
- [[memory-dream|Memory Dream]]
|
||
- [[memory-recall-fast-slow|快慢召回]]
|
||
- [[agent-runtime-trace|Agent 运行时追踪]]
|
||
- [[agent-boundary-design|Agent 边界设计]]
|
||
- [[multi-model-routing|多模型路由]]
|
||
- [[context-prefetch-vs-agentic|上下文预取 vs 按需]]
|
||
- [[channel-fracture|Channel Fracture]]
|