本地小模型的Claude Code来了，拆解它的完整 Harness！

最近 Agent 圈一直在讨论 Harness 和 Loop

Claude Code 之父 Boris Cherny 在访谈里提到，他现在不再只是手动提示 Claude，而是让一堆 loops 持续运行；这些 loops 会去提示 Claude，并判断下一步该做什么。他的工作，正在变成"写循环"。

OpenClaw 之父 Peter Steinberger 也表达过类似观点：未来使用编程 Agent，不应该只是给 Agent 写 prompt，而是设计一套循环机制，让这些循环去提示 Agent、观察结果、决定下一步。

在过去，Prompt Engineering 关注的是：这一轮怎么提示模型。Loop Engineering 关注的是：模型如何一轮轮观察、行动、接收反馈。Harness Engineering 关注的是：这些循环运行在什么系统里，如何长期稳定、可控、低成本地工作。

Harness 这一层目前还没有标准答案。但最近有一个很棒的开源项目：Zleap-Agent，一个自带稀疏注意力机制的 Agent Harness，专为本地小模型设计。

某种程度上，Zleap-Agent 是本地小模型的 Claude Code。

它把 Workspace-first 作为整个 Harness 的设计核心：工作区怎么切，记忆怎么分层，哪些内容提前进入上下文，哪些内容按需召回，哪些经验可以复用，哪些业务事实必须隔离。这样，模型不用每一步都实现一整套 Harness，而是只会领取当前任务用得上的那一份，上下文和成本就能一起省下来。

如果把 Agent 看成一个会行动的系统，那么 Harness 至少要解决五件事：

如果缺少统一组织方式，这五个问题最后往往会退化成长 Prompt：工具、记忆、历史不断追加，筛选压力重新回到模型身上。

而 Zleap-Agent 给出的解法是 Workspace-first。

它的思路很简单：不要先问 Agent 能接多少工具，而是先问当前任务应该发生在哪个工作区。写代码、查资料、处理文件、做销售复盘、看财务报销，本来就不应该共享同一个上下文空间。不同任务需要不同工具、不同记忆、不同权限，有时甚至需要不同模型。

具体做法，是先把 Agent 的运行环境切成不同工作区。

Main Workspace 负责理解用户目标和任务调度；Web Search Workspace 负责搜索、网页阅读、引用整理；CLI Workspace 负责文件读取、编辑、命令执行和测试；业务 Workspace 负责销售、财务、运营、研究等具体场景。每个 Workspace 都有自己的 prompt、tools、memory、history、model 和 permission。Agent 进入哪个 Workspace，就只加载当前工作区需要的内容。

这里给大家科普一下 Workspace、子 Agent 和工具分组的区别。

子 Agent 更像临时找另一个人帮忙，有自己的角色和上下文，做完后把结果交回来。Workspace 更像同一个人切换工作台：人还是同一个人，但眼前的软件、资料、工具和权限变了。

所以，Zleap-Agent 的这一套方法可以先总结成一句话：先选工作区，再组装上下文。

也就是说，不让 Agent 每一步都加载全部工具、记忆和历史，而是让它在当前任务所需的信息范围内工作。

Zleap-Agent 这套设计相当完整，值得拆开来看。接下来，我们顺着它的设计，按 Context、Tools、Memory、Runtime、Boundary 五个问题，看它的 Harness 具体是怎么设计的。

过去一年，长上下文模型发展很快。上下文窗口变大之后，很容易产生一个错觉：既然模型能装下更多 token，那就把工具、历史、记忆、规则都放进去。但窗口变大，不代表注意力变便宜。

OpenClaw 的 context 文档里有一个很直观的数据：一次运行中，system prompt 约 38,412 字符，tool schemas 约 31,988 字符。

也就是说，任务还没真正展开，系统说明、项目上下文、skills 列表、工具 schema 已经占用了大量上下文预算。更重要的是，tool schemas 虽然不一定以普通文本展示给用户，但它们仍然会发送给模型，并计入上下文。

这里看一个小案例：销售复盘 Agent。用户说："帮我复盘一下这个客户为什么迟迟没有成交。"粗暴做法是把 CRM 记录、邮件、会议纪要、销售方法论、公司产品文档、历史对话全部塞进去。更好的做法，是先拆 context：当前客户最近三次沟通记录、当前销售阶段和合同状态、用户个人偏好可以预取；完整会议纪要和历史邮件不要一开始全塞，只保留摘要，必要时再读取；公司所有销售方法论也不要全塞，只带入和"客户复盘"相关的经验摘要。

