Agent 学习笔记

一、四个核心概念速览

术语	全称	一句话解释
Harness	控制框架	驾驭LLM这匹"马"的缰绳，管理记忆、检索、工具调用
Loop	代理循环	Agent反复调用工具直到任务完成的执行机制
LLM Ops	大模型运维	追踪、评估、诊断、修复Agent运行的持续迭代流程
Eval	评估系统	用LLM作裁判，给Agent的每次运行质量打分

这四个概念之所以流行，是因为它们都极其简单——正是这些简单组件，构成了全球最复杂的AI智能体架构。

---

二、一次 AI Agent 运行到底是什么？

基本模型：输入 → 工作记忆 → LLM → 输出

用户提示 (User Prompt)
当前对话历史 (Chat History)   →  工作记忆 / Context RAM  →  LLM (GPT/Claude)  →  Reply
系统提示 (System Prompt)

• 整个过程是临时的（Ephemeral）：Agent运行期间的一切都在上下文窗口中，运行结束后不自动保留
• LLM本身不了解"你"：它知道人类全部公开知识，但不知道你是谁、你的系统怎么运行、你的历史数据是什么
• 这就是为什么需要额外的记忆系统和Harness框架来补全这一切

---

三、记忆系统：三种类型详解

Agent的记忆分为三层，各司其职：

1. 程序记忆（Procedural Memory）

• 存储内容：Agent应该"如何行动"的指令
• 载体：文件、文本、Markdown格式的技能说明（Skill.md）
• 类比：给马套上马具，告诉它跑快还是跑慢
• 例子：你是一个客服Agent，回复时始终保持礼貌，退款超过100元需要主管审批

2. 语义记忆（Semantic Memory）

• 存储内容：持久性事实（Durable Facts）、用户画像
• 载体：向量数据库（Vector Store）
• 特点：不随对话结束而消失，是需要Agent长期记住的事实
• 例子：用户叫Sean，是连续创业者，偏好简洁的回答风格
• 更新方式：手动输入，或由系统自动从对话中提炼（Distill into Facts）

3. 情景记忆（Episodic Memory）

• 存储内容：带时间戳的历史事件序列、过去的对话记录
• 载体：SQL数据库 + 向量数据库的组合
• 特点：有时间维度，可按时间顺序检索
• 例子：用户上次申请退款是3周前，问题是产品破损，最终得到解决

记忆系统对比

类型	存什么	存在哪	检索方式
程序记忆	行为指令、技能	文件系统 / S3	直接加载到提示词
语义记忆	持久事实、用户画像	向量数据库	RAG语义搜索
情景记忆	历史事件、过去对话	SQL + 向量数据库	SQL查最近 + RAG查相关

---

四、Harness：控制框架

核心比喻：LLM是一匹马，Harness是缰绳

LLM本质上是在预测下一个词的概率分布——这意味着它天然存在随机性。
在解决具体业务问题时，我们不希望这匹"马"随机乱跑，而是需要驾驭它走正确的路。

Harness框架的作用：

• 将三种记忆正确地注入工作记忆（Context RAM）
• 控制工具调用的范围和频率
• 定义系统的行为边界
• 减少LLM输出的随机性，提升确定性

常见Harness工具：

• LangGraph — 基于图结构的Agent流程控制
• LangChain — 链式调用框架
• Pydantic — 结构化数据验证，约束LLM输出格式

没有好的Harness，就像骑着一匹不受控的马上战场——你可能被甩出去，也可能随机到达一个你完全不想去的地方。

---

五、记忆的存储与更新机制

数据库存储

• 三种记忆都需要持久化到数据库：AWS S3、Google Cloud、Azure等云存储
• 每次Agent回复后，将对话内容保存到情景记忆数据库（Save the messages）
• 后续相关问题到来时，从数据库检索并注入工作记忆

摘要Agent（Summarizer Agent）

