1.Agent

1.1 如何理解 Agent 应用开发

Agent 应用开发不是简单调用大模型 API，也不是只做一个聊天机器人，而是围绕大模型构建一个可以理解目标、拆解任务、调用工具、观察结果、持续修正并最终完成任务的系统。

一个完整的 Agent 一般包括：

Agent = LLM 决策核心 + Context 上下文 + Planner 任务规划 + Tools 工具执行 + RAG 知识补充 + Memory 状态记忆 + Permission 权限控制 + Evaluation 评测优化。

1.2 Agent 应用开发需要做哪些工作

1. 明确目标和边界
确定 Agent 要解决什么问题、适用什么场景、能做什么、不能做什么。
2. 设计整体架构
拆分核心模块：输入理解、上下文管理、任务规划、工具调用、记忆、安全、评测。
3. 设计 Prompt
约束 Agent 的角色、行为规则、工具使用方式和输出格式。
4. 设计上下文管理
组织当前任务需要的信息，例如用户输入、历史对话、任务状态、工具结果、检索内容。
5. 设计工具调用体系
定义工具描述、参数 Schema、权限等级、执行逻辑和返回结果
6. 设计任务执行流程
通过任务拆解和 Agent Loop，让 Agent 能“思考 → 调用工具 → 观察结果 → 继续修正”。
7. 设计 RAG 和 Memory
RAG 用来补充外部知识，Memory 用来保存任务状态、用户偏好和历史经验。
8. 设计安全和评测
控制高风险操作，处理异常，并通过任务完成率、工具调用准确率、响应时间等指标持续优化。
​
总结：
Agent 应用开发的核心，不是简单接入大模型，而是围绕大模型设计一套能理解任务、组织上下文、调用工具、持续执行、可控安全、可评测优化的完整系统。

1.3 从 0 设计一个 Agent

从 0 设计一个 Agent，我会先明确业务目标和任务边界，判断它是问答型、工具型还是流程型 Agent。
然后设计整体架构，包括输入理解、上下文构建、任务规划、工具调用、知识检索、Memory、权限控制和评测优化。
执行流程上，我会采用 ReAct + Agent Loop，让模型先分析任务，再决定是否调用工具，工具返回结果后继续观察和修正，直到任务完成。
最后通过任务完成率、工具调用准确率、响应时间、失败恢复能力和安全拦截率来评估效果。
​
​
一个完整 Agent 至少需要几个核心模块。
第一是意图理解模块，用来判断用户要做什么。
第二是上下文管理模块，用来组织当前任务需要的信息。
第三是任务规划模块，把复杂目标拆成步骤。
第四是工具调用模块，让 Agent 能执行真实动作。
第五是 RAG 模块，补充外部业务知识。
第六是 Memory 模块，保存任务状态和用户偏好。
第七是权限和安全模块，控制高风险操作。
最后是评测模块，用来持续优化 Agent 的效果。

1.4 Agent和Chatbot 的区别

我理解的 Agent 不是简单聊天机器人，而是围绕目标进行任务执行的系统。
 普通 Chatbot 主要基于上下文生成回答，而 Agent 除了回答问题，还能理解用户目标、拆解任务、调用工具、观察结果、持续修正，最终完成一个可验证的任务。
 所以 Agent 的核心不只是大模型，而是大模型加上工具调用、上下文管理、任务规划、记忆机制、权限控制和评测体系。

1.5 Agent 的执行流程是什么

Agent 的执行流程本质上是一个循环，不是模型一次性回答完就结束。用户输入任务后，Agent 会先理解用户意图，构建当前上下文，然后进入 Agent Loop。
在这个循环中，模型会先判断当前应该做什么，也就是 Reasoning；如果需要外部能力，就选择合适的工具执行，也就是 Action；工具执行后会返回结果，这个结果就是 Observation；Agent 再根据 Observation 判断任务是否完成。
如果任务还没完成，就继续下一轮“思考、行动、观察、修正”；如果任务完成，就跳出循环，生成最终答案。、
​
​
User Input
  ↓
理解任务 / 构建上下文
  ↓
进入 Agent Loop
  ↓
Reasoning：思考当前要做什么
  ↓
Action：选择并调用工具
  ↓
Observation：接收工具返回结果
  ↓
判断任务是否完成
  ↓
未完成：继续下一轮循环
已完成：输出最终答案

1.6 ReAct 和 Agent Loop

  ReAct：   思考 → 行动 → 观察
Agent Loop：多轮 ReAct，直到任务完成

1.7 Agent 的评价标准

核心评价维度有 6 个：