这传递出 Harness 的第一层价值：它不只是拼 prompt，而是在每一轮帮模型做上下文装配。尤其是本地小模型，它本来就没有那么强的长上下文定位能力。如果把几十个工具、几百条历史、各种规则和记忆全部塞进去，它不是先变聪明，而是先被迫做信息筛选。

Zleap-Agent 在 Context 这一层的设计，比较关键的一点是：Main Workspace 不直接承担所有上下文。Main 更像调度台，负责理解用户目标、判断任务应该进入哪个工作区，并把必要背景带过去。进入具体 Workspace 之后，模型看到的是当前工作区的 prompt、工具、记忆和历史，而不是整段主对话的完整回放。

这个设计和 OpenClaw 的长上下文压力形成了一个很好的对照。OpenClaw 展示了真实 Agent 会自然堆出很厚的 system prompt 和 tool schemas；Zleap 的解法则是提前把上下文按工作区切开，让每一轮模型请求只携带当前任务需要的信息。它不是靠模型在长上下文里自行筛选，而是让 Harness 先把信息范围收窄。

工具是 Agent 的手，但工具太多也会变成负担。

每个 tool schema 都会增加模型要理解的动作空间。工具越多，模型越容易在无关能力之间摇摆。更现实的问题是，工具越多，权限面也越宽，审计和安全成本会变高。这也是 Zleap-Agent 在工具层最先处理的问题：工具暴露得越全局，风险面越大。

OpenClaw 是一个很好的观察样本。它把个人 Agent 做成一个本地常驻 Gateway，可以接入 WhatsApp、Telegram、Slack、Discord、Signal、iMessage、WebChat 等消息入口，也能通过 CLI、Web UI、automations、nodes 等连接本地能力。

这说明个人 Agent 不一定只是聊天框，它可以成为一个长期在线的本地控制平面。但也正因为它能接很多工具，Harness 必须回答一个问题：这一轮到底应该暴露哪些工具？

看一个小案例：查资料任务和改文件任务。用户说"帮我查一下这个技术方案最近有没有新进展"，这时 Agent 需要的是搜索、网页读取、网页摘要、引用整理，不需要 shell、文件删除、数据库写入。用户说"帮我改一下这个项目里的配置文件"，这时 Agent 需要的是文件读取、文件编辑、命令执行、测试运行，不一定需要联网搜索，也不应该看到所有业务系统工具。

所以工具设计的核心不是"接了多少工具"，而是"在什么空间里可见"。Workspace-first 的方法，就是把工具挂在工作区上：Web Search Workspace 暴露搜索和阅读工具，CLI Workspace 暴露文件和命令工具，财务 Workspace 暴露报销、预算、审批相关工具。模型进入哪个工作区，就只看到当前工作区的工具。这比全局工具池更稳，也更容易做权限控制。

Zleap-Agent 在工具层的做法很直接：将工具跟 Workspace 绑定，不再全局暴露。这样，Main Workspace 就只会保留调度、读取历史、召回记忆、任务管理和最终交付这类工具；CLI Workspace 才能读写文件、搜索项目、执行命令；Web Search Workspace 才能搜索网页和读取网页内容。

这个拆法的好处是，模型在每个空间里只面对一组更小、更明确的动作集合。查资料时不会看到文件删除和 shell 命令，改项目时也不会默认加载网页搜索工具。工具面缩小之后，tool schema 成本、误调用概率和权限审计压力都会下降。

记忆是 Agent 超级容易被低估的部分。在普通应用里，保存数据就是写入数据库。但在 Agent 系统里，记忆会影响未来推理。写错、取错、串到别的任务里，都会影响后续行为。

Hermes Agent 相关的 Channel Fracture 案例就说明了这个问题。论文分析了一个生产环境里的 Hermes Agent 部署，系统里有多个 specialized profiles，并尝试让定时任务 Agent 向目标 Agent 注入持久记忆。实验比较了三条路径：直接写 SQLite、目标 Agent 通过 memory tools 自写入、cron delegated 写入。结果 cron 路径因为 skip_memory=True 和 memory manager 初始化条件，出现了"看似完成、实际未送达"的通道断裂。

这个案例给我们的启发是：记忆系统不能只看"有没有存储"，还要看完整链路。谁写入，写给谁，通过什么通道写入，有没有确认送达，未来什么时候会被检索出来，会不会污染别的用户或别的任务，这些都要被设计清楚。

Zleap-Agent 最新记忆层更新，给这个问题拆得很细节。它把记忆分成两条线：A 线处理 people notes，B 线处理 core records。

