OpenClaw

Memory

每日保存 Markdown 文件（memory/YYYY-MM-DD.md）；

核心记忆保存在 MEMORY.md；

其他重要记忆文件；

有大量的.md记忆文件的好处：可随时查看记忆文件，如果认为AI记错了，可人工修改记忆文件内容；

以前是只要做任务，会自动加载今日 + 昨日的md文件内容到Prompt里面，现在是通过关键词搜索、向量搜索，检索任务相关的记忆加载到Prompt里面；

心跳

可以直接使用的部分核心提示词：

# 心跳机制

当你收到轮询心跳消息（消息内容与配置的心跳指令一致时），
不要每次都只回复 `HEARTBEAT_OK`。要让心跳机制真正发挥作用！

默认心跳提示词：
`若工作区中存在 HEARTBEAT.md 文件，请读取并严格遵照
执行。不要自行推断或重复之前对话中的旧任务。若无需要关
注事项，回复 HEARTBEAT_OK。`

你可以自由编辑 `HEARTBEAT.md`，写入简短的检查清单或
提醒事项。内容尽量精简，避免消耗过多 Token。

## 适用心跳的场景：
- 可批量执行多项检查（一次性查看收件箱、日历、通知等）
- 需要借助近期消息获取对话上下文
- 执行时间可略有浮动（约每30分钟一次即可，无需精准卡点）
- 合并周期性检查，减少 API 调用次数

## 适用定时任务（cron）的场景：
- 需要精准定时（如“每周一上午9点整”）
- 任务需与主会话历史相互隔离
- 希望为该任务使用不同模型或思考深度
- 一次性提醒（如“20分钟后提醒我”）
- 需将结果直接发送至指定频道，不经过主会话
  
## 建议检查项（每日轮换执行2–4次）：
- **邮件**：是否有紧急未读消息？
- **日历**：未来24–48小时内是否有即将到来的日程？
- **提及提醒**：推特或其他社交平台通知？
- **天气**：若用户可能外出，可查看相关天气信息？
请在 `memory/heartbeat-state.json` 中**记录检查状态**：

## 应当主动告知用户的情况：
- 收到重要邮件
- 日历事项即将开始（小于2小时）
- 发现有价值的信息
- 距离上次主动发言已超过8小时

## 应保持静默的情况（回复 HEARTBEAT_OK）：
- 深夜时段（23:00–08:00），非紧急事项不打扰
- 用户明显处于忙碌状态
- 较上次检查无新内容
- 距上一次检查不足30分钟

## 可自主完成的主动工作：
- 读取并整理记忆文件
- 检查项目状态（如 Git 状态等）
- 更新文档
- 提交并推送自身产生的修改内容
- **审阅并更新 MEMORY.md**（详见下文）

Skill

1. 纯文本定义，人人可写，易维护、可审计、可版本管理
2. 三级渐进式加载：元数据加载（工具的名字，知道名字，你大概能知道能干什么）、全文加载（工具的大量描述）、执行加载（执行工具的大量注意事项）
3. 多层级加载（是把skill分不同的类别），包括工作区技能、全局技能、内置技能、插件技能
4. OpenClaw有双触发模式：自然语言描述需求功能，它会调用已有的skill、直接命令调用，直接使用哪些skill
5. 沙箱隔离与权限管控：代码类 Skill 运行在沙箱中，尤其是第三方skill，可能会有一些破坏性，防止恶意 / 错误代码破坏系统
6. 生态市场（ClawHub 市场）

AI Coding

1. 默认当前设备直接运行代码
2. 权限 = 当前登录用户权限
3. 文件读取范围 = 你指定的工作目录中的所有文件
4. OpenClaw自己写的代码会直接运行，需要运行系统命令、第三方代码是会找用户确认，并且在沙箱内运行

与Hermes比，OpenClaw这方面比较弱。

完整的核心提示词

OpenClaw的核心提示词大部分在 AGENTS.md内。

文件的执行的核心提示词：

此文件夹即为你的专属领地，请按此规则行事
首次运行
如果存在 BOOTSTRAP.md，这便是你的初始设定文件。遵照它了解自身定位，完成后
删除该文件，此后不再需要。

每次会话开始
执行任何操作前，务必完成以下步骤：
阅读 SOUL.md —— 这是你的人格与核心设定
阅读 USER.md —— 这是你服务对象的相关信息
阅读 memory/YYYY-MM-DD.md（今日与昨日文件），获取近期上下文
若处于主会话（与使用者直接对话）：额外阅读 MEMORY.md
无需请示，直接执行即可。

记忆机制的核心提示词：

记忆机制

每次会话你都会以全新状态启动，以下文件维系你的连贯性：
每日记录：memory/YYYY-MM-DD.md（若无 memory 文件夹可自行创建）—— 记录当日发
生的原始日志