1. 任务完成率：是否真正完成用户目标
2. 准确性：理解、判断和结果是否正确
3. 稳定性：多轮执行是否可靠，是否容易跑偏
4. 安全可控性：高风险操作是否受限制，是否可追踪
5. 效率与成本：响应时间、执行步数、Token 和接口成本是否可接受
6. 用户体验：交互是否顺畅，失败时是否解释清楚

面试回答版

我评价 Agent 不会只看它回答得像不像人，而是看它能不能完成真实任务。 主要从任务完成率、准确性、稳定性、安全可控性、效率成本和用户体验几个方面评估。 一个好的 Agent，应该能稳定完成目标，结果正确，过程可控，成本可接受，并且用户用起来清晰可靠。

1.8Harness

Harness 更像模型运行外壳，负责在模型调用前把系统 Prompt、用户任务、Memory、RAG 结果、工具 schema、权限规则和环境信息装配成最终 Context，让模型在正确的信息和规则下工作。

2.RAG

  RAG 在 Agent 中负责外部知识补充，让 Agent 在回答或决策前先检索可靠资料  ，
解决模型知识不足、知识过时、不了解企业内部数据的问题
核心价值是降低幻觉，提高回答准确性、时效性和可追溯性
  在 Agent 中，RAG 不只用于问答，也可以辅助工具选择、任务规划、权限判断和上下文补充
基本流程：用户问题 → Query 理解/改写 → 检索相关知识 → 过滤/重排 → 上下文组装 → LLM 生成回答或决策 → 返回答案/调用工具

2.1数据接入与清洗

- 数据来源：文档、网页、数据库、工具说明、历史记录
- 数据解析：PDF、Word、Markdown、HTML、代码、表格
- 数据清洗：去重、去噪、格式统一、无效内容过滤
- 数据同步：全量导入、增量更新、定时刷新
​
对于文档类数据 如doc pdf等等 统一转md
表格类数据 处理

2.2 切片策略

常见切片策略主要有几类：
第一种是固定长度切片，按字符数或 token 数切，简单快速，但容易切断语义，所以通常会加 overlap 保留前后文。
第二种是标题/章节切片，适合 Markdown、技术文档、接口文档这类结构化资料，可以保留标题路径，方便溯源。
第三种是递归切片，先按标题切，太长再按段落、句子、token 继续切，是企业知识库里比较常用的工程方案。
第四种是语义切片，根据主题变化切分，语义完整度更高，但成本也更高，适合论文、长报告、高价值文档。
第五种是父子切片，用小 chunk 做检索，用大 chunk 提供上下文，解决小切片上下文不足、大切片检索不准的问题。
另外对于特殊数据，还会用问答对切片、表格切片、代码结构切片和工具卡片切片。比如 Agent 工具检索场景下，我会把完整工具说明作为工具卡片，保留功能、参数、权限、示例等信息，方便 Agent 判断是否调用工具。

Chunk 跨度问题

1. overlap 重叠切片
   每个 chunk 保留前后一定内容，避免语义断裂。

2. 父子切片
   小 chunk 用来检索，大 chunk 用来提供上下文。

3. 标题路径保留
   chunk metadata 里保留所属章节标题，帮助模型理解语境。

4. 邻近 chunk 补全
   召回某个 chunk 后，把前一个、后一个 chunk 一起带上。

5. 上下文重组
   不是只拼 TopK，而是按文档顺序、章节结构重新组织。

6. 多路召回
   original query、改写 query、关键词 query 一起召回，降低漏召回。

2.3 向量化与向量存储：

  切片只是把文档拆成可检索的小文本单元，但数据库无法直接理解文本语义。向量化是把每个 chunk 转成 embedding 向量，让语义相近的内容在向量空间中距离更近。这样用户提问时，也可以把问题向量化，然后通过相似度检索找到最相关的知识片段。  
 		维度（1536维)    768、1024、1536、3072 

入库时：对所有 chunk 做 embedding，存入向量数据库。 查询时：对用户问题做 embedding，然后去向量库做相似度检索。

向量库里不只是存 embedding，还要存 chunk 文本和 metadata。metadata 很重要，比如文档来源、页码、所属知识库、租户权限、chunk 顺序等，方便后续做过滤、权限控制、引用溯源和上下文拼接。

Embedding 模型:

Qwen3-Embedding-0.6B / 4B