A 线保存用户偏好、稳定画像、Agent 自身认知这类轻量记忆；B 线保存工作事件和可复用经验。两条线的读写方式不同：people notes 更适合快速预取，core records 则进入抽取、向量化、实体关联、召回和精排链路。

这个设计比「长期记忆桶」更适合真实任务。用户偏好不应该和项目事实混在一起，项目事实不应该和可复用经验混在一起，一次性的业务数据也不应该污染经验库。

再看一个小案例：周报 Agent 和客户复盘 Agent。用户偏好，比如"我喜欢先看结论"，这是人的记忆，应该跟用户绑定；某个客户上次卡在合同审批，这是事情的记忆，应该绑定到销售工作区和对应客户；"写周报时按目标、进展、风险、下周计划组织"，这是经验的记忆，可以脱敏后复用给更多人。

Zleap-Agent 这次更新里，经验记忆还有更明确的准入规则。它更像一套「方法库」，只记录可复用流程、失败模式、验证习惯和恢复策略；公司名、客户名、项目名、财务事实、私有路径、一次性任务结果，都不应该进入经验记忆。这样经验可以被复用，但不会把业务隐私和临时事实带到别的任务里。

另一个值得看的点是 Memory Dream。它可以理解为离线记忆整理器：不在用户实时对话里抢上下文，而是在后台从经过清理的会话材料中提取稳定画像和可复用经验。事件/工作记忆走另一条链路，经验记忆则要经过脱敏和可复用性判断。这样一来，Agent 不必每轮都把完整历史塞进上下文，也不必把所有历史都当成长期记忆。

Zleap-Agent 的 recall 也分成快慢两层。prefetch 用 fast 模式，不走 LLM，主要把用户画像、近期工作事件、常用经验快速放进上下文；主动 recall 才走更精细的检索和 rerank。这个拆法很重要：如果每次记忆读取都依赖大模型，延迟和成本会被放大；如果完全不做精排，召回质量又容易不稳定。快取和精取分开，才能兼顾响应速度和记忆质量。

因此，记忆至少应该按"人、事、经验"分区：人的记忆记录用户偏好，事情的记忆记录某个工作区里的项目事实，经验的记忆沉淀脱敏后的方法。进一步看，记忆还需要抽取、去重、更新、归档和召回策略。Zleap-Agent 里的 B 线 record memory 会把会话片段抽取成结构化事件，并通过向量、关键词、实体和图关系做召回；新记忆进入系统时，还会和旧记忆做 reconcile，判断是跳过、并存、替换旧记忆，还是保留旧记忆。

这种分区和治理机制，让记忆的归属更清楚，也降低了跨用户、跨任务、跨工作区污染的风险。

Agent Loop 不是模型输出一句话那么简单。一次真实运行里，模型会读上下文、选工具、调用工具、接收结果、修正计划、再次调用工具。中间可能失败、重试、切换策略，也可能写入记忆或修改文件。

如果没有运行轨迹，出错后很难判断问题在哪里：是模型能力不够，是工具说明写得不清楚，是上下文带错了，是记忆读错了，还是某个工具返回了误导信息？

WildClawBench 在真实 CLI harness 中评估 OpenClaw、Claude Code、Codex、Hermes Agent 等环境，结果显示，同一个模型切换不同 harness，表现最高可以相差 18 个百分点。Agentic Harness Engineering 的实验也显示，通过多轮 harness 演化，Terminal-Bench 2 pass@1 从 69.7% 提升到 77.0%，收益主要来自 tools、middleware、long-term memory，而不是单纯改 system prompt。

一个小案例是：代码修复 Agent 必须记录失败路径。用户让 Agent 修一个测试失败的问题。Agent 读取报错，修改代码，运行测试。如果测试失败，它不能只说"失败了"，而应该记录自己读取了哪些文件，为什么选择修改这个函数，执行了什么命令，命令返回了什么错误，下一轮又根据什么信息调整方案，以及最终测试是否通过。

Zleap-Agent 把这部分单独拆成了一个 runtime 模块，运行状态和记忆共用同一套 PostgreSQL 持久化，而不是只在进程内存里跑一遍就丢掉。这样运行轨迹本身也能被审计和回滚：出问题时可以倒回去看某一步具体读了什么、调了什么工具、拿到了什么结果，而不只是看最后一条报错。

这些轨迹决定了系统能不能定位失败原因、复现执行过程，并为后续优化提供依据。Prompt 主要作用于单轮输入输出；Harness 还要管理执行过程、状态变化、失败恢复和后续优化。

Agent 越接近真实业务，边界越重要。企业场景和个人玩具不一样。数据不能随便出内网，成本不能无限往上堆，权限不能只靠模型自觉，记忆不能在用户之间串，工具也不能对所有任务开放。