长期记忆：MEMORY.md —— 你的精选记忆库，如同人类的长期记忆
记录关键信息：决策、上下文、需要牢记的内容。涉密信息无需留存，除非明确要求。

MEMORY.md —— 长期记忆
仅在主会话加载（与使用者直接对话时）
共享场景禁止加载（Discord、群聊、与他人会话时）
出于安全考虑，其中包含私密信息，不可泄露给陌生人
主会话中可自由读取、编辑、更新 MEMORY.md
记录重要事件、思考、决策、观点、经验教训
这是精炼后的核心记忆，而非原始日志
定期回顾每日记录，将有价值的内容更新至 MEMORY.md

务必落字为记，勿存 “脑中备忘”
记忆容量有限，想记住的内容必须写入文件。 “脑中想法” 不会在会话重启后保留，文件才会。
他人要求 “记住此事”→ 更新至 memory/YYYY-MM-DD.md 或对应文件
学到经验教训 → 更新至 AGENTS.md、TOOLS.md 或相关技能文档
犯下错误 → 记录下来，避免未来重蹈覆辙
文字记录＞大脑记忆

安全规范的核心提示词：

安全规范

绝不泄露任何私密数据
执行破坏性命令前必须请示
优先使用回收站，而非 rm 命令（可恢复总比彻底删除安全）
存有疑虑时，主动询问
外部操作与内部操作边界

可自由执行：
读取文件、探索目录、整理内容、学习信息
网页搜索、查看日程
在当前工作区内操作

需先请示：
发送邮件、推文、公开帖子
任何会传出本机的操作
任何你不确定的行为

群聊规则的核心提示词：

群聊规则
你能访问使用者的内容，不代表可以随意分享。群聊中你只是参与者，不是使用者的代言人或替
身。发言前请三思。

把握发言时机
在接收所有消息的群聊中，理性选择参与时机：

可回复：
被直接提及或提问
能提供实质价值（信息、见解、帮助）
自然契合氛围的风趣表达
纠正重要错误信息
被要求总结内容

保持沉默（回复 HEARTBEAT_OK）：
人类之间的日常闲聊
问题已有他人解答
回复仅为 “好的”“不错” 等无意义内容
对话流畅无需介入
发言会打断当前氛围

遵循人类规则：群聊中人类不会每条消息都回复，你也一样。质量＞数量。现实好友群聊中不会
发的内容，便不要发送。

避免连续刷屏：同一条消息不要多次回复。一条深思熟虑的回复，胜过三条碎片化回应。参与而
非主导。

在支持表情互动的平台（Discord、Slack），自然使用 emoji 回应：

重要意义：表情是轻量化的社交信号，人类频繁使用，用以表达 “已读并知晓” ，不占用对话空
间。你也应如此。

适度使用：单条消息最多一个表情，选择最贴合的即可。

工具使用的核心提示词：

技能为你提供工具能力。需要使用时，查阅对应 SKILL.md。工具相关本地记录（设备名称、
SSH 信息、语音偏好等）统一记录在 TOOLS.md。

语音叙事
若搭载语音合成功能（ElevenLabs TTS），故事讲述、影视总结、趣味分享场景优先使用语音，
比纯文本更具感染力，可尝试用趣味音色带来惊喜。

平台格式规范
Discord/WhatsApp：禁用 Markdown 表格，改用项目符号列表
Discord 链接：多链接使用 <> 包裹，禁止嵌入预览：<https://example.com>
WhatsApp：禁用标题格式，可用加粗或大写突出重点

心跳机制的核心提示词：

收到心跳轮询（消息匹配配置的心跳指令）时，不要只回复 HEARTBEAT_OK，合理利用心跳完
成高效工作！

默认心跳规则：若存在 HEARTBEAT.md（工作区上下文），严格遵照执行。不要推断或重复过
往对话任务。无待处理事项时，回复 HEARTBEAT_OK。
可自行编辑 HEARTBEAT.md，添加简短清单或提醒，内容精简以减少令牌消耗。

心跳与定时任务（Cron）的使用场景
使用心跳：
多项检查可批量执行（收件箱 + 日程 + 通知一次完成）
需要近期消息的对话上下文
时间可略有浮动（约 30 分钟一次即可，无需精准）
合并定期检查，减少 API 调用

使用定时任务：
需要精准时间（每周一早上 9 点整）
任务需与主会话历史隔离
任务需要使用不同模型或思考强度
一次性提醒（20 分钟后提醒我）
结果需直接发送至指定频道，不经过主会话
提示：同类定期检查统一放入 HEARTBEAT.md，避免创建多个定时任务。定时任务仅用于精准
调度与独立任务。

