用 OpenClaw 构建可自我迭代的银行客户经理 AI 助手

OpenClaw 的价值不只是“让模型帮忙回答问题”，更适合用来搭建一个长期运行的专属智能体。它可以保存身份、偏好、任务历史和反馈记录，再通过 Heartbeat、Cron、Skill、SubAgent 等机制，把一次次交互沉淀成可持续优化的上下文。

以银行客户经理助手为例，客户经理每天面临三类高频问题：

要让这个助手真正可用，重点不在单次回答有多漂亮，而在它能不能持续记住用户偏好、识别自己的不足，并把反馈写回工作规则中。这个过程可以理解为：模型能力是基础，Context 能力决定长期表现。

整体架构：把主 Agent 做成协调层

银行客户经理助手不应该只是一个“万能聊天框”。更合理的做法是把主 Agent 设计成协调层，由它理解用户意图、拆解任务、选择工具、调度专业 Agent，并把结果整理成用户能直接使用的格式。

flowchart TB
    U[用户<br/>IM / WebUI] --> M[主 Agent<br/>银行客户经理助手]

    M --> S1[搜索 / 浏览器]
    M --> S2[planning-with-files<br/>深度分析]
    M --> S3[SubAgent<br/>专业任务执行]
    M --> MEM[(Memory<br/>长期记忆)]
    M --> HB[Heartbeat<br/>状态检查]
    M --> CRON[Cron<br/>定时任务]

    S3 --> A1[风险预警 Agent]
    S3 --> A2[晨间准备 Agent]
    S3 --> A3[业绩增长 Agent]
    S3 --> A4[中后台自动化 Agent]

    HB --> M
    CRON --> M
    MEM --> M
    M --> U

这套结构里，主 Agent 负责“判断和协调”，专业 Agent 负责“执行具体业务”。例如：

核心文件：让 Agent 有身份、边界和记忆

OpenClaw 的一个关键设计是用 Markdown 文件承载 Agent 的身份、规则和记忆。这样做有两个好处：

1. 人可以直接阅读和修改，调试成本低。
2. Agent 可以把反馈、反思、规则变更写回文件，形成长期演化。

一个可自我迭代的工作区，通常需要这些核心文件：

SOUL.md：定义身份和职责边界

SOUL.md 不只是人设描述，它会影响 Agent 的任务选择、语气、边界判断和长期行为。银行客户经理助手可以这样设计：

# SOUL.md - 银行客户经理助手

## 身份

我是银行客户经理 AI 助手，负责协助客户经理处理日常经营、风险预警、营销线索和中后台事务。

## 核心职责

### 1. 中后台任务自动化

- 整理日报、周报、活动总结
- 汇总邮件、会议纪要、台账材料
- 跟踪待办事项和截止时间
- 生成合规检查草稿

### 2. 客户和行业风险预警

- 关注客户所在行业的政策变化
- 识别企业经营异常信号
- 提醒产品净值波动和到期风险
- 对授信客户生成贷后监控线索

### 3. 营销线索洞察

- 识别产品到期、大额资金闲置、客户偏好变化
- 汇总客户画像和沟通建议
- 生成可执行的营销行动清单

## 工作原则

- 先理解需求，再选择工具
- 简单查询直接处理
- 多步骤分析使用 planning-with-files
- 中后台任务优先交给专业 Agent
- 涉及客户资金、合规判断、对外发送内容时必须请求人工确认

## 边界

可以自主完成：
- 读取和整理内部文件
- 搜索公开信息
- 生成报告草稿
- 记录反馈和更新记忆
- 设置提醒和维护日程

必须确认后才能执行：
- 给客户发送消息
- 对外发布材料
- 给出资金操作建议
- 做出合规结论

金融场景对边界特别敏感。Agent 可以提供分析、提示和草稿，但不能替客户经理做最终决策，更不能自动执行涉及客户资金和合规责任的动作。

AGENTS.md：定义可追溯的变更规则

如果允许 Agent 自己修改规则，就必须要求它记录修改原因。否则运行一段时间后，很难判断某个行为变化从哪里来。

可以在 AGENTS.md 里加入“核心文件变更必须记录”的规则：

# AGENTS.md - 工作区规则

## 核心文件范围

