一、Agent是什么？

1.原理

LLM - large language model

无状态的机器 y  = f(x)

注意力机制-计算邻居间的相似度

预测下一个token

2.为什么要agent？以及解决问题方法

核心目的是一是增加LLM的能力，二是规范LLM的边界。

LLM没有记忆：

增加记忆

上下文容量和注意力缺失

长中短短期记忆的方案 - 摘要压缩、存数据库、md

RAG

具有失效，数据不完备：

实时搜索web

RAG

接下来说说RAG原理：

全称检索增强生成。核心步骤：1.文档解析切块向量化存向量数据库 2.query向量化语义和关键词混合检索召回 RRF 融合 rerank 精排，把top k输出给llm

claude code 用的检索方式是 grep + find + read

过程问题：

1.用户输入模糊！

LLM提取重点改写，在进行搜索

2.文档切割成chunk，块的大小，破坏上下文，检索不准！

RAG的关注点：

准-@Recall召回率 + @Precision精确率

时间

token成本

元信息记录文档信息，就像我之前的父子分块策略一样

输出单一：

工具调用-tool calling

接下来说说Tools和MCP原理：

Tools：根据tool名字和tool参数调用工具，调用对应的函数返回输出.

MCP：根据统一的标准协议进行工具调用，分为本地通信stdio和远程Streamable协议，主要对接外部的服务.

基于概率预测，天然有不准确或者幻觉的缺陷：

自检 ReAct、Reflection

SandBox沙盒

（题外话，目前有很多方案关于agent的治理架构，如harness、hevit但未来发展还是未知数，不要局限于现在的技术，要有场景思考）

二、规范边界

1.Harness（马具）

为什么要加Harness？

LLM是基于预测的模型，会出现随机性、幻觉；无记忆 y=f(x)；添加tools-实际的行动

操作：

1、物理手段：建立sandbox + 监测记录和反馈 + 必要的阶段加入人工审核

2、精神手段：定义Agent loop（思考模式）+ 记忆管理

这种框架 沙箱+记忆 + 思考模式 称为 Harness，等于 程序 + 工作流 + 思考模式

2.思考范式

ReAct：边规划边执行

如用户输入：今天天气怎么样，跟之前相比，有更适合去徒步吗？

LLM先调用天气too和参数今天以及地点，在发现资料不够需要再次调用工具去查之前的天气和参数，在结合思考输出。走一步算一步。

缺点：有可能进入死循环（不断换参数）> Harness，会消耗更多token导致成本上升；全局意识，缺少长期规划

Plan and Execute：规划执行

以上面的天气例子：先获得今天天气，再获得昨天天气，总结徒步最好天气，对比天气。

场景：大任务、有效监控

Reflection：反思

在llm里写好system prompt，定义标准对不对，有两种方案：1是给反思的内容给llm，2是把反思内容给记忆下次修正。

那什么用这三种思考方式呢？

ReAct(Reasoning and act)：后一步重点依赖前一步的结果的任务，如数据搜索、debug A -> debug B；短任务

Plan and Execute：明显可拆分步骤的任务，如并行任务-长任务等。

Reflection：无论用哪种范式都可以用反思去修正。

三、多Agent

出发点：LLM记忆问题：上下文的长度限制；长下文太长了会导致注意力扩散问题；

多Agent解决的问题：记忆分离-注意力集中+上下文窗口，充分使用；并行执行tools，加快效率

框架：

管理者-工作者模式：分配不同任务给子agent，汇总结果；管理者用Plan and Execute范式，子agent用ReAct范式。

无管理者模式：子agent内部协调

四、agent 评估Evaluation

AB测试，从小到大

1.成功输出

2.正确与否 correctness

3.可信度 reliable

4.质量

5.速度

6.token usage

五、Agent的记忆Memory

为什么需要记忆？

LLM没有记忆，但是实际应用中Agent涉及多轮交互，把有价值的信息存起来，下次执行任务时取出来放进上下文，让Agent基于这些信息继续推理。

一般上下文 200k token左右

方案：

1.数据库 -> 公司文件库 RAG

历史消息记忆（元信息）分块存入数据库进行检索；query取转向量，数据库比对。

LLM -> agent 采用 ReAct 分析用户query 生成更合适的方案如什么关键词搜索！recall文档后再进行reason判断是否够，不够继续重新定义query进行搜索。

2.md

如Claude code的md记忆架构

MEMORY.md-长期记忆-用户偏好+简介，把topic轻量化写进这里面

结构化：

# profile 简介

# user perference 用户偏好

# constraint 约束

维护：加载的时候结构化出来json格式，生成Dict；最后重新渲染成md。

pre_define key 固定

LLM key

Topic层：主题文件配置如具体经验、调试模式

Transcript层：存的原生数据，记录这一轮发生了什么

六、skills

1.结构组成

.md文件，里面包含元数据name + description

示例：

name: get_weather

description:获取本地今天天气

# 获取本地今天天气

## 步骤

1.先用get_location

2.用get_date

3.get_weather 获取天气

##    输出格式

{

地点：xx

日期：2026.01.01

天气：xx

}

2.加载策略

按需加载：扫描skill目录读取每个SKILL.md 顶部metadata，把每个 name和description注册到Skill列表，query提出任务，模型根据任务和描述判断用哪个skill，触发对应skill，读取完整SKILL.md正文，按里面的步骤执行；实际上把skills包装成system prompt 传给llm

热更新：不重启服务，运行中重新加载变化内容- 可以用定时扫描：每隔几秒检查文件修改时间