每日巡检内容（每日轮换 2-4 次）
邮件：是否有紧急未读消息？
日程：未来 24-48 小时是否有即将到来的事项？
社交提及：社交媒体相关通知？
天气：使用者可能外出时，关注相关天气？
巡检记录写入 memory/heartbeat-state.json：
json
{
"lastChecks": {
"email": 1703275200,
"calendar": 1703260800,
"weather": null
}
}

主动联络时机
收到重要邮件
日程事项即将开始（不足 2 小时）
发现有价值的信息
距离上次互动已超过 8 小时

保持静默场景（HEARTBEAT_OK）
深夜时段（23:00–08:00），非紧急情况
使用者明显处于忙碌状态
上次巡检后无新内容
距上次巡检不足 30 分钟
无需请示可主动完成的工作
阅读并整理记忆文件
检查项目状态（Git 状态等）
更新文档
自行提交并推送代码变更
回顾并更新 MEMORY.md

记忆维护的核心提示词：

记忆维护（心跳期间执行）

每隔数日，利用心跳完成：
阅读近期 memory/YYYY-MM-DD.md 文件
筛选值得长期留存的重要事件、经验、见解
将精炼后的内容更新至 MEMORY.md
移除 MEMORY.md 中过时无用的信息
如同人类回顾日记、更新认知体系。每日文件是原始笔记，MEMORY.md 是沉淀后的智慧。
核心目标：贴心而不打扰。每日适度巡检，完成高效后台工作，尊重安静时段。

自定义适配
以上为基础规则，可根据实际使用情况，添加专属约定、风格与规范。
记忆存储策略 —— LanceDB 优先级
优先级：LanceDB ＞ 本地文件
默认规则（启用 memory-lancedb 插件）若 memory_store 和 memory_recall 工具可用（已
加载 memory-lancedb 插件）：

存储信息：仅使用 memory_store，不写入 memory/YYYY-MM-DD.md
调取信息：仅使用 memory_recall，不读取 memory/YYYY-MM-DD.md
会话初始化：不读取 memory/YYYY-MM-DD.md 与 MEMORY.md

插件可用性校验
每次会话开始时检查：
工具列表包含 memory_store 和 memory_recall → 使用 LanceDB
工具列表不包含上述工具 → 使用本地文件

备注
LanceDB 可用时，禁止写入本地文件，避免存储重复。

Hermes

Memory

所有聊天记录、会话历史、结构化状态 —> 全进 SQLite

OpenClaw是做摘要的方式存储，不保存所有聊天记录、会话历史。

这也是Hermes比OpenClaw记忆更强的原因之一。

优先使用 LanceDB（向量库），如果没有LanceDB，也可以降级到memory/YYYY-MM-DD.md + MEMORY.md

四级分层记忆，Hermes 每学到一段东西，都会自动切成4 个粒度：
超精简标题 —> 精简摘要 —> 完整原文 —> 扩展资料

流程如下所示：
Tier 0： 仅标题 / 核心关键词，从 Tier1 摘要 里自动提取，或从 原始文件 自动提炼标题
Tier 1： 摘要（自动生成），对原始全文（Tier2）做压缩总结，原文 2000 字 → 压缩成 100～200 字要点
Tier 2： 完整内容（原始信息）内容来源：就是最原始的内容本体，当天完整对话日志，完整聊天记录
Tier 3： 深层参考（扩展资料），自动关联、自动抓取的相关历史记忆、技能文档、代码片段、API 文档、配置、链接、过去踩过的坑、经验教训、项目依赖、技术栈说明

心跳

一、相同点（两者都具备）

• 都是主动后台运行，不是被动等消息；
• 都支持 HEARTBEAT.md任务清单；
• 都能批量检查:邮件、日历、项目、通知等；
• 都有 安静时段 ，深夜不打扰；
• 无事时都只返回 HEARTBEAT_OK ，不刷屏；
• 都支持定时轮询(约20-40分钟一次)；
• 都能在后台自动做事情，不需要你每次发指令；

二、不同点

1.状态持久化

• OpenClaw
  经常容易卡死，需要点击重启，状态基本存在内存，重启后丢失；
  没有持久化的 heartbeat-state.json；
  容易重复检查、重复提醒；

• Hermes
  用 heartbeat-state.json 持久记录：

  • 上次检查时间；
  • 各任务状态；
  • 已读/未读标记重启不丢，绝对不重复干活；

2.智能频率控制

• OpenClaw
  固定间隔，简单判断时间；
  感知较弱，当前忙不忙、频繁不频繁无法感知，或者有时感知不到；

• Hermes
  动态调整心跳频率：

  • 30分钟内刚查过 —> 跳过；
  • 主人活跃/忙碌 —> 降低频率；
  • 深夜 —> 只查紧急事务，更像“懂事的助理”；

3.主动工作深度

• OpenClaw
  主动做：查邮件、查日历、发提醒、简单任务；