| 文件 | 职责 |
|---|---|
| SOUL.md | 身份、人设、职责边界 |
| AGENTS.md | 工作区规范和流程 |
| USER.md | 用户偏好 |
| MEMORY.md | 长期记忆 |
| HEARTBEAT.md | 心跳检查清单 |
| agents/prompts/*.md | 专业 Agent 提示词 |

## 核心文件变更流程

任何核心文件变更，都必须创建进化日志：

1. 判断是否需要修改核心文件
2. 修改目标文件
3. 创建 `memory/evolution/YYYY-MM-DD-topic.md`
4. 记录修改前、修改后、修改原因和来源
5. 每日反思时汇总当天变更

## 禁止操作

- 不记录日志就修改核心文件
- 不说明修改来源
- 不保留修改前后对比
- 跳过每日反思汇总

配套的进化日志模板可以这样写：

# 进化日志 - 2026-06-07-heartbeat-risk-reminder

## 修改时间

2026-06-07 22:00

## 优化类型

反馈驱动

## 修改内容

### 文件：HEARTBEAT.md

修改章节：重要事项识别

修改前：
- 仅检查紧急邮件、近期日程、临时任务和用户反馈。

修改后：
- 增加“重要事件识别”检查项。
- 当日程、邮件或任务中出现“风险、逾期、授信、产品到期、客户投诉”等关键词时，即使没有明确截止时间，也需要提醒。

修改原因：
- 测试中发现助手没有识别出隐含的重要提醒。

来源：
- memory/feedback/2026-06-07-feedback.md

这一步很关键。自我迭代不是让模型随意“改性格”，而是让每次变化都能被追溯、复查和回滚。

任务执行机制：Cron、Heartbeat、SubAgent 和 planning-with-files

银行客户经理场景有大量周期性任务，也有不少临时复杂任务。不同任务应该走不同机制。

Heartbeat 和 Cron 的区别

Heartbeat 和 Cron 都能“定期触发”，但它们的定位不一样。

Heartbeat 更像“主动关怀机制”。它每隔一段时间醒来，检查是否有值得提醒的事情；如果没有，就保持沉默。Cron 更像“调度器”，适合每天 08:30 生成晨报、每晚 22:00 做反思总结这类确定任务。

flowchart LR
    A[任务需求] --> B{是否要求精确时间?}
    B -- 是 --> C[Cron]
    B -- 否 --> D{是否需要主动检查状态?}
    D -- 是 --> E[Heartbeat]
    D -- 否 --> F{是否复杂且多步骤?}
    F -- 是 --> G[planning-with-files / SubAgent]
    F -- 否 --> H[主 Agent 直接处理]

HEARTBEAT.md：只提醒真正有价值的信息

Heartbeat 最大的坑是“过度打扰”。如果每次检查都推送一堆无关状态，用户很快就会忽略它。

一个简化版 HEARTBEAT.md 可以这样设计：

# HEARTBEAT.md - 心跳检查清单

## 检查项

### 1. 紧急邮件

- 检查未读邮件
- 只提醒今日截止、客户投诉、风险事件、监管要求
- 普通邮件不推送

### 2. 近期日程

- 检查今日和明日日程
- 15 分钟内开始的会议需要提醒
- 明日日程只提醒重要事项

### 3. 临时任务

- 检查任务队列和日历
- 识别今日截止、即将到期、需要提交的事项

### 4. 用户反馈

- 识别“建议、不好、希望、优化、改进、问题”等表达
- 记录到 `memory/feedback/YYYY-MM-DD-feedback.md`

### 5. 重要事件识别

即使没有明确截止时间，只要出现以下信号，也需要提醒：

- 客户风险
- 授信异常
- 产品到期
- 逾期
- 客户投诉
- 合规风险
- 重大政策变化

## 推送规则

需要推送：
- 有紧急邮件
- 有 15 分钟内开始的重要会议
- 有今日截止事项
- 有新反馈需要记录
- 发现重要风险或机会

不需要推送：
- 无新信息
- 无紧急事项
- 例行检查无异常

无提醒时返回：
HEARTBEAT_OK

这里的重点不是让 Heartbeat “勤奋”，而是让它知道什么时候不该说话。

Cron：适合稳定执行的固定任务

银行客户经理助手可以配置几类 Cron 任务：

每日反思适合放在 Cron 中，因为它需要稳定执行，并且通常不依赖用户是否在线。

sequenceDiagram
    participant Cron
    participant Agent as 主 Agent
    participant Memory as Memory
    participant Files as 核心文件
    participant User as 用户

    Cron->>Agent: 22:00 触发每日反思
    Agent->>Memory: 读取当天反馈、Timeline、任务记录
    Agent->>Agent: 判断是否需要调整规则
    Agent->>Files: 更新 SOUL / HEARTBEAT / prompts
    Agent->>Memory: 写入 evolution 日志
    Agent-->>User: 汇总重要变化

SubAgent 和 planning-with-files 的选择

不是所有任务都适合主 Agent 亲自做。可以按任务复杂度选择执行方式：

planning-with-files 适合处理“资料多、步骤多、需要中间计划”的任务。例如分析一个企业客户时，可能要读取财报、行业研报、舆情搜索结果、授信历史和客户经理备注。直接让主 Agent 一口气回答，容易漏步骤；先规划、再逐步处理文件，结果更稳定。

自我迭代闭环：反馈不是聊天记录，而是系统输入

OpenClaw 有记忆能力，但“反思”和“迭代”需要自己搭建流程。一个可运行的闭环可以由 Heartbeat、Cron 和 Memory 组成：

flowchart TD
    A[用户反馈 / 任务结果 / 异常表现] --> B[Heartbeat 捕捉实时信号]
    A --> C[任务执行日志 Timeline]
    B --> D[(memory/feedback)]
    C --> E[(memory/daily)]
    D --> F[每日 Cron 反思]
    E --> F
    F --> G{是否需要修改规则?}
    G -- 否 --> H[写入反思总结]
    G -- 是 --> I[更新核心文件或 Agent prompt]
    I --> J[(memory/evolution)]
    J --> K[后续任务使用新规则]

这个闭环有三层含义：

1. 收集：把用户反馈、任务失败、漏提醒、格式偏好记录下来。
2. 判断：每天定时分析这些记录，判断是偶发问题还是规则缺失。
3. 更新：如果规则缺失，就修改 SOUL.md、HEARTBEAT.md 或专业 Agent prompt，并记录进化日志。

例如用户反馈“这个提醒太晚了”，Agent 不应该只回复“收到”。更好的处理流程是：

flowchart LR
    A[用户反馈：提醒太晚] --> B[记录 feedback 日志]
    B --> C[判断类型：流程优化]
    C --> D[修改 HEARTBEAT.md<br/>提前提醒阈值]
    D --> E[写 evolution 日志]
    E --> F[下次 Heartbeat 按新规则执行]

这样，反馈才会真正改变后续行为。

跨 Agent 自主测试：用 Agent 模拟客户和评估者

人工陪测智能体有一个明显瓶颈：人很难持续扮演各种用户、反复下发任务、观察结果并给出反馈。更好的办法是让另一个 Agent 扮演测试方，主动和被测 Agent 交流。

OpenClaw 可以通过 AgentToAgent（Agent 到 Agent 通信）实现这种测试方式。

开启 AgentToAgent

需要在配置中打开会话可见性和 AgentToAgent 权限：

{
  "sessions": {
    "visibility": "all"
  },
  "agentToAgent": {
    "enabled": true,
    "allow": [
      "main",
      "ai-expert",
      "bank-manager"
    ]
  }
}

这里有几个要点：

session_send 和 session_spawn 的区别很重要。测试银行客户经理助手时，应把消息发到它的主会话，因为主会话承载长期上下文、身份和记忆。如果新建隔离会话，被测结果可能无法反映真实长期协作状态。

自主交流测试流程

sequenceDiagram
    participant Tester as 测试 Agent
    participant Bank as 银行客户经理助手
    participant Tools as 工具 / Skill
    participant Memory as Memory

    Tester->>Bank: 新的一天开始，请处理今日工作
    Bank->>Tools: 检查日程、邮件、风险线索
    Tools-->>Bank: 返回检查结果
    Bank-->>Tester: 输出晨间清单
    Tester->>Bank: 追加真实场景任务
    Bank->>Tools: 调用搜索、planning-with-files 或 SubAgent
    Bank-->>Tester: 返回任务结果
    Tester->>Bank: 给出工作反馈
    Bank->>Memory: 记录反馈
    Bank->>Memory: 需要时写入进化日志

这种方式可以模拟真实客户经理的一天：晨间准备、临时任务、风险提醒、客户分析、反馈改进。测试方不需要透露“这是测试”，只需要像真实用户一样下发任务和反馈。

agent-eval Skill：把评估流程产品化

如果每次测试都靠临时提示词，评估结果很难复用。可以把测试流程做成一个通用 Skill，例如 agent-eval。

目录结构

skills/agent-eval/
├── agents/
│   ├── bank-manager/
│   │   ├── config.yaml
│   │   └── eval_rule.md
│   └── default/
│       ├── config.yaml
│       └── eval_rule.md
├── scripts/
│   ├── run-agent-eval.py
│   └── summarize-results.py
└── references/
    ├── result-schema.json
    └── testcase-flow.md

每个被测 Agent 有独立目录，里面放配置和评估规则。这样可以避免不同 Agent 的测试标准混在一起。

设计原则

测试流程

flowchart TD
    A[检查 agents/<agent-id>/config.yaml] --> B[读取 eval_rule.md]
    B --> C[生成测试用例 UC-XXX.md]
    C --> D[创建 UC-XXX-todo.md]
    D --> E[按 todo 执行跨 Agent 交流]
    E --> F[发送自然工作反馈]
    F --> G[生成 UC-XXX-result.json]
    G --> H[汇总多轮结果]

使用方式

# 测试银行客户经理助手
/agenteval bank-manager 今天测试企业深度分析能力

执行时，Skill 可以自动完成这些动作：

✅ 检查 agents/bank-manager/config.yaml
✅ 读取 agents/bank-manager/eval_rule.md
✅ 生成 UC-017-enterprise-analysis.md
✅ 创建 UC-017-todo.md
✅ 向 bank-manager 主会话发送开场任务
✅ 观察被测 Agent 的执行结果
✅ 发送自然反馈
✅ 生成 results/UC-017-result.json
✅ 勾选 todo.md 中的测试步骤

结果文件可以采用固定 schema，便于后续统计：

{
  "case_id": "UC-017",
  "agent_id": "bank-manager",
  "scenario": "企业深度分析",
  "score": {
    "task_understanding": 4,
    "tool_selection": 5,
    "risk_identification": 3,
    "output_actionability": 4,
    "feedback_handling": 5
  },
  "issues": [
    {
      "type": "risk_reminder",
      "description": "识别出客户风险，但提醒优先级不够明确"
    }
  ],
  "feedback_sent": true,
  "evolution_required": true
}

新增一个被测 Agent

新增测试对象时，只需要复制默认模板：

mkdir -p skills/agent-eval/agents/ai-expert
cd skills/agent-eval/agents/ai-expert

cp ../default/config.yaml .
cp ../default/eval_rule.md .

vim config.yaml    # 修改目标 sessionKey
vim eval_rule.md   # 修改评估规则

然后运行：

/agenteval ai-expert 测试 AI 专家能力

示例：一次 Heartbeat 漏提醒如何完成自我修复

假设测试方模拟一个场景：客户经理今天有一个重要风险事项，但 HEARTBEAT.md 只检查了“紧急邮件、近期日程、临时任务、用户反馈”，没有把“隐含的重要事件”作为单独检查项。

测试过程可以这样走：

sequenceDiagram
    participant Tester as 测试 Agent
    participant Bank as 银行客户经理助手
    participant HB as Heartbeat
    participant Memory as Memory

    Tester->>Bank: 今日有客户风险相关事项，请开始一天工作
    HB->>Bank: 执行心跳检查
    Bank-->>Tester: 未提醒该风险事项
    Tester->>Bank: 反馈：刚才遗漏了重要风险提醒
    Bank->>Memory: 写入 feedback 日志
    Bank->>Bank: 判断 HEARTBEAT.md 缺少重要事件识别规则
    Bank->>Memory: 写入 evolution 日志
    Bank->>Bank: 更新 HEARTBEAT.md
    Tester->>Bank: 再次触发心跳测试
    Bank-->>Tester: 成功提醒重要风险事项

对应的修复不是“下次注意”，而是规则变更：

 # HEARTBEAT.md

 ## 检查项

+### 5. 重要事件识别
+
+检查邮件、日程、任务、客户记录中是否出现以下信号：
+
+- 风险
+- 逾期
+- 授信
+- 客户投诉
+- 产品到期
+- 合规异常
+
+只要出现高优先级信号，即使没有明确截止时间，也需要提醒。

这就是自我迭代的核心：一次失败变成一条规则，一条规则改变后续行为。

OpenClaw 和 Claude Code 的差异

OpenClaw 和 Claude Code 都能调用工具、编辑文件、执行任务，但二者适合的工作模式不一样。

可以把 OpenClaw 理解为“养成型助手”：它适合 24 小时存在，随时从 IM 接收任务，后台处理后再把结果推回给用户。

Claude Code 更适合“专注开发时段”：开多个项目窗口，让模型并行写代码、跑测试、改 bug。

两种工具不是替代关系，而是面向不同工作节奏：

flowchart LR
    A[移动 / 碎片时间] --> B[OpenClaw]
    B --> C[下发任务]
    B --> D[后台执行]
    B --> E[IM 返回结果]

    F[电脑前 / 深度开发] --> G[Claude Code]
    G --> H[代码生成]
    G --> I[重构调试]
    G --> J[多窗口并行]

记忆系统：文件是事实源，检索是加速层

OpenClaw 的记忆系统可以理解为“Markdown 文件 + 可插拔检索后端”。

Markdown 文件是事实源，也就是长期记忆真正存放的地方；检索后端负责加速查找相关内容。默认模式通常会结合 SQLite、FTS5（SQLite 的全文搜索模块）和向量检索。QMD（OpenClaw 的实验性记忆检索后端）则更强调混合检索能力，例如 BM25（经典关键词相关性排序算法）、向量召回和 LLM（大语言模型）重排。

flowchart TB
    A[Markdown 记忆文件] --> B[索引构建]
    B --> C[关键词检索<br/>BM25 / FTS5]
    B --> D[向量检索]
    C --> E[候选片段]
    D --> E
    E --> F[LLM 重排]
    F --> G[返回相关记忆]

这种设计的优点是透明：记忆都在文件里，人可以直接打开看。缺点是检索质量依赖分块、索引和重排模型，如果 chunk 太大，重排模型可能处理不了，只能退回文件级检索；如果本地模型较大，资源消耗也会明显增加。

OpenClaw 与 OpenViking 的记忆思路对比

OpenViking 是另一类 Agent 记忆框架，更强调分层上下文和目录递归检索。二者关注点不同：

一句话区分：

对专属智能体来说，记忆是最重要的数据资产之一。框架可以换，记忆最好能保留和迁移。因此 Markdown 这种朴素方案虽然不够“高级”，但在可控性和可迁移性上很有优势。

成本和 token 控制

完整跑一轮“构建助手 + 自主测试 + 反思迭代 + 评估汇总”，token 消耗会很大。尤其是深度分析、跨 Agent 交流、生成测试用例和结果汇总，都会反复调用模型。

如果使用 coding plan 或类似的任务规划能力，多步骤任务的体感等待会降低，因为 Agent 可以把复杂过程拆开执行。但成本不会消失，只是从单次对话转移到后台执行链路中。

落地时需要注意的坑

1. Heartbeat 不适合强确定性提醒

Heartbeat 的定位是状态检查，不是严格定时器。必须准点执行的任务应该放进 Cron，例如日报、周报、每日反思、固定会议提醒。

2. A2A 测试要控制轮次

跨 Agent 对话如果不限制，很容易互相追问、互相解释，形成 ping-pong。测试用例最好 5 轮内结束，每轮只验证一个核心能力。

3. 核心文件不能被静默修改

允许 Agent 修改 SOUL.md、HEARTBEAT.md、prompt 等文件时，一定要要求它写进化日志。否则行为变化无法追踪。

4. 反馈要分类处理

不同反馈应该进入不同位置：

5. 金融场景必须保留人工确认

银行客户经理助手可以生成建议，但不能自动替人做高风险动作。尤其是客户资金、授信判断、合规结论、对外发送消息，都应该进入人工确认流程。

6. 长期记忆仍然会遗忘

当前很多 Agent 记忆系统还没有彻底解决时序关系、知识图谱、冲突记忆、长期压缩和反思质量问题。可行的工程策略是：把重要结论写成稳定 Markdown，定时压缩短期日志，并用评估用例持续检查召回效果。

最小可行方案

如果要快速搭一个可自我迭代的 OpenClaw 助手，可以按这个顺序做：

flowchart TD
    A[创建 SOUL.md<br/>定义身份和边界] --> B[创建 AGENTS.md<br/>定义变更规范]
    B --> C[创建 USER.md / MEMORY.md<br/>保存偏好和长期记忆]
    C --> D[创建 HEARTBEAT.md<br/>定义主动检查项]
    D --> E[配置 Cron<br/>晨报、日终、每日反思]
    E --> F[配置专业 Agent prompts]
    F --> G[接入 planning-with-files]
    G --> H[开启 AgentToAgent 测试]
    H --> I[构建 agent-eval Skill]
    I --> J[用反馈驱动持续迭代]

最小目录结构可以这样开始：

workspace/
├── SOUL.md
├── AGENTS.md
├── USER.md
├── MEMORY.md
├── HEARTBEAT.md
├── agents/
│   └── prompts/
│       ├── risk-warning.md
│       ├── morning-brief.md
│       └── growth-agent.md
├── memory/
│   ├── feedback/
│   ├── evolution/
│   └── daily/
└── skills/
    └── agent-eval/

专属智能体的核心不是“一次回答正确”，而是能把任务、反馈、记忆和规则连成闭环。OpenClaw 提供了适合搭建这种闭环的基础设施：身份文件负责稳定人格和边界，Memory 负责长期上下文，Heartbeat 负责主动检查，Cron 负责确定性调度，Skill 和 SubAgent 负责专业能力扩展。

当这些模块组合起来，Agent 就不再只是一个临时问答窗口，而是一个能长期协作、持续校准、逐步贴合用户工作流的个人生产力系统。