当情景记忆数据量过大时（例如电商平台有百万用户），不可能每次都加载全部历史。

解决方案：触发式记忆整合

1. 设定阈值（如每积累N次新对话后触发一次）
2. 启动一个廉价的摘要Agent（使用更便宜的开源模型，因为上下文窗口大、成本高）
3. 将大量情景记忆提炼（Distill）为精炼的事实
4. 存入语义记忆，供快速检索

情景记忆 (大量原始对话)↓  [每N次对话触发]
摘要Agent (廉价模型)↓  [提炼事实]
语义记忆 (精炼事实，检索更快)

---

六、检索机制：RAG vs SQL

检索是Harness的核心环节，不同类型的记忆使用不同的检索策略。

RAG（检索增强生成）

• 适用场景：语义记忆 + 情景记忆中的相关性检索
• 工作原理：将文本转为向量，通过Top-K相似度搜索找到最相关的内容
• 例子：从2000条历史投诉中，找到与"产品质量问题且未解决"最相关的20条

SQL查询

• 适用场景：情景记忆中的时间性检索
• 工作原理：按时间顺序、日期范围、用户ID等结构化字段精确查询
• 例子：查询某客户最近10次对话记录

两者结合使用

实际系统中往往需要同时使用：

• 先用SQL按时间筛选范围（WHERE date > '2024-01-01'）
• 再用RAG在结果中做语义匹配（找最相关的那些）

核心原则：你不需要把2000条消息全塞进上下文，只需要找到其中最相关的20条——这就是RAG存在的意义。

---

七、工具调用（Tool Calls）

Agent不仅能读取记忆，还能调用外部工具执行真实操作：

常见工具类型举例：

• 安排会议（Schedule Meeting）
• 读写CRM系统（Salesforce, HubSpot）
• 获取支付信息（Stripe, 支付宝）
• 发送邮件、推送通知

为什么会产生"循环"？

Agent每次调用工具都会获得返回结果，这个结果会触发下一步思考，从而可能产生新的工具调用：

用户提问→ Agent思考：需要先查CRM→ 调用工具：查CRM → 返回"30起投诉，8起未赔偿"→ Agent思考：需要给这8位安排跟进→ 调用工具：安排会议 / 触发退款→ 任务完成 → 输出Reply

如果没有终止机制，Agent可能无限循环下去——这就是Loop工程要解决的问题。

---

八、Loop工程：循环控制与护栏

什么是Loop（循环）？

Loop是Agent在完成任务过程中，反复调用工具、思考、再调用工具的执行模式。
它是Harness的一部分，目的是在给LLM足够自主权的同时，确保它按预期方式运行。

终止循环的护栏（End Loop Guardrails）

护栏决定Agent什么时候该停下来返回结果，常见策略：

1. 任务完成判断：Agent在规划时，判断当前结果是否已经足够回答用户的问题
2. 用户确认节点：在关键步骤暂停，向用户确认（例如"要为这8位客户申请退款吗？"）
3. 最大迭代次数：设置工具调用上限，防止无限循环
4. 外部通知触发：通过推送通知让用户介入（避免Agent卡住等待而浪费时间）

Claude Code Hooks 实例

一个实际的Loop工程例子：在使用Claude Code编写代码时，

• 设置一个Hook，当Claude Code需要权限授权时，不是让它卡住等待
• 而是发送系统通知到你的电脑/手机
• 你在看视频30分钟后回来，看到通知，授权，循环继续

这就是通过循环工程，让Agent既能自主执行，又不会因为等待权限而白白浪费时间。

---

九、LLM Ops：大模型运维体系

为什么需要LLM Ops？

Harness解决了"怎么让Agent跑起来"的问题，但还有另一个关键问题：
你怎么知道它跑得好不好？出了问题怎么修复？

LLM Ops就是Agent系统的持续质量保证体系，包含四个环节：