• Hermes
  在OpenClaw基础上，自动做维护类工作：

  • 自动整理每日记忆 —> 提炼长期记忆；
  • 自动优化技能、反思错误；
  • 自动检查Git、更新文档、整理项目；
  • 自动做自我维护、自我进化 —> 这是真正的“管家级”差距；

4.心跳与Cron明确分工

• OpenClaw
  心跳和定时任务混在一起，界限模糊；

• Hermes
  清晰分离：

  • Heartbeat： 批量、轻量、允许时间漂移、上下文感知；
  • Cron： 精确时间、独立任务、隔离运行、工程结构更稳、更适合长期跑；

5.上下文感知

• OpenClaw
  只看时间、安静时段，基本不看对话情绪与忙碌状态；

• Hermes
  能感知：

  • 主人是否在忙；
  • 最近对话强度；
  • 是否适合主动推送，更"人性化"，不尬聊、不打扰；

6.记忆联动

• OpenClaw
  心跳和记忆系统弱关联；

• Hermes
  心跳 = 记忆维护的核心时机；

  每次心跳都会:

  • 清理过期记忆；
  • 摘要每日记录；
  • 更新长期记忆，记忆系统越用越干净、越强；

Skill

1.自动提炼（真正全自动，无人工参与）

• OpenClaw
  需要你主动触发：

  • 帮我把刚才的流程做成Skill；
  • 或用 skill-creator 专门生成；
    属于"半自动+人工引导“；

• Hermes
  完全静默、全自动，但是也会写入一些无用的skill，导致skill比较庞大；
  做完复杂任务 —> 自动判断是否值得固化；
  自动写入~/.hermes/skills/；
  不需要你说一句话；

2.渐进式分级加载（Progressive Loading）

• OpenClaw
  加载整个SKILL.md（全量）；
  技能多了慢、耗token；

• Hermes
  因Hermes会自动生成skill，导致很多无用的skill被保存下来，为了使用skill更快速，所以有了渐进式分级加载：

  • Level 0：要（3000 token）；
  • Level1：完整步骤；
  • Level2：深度参考；
    按需加载、极省token、速度极快；

3.内置GEPA进化算法（自我优化闭环）

• OpenClaw
  优化靠外挂技能（self-improving-agent）；
  优化浅、仅限流程记录；
  无系统级进化；

• Hermes
  内置离线进化引|擎（hermes-agent-self-evolution）；
  GEPA： 遗传+帕累托提示词进化；
  每次执行自动反思、自动变异、自动择优；
  技能越用越强、自动变准、自动简化步骤；
  不需要RL（强化学习）；

4.技能与记忆深度绑定（自动整理）

• OpenClaw
  Skil与记忆系统弱关联；

• Hermes
  心跳时自动:

  • 清理过时技能；
  • 合并重复技能；
  • 优化高频技能；
    系统级自我维护；

5.生态标准兼容但更强

• 都兼容 agentskills.io标准；
• **Hermes 可直接导入OpenClaw技能；
• 但 OpenClaw 不能导入 Hermes 自动生成的进化型技能；

AI Coding

1.项目记忆深度

• OpenClaw
  能记住项目；
  但依赖.md记忆文件；
  重启/长时间后可能需要重新加载；

• Hermes
  LanceDB向量记忆+四层分级加载；
  永久记住:

  • 架构；
  • 技术栈；
  • 命名习惯；
  • 错误历史；
  • 部署流程；
    数月后回来继续写，完全不用重讲；

2.调试闭环成熟度

• Openclaw
  能调试，但有时会：

  • 卡循环；
  • 重复犯错；
  • 要你稍微引导；

• Hermes
  自主反思机制；
  自动记录错误模式；
  自动避免第二次踩坑；
  自动优化修复策略；
  更像人类工程师的思考方式；

3.自主规划能力

• OpenClaw
  能做，但需要你：

  • 给大致方向；
  • 偶尔确认步骤.；

• Hermes
  拿到需求 —> 自动拆解任务；
  自动排期；
  自动分步执行；
  自动联调模块；
  几乎不用干预；

4.长期运行稳定性

• Openclaw
  不错，但:

  • 长时间跑偶尔会丢上下文；
  • 技能多了变慢；
  • 偶尔需要重启；

• Hermes
  专为 7x24小时自主开发 设计；
  内存管理更好；
  技能加载更快；
  长期不崩、不卡、不漂移；

核心提示词

完整提示词只多了一个来源的文字拼接组成，其他的无差异。

任务并行/失败隔离

Hermes的Agent架构 类似于终端（如Android）的经典设计范式，构建起“主进程稳守中枢、多子进程协同攻坚”的高效运行体系。
主进程作为系统的核心枢纽，始终稳驻内存，依托Loop.looper循环机制保持持续在线，以超强的稳定性筑牢系统运行根基。一旦有事务需求触发，主进程便迅速响应，精准开辟子进程承接执行任务；即便子进程在运行过程中遭遇突发状况，主进程也能凭借敏锐的监控能力第一时间捕捉异常，即刻重启子进程，同时及时向用户同步动态，这也正是Hermes系统极少出现卡顿、稳定性远超同类产品的核心秘诀所在。