这也是本地小模型重新变得重要的原因。很多企业不会默认所有任务都交给最贵、最大的云端模型。敏感数据最好在本地处理，常规流程可以用便宜模型，复杂分析再交给更强模型。

看一个小案例：财务报销 Agent。用户问："帮我看看这张报销单为什么没过。"这个任务可能需要读取发票、预算、审批规则、历史报销状态。但它不应该看到销售客户记录，也不应该调用研发代码工具。涉及敏感票据信息时，可以优先走本地模型；需要复杂规则解释时，再由工作区决定是否调用更强模型。

Zleap 的 Workspace 设计让这种模型路由更自然：不同工作区可以绑定不同模型。常规沟通、网页检索、文件处理、复杂分析、本地敏感任务，不必都交给同一个模型处理。对本地小模型和企业私有化场景来说，这种路由方式可以同时控制成本、延迟和数据边界。这也是 Zleap-Agent 强调的多模型协作机制：不是把所有任务都交给同一个最强模型，而是按工作区分配合适的模型。

这就是边界设计：数据边界、工具边界、模型边界、记忆边界都要控制住。

到这里再回看 Workspace-first，它其实是在同时处理这五个问题：Context 被限制在当前工作区里，Tools 按工作区暴露，Memory 按用户、工作区和类型分区，Runtime 记录每次循环发生在哪个工作区，Boundary 则落到权限、模型和数据访问规则上。

OpenClaw 展示了个人 Agent 如何接入真实工作流；Hermes 的案例提醒我们，记忆写入需要验证完整通道；Zleap-Agent 更关注的是，当工具、上下文和记忆越来越多时，Harness 如何控制可见范围，并把记忆变成可治理的系统。

如果把上面这套方法落到一个具体系统里，Zleap-Agent 是一个值得观察的开源样本。它没有把 Agent 设计成一个不断扩张的全局 Prompt，而是把 Workspace 作为上下文、工具、记忆和模型的隔离层。

Main Workspace 负责理解目标和调度，CLI / Web Search / 业务 Workspace 负责具体执行；记忆按人、事、经验分区；上下文按 System Prompt、Workspace Prompt、Tools、Memory、History 组装。这样的结构让 Agent 不必在每一步加载所有工具、记忆和历史，而是在当前任务所需的信息范围内工作。

进一步看，这种设计其实是在把 context 当成一种内存布局：

Context = System Prompt + Workspace Prompt + Tools + Memory + History

System Prompt 保持全局行为风格，Workspace Prompt 说明当前工作区，Tools 只暴露当前工具，Memory 只取相关记忆，History 保留必要近期轨迹。

上下文还可以分成两种加载方式。Prefetch 是提前放进来的内容，比如用户偏好、当前工作区最近事件、常用经验，它应该短、准、可控。Agentic 是按需读取，比如模型看到一条旧记忆摘要，用户追问"详细说说"，再去读完整详情。预取过多会抬高上下文成本；全部按需读取又会增加交互轮次和失败点。Harness 要明确规定，哪些提前带入，哪些按需读取。

最后是数据库驱动。数据库驱动让 Agent 的运行过程具备分区、审计、回滚和复用能力。多个用户共享同一个 Agent 时，谁能看谁的记忆、哪个工作区能读哪些上下文、哪些经验可以共享，都需要底层系统管理。

回到开头的问题：Agent 圈从讨论 Prompt 走到讨论 Loop，再走到讨论 Harness，其实都是因为单轮提示词已经不够用了，接下来要处理的是循环怎么跑、系统怎么撑住这些循环。

Zleap-Agent 提供了一套可以拿来参考的 Harness 设计，解决了一个大家都会遇到的问题：当上下文、工具、记忆都会不断膨胀时，怎么让 Agent 只看该看的那部分。

Workspace-first 是它给出的答案，但这个思路本身可以脱离 Zleap-Agent 单独使用：不管用什么模型、什么框架，先切工作区、再组装上下文，都是一个值得参考的起点。

对本地小模型和企业私有化场景来说，这套设计尤其有意义。上下文更省，权限更容易隔离，多模型协作也更自然。模型层做稀疏注意力，是为了让模型不要看所有 token；Harness 层做 Workspace，是为了让 Agent 不要加载所有上下文。

Zleap-Agent 目前还在持续更新，这篇文章只是梳理了它现阶段的设计思路，感兴趣可以去看代码和文档。

项目地址：https://github.com/Zleap-AI/Zleap-Agent

点个在看你最好看

SPRING HAS ARRIVED