追踪（Trace）→ 评估（Eval）→ 诊断（Diagnose）→ 修复/发布（Gate → Release）

完整LLM Ops流程

1. 追踪（Trace）

• 每次Agent运行产生一条Trace（一次完整的用户输入→输出过程）
• 记录的内容：
  • 用户问了什么
  • 进行了哪些RAG检索
  • 调用了哪些工具、调用几次
  • 各步骤耗时（延迟）
  • 消耗了多少Token
• 工具：Langfuse、LangSmith

2. 评估（Eval）

评估回答两个问题：

① Was it good?（质量好吗？）

• 使用LLM-as-a-Judge（用大模型当裁判）
• 给系统表现打分
• 例：会议是否被正确安排了？退款是否触发了？

② Was it healthy?（系统健康吗？）

• 追踪Token消耗、延迟、错误率等指标
• 可以用确定性代码实现（硬规则），也可以用AI判断

3. 诊断（Diagnose）

当发现问题时，深入分析"哪里出了问题，为什么"：

• 延迟20秒 vs 2毫秒？→ 可能是某个工具调用太慢，或上下文窗口太大
• 会议从未被触发？→ 可能是工具调用逻辑有误，或RAG检索结果不对
• 将Trace数据输入Claude/GPT进行深度分析

4. 门控 & 发布（Gate & Release）

评估通过？✅ 是 → 直接部署修复（更新提示词/模型配置/工具参数）❌ 否 → 修复Bug → 重新运行 → 重新追踪 → 重新评估 → 再次判断

可以修复/调整的内容：

• 系统提示词（System Prompt）
• 模型配置（温度、模型版本）
• 工具参数
• RAG检索参数（Top-K数量等）

修复后，改进的配置反馈回Harness框架，完成一次迭代闭环。

---

十、完整系统全景图解读

结合视频中的架构图，完整系统由左右两大部分组成：

左侧：Harness + Loop（Agent执行层）

用户提示 + 对话历史 + 系统提示↓工作记忆（Context RAM）↓  ↑（RAG/SQL检索）[程序记忆] [语义记忆] [情景记忆]↓LLM-Q&A Agent（GPT/Claude）↕ 工具调用循环（Loop）[工具：安排会议/CRM/支付]↓（护栏触发终止）Reply 输出↓保存消息 → 情景记忆数据库

右侧：LLM Ops（质量保障层）

每次Reply↓Trace（Langfuse/LangSmith）↓Eval（质量评分 + 健康监控）↓Diagnose（问题诊断）↓Gate（是否通过？）↓ 通过            ↓ 不通过Release            修复Bug → 重新运行
（更新Prompt/Config）↓改进的System Prompt + Config → 反馈回Harness

---

十一、关键知识总结

Agent系统的本质

Harness + Loop + LLM Ops = 一个能够自主进化、持续改进的AI Agent系统

最重要的几个认知

1. LLM是概率引擎，天然有随机性——Harness存在的意义就是减少这种随机性，让输出更确定、更可控

2. 记忆不是天生的，需要工程化——三种记忆类型需要配合不同的数据库和检索策略

3. 循环不是Bug，是Feature——Loop工程让Agent能够完成复杂的多步骤任务，关键是知道何时终止

4. 不追踪就无法改进——LLM Ops的核心是"可观测性"，没有Trace就没有诊断，没有诊断就没有改进

5. 修复不等于重写——大多数时候，问题可以通过调整提示词、RAG参数或模型配置来解决，无需修改代码

技术栈参考

层级	工具选择
Harness框架	LangGraph、LangChain、Pydantic
向量数据库	Pinecone、Weaviate、Chroma
情景记忆	PostgreSQL、SQLite + 向量扩展
追踪工具	Langfuse、LangSmith
云存储	AWS S3、Google Cloud Storage、Azure Blob

本文内容参考于视频一口气学会AI Agent Harness/Loop工程/LLM Ops/Eval评估系统