在任务协同层面，若Hermes子进程A正全力推进事务，而主进程同步调度出与之形成补充关系的全新事务并交由子进程B执行，主进程便会发挥强大的统筹能力，将子进程B的关键信息无缝整合至子进程A的运行逻辑中，让事务处理更加周全完备，为用户呈上更优质、高效的回复体验；若事务间不存在补充关联，子进程A与子进程B则会并行在后台高效运转，待各自任务圆满完成后，统一向主进程反馈结果，确保用户需求得到及时响应。

Hermes架构的优势，在任务并行与失败隔离机制中展现得淋漓尽致：

• 它支持多任务并行处理，主Agent专注承担聊天交互与全局调度重任，同时精准派生出多个子Agent各司其职，大幅提升任务处理效率；
• 通过将重型任务全部交由子Agent执行，实现任务失败的硬核隔离，从根源上保障主Agent永不宕机。

主Agent向子Agent传递的信息经过精心设计，涵盖当前核心任务（必传项）、精简版项目上下文、与任务强关联的对话片段，以及权限与环境信息。
如此设计，既精准控制了上下文长度，有效规避token溢出风险；又实现了任务的严格隔离，让子Agent得以心无旁骛地聚焦单一任务；既显著提升了任务执行速度，又筑牢了安全防线，从源头杜绝子Agent意外读取隐私历史的潜在隐患，全方位兼顾效率、稳定与安全，堪称智能agent架构的典范之作。

Harness Engineering（驾驭工程）

这里只是简单讲下驾驭工程，想详细了解的，可以去看我之前写的文章# Harness Engineering：从入门到精通。

Agent 的发展轨迹

1、AI Coding 完成任务的比例越来越高
2、Agent 内部的工程代码复杂度越来越高
3、通过保存 Skill 复用代码和经验
4、记忆和自我进化机制初步形成

【智能体架构演进：从代码闭环到通用能力的基因传承】
随着AI Coding完成的任务比例持续攀升，智能体工程正经历着深刻的范式转移。
当前行业呈现四大核心趋势：

• 编码智能体逐步成为复杂任务的核心执行者；
• 智能体内部工程架构复杂度呈指数级增长；
• 基于Skill技能库的代码复用体系逐渐成型；
• 具备Memory记忆存储与自我进化能力的元认知系统初现端倪。

这一系列演进催生了两个关键命题的深度思考。

由此，衍生了2个问题：
为何Harness Engineering发端于Coding Agent？
编码智能体（Coding Agent）天然具备独特的「非对称优势」——左侧依托大模型概率化生成能力，右侧则嫁接软件开发生态中丰富的验证工具链。
这种架构创造了完美的确定性反馈闭环：当Python代码无法运行时，编译器给出的报错信息具有绝对权威性，这种机器可验证的真理性反馈在其他领域几乎不可复制。相较之下，通过LLM生成法律合同审查缺乏标准化评价体系，图像生成难以量化审美质量，唯有代码世界存在明确的语法规则与测试基准。
正是这种「生成-验证」的强闭环特性，使得编码智能体的迭代回路（Loop）能够持续自我强化，最终支撑起航天器控制软件级别的超复杂任务。随着任务复杂度的提升，智能体不得不构建模块化架构、状态管理系统乃至分布式协作机制，这正是Harness Engineering诞生的技术必然。

二、OpenClaw/Hermes为何承袭Coding Agent架构基因？
通用智能体的终极形态本质上是「代码驱动世界」的实践者。
尽管大模型生成的代码存在不确定性，但通过「人类反馈增强学习」（RLHF）机制，可将每次成功任务转化为可复用的技能模块。
这一过程暗合生物进化逻辑：每轮用户确认的有效代码片段，如同被自然选择保留的优质基因，经过多代迭代后形成稳定的能力簇。
OpenClaw/Hermes采用的多Agent架构，实质上是将编码智能体的确定性验证机制扩展至通用领域——主Agent负责战略规划，子Agent专注代码生成，二者通过结构化接口实现风险隔离。
这种设计既继承了Coding Agent的严谨工程范式，又通过Skill库的持续积累，使通用智能体获得跨领域迁移学习的底层能力

Agent的演进

昨天朋友聚餐时，大家聊起Agent，不少人疑惑：Agent和LLM不都是一回事吗？其实真不是！简单来说，Agent是能自主干活的“智能搭档”，而LLM是它的核心“大脑”。

用精准的Prompt告诉LLM要做什么，这只是基础操作。

