1.Agent1.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工具执行后会返回结果这个结果就是 ObservationAgent 再根据 Observation 判断任务是否完成。 如果任务还没完成就继续下一轮“思考、行动、观察、修正”如果任务完成就跳出循环生成最终答案。、 User Input ↓ 理解任务 / 构建上下文 ↓ 进入 Agent Loop ↓ Reasoning思考当前要做什么 ↓ Action选择并调用工具 ↓ Observation接收工具返回结果 ↓ 判断任务是否完成 ↓ 未完成继续下一轮循环 已完成输出最终答案1.6 ReAct 和 Agent LoopReAct 思考 → 行动 → 观察 Agent Loop多轮 ReAct直到任务完成1.7 Agent 的评价标准核心评价维度有 6 个1\. 任务完成率是否真正完成用户目标 2. 准确性理解、判断和结果是否正确 3. 稳定性多轮执行是否可靠是否容易跑偏 4. 安全可控性高风险操作是否受限制是否可追踪 5. 效率与成本响应时间、执行步数、Token 和接口成本是否可接受 6. 用户体验交互是否顺畅失败时是否解释清楚面试回答版我评价 Agent 不会只看它回答得像不像人而是看它能不能完成真实任务。 主要从任务完成率、准确性、稳定性、安全可控性、效率成本和用户体验几个方面评估。 一个好的 Agent应该能稳定完成目标结果正确过程可控成本可接受并且用户用起来清晰可靠。1.8HarnessHarness 更像模型运行外壳负责在模型调用前把系统 Prompt、用户任务、Memory、RAG 结果、工具 schema、权限规则和环境信息装配成最终 Context让模型在正确的信息和规则下工作。2.RAGRAG 在 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 / 4Btext-embedding-3-large / small (Obge-m31\. 语言场景中文、英文、多语言 2. 向量维度维度越高表达能力可能越强但存储和检索成本也更高 3. 检索效果看 RecallK、MRR、命中率 4. 成本和延迟在线调用还是本地部署 5. 与业务适配是否能理解业务术语、工具描述、代码、文档优先选择和业务语料匹配的 embedding 模型比如中文业务文档优先选择中文或多语言 embedding 模型。如果是企业内部 RAG还要关注部署成本、响应延迟、向量维度、是否支持批量 embedding以及后续能否做增量更新。向量数据库 Milvus PostgreSQLpgvector, Elasticsearch存储时不仅要存储原内容也要存储元数据 向量pgvector 和 Milvus 怎么选对比点pgvectorMilvus适合场景中小规模、业务系统集成大规模、高并发向量检索优点和 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 用于计算 RecallK、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 rate2.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.MemoryAgent Memory 1. 会话记忆 2. 工作记忆 3. 短期记忆 / 最近记忆 4. 长期记忆 5. 用户画像记忆 6. 业务知识记忆 / 项目记忆1.工作记忆工作记忆主要保存 1. 任务目标 2. 任务计划 3. 当前步骤 4. 已完成步骤 5. 待执行步骤 6. 中间结果 7. 关键工具结果摘要 8. 错误状态 9. 是否等待用户确认工作记忆存 Redis 或数据库。Redis 适合保存活跃任务状态比如agent:task:{task_id}:stateTTL 可以根据任务类型设置普通任务 13 天跨天开发任务 37 天。如果任务很重要还需要把关键 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.contextMemory 是外部存储的信息Context 是本轮真正喂给模型的信息。 Memory 只有经过检索、筛选、压缩后才会变成本轮上下文。Context 主要包含系统规则、用户/项目背景、当前任务状态、对话历史、工具结果、RAG 检索内容、文件/API 返回和错误日志等模型当前决策所需的信息。Context信息可能冲突所以应该有优先级系统规则 开发者规则 用户要求 项目规则 检索内容 历史对话context 压缩Context 压缩裁剪是为了解决长任务中上下文膨胀的问题。Agent 不应该无限保留所有对话、日志和工具结果而是要通过滑动窗口、摘要压缩、去重、相关性过滤、工具结果摘要等方式只保留当前目标、用户要求、任务进度、关键结论、错误状态和下一步计划。这样既能降低 token 成本也能避免模型被无关历史干扰。5.ToolsAgent 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.skillsSkill 更像一个“技能专家”或“任务方法包” 它把流程固定、重复性强的一类任务封装起来 让 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.MCPMCP 基于 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 menmory9.LLM1 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. 审计日志记录谁在什么时间做了什么操作本文转自 https://blog.csdn.net/2302_80272657/article/details/161344860?ops_request_miscrequest_idbiz_id102utm_termAgent%E5%BC%80%E5%8F%91utm_mediumdistribute.pc_search_result.none-task-blog-2allsobaiduweb~default-4-161344860.142v102pc_search_result_base4spm1018.2226.3001.4187如有侵权请联系删除。 Agent应用开发全攻略：从零构建智能任务执行系统_agent开发做什么的
1.Agent1.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工具执行后会返回结果这个结果就是 ObservationAgent 再根据 Observation 判断任务是否完成。 如果任务还没完成就继续下一轮“思考、行动、观察、修正”如果任务完成就跳出循环生成最终答案。、 User Input ↓ 理解任务 / 构建上下文 ↓ 进入 Agent Loop ↓ Reasoning思考当前要做什么 ↓ Action选择并调用工具 ↓ Observation接收工具返回结果 ↓ 判断任务是否完成 ↓ 未完成继续下一轮循环 已完成输出最终答案1.6 ReAct 和 Agent LoopReAct 思考 → 行动 → 观察 Agent Loop多轮 ReAct直到任务完成1.7 Agent 的评价标准核心评价维度有 6 个1\. 任务完成率是否真正完成用户目标 2. 准确性理解、判断和结果是否正确 3. 稳定性多轮执行是否可靠是否容易跑偏 4. 安全可控性高风险操作是否受限制是否可追踪 5. 效率与成本响应时间、执行步数、Token 和接口成本是否可接受 6. 用户体验交互是否顺畅失败时是否解释清楚面试回答版我评价 Agent 不会只看它回答得像不像人而是看它能不能完成真实任务。 主要从任务完成率、准确性、稳定性、安全可控性、效率成本和用户体验几个方面评估。 一个好的 Agent应该能稳定完成目标结果正确过程可控成本可接受并且用户用起来清晰可靠。1.8HarnessHarness 更像模型运行外壳负责在模型调用前把系统 Prompt、用户任务、Memory、RAG 结果、工具 schema、权限规则和环境信息装配成最终 Context让模型在正确的信息和规则下工作。2.RAGRAG 在 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 / 4Btext-embedding-3-large / small (Obge-m31\. 语言场景中文、英文、多语言 2. 向量维度维度越高表达能力可能越强但存储和检索成本也更高 3. 检索效果看 RecallK、MRR、命中率 4. 成本和延迟在线调用还是本地部署 5. 与业务适配是否能理解业务术语、工具描述、代码、文档优先选择和业务语料匹配的 embedding 模型比如中文业务文档优先选择中文或多语言 embedding 模型。如果是企业内部 RAG还要关注部署成本、响应延迟、向量维度、是否支持批量 embedding以及后续能否做增量更新。向量数据库 Milvus PostgreSQLpgvector, Elasticsearch存储时不仅要存储原内容也要存储元数据 向量pgvector 和 Milvus 怎么选对比点pgvectorMilvus适合场景中小规模、业务系统集成大规模、高并发向量检索优点和 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 用于计算 RecallK、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 rate2.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.MemoryAgent Memory 1. 会话记忆 2. 工作记忆 3. 短期记忆 / 最近记忆 4. 长期记忆 5. 用户画像记忆 6. 业务知识记忆 / 项目记忆1.工作记忆工作记忆主要保存 1. 任务目标 2. 任务计划 3. 当前步骤 4. 已完成步骤 5. 待执行步骤 6. 中间结果 7. 关键工具结果摘要 8. 错误状态 9. 是否等待用户确认工作记忆存 Redis 或数据库。Redis 适合保存活跃任务状态比如agent:task:{task_id}:stateTTL 可以根据任务类型设置普通任务 13 天跨天开发任务 37 天。如果任务很重要还需要把关键 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.contextMemory 是外部存储的信息Context 是本轮真正喂给模型的信息。 Memory 只有经过检索、筛选、压缩后才会变成本轮上下文。Context 主要包含系统规则、用户/项目背景、当前任务状态、对话历史、工具结果、RAG 检索内容、文件/API 返回和错误日志等模型当前决策所需的信息。Context信息可能冲突所以应该有优先级系统规则 开发者规则 用户要求 项目规则 检索内容 历史对话context 压缩Context 压缩裁剪是为了解决长任务中上下文膨胀的问题。Agent 不应该无限保留所有对话、日志和工具结果而是要通过滑动窗口、摘要压缩、去重、相关性过滤、工具结果摘要等方式只保留当前目标、用户要求、任务进度、关键结论、错误状态和下一步计划。这样既能降低 token 成本也能避免模型被无关历史干扰。5.ToolsAgent 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.skillsSkill 更像一个“技能专家”或“任务方法包” 它把流程固定、重复性强的一类任务封装起来 让 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.MCPMCP 基于 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 menmory9.LLM1 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. 审计日志记录谁在什么时间做了什么操作本文转自 https://blog.csdn.net/2302_80272657/article/details/161344860?ops_request_miscrequest_idbiz_id102utm_termAgent%E5%BC%80%E5%8F%91utm_mediumdistribute.pc_search_result.none-task-blog-2allsobaiduweb~default-4-161344860.142v102pc_search_result_base4spm1018.2226.3001.4187如有侵权请联系删除。