text-embedding-3-large / small (O

bge-m3

1. 语言场景：中文、英文、多语言
2. 向量维度：维度越高表达能力可能越强，但存储和检索成本也更高
3. 检索效果：看 Recall@K、MRR、命中率
4. 成本和延迟：在线调用还是本地部署
5. 与业务适配：是否能理解业务术语、工具描述、代码、文档

优先选择和业务语料匹配的 embedding 模型，比如中文业务文档优先选择中文或多语言 embedding 模型。如果是企业内部 RAG，还要关注部署成本、响应延迟、向量维度、是否支持批量 embedding，以及后续能否做增量更新。

向量数据库 ： Milvus， PostgreSQL+pgvector, Elasticsearch

存储时不仅要存储原内容也要存储元数据 向量

pgvector 和 Milvus 怎么选？

对比点	pgvector	Milvus
适合场景	中小规模、业务系统集成	大规模、高并发向量检索
优点	和 PostgreSQL 集成简单，事务/权限/结构化数据方便	向量检索性能强，适合海量向量
缺点	超大规模检索性能有限	系统复杂度更高，需要单独维护
面试总结	适合业务系统快速落地	适合专业向量检索场景

项目数据量在百万级以内，并且业务数据本身就在 PostgreSQL 中，我倾向于用 pgvector，减少系统复杂度。 如果数据规模更大、检索 QPS 更高，或者需要专门优化向量检索性能，就更适合 Milvus 这类专业向量数据库。

2.4 query 改写

Query 理解与改写，是在真正检索前，对用户问题做预处理。
它的目标是把用户原始输入，转换成更适合检索系统理解的问题。

用户原始问题经常存在这些问题：

1. 太短：比如“怎么配置？”
2. 太口语化：比如“这个东西咋用？”
3. 有指代：比如“它支持哪些参数？”
4. 信息缺失：比如没有说明对象、工具名、文档范围
5. 表达和知识库不一致：用户说“大模型接入”，文档里写“模型供应商配置”
6. 多轮对话依赖上下文：必须结合历史消息才能理解

所以在 RAG 中，不能总是直接拿用户原始问题去向量检索，而是需要先做：

意图识别
问题补全
多轮指代消解
同义词扩展
Query 改写
original query + rewritten query 多路召回

问题补全主要依赖历史对话、当前任务状态、用户当前页面、选中的文档或工具对象。

为了避免补错，我不会只用补全后的 query，而是保留 original query 和 rewritten query 一起检索。如果补全错误，原始 query 仍然可以提供兜底召回。

我不会简单地用 rewritten query 替代 original query。 因为 Query 改写可能提高召回，也可能因为理解偏差导致检索方向跑偏。 所以更稳妥的做法是保留 original query，同时生成一个或多个 rewritten query，然后做多路召回。最后对召回结果去重、融合，再通过 rerank 精排。

意图识别

1. 先判断用户大概想干什么
   - 是想问知识？
   - 是想找某个工具？
   - 是想让我调用工具执行任务？
   - 是想问配置方法？
   - 是遇到报错想排查？
   - 是权限不够想知道原因？
   - 是接着上一轮继续追问？
   - 还是和业务无关的闲聊？

2. 判断方式不要只靠一种
   - 简单明确的问题，用规则判断就行
   - 比如看到“报错、失败、异常”，大概率是故障排查
   - 看到“帮我上传、创建、删除”，大概率是工具调用
   - 如果用户表达比较绕、上下文比较复杂，就交给 LLM 判断

3. 判断完以后，不只是给一个分类
   - 还要知道用户问的是哪个对象
   - 关键词有哪些
   - 要不要查知识库
   - 应该查哪个范围
   - 要不要调用工具
   - 要不要做权限校验
   - 操作有没有风险
   - 系统有多大把握判断正确

4. 如果系统不确定，就不要贸然执行
   - 可以保留多个可能方向一起检索
   - 可以先查资料再判断
   - 如果涉及删除、修改、授权、上传这类操作，要先让用户确认
   - 不确定时，宁可多问一句，也不要直接执行高风险动作
   
   
  

意图识别就是先判断用户到底想干什么：是问知识、找工具、调用工具、问配置、排查报错、问权限，还是继续追问。

实现上可以用“规则 + LLM”结合：简单明确的用规则判断，比如“报错/失败”偏故障排查，“上传/创建/删除”偏工具调用；复杂表达、多轮上下文、隐含意图再交给 LLM 判断。

判断结果最好结构化，包括：用户意图、目标对象、关键词、是否需要检索、是否需要调用工具、是否需要权限校验、风险等级和置信度。

如果系统不确定，尤其涉及删除、修改、授权等高风险操作，不能直接执行，要先确认或走权限校验。

改写方式

1. 问题补全
   补齐缺失对象、模块、上下文
2. 指代消解
   处理“它”“这个”“刚才那个”
3. 同义词扩展
   补充业务术语、别名、英文缩写
4. 关键词提取
   从长问题中提取核心检索词
5. 查询分解
   把复杂问题拆成多个子问题
6. 多 Query 生成
   original query + rewritten query 一起检索
7. HyDE
   先生成假设答案，再用假设答案检索
8. 结构化改写
   转成 task、target、constraints、retrieval_scope 等结构

总结

Query 理解与改写是 RAG 检索前的重要环节。

用户原始问题往往存在口语化、信息缺失、指代不清、多轮上下文依赖、业务术语不一致等问题，所以不能总是直接拿原问题去检索。

我会先做意图识别，判断用户是知识问答、工具查询、任务执行还是故障排查；然后做问题补全、多轮指代消解和同义词扩展，把问题改写成更适合检索的形式。

同时，为了避免改写跑偏，我不会用 rewritten query 完全替代 original query，而是保留 original query + rewritten query 一起做多路召回，再通过去重、融合和 rerank 排序。

这样既能提高召回率，又能降低 query 改写错误带来的风险。

2.5召回

召回策略的核心是先把可能相关的内容找出来。常见方式包括向量召回、关键词召回、标题召回、工具名召回、metadata 过滤和多路召回。

向量召回适合语义匹配，关键词召回适合工具名、参数名、错误码等精确匹配，标题召回适合结构化文档，工具名召回适合 Agent 工具选择，metadata 过滤用于权限、租户、知识库范围控制。

召回率主要和 Query 质量、切片质量、Embedding 模型、检索方式、metadata 设计、TopK 设置和数据质量有关。工程上通常会用 Query 改写、混合检索、多路召回、合理切片和 rerank 来提升整体效果。

召回失败和兜底策略

首先按问题类型区分：低风险通用问题，可以结合模型通用能力回答，但要说明不确定；业务知识问题，必须基于 RAG 检索依据回答；工具执行类问题，如果上下文不足，需要先追问补全信息；高风险操作，比如删除、授权、支付等，必须经过用户确认和权限校验。

然后按召回置信度处理：

1. 高置信度：直接回答  
当 TopK 相似度、rerank 分数较高，多个 chunk 指向同一答案，并且命中标题、关键词、工具名或核心字段时，说明召回结果可靠，可以直接基于知识库回答，并给出来源或依据。

2. 中置信度：谨慎回答 + 引导确认  
当召回内容相关但不完全匹配，可能缺少对象、版本或具体场景时，可以先给出一个可能答案，同时引导用户确认。ToC 场景下不要直接打断用户，而是用“我理解你可能是在问……”的方式降低沟通成本。

3. 低置信度：不硬答，先追问或扩大召回  
当 TopK 分数低、召回内容不相关、用户表达过短或指代不清时，不要让模型编答案。应该先扩大召回，仍然不确定时追问一个关键问题，并给出选项，比如让用户选择是在登录、支付、上传文件还是其他功能中遇到问题。

总结来说，ToC 场景下的兜底策略是：低风险可谨慎回答，业务问题必须有依据，执行类问题先补全，高风险操作必须确认；召回结果则按高、中、低置信度分别采取直接回答、谨慎确认、不硬答追问的策略。

2.6混合检索

混合检索就是把向量检索和关键词检索结合起来。向量检索擅长语义匹配，BM25 擅长关键词和精确字段匹配。

在 Agent 项目里，工具名、参数名、接口名、错误码、配置项都非常依赖精确匹配；而用户的自然语言问题又需要语义理解，所以只用一种检索方式都不够稳定。

工程上一般是向量召回一批、BM25 召回一批，然后去重、融合，再通过 rerank 精排，最终选择最相关的内容进入上下文。

2.7 Rerank 重排

Rerank 的核心作用是：召回阶段先尽量找全，重排阶段再把最相关的内容排到前面。

Rerank 会不会增加延迟？

会增加一定延迟，因为 rerank 要对 query 和多个候选 chunk 逐一计算相关性。

优化方式：

1. 控制召回 TopN 数量
2. 只对去重后的候选 rerank
3. 对高频 query 缓存 rerank 结果
4. 简单问题可以跳过 rerank
5. 使用轻量 rerank 模型或规则排序兜底

如果没有专门的 rerank 模型，可以先用规则做轻量重排，比如综合向量相似度、关键词命中、标题命中、时间权重和来源可信度。 虽然不如专门 rerank 模型准确，但可以作为工程兜底方案。

TopN 和 TopK 怎么设置？

TopN：召回阶段候选数量，可以稍微大一些，比如 Top20 / Top50。
TopK：最终放入上下文的数量，要更小，比如 Top5 / Top8。

面试回答：

TopN 太小容易漏掉正确内容，TopN 太大会增加 rerank 成本和噪声。

TopK 太小可能信息不够，TopK 太大又会占用上下文窗口，引入无关内容。

所以一般先召回较多候选，再通过 rerank 精排，最后只把最相关的少量 chunk 放进上下文。

2.8 上下文组装

上下文组装发生在召回和 rerank 之后、LLM 生成之前。

它不是简单拼接 chunk，而是要做去重、排序、父子 chunk 补全、token 控制和来源引用。

核心目标是把最相关、最完整、最可靠的内容交给大模型，从而提高回答准确率，降低幻觉。

上下文窗口这么长，为什么还需要 RAG？直接把文档全塞进去不行吗

成本太高 费token
注意力容易被稀释
权限控制问题，不同级别的用户得到的内容应该是不一样的

2.9 评估

1. 准备一批标准问题
   来自真实用户问题、FAQ、业务高频问题、历史工单。
2. 给每个问题标注标准答案
   用于判断最终回答是否正确。
3. 标注正确文档或正确 chunk
   用于计算 Recall@K、MRR、Hit Rate。
4. 覆盖不同类型问题
   配置类、故障排查类、权限类、工具调用类、概念解释类。
5. 做版本对比
   比如：
   只向量检索 vs 混合检索
   无 rerank vs 有 rerank
   不同 chunk size
   不同 embedding 模型

swe评测

1. 准备真实项目代码仓库
2. 给 Agent issue 描述
3. Agent 分析仓库并生成 patch
4. 把 patch 应用到仓库
5. 在 Docker 隔离环境中运行测试
6. 如果测试通过，认为该 issue 被 resolved
7. 统计 resolved rate

2.10 知识图谱

知识图谱是一种用图结构组织知识的方式，核心由实体、关系、属性和来源证据组成。

实体是业务对象，比如工具、用户、权限、文档、参数；
关系是实体之间的连接，比如属于、依赖、调用、需要权限；
属性是补充信息，比如描述、状态、置信度、来源文档。

它的核心价值是把零散知识结构化，方便做关系查询、多跳推理和可解释问答。

构建知识图谱

一般分为五步：

1. 定义 schema：确定有哪些实体类型和关系类型。
2. 数据接入：接入文档、数据库、API 文档、工具说明、权限表等。
3. 实体抽取：从文本或结构化数据中抽取 Tool、API、参数、权限等实体。
4. 关系抽取：抽取实体之间的依赖、调用、属于、需要参数等关系。
5. 存储入库：写入 Neo4j 或用关系型数据库的 entity/relation 表存储。

GraphRAG / 知识图谱增强 RAG 是：

用户问题
 ↓
识别问题中的实体
 ↓
查知识图谱中的关系
 ↓
同时检索相关原文 chunk
 ↓
把图谱关系 + 原文证据一起给 LLM
 ↓
生成回答

存储

主要存四类内容：

1. 实体：业务对象，比如 Tool、API、用户、角色、权限、文档、错误码。
2. 关系：实体之间的连接，比如依赖、调用、属于、需要参数、需要权限。
3. 属性：实体或关系的补充信息，比如描述、状态、风险等级、更新时间。
4. 证据：这条关系来自哪个文档、哪个 chunk、哪段原文，方便溯源。

两者结合打造出更好的rag

语义线：query → embedding → 向量库 → 相关文本 chunk 关系线：query → 实体识别 → 知识图谱 → 实体关系路径

3.Memory

Agent Memory =
1. 会话记忆
2. 工作记忆
3. 短期记忆 / 最近记忆
4. 长期记忆
5. 用户画像记忆
6. 业务知识记忆 / 项目记忆

1.工作记忆

工作记忆主要保存：

1. 任务目标
2. 任务计划
3. 当前步骤
4. 已完成步骤
5. 待执行步骤
6. 中间结果
7. 关键工具结果摘要
8. 错误状态
9. 是否等待用户确认

工作记忆存 Redis 或数据库。Redis 适合保存活跃任务状态，比如 agent:task:{task_id}:state，TTL 可以根据任务类型设置，普通任务 1～3 天，跨天开发任务 3～7 天。如果任务很重要，还需要把关键 task_state 同步落数据库。

一个会话里可以有多个 task_id，所以不能只靠 conversation_id 判断当前任务。我会在 conversation 中维护 active_task_id，用户说“继续当前任务”时，系统根据 task_id 或 active_task_id 读取对应工作记忆，而不是让大模型猜。

2.会话记忆

会话记忆存储的是当前会话中已经发生过的上下文信息，包括前文对话、用户意图、Agent 回复、工具调用记录、工具返回结果，以及本轮会话中已使用过的 Skill / MCP 调用过程。
而系统提示词、可用工具列表、Skill/MCP 的完整定义，更偏向上下文组装内容，不完全等同于会话记忆。

原始聊天记录完整存 message 表，用于展示和审计；会话摘要 summary 用于模型上下文恢复，两者作用不同。

用户和 Agent 的完整聊天记录会持久化到数据库，用于前端展示、历史追溯和审计；但模型推理时不会每次都读取全部历史，而是根据当前任务只组装最近几轮消息、会话摘要、关键工具结果和当前任务状态。

为了降低 token 成本、增强模型注意力，会话记忆需要压缩。压缩条件可以结合轮数和 token 阈值，比如超过 10 轮对话，或者上下文超过 6000 token，就把早期内容压缩成 summary。同时压缩时不能丢失关键状态，比如用户目标、重要约束、工具结果、实体 ID、当前任务进度和待确认事项。工具需结构化存储

用户画像是长期记忆的一部分，主要保存用户长期稳定、对后续服务有价值的信息，用于让 Agent 更好地理解用户是谁、目标是什么、偏好什么。

用户画像主要保存：

1. 用户基本信息
2. 用户长期目标
3. 用户长期偏好
4. 用户专业方向
5. 用户常用项目背景
6. 用户常用输出风格
7. 用户知识基础 / 能力阶段
8. 用户历史高频需求
9. 用户明确要求记住的信息

注意事项：

1. 不要把临时偏好写入用户画像
2. 不要记录敏感隐私信息
3. 用户画像要支持查看、修改、删除
4. 画像冲突时，以用户最新明确表达为准
5. 用户画像不会全部塞进 Prompt，只注入当前任务相关部分

3.长期记忆

存储内容

长期记忆主要保存用户画像、项目背景、历史决策、业务规则/流程，以及可复用的经验和知识结论。

存储方式

1. 数据库
存结构化长期记忆，是主存储。
例如：用户偏好、长期目标、项目背景、历史决策、更新时间、来源、重要性评分。
2. 向量库
存非结构化长期摘要，用于语义召回。
例如：项目背景总结、经验总结、高价值问答结论。
3. Redis
只做缓存，不作为长期记忆主存储。
4. Markdown / 文件
适合项目级规则、开发规范、团队约定等可人工维护的信息。

目标

1. 让 Agent 长期理解用户
不用每次重新介绍用户目标、偏好和背景。

2. 提升个性化回答
根据用户长期偏好调整回答风格和内容重点。

3. 复用历史经验和决策
把过去确认过的方案、规则和流程用于后续任务。

4. 降低重复沟通成本
减少用户反复说明项目背景、输出要求和使用习惯。

5. 保持长期一致性
让 Agent 在不同会话中保持相对稳定的理解和行为。

用户画像是长期记忆的一部分，主要保存用户长期稳定、对后续服务有价值的信息，用于让 Agent 更好地理解用户是谁、目标是什么、偏好什么。

用户画像主要保存：

1. 用户基本信息
2. 用户长期目标
3. 用户长期偏好
4. 用户专业方向
5. 用户常用项目背景
6. 用户常用输出风格
7. 用户知识基础 / 能力阶段
8. 用户历史高频需求
9. 用户明确要求记住的信息

注意事项：

1. 不要把临时偏好写入用户画像
2. 不要记录敏感隐私信息
3. 用户画像要支持查看、修改、删除
4. 画像冲突时，以用户最新明确表达为准
5. 用户画像不会全部塞进 Prompt，只注入当前任务相关部分

4. 业务记忆 / 项目记忆

业务知识记忆主要保存外部知识和项目规则，比如：

1. 产品文档
2. 业务规则
3. 接口说明
4. 工具说明
5. 项目规范
6. 代码架构说明
7. FAQ
8. 权限规则
9. MCP / Tool / Skill 描述

存储方式：

结构化规则 → 数据库
文档原文 → 对象存储 / Markdown
语义检索 → 向量库
关键词检索 → Elasticsearch / OpenSearch
项目级规则 → AGENTS.md / CLAUDE.md / Memory.md

作用：

让 Agent 不只依赖模型通用知识，而是能够基于项目和业务资料进行回答、决策和工具调用。

4.context

Memory 是外部存储的信息，Context 是本轮真正喂给模型的信息。 Memory 只有经过检索、筛选、压缩后，才会变成本轮上下文。

Context 主要包含系统规则、用户/项目背景、当前任务状态、对话历史、工具结果、RAG 检索内容、文件/API 返回和错误日志等模型当前决策所需的信息。

Context信息可能冲突，所以应该有优先级

系统规则 > 开发者规则 > 用户要求 > 项目规则 > 检索内容 > 历史对话

context 压缩

Context 压缩裁剪是为了解决长任务中上下文膨胀的问题。Agent 不应该无限保留所有对话、日志和工具结果，而是要通过滑动窗口、摘要压缩、去重、相关性过滤、工具结果摘要等方式，只保留当前目标、用户要求、任务进度、关键结论、错误状态和下一步计划。这样既能降低 token 成本，也能避免模型被无关历史干扰。

5.Tools

Agent Tools 是 Agent 的外部执行能力封装。

LLM 本身只负责理解意图、分析上下文、规划步骤、选择工具和生成参数；真正的执行动作，例如查数据库、调接口、读写文件、搜索知识库、发送消息、执行代码，都应该交给 Tools 完成

一个标准 Tool 通常包括：

1. name：工具名称
2. description：工具描述
3. input_schema：输入参数结构
4. output_schema：输出结构
5. permission：权限与风险等级
6. executor：真实执行逻辑
7. error_handler：异常处理
8. metadata：分类、版本、标签、适用场景

一个标准 Tool 通常包括工具名、工具描述、输入参数 schema、输出结构、权限规则、执行函数和异常处理。开发工具时，我会强调单一职责、清晰命名、准确描述、结构化参数、结果可控、权限校验和可观测性。

模型不会直接执行工具，而是生成 tool_call / tool_use 请求。真正的执行由 Agent Runtime 或 Tool Runtime 完成，包括参数校验、权限校验、工具调用、异常处理和结果回填

工具存放上下文.

1. Tool Registry 统一注册所有工具
2. 上下文中放工具简要信息
3. LLM 根据简要信息选择候选工具
4. Runtime 按需加载完整 schema
5. LLM 生成参数
6. Runtime 校验并执行

生产级 Agent 通常不是把所有工具完整暴露，而是通过 封装简要信息到工具列表，把轻量工具元数据放入上下文，完整参数和执行逻辑按需加载。

设计一个工具系统

通过Tool Interface 统一工具规范，每个工具都包含名称、描述、输入输出 schema、风险等级、权限规则和执行方法。然后通过 Tool Registry 统一注册和管理工具，工具少时可以直接暴露 schema，工具多时只暴露元数据或 search_tools 入口，按需加载完整工具信息

真正执行时，由 Tool Runtime 接收模型生成的 tool_call，先校验工具是否存在、参数是否合法、用户是否有权限，以及是否属于高风险操作。只读工具可以直接执行，写入或删除等高风险工具必须二次确认。

工具执行后，Runtime 会把结果结构化、摘要化、脱敏后回填给模型；失败时返回统一错误结构。最后通过日志和监控记录调用用户、工具名、参数摘要、耗时、成功率和错误码，用于排查问题、安全审计和后续优化

6.skills

Skill 更像一个“技能专家”或“任务方法包”，
它把流程固定、重复性强的一类任务封装起来，
让 Agent 在遇到类似任务时按固定步骤、规则、模板和脚本执行。

Skill 通常以目录形式存在，
包括
my-skill/
  SKILL.md
  scripts/
  templates/
  resources/
核心文件是 SKILL.md。
SKILL.md 一般由两部分组成：
1. YAML frontmatter：写 name、description、allowedTools 等元数据；
2. Markdown 正文：写执行流程、规则、注意事项、示例、脚本使用方式等。


Skill 的加载通常采用渐进式披露：启动时只加载名称和描述等轻量信息，
当任务命中某个 Skill 时，再按需加载完整说明、模板、资源和脚本，
避免一次性占用过多上下文。

Skill 中的 scripts 用来存放当前 Skill 专属的辅助脚本，
比如数据清洗、格式转换、图表生成、评测执行等。
Agent 可以按照 SKILL.md 的说明调用这些脚本，
但脚本执行仍然需要经过 Runtime 的参数校验、权限校验和安全控制。

简单说，Skill 不是单个工具，而是一套可复用的任务经验包；
它告诉 Agent 面对某类任务时应该怎么做、用哪些工具、按什么流程执行。

7.MCP

MCP 基于 JSON-RPC 协议，本质上是一套标准化接入规范。
它把不同来源的工具、数据源和服务统一封装成 MCP Server，
让 Agent 可以通过 MCP Client 以统一方式发现和调用外部能力

MCP Server 通常可以暴露三类能力：
Tools、Resources 和 Prompts。
Tools 是可执行动作，比如查数据库、调 API；
Resources 是可读取的上下文数据，比如文件、日志、数据库 schema；
Prompts 是可复用的提示词模板或任务流程

传输方式常见有 stdio、SSE 和 HTTP。
stdio 适合本地 MCP Server，比如 IDE、本地文件系统、本地脚本；
SSE 是早期远程通信方式，适合服务端流式推送；
HTTP 更适合现代远程和企业级 MCP Server，可以通过 HTTP POST/GET 通信，并在需要时结合 SSE 做流式返回。

8.prompt

系统 Prompt > 开发者规则 > 工具/权限规则 > 用户 Prompt > 检索内容 > 历史对话

Prompt 可以分成系统 Prompt 和用户 Prompt。系统 Prompt 是 Agent 的长期规则层，主要定义 Agent 的角色、能力边界、安全规范、工具调用原则和输出格式；用户 Prompt 是当前任务层，表达用户这一轮具体想让 Agent 做什么，以及格式、范围、语气等要求。

二者的关系是系统 Prompt 决定 Agent 怎么工作，用户 Prompt 决定当前要完成什么任务。执行时系统 Prompt 优先级更高，用户要求不能突破系统规则。比如用户要求执行高风险操作，也必须经过系统层定义的权限校验和确认机制。

角色 + 任务目标 + 背景信息 + 具体要求 + 输出格式 + 限制条件 + 示例

你是一个【角色】。

我现在要完成【任务目标】，
背景是【背景信息】。

请按照以下要求处理：
1. 【要求一】
2. 【要求二】
3. 【要求三】

输出格式：
1. 【结构一】
2. 【结构二】
3. 【结构三】

限制条件：
- 【限制一】
- 【限制二】

下面是内容：
【粘贴内容】

Prompt 可以做成分层架构。最上层是总指挥 Prompt，负责定义 Agent 的角色、目标、安全边界、工具调用原则和任务拆解方式；下层是子 Agent 或 Skill Prompt，负责某个具体任务的执行流程和输出格式。

总指挥关注全局，决定做什么、怎么拆、交给谁做、哪些操作需要权限确认；下属 Prompt 关注局部，按照固定步骤完成日志分析、代码审查、RAG 检索、数据处理等子任务。

这样做的好处是职责清晰、上下文更干净、复杂任务更稳定，也方便权限控制和结果汇总。简单说，总指挥负责调度和边界，下属负责专业执行。

归纳与联系

prompt context menmory

9.LLM

1 LLM介绍

在 Agent 中，LLM 更像是“大脑”或“决策核心”。 它主要负责理解用户意图、分析当前上下文、判断下一步动作、决定是否调用工具、生成工具参数，以及根据工具返回结果继续推理。 但 LLM 本身不应该直接负责所有执行，真正的执行动作应该交给工具、接口、数据库、文件系统等外部模块完成。

概括一下

LLM：负责想清楚要做什么
Tools：负责真正去做
Agent：负责把“想”和“做”组织成完整流程

2 LLM主要功能

理解用户意图
分析上下文
判断任务是否需要拆解
决定下一步动作
选择是否调用工具
生成工具调用参数
根据观察结果继续推理
生成最终回答

3 强弱LLM 的选择

强模型适合放在 Agent 的核心决策层，负责理解复杂任务、拆解步骤、选择工具、处理异常和生成最终结果。它的优势是推理能力强、上下文理解好、工具调用更稳定，但成本和延迟更高。

弱模型适合做辅助型子任务，比如分类、摘要、抽取、格式化和路由。它的优势是便宜、响应快，适合高频调用，但不适合复杂规划、多步推理和高风险决策。

对于复杂任务，不建议频繁切换模型。因为复杂任务依赖连续上下文、稳定推理和一致的任务状态，不同模型之间理解能力和输出风格不一致，频繁切换容易造成上下文丢失、规划断层和执行偏差。 所以比较稳妥的做法是：强模型负责主决策链路，弱模型只负责边缘辅助任务，在效果、成本和稳定性之间取得平衡。

4 模型怎么知道该调用哪个工具

工具一般会以结构化描述的形式提供给模型，包括工具名称、功能描述、参数 schema、使用条件和限制。LLM 会根据用户任务和工具描述进行语义匹配，判断哪个工具最适合当前任务。 在工程实现上，通常会结合工具描述、函数签名、JSON Schema、权限约束、RAG 检索工具列表等方式，让模型更稳定地选择工具。

可以概括为：

工具名称：告诉模型这个工具叫什么
工具描述：告诉模型这个工具能做什么
参数 Schema：告诉模型需要哪些参数
权限约束：告诉模型哪些操作能不能做
调用示例：帮助模型学习正确使用方式

10.权限控制

1 为什么 Agent 需要权限校验

是防止 Agent 因模型误判、幻觉或恶意输入，执行高风险、越权或不可逆操作。

2 权限校验主要校验什么

1. 工具权限：这个 Agent 是否允许调用该工具
2. 资源权限：能不能访问这个文件、接口、数据库、用户数据
3. 操作权限：是读操作、写操作、删除操作，还是执行命令
4. 参数权限：参数是否越界、是否访问敏感路径、是否包含危险命令
5. 用户授权：当前用户是否明确同意执行该操作

3 权限校验放在哪里

1. System Prompt：告诉模型哪些事不能做
2. Tool Schema：限制工具参数格式
3. Tool Runtime：执行前做真实权限校验
4. 业务后端：做最终用户权限校验
5. 审计日志：记录谁在什么时间做了什么操作