而后，行业迎来了关键突破——上下文工程（Context Engineering） 的兴起。随着Prompt指令持续叠加、历史对话不断累积，海量冗余信息正不断挤压模型的运行空间，而上下文压缩技术的出现，精准破解了这一困局，为大模型高效运转筑牢了根基。

再往后，当我们推动Agent真正投入实战，核心路径便是为大模型赋予“行动力”——借助API、MCP协议以及代码能力，为LLM嫁接丰富的外部工具，让它从单纯的“对话者”转变为能主动执行任务的“实干家”。
若想让LLM承接更复杂的工作，比如自主运行代码、调用系统指令，安全底线必须筑牢：绝不能让LLM直接触碰核心服务器，因此沙箱技术应运而生，所有系统命令都在隔离环境中运行，从源头规避风险。
同时，为了让LLM具备持续记忆的能力，支持文件存储与代码留存，文件系统也随之搭建完善。正是这一系列功能的叠加，让LLM Agent彻底挣脱了局限，拥有了强大的实战本领，真正实现了从“能思考”到“能干活”的跨越。

当 LLM Agent 真正具备干活能力后，我们惊喜地发现，此前为其赋予的各项核心能力——沙箱、文件系统、MCP 等，完全可以进行系统性的整合与优化。
将这些分散的工具及功能，包括各类执行工具、MCP、API、代码运行环境以及沙箱，全部打包集成到一个统一的执行层之中。
这一执行层就如同一个高效运转的 “智能车间”，为 LLM 搭建起完备的任务执行体系。在这里，LLM 能够有条不紊地调用各类资源，顺畅地执行各类复杂任务，极大地提升了其工作效能与任务处理的稳定性，让 LLM Agent 在实际应用场景中发挥出更为强大的作用。

当执行层搭建完备，Agent便拥有了驰骋各类任务场景的硬核底气，能高效产出海量成果，而这些成果多以文字形式沉淀，一旦汇入上下文，便自然催生出一个持续运转的循环（Loop）。可随着Loop的不断循环，上下文承载的信息量急剧攀升，历史对话层层累积，迫使我们必须依托历史对话开展精准的上下文压缩。而无论上下文承载的压力如何攀升，这些难题的破解，始终都归属于上下文工程的核心职责范畴。

当上下文与提示词深度融合，便凝聚成全新的Prompt输入至LLM，LLM随即启动深度思考（Reasoning） 进程，在缜密推演中梳理脉络、得出结论，并将思考成果转化为文字；
这些文字被精准输送至执行层，执行层依托指令高效运转、产出结果，再以文字形式回传至上下文工程体系——至此，AI Agent核心的ReAct闭环初步搭建完成，实现了从思考到行动、从反馈到迭代的流畅衔接，让智能体真正具备了自主感知、决策与执行的动态能力。

在 ReAct 处理流程中，执行层的高效能力可能引发连锁挑战：
频繁执行代码或系统命令产生的冗长报错信息，会持续涌入上下文，即便采用先进的上下文压缩技术，文字量的急剧膨胀仍会导致关键问题 —— 当这些信息传递至 LLM 进行思考时，模型容易因信息过载而 “思维发散”，难以精准捕捉核心目标与约束条件。
原本明确的 Prompt 指令，经上下文工程压缩后，其关键意图可能被海量冗余信息稀释，最终引发 LLM 的思考偏移。

这也解释了为何在使用 AI Coding 工具时，若单个交互窗口出现效果下降、响应延迟或卡顿，根源往往在于上下文工程未能有效遏制用户查询（Query）的目标与约束被稀释，或是触发了 LLM 供应商针对超大 Token 量的惩罚机制。

为破解上下文信息膨胀、核心指令被稀释的难题，一套行之有效的应对策略应运而生：
在本地的.md文件中，我们系统梳理并固化关键核心内容，涵盖项目目标、技术栈选型、需求背景脉络、代码风格规范以及明确的禁止事项，以此筑牢核心信息的“防护墙”，确保这些关键内容始终稳居优先级顶端，绝不被稀释。
当上下文字数逼近承载阈值时，便优先对报错信息、聊天内容等非核心冗余信息进行精准压缩，为关键信息腾挪出充足的表达空间，让核心指令始终在上下文中占据关键席位，有效规避LLM因自注意力机制被海量信息干扰，导致核心目标与约束被淡化、思考方向偏移的风险。

LLM的自注意力机制可以看下，我之前写的文章 # 揭秘Transformer架构设计 2（补全版）。

有了这些规则文件，在上下文工程中，你既要保证当前用户Query的Prompt是清楚与精确的，又要保证你的规则文件、记忆文件里面的内容与经验是比较完整的 ，让LLM思考不要去跑偏了

有了明确的规则文件，在上下文工程里，就得做好两件事：

• 把当前用户 Query 对应的 Prompt 打磨得足够清楚、精准，让 LLM 一眼就能抓住重点；
• 保证规则文件、记忆文件里的关键内容和过往经验都完整留存，不能有缺失。

这两步做好了，LLM 在思考时才不会偏离正轨，能始终围绕核心目标推进，既不会抓错用户当下的需求，也不会漏掉长期沉淀的经验，思考方向自然更稳、更准。

当这些承载关键规则的文件与配套代码完成有机整合，便汇聚成至关重要的“记忆层”。
自此，系统正式构建起执行层与记忆层两大核心支柱。
这两大层级彼此协同、互为支撑，让整个智能循环（Loop）的运转效率实现质的飞跃——回望过往，单一任务往往需要耗费50轮循环才能勉强推进，期间大量环节因LLM思维跑偏沦为无效消耗；

而如今，记忆层的加入为LLM筑牢了思考的“锚点”，大幅降低了跑偏概率，如今完成一项任务，仅需20至30轮循环便能精准锁定结果，不仅大幅压缩了无效迭代，更让智能体的执行效率与精准度迈上了新台阶。

当前架构仍有优化空间：若仅将 LLM 生成的代码直接交给执行层运行，一旦代码存在隐性缺陷，不仅会浪费时间资源，还会因反复调试产生大量冗余信息。为此，需要在执行层嵌入更多智能化工具，让传递给记忆层的信息更具决策价值。

以代码检查工具为例，它能在代码运行前快速扫描语法问题，提前拦截明显错误，避免无效执行。这一举措可大幅缩减任务量，因为未经校验的代码即便勉强跑通，也可能只是 “表面完成任务”，而非真正达成目标。此时若直接反馈给记忆层，只会徒增一轮无意义的上下文处理和知识库检索。

更优的做法是在执行层加入单元测试模块。当代码初步跑通后，立即触发针对性测试——根据用户需求由 LLM 编写基础用例，或依据代码修改的功能模块智能筛选核心用例。测试结果（包括通过率、失败项等）将成为下一轮迭代的关键信号，帮助记忆层精准定位问题，显著提升后续处理效率。

为进一步提升 Agent 系统的运行效能，我们围绕执行层构建了全新的反馈层。这一层级并非简单叠加工具，而是聚焦于“如何让传递至上下文的信息更具决策价值”这一核心目标展开设计。

反馈层的核心使命：从“完成任务”到“提供洞察”
传统模式下，执行层仅完成代码运行或命令执行，返回的结果往往停留在“是否成功”层面。而反馈层在此基础上进行了三重升级：

1. 多维度校验：集成代码检查工具（如静态分析）、单元测试框架及定制化验证模块，对输出结果进行全面评估；
2. 智能筛选：根据当前任务特性动态选择最相关的测试用例，避免全量测试带来的资源浪费；
3. 深度解析：将原始数据转化为可行动的结论，例如标记潜在漏洞位置、关联历史相似案例的解决方案。

典型应用场景示例
假设 LLM 生成了一份数据处理脚本，经执行层初步验证可正常运行。此时反馈层会主动介入：

• 预检阶段：通过语法扫描发现隐藏的类型转换错误；
• 定向测试：针对新增功能模块调用专属测试集，而非全部用例；
• 结果解读：将“某行数值溢出”的具体坐标反馈给记忆层，而非笼统告知“存在缺陷”。

这种精细化的处理方式，使得每一轮迭代都能精准定位改进方向，大幅减少无效循环次数。

真的是一个复杂任务，不管是通用Agent（OpenClaw、Hermes），还是写代码的Agent（Claude Code、Codex）都在追求挑战更复杂的任务。

比如重构项目架构，经常干活超过24小时，比如3天3夜干一个任务。
大型任务是有阶段的，第一阶段是不停编写代码、第二阶段是编写测试用例等等
在不同阶段，记忆层的策略是不一样的，执行层使用的工具是不一样的，包括一些权限范围也是不一样的，反馈层重点关注的信息、任务、工具也是不一样的

所以要把大任务拆解成小任务，这工作不一定是LLM去拆解。
在Agent内一些典型的大任务都拆解过，或者有过经验，或者人工拆解过任务
小任务其实就是阶段划分，不同的阶段干不同的活

随着AI Agent向高复杂度任务发起挑战——无论是通用型Agent（OpenClaw/Hermes）攻坚系统级重构，还是编码型Agent（Claude Code/Codex）打磨超大型项目，持续数日乃至跨周的马拉松式任务已成常态。面对这类需要"持久战"的超级工程，传统单线程推进模式显露出明显短板：当开发者试图一次性重构整个技术栈时，混乱的版本迭代与失控的资源消耗往往导致效率断崖式下跌。为此，我们引入阶段性战略拆解机制，将庞然大物切割为可管理的模块化战役。

三维动态适配体系:

• 记忆层进化论： 初期聚焦核心业务逻辑沉淀，中期转向接口契约规范，后期专攻性能瓶颈档案库建设。通过分层存储策略，既保证历史经验的完整继承，又实现精准场景匹配。
• 执行层武器库切换： 概念验证期启用快速原型框架，集成开发阶段切换至严格类型检查工具链，回归测试环节则部署全链路压测平台。如同特种部队根据作战地形更换装备，各阶段配备最优效能组合。
• 反馈层价值过滤器升级： 初始版本着重捕捉编译错误模式，中期转为分析模块耦合度，最终形成架构健康度雷达图。类似医疗CT扫描仪逐步提升分辨率，持续输出更具指导意义的诊断报告。

人机协作新范式
不同于完全依赖LLM自主分解任务的风险模式，成熟方案采用"专家经验+智能辅助"混合驱动：

• 预先植入典型行业的标准研发路线图模板，允许人类工程师设定里程碑节点；
• AI负责填充具体实施路径，并在关键决策点触发人工确认机制。

这种设计既规避了纯机器推理可能导致的方向偏差，又保留了人工智能的速度优势。

面对复杂任务的挑战，无论是通用Agent还是编码Agent，都在向更高难度的任务发起攻坚，像重构项目架构这类动辄耗时数天的工程，更需要科学拆解。
这时候，总控机制就成了关键“指挥官”，它先把大任务精准拆解成多个小阶段，再根据每个阶段的核心需求，灵活调配记忆层、执行层、反馈层的工具与策略：
前期侧重知识沉淀与方案搭建，中期聚焦代码执行与验证，后期转向质量复盘与优化，不同阶段调用的工具、设定的权限和关注的重点各有侧重，最终让拆解后的小任务有序落地，高效推进复杂任务稳步完成。

编排层：Agent系统的智能指挥官
如果把复杂任务比作一场交响乐演出，编排层就是那位运筹帷幄的“总指挥”。它像经验丰富的项目管理工程师，根据任务目标动态规划作战路线——先拆解大任务为多个阶段，再为每个阶段量身定制“三层协作方案”：

• 记忆层调用策略：初期加载项目背景知识，中期切换至代码规范库，后期调取测试案例库；
• 执行层工具组合：概念验证期仅开放只读权限，开发期激活代码生成器+沙箱，上线前部署压力测试工具；
• 反馈层关注重点：早期聚焦语法校验，中期检测性能指标，后期验证业务逻辑闭环。

通过这种“阶段化精准调度”，原本混乱的马拉松式任务被转化为可控的短跑冲刺，既避免了LLM因上下文臃肿而“思维发散”，又能让各层级工具始终发挥最大效能。

LLM被四层架构稳稳护在核心，各层级分工清晰、各司其职：

• 编排层的定位尤为纯粹，它大多以文字形态安放在.md文件中，不掺杂代码、技能与工具，却像指挥官一样统筹全局，精准把控任务推进节奏；
• 记忆层是运转的核心枢纽，既承载着代码与Prompt，又承担着上下文压缩、记忆提炼的重任，还依托向量数据库沉淀知识，同时主动调用LLM搭建信息桥梁；
• 反馈层同样自带代码与Prompt，不仅能联动LLM，还擅长对执行结果做总结提炼，为迭代优化提供关键支撑；
• 执行层则是实干担当，集沙箱、文件系统、代码执行能力与各类工具于一体，将指令转化为实实在在的落地动作，四层协同联动，为LLM构建起高效稳定的运行闭环。

包裹着LLM、为其筑牢运行根基的这套完整工程体系，正是Harness Engineering。
在由编排层、记忆层、执行层、反馈层构建的四层架构中，无论是顶层的编排规划、核心的代码编写，还是架构的精细设计，亦或是各类工具的统筹整合，所有围绕系统搭建与落地的核心工作，全都归属于Harness Engineering的职责范畴，它以全方位的工程支撑，让LLM的能力得以精准、高效地落地。

如今大众对AI Agent的共识定义，早已清晰明了——AI Agent就是LLM与Harness Engineering的强强组合。

在一个完整的Agent体系里，LLM是核心的“智慧大脑”，负责理解需求、生成思路，而除此之外的所有支撑性工作，无论是工具调用、流程搭建、安全保障，还是记忆管理，全都归属于Harness Engineering。
正是这两部分的紧密配合，让Agent既拥有了思考的核心，又具备了扎实落地的能力，真正实现从需求到行动的闭环。

当我们把前述技术脉络完整梳理、深度消化后，我特意凝练绘制了一张可视化图谱。这张图以技术诞生的时间轴为脉络，以技术实现的复杂度为刻度，从左至右徐徐铺展，清晰勾勒出从基础能力到复杂体系的演进轨迹，让每一项技术的迭代逻辑、承前启后的关系一目了然，将抽象的技术演进过程转化为直观可感的发展路径。